[dm-crypt] No key available for this passphrase

Sebastian r4p.t0x at googlemail.com
Sat Jan 26 11:15:16 CET 2013


Sorry to bother again, but I'm trying to understand the whole processing of
keys/password/masterkey within the LUKS mechanism when unlocking/decrypting the
disk.

I'm trying to understand it by using fugure 5 in this paper:
http://wiki.cryptsetup.googlecode.com/git/LUKS-standard/on-disk-format.pdf


Lets use my header as example (it's useless now anyways...)

LUKS header information for /dev/sda2

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 2056
MK bits:        256
MK digest:      53 44 c2 4d b0 9e c5 73 ef fa d7 12 4f dd f0 75 64 3b 88 ad 
MK salt:        50 5f a9 69 21 6e 21 ac db 09 bd 79 b0 9b 9b 1e 
                14 2a 5d e4 46 2b 4d 9c 49 e3 9f 7d f9 d7 64 84 
MK iterations:  10
UUID:           b89fe8ad-3aea-4f27-9448-06e75fd8a05a

Key Slot 0: ENABLED
        Iterations:             75899
        Salt:                   2d 2b 66 4c 57 eb ff e7 7f 63 14 8f c5 3b 6b aa 
                                38 53 2d 52 52 b6 d9 cc 84 b0 1a 11 bd cf 88 70 
        Key material offset:    8
        AF stripes:             4000




So when I enter the Password, it is processed by PBKDF2:

pwdPBKDF2ed = PBKDF2 ( 
entered password, 
Salt for Key Slot 0 as given by header (2d 2b 66 4c ....), 
iteration-count (=75899), 
MasterKey lenth (256 bits) 
)

Am I correct about MK-lenght = MK bits?


Then it reads the encrypted key aka payload:

encryptedKey = data from "payload offset (sectors*size)" * "key leghth" 
-> offset 8 sectors * 512 byte = 4096 = 0x1000
key lenght = 4000 * original key lenght of the master key (256bit)
that would be 128000 byte -> address 0x1000 + 128 000 byte = address 0x20400
correct?

so "encryptedKey" = data from 0x1000 - 0x20400 (including 512 of crap from
0x10000 in my case...)



now we put those 2 together and add some magic:

splitKey = decrypt (
use aes/cbc-essiv:sha256 algorithm,
pwd-PBKDF2ed calculated first by entered password,
encrypted key data read from 0x1000 - 0x20400,
"encrypted" ???  
)

what is "encrypted"? The comment "content lenght" for it confuses me even more...


With this splitKey we now create a checksum:
masterKeyCandidate = AFmerge (
splitKey (ft. magic(TM) ),
masterKeyLength (256),
ks-stripes (4000)
)

And process the checksum to compare with the MasterkeyChecksum from header:
PBKDF2 (
masterKeyCandidate,
phdr.mk-digest-salt ( 50 5f a9 69 21 ....),
phdr.mk-digest-iter (10),
LUKS_DIGEST_SIZE (20)
)

if this processed Checksum is equal to the MK digest from header (53 44 c2 4d b0
9e c5 73 ef fa d7 12 4f dd f0 75 64 3b 88 ad ) the partition gets unlocked.



Oh, and just hypothetical:

If I would write a script to replace the broken 512 bits of the "encryptedKey"
sequential from 00 00 00...  up to FF FF FF...  values, we would have 512^255
possible combinations.
Lets assume we can try 1000 combinations per second in one process (I have no
idea whether this is realistic) and also assume we have a 8-core system
available for running 8 processes, starting at different offsets, it would still
take 2,896966378463778741e+679 years.... (OK, some factor for mathematical
probability when starting at 8 offsets will be added, but i think it's
negligible...) 
Well, until theres a way to travel near speed of light to make use of time
dilatation, the data is gone forever ;)

So i'm still grep-ing the disks of my network-fileserver, maybe i had another
backup of the header... Lesson learned, new drives for the fileserver ordered so
i can backup more complete and more often...



More information about the dm-crypt mailing list