> As far as I understand PBKDF2, the key without the salts is completely
> useless. As far as I can tell, both salts are generated in cryptsetup
This would seem to be the key question... I hope you're wrong, but
suspect you're right.
I spent the last couple hours stitching together a hybrid image from
various bits of a clean luks loopback device and my real device image,
using the phdr from the clean image, with mk-digest, mk-digest-salt,
and keyslot 0 salt from my real image patched in, and then everything
past byte 592 (key material + payload) from the real device. In other
words, just based on the hope that maybe the salt values from the real
device might somehow still be valid, despite evidence to the contrary.
The resulting image is recognized by luksDump as a valid luks device,
with correct-seeming values for all the cipher specs and parameters...
luksOpen'ing it prompts for a passphrase..... and then cryptsetup pegs
my cpu at 100%, and sits there with no output. Damn.
I would think that luksOpen would error out on failure, rather than
just sitting there eating cycles..... weird.
It's starting to sink in now that my data may be toast. This sucks.
> attack on two key-strength 256 bit random numbers would be needed to
> recover the data, even if the key material is intact. That would be
> infeasible.
Pardon my crypto-ignorance, but when you say 'infeasible', do you mean
NSA infeasible, or desktop class machine infeasible? Would, say, a
year or two of 8-core cpu time do any good?
On Mon, Nov 10, 2008 at 3:38 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote:
> Ok, here is a preliminary analysis. Note that I use "hex", not "hexdump"
> for the output, which gives better readability, as the data is stored
> in network byte order, i.e. big-endian by LUKS. This means with the "hex"
> output you can just read numbers left-to-right. Sorry for going over 80
> columns, the alternative is unprintables which confuse my terminal.
>
> First the part before the keyslots:
>
> Good LUKS header:
>
> 0x00000000: 4c 55 4b 53 ba be 00 01 - 61 65 73 00 00 00 00 00 LUKS<BA><BE>..aes.....
> 0x00000010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 0x00000020: 00 00 00 00 00 00 00 00 - 63 62 63 2d 65 73 73 69 ........cbc-essi
> 0x00000030: 76 3a 73 68 61 32 35 36 - 00 00 00 00 00 00 00 00 v:sha256........
> 0x00000040: 00 00 00 00 00 00 00 00 - 73 68 61 31 00 00 00 00 ........sha1....
> 0x00000050: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 0x00000060: 00 00 00 00 00 00 00 00 - 00 00 04 08 00 00 00 10 ................
> 0x00000070: 14 dd 4f b8 1f 42 a1 02 - 9a 93 ec ae bf 26 8d 7c ..O..B....<EC><AE>.&.|
> 0x00000080: 40 2e 6d 5c 4c ba 21 d8 - 31 94 dc 00 2c 0d 43 39 @.m\L.!.1...,.C9
> 0x00000090: bb 03 24 95 4f fe 97 97 - a0 2c 75 63 ea 92 cb a5 ..$.O....,uc..<CB><A5>
> 0x000000a0: 4d aa a0 1c 00 00 00 0a - 31 35 31 61 37 30 34 64 M.......151a704d
> 0x000000b0: 2d 34 36 33 36 2d 34 61 - 38 30 2d 39 34 61 66 2d -4636-4a80-94af-
> 0x000000c0: 63 32 61 34 65 61 62 66 - 36 38 31 63 00 00 00 00 c2a4eabf681c....
>
> Good GRUB bootsector:
>
> 0x00000000: eb 48 90 00 00 00 00 00 - 00 00 00 00 00 00 00 00 .H..............
> 0x00000010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 0x00000020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 0x00000030: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 03 02 ................
> 0x00000040: ff 00 00 20 01 00 00 00 - 00 02 fa 80 ca 80 ea 53 ... ...........S
> 0x00000050: 7c 00 00 31 c0 8e d8 8e - d0 bc 00 20 fb a0 40 7c |..1.<8E><D8>.<8E><D0>... ..@|
> 0x00000060: 3c ff 74 02 88 c2 52 be - 79 7d e8 34 01 f6 c2 80 <.t...R.y}.4.<F6><C2>.
> 0x00000070: 74 54 b4 41 bb aa 55 cd - 13 5a 52 72 49 81 fb 55 tT.A<BB><AA>U..ZRrI..U
> 0x00000080: aa 75 43 a0 41 7c 84 c0 - 75 05 83 e1 01 74 37 66 .uC.A|..u....t7f
> 0x00000090: 8b 4c 10 be 05 7c c6 44 - ff 01 66 8b 1e 44 7c c7 .L...|.D..f..D|.
> 0x000000a0: 04 10 00 c7 44 02 01 00 - 66 89 5c 08 c7 44 06 00 ....D...f.\..D..
> 0x000000b0: 70 66 31 c0 89 44 04 66 - 89 44 0c b4 42 cd 13 72 pf1..D.f.D..B..r
> 0x000000c0: 05 bb 00 70 eb 7d b4 08 - cd 13 73 0a f6 c2 80 0f ...p.}....s.<F6><C2>..
>
> The problem:
>
> 0x00000000: eb 48 90 53 ba be 00 01 - 61 65 73 00 00 00 00 00 .H.S<BA><BE>..aes.....
> 0x00000010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 0x00000020: 00 00 00 00 00 00 00 00 - 63 62 63 2d 65 73 73 69 ........cbc-essi
> 0x00000030: 76 3a 73 68 61 32 35 36 - 00 00 00 00 00 00 03 02 v:sha256........
> 0x00000040: ff 00 00 80 3d 3f 3a 01 - 00 08 fa 90 90 f6 c2 80 ....=?:......<F6><C2>.
> 0x00000050: 75 02 b2 80 ea 59 7c 00 - 00 31 c0 8e d8 8e d0 bc u....Y|..1.<8E><D8>.<8E><D0>
> 0x00000060: 00 20 fb a0 40 7c 3c ff - 74 02 88 c2 52 be 7f 7d . ..@|<.t...R..}
> 0x00000070: e8 34 01 f6 c2 80 74 54 - b4 41 bb aa 55 cd 13 5a .4.<F6><C2>.tT.A<BB><AA>U..Z
> 0x00000080: 52 72 49 81 fb 55 aa 75 - 43 a0 41 7c 84 c0 75 05 RrI..U.uC.A|..u.
> 0x00000090: 83 e1 01 74 37 66 8b 4c - 10 be 05 7c c6 44 ff 01 ...t7f.L...|.D..
> 0x000000a0: 66 8b 1e 44 7c c7 04 10 - 00 c7 44 02 01 00 66 89 f..D|.....D...f.
> 0x000000b0: 5c 08 c7 44 06 00 70 66 - 31 c0 89 44 04 66 89 44 \..D..pf1..D.f.D
> 0x000000c0: 0c b4 42 cd 13 72 05 bb - 00 70 eb 7d b4 08 cd 13 ..B..r...p.}....
>
> This looks very much like GRUB taking the original sectors, modifying
> only the bytes it needs, and thereby leaving parts of the LUKS header intact.
>
> Now for the rest of the problem:
>
> 0x000000d0: 73 0a f6 c2 80 0f 84 ea - 00 e9 8d 00 be 05 7c c6 s.<F6><C2>..........|.
> 0x000000e0: 44 ff 00 66 31 c0 88 f0 - 40 66 89 44 04 31 d2 88 D..f1...@xxxxxxx
> 0x000000f0: ca c1 e2 02 88 e8 88 f4 - 40 89 44 08 31 c0 88 d0 <CA><C1>......@.D.1..<D0>
> 0x00000100: c0 e8 02 66 89 04 66 a1 - 44 7c 66 31 d2 66 f7 34 ...f..f.D|f1.f.4
> 0x00000110: 88 54 0a 66 31 d2 66 f7 - 74 04 88 54 0b 89 44 0c .T.f1.f.t..T..D.
> 0x00000120: 3b 44 08 7d 3c 8a 54 0d - c0 e2 06 8a 4c 0a fe c1 ;D.}<.T.<C0><E2>..L.<FE><C1>
> 0x00000130: 08 d1 8a 6c 0c 5a 8a 74 - 0b bb 00 70 8e c3 31 db ...l.Z.t...p<8E><C3>.1<DB>
> 0x00000140: b8 01 02 cd 13 72 2a 8c - c3 8e 06 48 7c 60 1e b9 .....r*....H|`..
> 0x00000150: 00 01 8e db 31 f6 31 ff - fc f3 a5 1f 61 ff 26 42 ..<8E><DB>.1.1.<FC><F3>..a.&
> 0x00000160: 7c be 85 7d e8 40 00 eb - 0e be 8a 7d e8 38 00 eb |..}.@.....}.<8E><B8>..
> 0x00000170: 06 be 94 7d e8 30 00 be - 99 7d e8 2a 00 eb fe 47 ...}.0...}.*.<EB><FE>G
> 0x00000180: 52 55 42 20 00 47 65 6f - 6d 00 48 61 72 64 20 44 RUB .Geom.Hard D
> 0x00000190: 69 73 6b 00 52 65 61 64 - 00 20 45 72 72 6f 72 00 isk.Read. Error.
> 0x000001a0: bb 01 00 b4 0e cd 10 ac - 3c 00 75 f4 c3 00 00 00 ........<8E><BC>.u<F4><C3>..
> 0x000001b0: 00 00 00 00 00 00 00 00 - 00 00 02 08 00 00 0f a0 ................
> 0x000001c0: 00 00 de ad 00 00 00 00 - 00 00 00 00 00 00 00 00 ..<DE><AD>............
> 0x000001d0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 0x000001e0: 00 00 00 00 00 00 00 00 - 00 00 02 88 00 00 0f a0 ................
> 0x000001f0: 00 00 de ad 00 00 00 00 - 00 00 00 00 00 00 55 aa ..<DE><AD>..........U.
> 0x00000200: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 0x00000210: 00 00 00 00 00 00 00 00 - 00 00 03 08 00 00 0f a0 ................
> 0x00000220: 00 00 de ad 00 00 00 00 - 00 00 00 00 00 00 00 00 ..<DE><AD>............
> 0x00000230: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 0x00000240: 00 00 00 00 00 00 00 00 - 00 00 03 88 00 00 0f a0 ................
>
> ...
>
>
> This looks to me like GURB data until 0x1b0 and then remaining (unfortunately unused)
> LUKS keyslot descriptors, up to and including slot 8.
>
> After that ist continues in what sems to be random data:
>
> 0x00000250: 96 60 e2 85 e9 52 b4 cd - 82 d9 de 46 91 af 79 cd .`...R<B4><CD>.<D9><DE>F..y
> 0x00000260: ed 19 2e d8 38 dc 56 d9 - 2e cb fd 28 b2 e4 e6 79 ....8.V..<CB><FD>(<B2><E4>.y
> 0x00000270: 9e 9f f6 46 39 77 32 ec - 91 bd c1 83 72 62 9f dd ...F9w2..<BD><C1>.rb.<DD>
> 0x00000280: ea d9 7e cf 7b 64 ea 7c - 0c cb 6d e3 4c 77 ac f2 ..~.{d.|..m.Lw<AC><F2>
> 0x00000290: b6 cc 20 bb 2a 7d 83 ce - 4e 5e f7 cd 4f 0e 2d f7 <B6><CC> .*}..N^<F7><CD>O.
> ...
>
> I asumme this is leftover disk content from before the LUKS initialisation.
>
> Given that the key-mateial-offsets in the residue look like my reference
> all-default values, I would say there is a good change the key material
> for keyslot 0 still resides at offset 0x1000 - 0x2000. However, here the
> problem starts. While the key is probably still there, the 256 bit salt,
> stored in the keyslot, is not. Also the salt parameter for the master key
> (also 256 bit) is very likely missing as well as GRUB writes data in both
> areas.
>
> As far as I understand PBKDF2, the key without the salts is completely
> useless. As far as I can tell, both salts are generated in cryptsetup
> by a call to getRandom, which in turn uses /dev/urandom. This means
> the salts are of key-material quality, unless the random pool was really,
> really empty.
>
> Hmm. Keep in mind this is preliminary. If I have this righ, then an
> attack on two key-strength 256 bit random numbers would be needed to
> recover the data, even if the key material is intact. That would be
> infeasible.
>
> Arno
> --
> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx
> GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
> ----
> Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
>
> If it's in the news, don't worry about it. The very definition of
> "news" is "something that hardly ever happens." -- Bruce Schneier
>
> ---------------------------------------------------------------------
> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
> For additional commands, e-mail: dm-crypt-help@xxxxxxxx
>
>
--
Kevin Bowen
kevin@xxxxxxxx
---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx
