0

I am about to go travelling to some high risk countries where corrupt officials will most likely try to go through my laptop and external HDD.

I am using Linux Mint and LUKS. Could someone please tell me based on these pictures whether I have encrypted them both properly, this includes the cache (or whatever it is called) as I would hate to leak information. I know that /boot can stay unencrypted.

Picture of my laptop's HDD: Internal pic

Picture of external HDD after I entered password: External pic

I can provide more information upon request.

Thank you

4
  • 3
    You should probably instead just leave the data you care about at home and install a fresh copy of whatever OS you're using before and after the trip.
    – user
    Jan 2 '20 at 20:43
  • There isn't enough information here to tell. We don't know what cipher, mode, or hash you are using, or your PBKDF2 iteration count.
    – forest
    Jan 4 '20 at 4:15
  • @user I know but the country I am going to have poor internet, furthermore I need those files for my job. Jan 4 '20 at 15:36
  • @forest How do I provide that information? Jan 4 '20 at 15:36
1

IMHO, your LUKS setup is OK:

  • On internal drive, you only have /boot that is unciphered. The rest of the volume consists in a stack of LUKS + LVM, so it's ok.

  • On external drive, everything looks encrypted.

Just a small remark: 700MiB is a lot for a /boot partition....

6
  • I don't think 700 MiB is necessarily a lot for the boot partition, depending on your setup. If you keep old kernels and have a bloated initramfs, you can quickly start using up quite a bit of storage.
    – forest
    Jan 4 '20 at 4:13
  • Usually, one only keep the n and n-1 kernel.... keep every old kernel is a bit useless.... Nevertheless, every body is free to do what he want with his /boot partition :)
    – binarym
    Jan 4 '20 at 10:37
  • For people who compile their own kernels, keeping old ones can be very useful for tracking down bugs.
    – forest
    Jan 4 '20 at 10:39
  • False. Only the .config is needed for this purpose. Eventually the patches applied or the whole kernel source tree (wich already contains the binary) can be usefull ... but this is usually stored under /usr/src. A standalone kernel binary would be very painful for debugging...
    – binarym
    Jan 4 '20 at 10:43
  • Well you need the config as well as any seed files (e.g. for RANDSTRUCT), and that's only if you're doing a deterministic build. If you aren't, then things like compiler version can affect the resulting binary. I've had kernel bugs caused by compiler bugs that would not have been reproducible if I didn't have the original binary (unless I also kept track of the compiler version, its libraries, etc).
    – forest
    Jan 4 '20 at 10:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.