2
$\begingroup$

It's my understanding that LUKS encrypts data by using a randomly-generated master-key, which is then itself stored encrypted by my passphrase. When I want to access the data, I use my passphrase to decrypt the master-key, which is then used to decrypt the data.

Question: Is it possible to have LUKS just encrypt the data by using the randomly-generated master-key (can I specify the size?), but then instead of encrypting this with my passphrase and storing it, just tell me the master-key (which I will memorize or write on a piece of paper). When I'll want to access the data, I will use the masterkey to decrypt it.

As a side note, let me explain why I think that this would be more secure than the usual procedure: when cryptographically sanitizing a USB or non self-encrypting SSD drive (or changing the LUKS password), it's my understanding that the master-key encrypted by the old password will always be physically present on the drive, because digital sanitization is hard to achieve for USB and SSD. The randomly-generated master-key would then be recoverable by either guessing the old password, or by brute-forcing it.

| improve this question | |
$\endgroup$
  • $\begingroup$ Luks uses PBKDF2 and the password limit is 512 chars. Therefore, you only need to keep a good random password $\endgroup$ – kelalaka Jan 27 '19 at 23:19
  • $\begingroup$ kelalaka: how is this related to my question? $\endgroup$ – user65411 Jan 28 '19 at 0:51
  • $\begingroup$ PBKDF2 generates the Key Encryption Key (KEK) for decryption the key used for encryption and decryption of the drive. If you use a good random password with good size, then the attack point will not be your passwords anymore, they can attack for the key itself by brute-forcing all possible keys. For the old master key; If the key is not existent there, they can try all possible AES keys. The only problem that you states is sanitization, I think they already solved that (need verification) that new key exactly overrides the old key. $\endgroup$ – kelalaka Jan 28 '19 at 7:31
  • 1
    $\begingroup$ @kelalaka They have solved it inasmuch as they expand the key into 4 KiB of space and wipe that space when deleting a keyslot, with the idea being that all it takes is a few bytes to be destroyed for the erasure to be successful. Naturally it's only effective on storage media that does not use wear leveling. $\endgroup$ – forest Jan 28 '19 at 7:34
  • 1
    $\begingroup$ It is possible to dump the master key (with the luksDump <device> command and the --dump-master-key option). It should be possible also to kill all the key slots. You can even dump the luksHeader and store it where you prefer. But, as @forest commented, you could simply add a new key slot (with a new password) and kill the old one (with the compromised password). Of course, the master key will be remain the same (You need re-format and encrypt to change master key) $\endgroup$ – ddddavidee Jan 28 '19 at 9:29
2
$\begingroup$

Normally, you don't provide the master key directly. The master key is protected by a key encryption key. All storage encryption systems work this way.

There is no way to change the master key without re-encrypting all the data. Using a master key that's stored in a form wrapped by a key encryption key allows changing the key encryption key without re-encrypting the data. It also allows having multiple key encryption keys.

You propose not using a key encryption key and using the master key directly. This is always weaker than using a key encryption key, unless the mechanism for processing the key encryption is flawed. In your proposal, you propose to remember the master key (128 bits or more). If the master key is ever compromised, you've lost. Instead, suppose that you remember a passphrase with as much entropy as the master key (a random passphrase chosen in a space of 128 bits or more). Then you are protected against all the attacks that you would be protected against if you'd remembered the master key, and more.

The attack you're concerned about is someone finding a copy of the master key encrypted with an old, weak passphrase. If you want to protect against this attack, don't use a weak passphrase! If you only use a strong passphrase then there won't be anything lying around that was made by a weak passphrase. Storing the master key encrypted with a passphrase that's as strong as the master key itself is not a risk. The passphrase can even be weaker because it goes through a strengthening function (PBKDF2 or Argon2).

| improve this answer | |
$\endgroup$
0
$\begingroup$

LUKS is a standard which governs how the keys are stored on disk, so the pedantic exact answer to your question is no.

If however you question were "can I use linux disk encryption, and provide the entire key myself rather than using LUKS to store the key" the answer is absolutely, yes.

the search term you need is "dm-crypt"

the command to load the keys and map the device would look something like

dmsetup create name-of-red-device --table "0 $(blockdev --getsz name-of-black-device` crypt twofish-xts-plain64 YOURKEYINHEXGOESHERE 0 name-of-black-device 0"

where name-of-black-device is your encrypted real block device (eg /dev/sda3) and name-of-red-device is your de-crypted virtual block device (eg /dev/mapper/crypt1) obviously you can change the encryption type &c.

| improve this answer | |
$\endgroup$

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.