I secure my USB drives with LUKS using Format “password protect volume” EXT4. Mostly the information is just my college work. I’ve lost USB drives in the past, so my question is how secure is LUKS beyond the average password cracker? I tend to use complex passwords.
My understanding is that the encryption mechanism itself is unlikely to be broken in the near term and that generally for this purpose, and most purposes, password complexity is less important than password length. I take this to mean lux is as secure as the password and the longer the password the more secure the encrypted data.
I would expect length to be the primary determining factor for how long it would take to brute force the password of said USB drive with the goal being that by the time access is successful the content is no longer valuable. Personally, if the drive is lost I would treat that data as compromised and react accordingly. I would also consider how long the data would be useful for and if that time period is extremely long I’d consider configuring MFA for the encrypted drive (yubikey-luks is one option, I don’t know if the Librem key can also be used for something similar or not but I expect it is likely possible and I’m sure there are other options as well).
@Kyle_Rankin likely has more precise guidance he can point to as he is more well versed in data security than myself, as I’m sure others on here are as well.
Hope this is useful.
3 Likes
I’ve always accepted a lost drive compromised, thank you for your response, it was very useful.
That’s the second time you’ve helped me @Kyle_Rankin tyvm sir.
1 Like
To make brute-forcing take more time you might want to look into the PBKDF settings for cryptsetup luksFormat:
-i, --iter-time=msecs PBKDF iteration time for LUKS (in ms)
--pbkdf=STRING PBKDF algorithm (for LUKS2): argon2i, argon2id, pbkdf2
--pbkdf-memory=kilobytes PBKDF memory cost limit
--pbkdf-parallel=threads PBKDF parallel cost
--pbkdf-force-iterations=LONG PBKDF iterations cost (forced, disables benchmark)
PBKDF is the key stretching function that converts the password to the encryption key that is used internally. By increasing the iteration time, you directly increases the time to check every password. However, this also means it takes more time to decrypt your volume if you enter the right password.
Changing the algorithm can be useful if you’re worried about specific kind of attacks using CPU/GPU/ASICs I don’t really know which one is best for what.
1 Like
You are probably using the default SHA-256 encryption if you are using LUKS. SHA-256 is used by Bitcoin and doesn’t have any vulnerabilities that are easy to exploit (whereas MD5 and SHA-1 are easier to attack).
If you are paranoid you can use SHA-512, but if you aren’t the target of a spy agency, I honestly don’t see the point, because if you use complex passwords, it isn’t easy to crack SHA-256. It is better to focus on the other aspects of your security, like whether anyone has had access to your PC, so they could use the USB drive without needing to enter a password.
Heh yes I have some doubt if the threat model here includes 0-day cryptoanalysis attacks on international standard encryption algorithms 
1 Like
That right there is better than most people!
That will be enough of a deterrent to the average person who finds your lost USB drive. They will see that it won’t mount by default and will just reformat the volume and use it themselves. (On the other hand, this may reduce the chances that an honest finder will return your flash drive to you, which is a can of worms.)
Beyond that, you want to force an attacker to use a brute force attack rather than a dictionary attack. So avoid using any common dictionary word or any alteration of a common dictionary word. (Your location may determine what is meant by a common dictionary word.)
A long random meaningless password is best.
That’s true but
a) there is a sweet spot that significantly slows down a brute force attack against the plaintext password while not significantly slowing down the initial access to the encrypted volume
b) the sweet spot moves over time i.e. you must be prepared to change the KDF parameters over time (to slow it down).
I think argon2 is considered superior to PBKDF2 if you are worried about GPU/ASIC attacks - but that might be outside the threat model for @victorhugo
1 Like
what is your general experience with ext4 formatted usb-thumb-drives ? did you ever lose data or have you experienced ANY corrupted important data due to PURELY passage of time ? is it reliable as an external file-system ? i’ve been under the impression that people generally use ext4 only on internal drives … my experience with ext4 on external devices hasn’t been great (not reliable) that’s why i interjected … sorry if this bothers anyone
@victorhugo did not specify whether the USB drive is a USB flash drive (thumb drive) or some other type of external USB drive (portable or desktop drive, whether magnetic or solid state).
i agree. that’s a distinction - I - made 
not really that important if i stop and think about it …
ext4 works fine as a file system for USB drives
Some people recommend formatting with -O ^journal to disable the journal as this causes less writes and might result in increased lifetime. I don’t think encryption makes any difference in this.
That said, please always make backups. Storage devices can and do fail at any time.
1 Like
Encryption does make a difference, although it isn’t clear that @reC was asking specifically about encryption or just ext4 on USB flash drives generally.
To further reduce writes, you can use the noatime option (if that is compatible with your use case).
As you say, it doesn’t matter whether the MTBF is 3 years or 100 years, you should always do backups - and not only because of failure of the underlying drive.
I had a Linux system booted off a USB flash drive (actual install, not Live Boot), running normally for a few years, without ill-effect. However we shouldn’t kid ourselves that a $5 flash drive has as good a flash memory controller etc. as a fully-fledged SSD.
1 Like
that’s good to know. i’m not knowledgeable enough in this department to make the distinction as you so clearly are able to …
I wonder in what way? I would expect the access pattern should be the same, as well as the bandwidth. Maybe unless the encrypted blocks are larger and rounded up compared to normal disk blocks.
The main way is in the interaction between TRIM (discard) and full disk encryption. For maximum security you can’t use TRIM with FDE (because a zeroed block leaving the file system is not a zeroed block in the underlying encrypted disk - or at least you don’t want that).
Another way is in the interaction between compression and encryption if the SSD itself is doing compression and the host is doing encryption. (You always want the host to be doing encryption rather than relying on blackbox encryption in the drive.)
A third way could arise if the encryption mechanism uses larger encryption blocks than the underlying SSD (which typically has 4KiB storage blocks).
3 Likes
I would be slightly surprised if USB sticks support advanced features like TRIM and controller-side compression. But good points otherwise.
1 Like
all i know is that MOST usb-thumb-drives i’ve used under a GNU/Linux system so far have the option “Drive-Settings” greyed out by default under the hamburger menu in the GNOME-Disks GUI-front-end.
here is what it looks like when the drive is a S-ATA based SSD and how I have it configured (i use a UPS with my LMini)
I would hazard a guess that that is because those settings (in particular APM) are genuine SATA device settings and are not available when using a different native drive interface such as USB or, in my case (and also greyed out), NVMe.
1 Like