On 11/23/2009 02:45 PM, Roscoe wrote: > On Thu, Nov 19, 2009 at 5:41 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote: >> If I understand this correctly, this is the "iteration-count" >> parameter to PBKDF2. If so, then RFC 2898 recommends a minimum >> count of 1000 anyways. This is hovever not protection against >> a broken hash, as even a very weak hash should be extremely >> hard to break when iterated 10 times. The main purpose of this >> parameter is to make exhaustive search more expensive. I think >> this should definitely go up to 1000. > > I'd like to point out that this use of PBKDF2 is is not as a KDF but > as a hash function. The recommendations in the RFC 2898 will be from a > KDF perspective. The idea of someone doing an exhaustive search in the > LUKS mk context seems silly (RNG quality aside) You are right, but note for normal exhaustive key search (brute force, because key is random here) you need to know some plain text on the disk (not problem with known FS signature though). Here you have always digest of hashed key (+ known salt). If the PBKDF2 with iterations is very quick and cheap, the exhaustive search for key candidates is much more simpler here than other technique. Adding iterations for mk digest is quite cheap and almost make this search unusable (even if it is just theoretic or silly attack). Or am I missing anything? Milan -- mbroz@xxxxxxxxxx _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
