I want to encrypt external HDDs to be compatible with both Ubuntu and Windows, and passphrase-locked.
However, I don’t want the passphrase to be merely a step in unlocking keys that then unlock the volume. I’ve suffered catastrophic data loss from LUKS headers being corrupted or overwritten. But my passphrases are forever.
I know there may be good reasons why LUKS is more secure, but I won’t use it on any drive I might need to connect to Windows. Unless there’s a way to have a passphrase acting directly as the key, I’ll have to encrypt files individually, or not encrypt at all.
That is what cryptsetup --type plain does. But I am not sure how you are going to use it in Windows.
Also, no standard tools in Linux (like request to unlock newly inserted drive) will work because plain encrypted devices are not self-identifying. That is what LUKS is for - to know how to deal with the content.
If you want something else than encryption headers on the filesystem, you will have to resort to hardware encrypted disks… they have an additional chip for the encryption handling and usually use a fingerprint or a pin (with either fingerprint reader or keypad directly on the device) to decrypt…
Is it not possible to generate unique keys from a passphrase? I can easily make my passphrases 256 bits deep.
As I understand it, LUKS doesn’t generate unique keys from a particular passphrase. If it did, I could just try to regenerate them. Instead they are gone forever.
It seems everyone is more paranoid about passphrases being hacked, than headers corrupted. I am more paranoid about the latter. I want a method that directly translates a typed passphrase into the appropriate keys.
I have no problem manually mounting drives, and window 10’s virtual ubuntu might work with it.
”cryptsetup - - type plain” means the drive-stored keys are implemented by the “non-plain” encryption methods? All I need to do is avoid these methods?
Whether the plain method evades storing keys on the drive, basically. And you’re right, it does. Fairly simple from command line.
Now all that remains is to do it securely - the cryptsetup manpage warns about dangerous errors but doesn’t say what they are. I’m testing a small drive that I wiped, created a GPT partition on, used cryptsetup to create a map of that partition, and mkfs.ext4 to create the filesystem in that.
Apparently this resulted in encrypted superblocks; any search of the unmapped drive e.g. with dumpe2fs can’t find any superblocks, they’re only there on the mapped device. Is this a vulnerability, a sort of “Rosetta Stone” for forensic attack?
Which is true for any FDE solution like LUKS, BitLocker etc. If you want to see your filesystem before its container is decrypted you should be using native filesystem encryption (although chances to interoperate with Windows are even smaller).
It’s possible to backup the LUKS headers to independent storage medium, then you can always recover whats left on the disk. Needing backupheader+passphrase+corrupted disk. sudo cryptsetup luksHeaderBackup /dev/sdxy --header-backup-file=header.luks. To backup header from device sdxy. And sudo cryptsetup luksHeaderRestore /dev/sdxy --header-backup-file=header.luks To restore header from file header.luks to device sdxy.
don’t forget to save file header.luks outside of that LUKS volume
Edit: that won’t make the volume natively decryptable on Windows
Edit2: Veracrypt also has built in backup header at the end of the disk and additionally can create a header backup file from the GUI the same way as luks and cryptsetup.
However please note that Windows will happily “format” such device as it thinks it’s uninitialized. That will cause some data loss even when data that is still there can be recovered like from unencrypted disk. (after header restoration and just opening the volume without mounting the damaged filesystem)
