1

For LUKS devices I know that hashes are stored somehow in the partition header (I don't really know what this means). But I don't know how to print the hash value in this case.

For example in a standard unix system the user password hashes are stored in /etc/shadow. If I want to see a hash of a password I can just open this file and see it.

So, how can I extract the hash value of a LUKS device?

4

If it's about generic information regarding the LUKS header, try luksDump.

# cryptsetup luksDump /dev/loop0
LUKS header information for /dev/loop0

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      67 77 17 e9 43 cf b2 e1 f3 a0 e2 0b 7a a9 fa a1 cf d8 e0 76 
MK salt:        f1 6a 09 51 55 e8 af d2 11 b2 73 1c cc ae b5 15 
                9e e9 dc 84 a5 22 aa b1 b3 0c 7c db 23 59 9a 14 
MK iterations:  77625
UUID:           ec59d9ad-39f1-4d5c-af9e-b35f34847561

Key Slot 0: ENABLED
    Iterations:             311434
    Salt:                   ed 69 d7 9d 7a 39 1a 23 3f 38 64 15 3f 38 dd 5f 
                            90 1e ea 9f 5b 9f c3 59 f3 18 49 2f 9a 3f 4e c6 
    Key material offset:    8
    AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

If you're looking for the actual key, when you luksOpen it, dmsetup will show it.

# dmsetup table --showkeys
luksthing: 0 209711104 crypt aes-xts-plain64 c2349e71e00186c784a1d83917778fcaacb87382ea508aa41f6324f1e2f056eb 0 7:0 4096

This is not so much a hash as the actual key to open the device. If you have this, the LUKS password is no longer necessary:

# cryptsetup luksClose luksthing
# echo 0 209711104 crypt aes-xts-plain64 c2349e71e00186c784a1d83917778fcaacb87382ea508aa41f6324f1e2f056eb 0 7:0 4096 \
| dmsetup create luksthing
# file -s -L /dev/mapper/luksthing
/dev/mapper/luksthing: Linux rev 1.0 ext2 filesystem data, UUID=34fadafe-31cf-467d-84c0-c2d50bbcfcde (large files)

Which is why you have to reinstall/re-encrypt if your system is ever compromised. They have your encryption keys, regardless what your LUKS password(s) are.

  • Thanks especially for the interesting point about getting the key, I didn't know this but this is not what I want, I am looking for the hash. – student Nov 15 '13 at 21:46
  • You should clarify in your question then, what exactly it is you mean by hash. – frostschutz Nov 15 '13 at 21:57
  • Your reaction indicates that my current understanding of how LUKS works is incorrect. I will post another question about this and link it here. – student Nov 16 '13 at 8:48
  • Nice answer, +1. But I believe the original question in the OP still stands, if translated in these terms: where are the (one or more) copies of the encrypted master key stored? The TKS1 paper referred to by Gilles in the follow-up question is quite clear that the encrypted master key is retrieved from the key storage, then decrypted by means of the encryption key obtained via PBKDF2, and states several times it is located on the disk (besides, where else could it be)? I also presume it is hidden, but do you happen to know how and where? – MariusMatutiae Apr 11 '16 at 16:35
0

You can't extract the hash value because it isn't there.

When a user logs in, the operating system needs to have a reference copy of his password to compare against the password that the user enters. This is what is stored in /etc/shadow. If the entered password is identical to the reference password, the authentication succeeds. To make password recovery difficult, the system doesn't store the password but a hash of it (a slow, salted hash to make brute force attempts to guess the password more difficult).

Encryption works differently. The aim is to protect against an attacker who has access to the storage, so it must not be possible to extract the encryption key from what is stored on the device alone. Hence the key is not stored on the device, but constructed from information stored on the device combined with information supplied by the user. Typically, the key is generated from a salt stored on the device combined with a password supplied by the user. Again, to slow down brute force attempts, the process to combine those values must be slow, and the process uses a per-device value (the salt) in addition to the user's password so that the use of the same password doesn't lead to the same key. What you have on the device is basically only a salt, to be combined with the password to generate the key.

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.