On Friday 18 September 2009, you wrote: > Note that hash verification is not applied directly to master key, > but to result of PBKDF2 (with DigestKey iterations) where master key > is only on its input. See LUKS_verify_master_key() in code to verify > that. > > Please read archive of this list, explaining that sha-1 is not > problem is here > http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/33 >00 OK. I see the current attacks do not apply, and that in future versions the user may be able to change this. But does this still mean that current LUKS volumes provide only mk-digest-iteration-count x 80 bits of effective security against brute force attacks? If we presume that SHA-1 provides 80-bits of security against bruteforcing the input by knowing only the output, and that PBKDF2 hashes the initial password string with salt iteration_count times, then it should be possible to reverse the procedure with iteration_count many brute force breaks of SHA-1, starting from the final digest and going backwards, towards the initial password string + salt value? The salt here only helps against dictionary attacks on the password string, doesn't it? If the iteration count is not very high, and if there is only a limited number of inputs that can generate the same SHA-1 output (collisions?), then if one is able to mount a 80-bit attack (surely one day in less-than-unforeseeable future), then simply forcing this then-feasible attack level to be carried out few more times (iter count 10 now?) should not provide long-term security, as if that level (80 bits) is achieved, then doing it ten times should become after that equally feasible quite quickly, especially if the default LUKS setup is for a 256 bit AES key, which would suggest an entirely different level of attempted security. For example, 10x2^80 < 2^84. This, of course, presuming that SHA-1 maintains its current, maximum, security level, which many seem to believe it will not retain for very long. This could be countered by SHA-1 actually having very many collisions for those outputs, i.e. the iteration output when broken provides many possible inputs, but even for that the iter count seems low in a 80-bit-is-feasible scenario. I have no issue with, say, 80+something bits of security for my USB memory sticks, for example, but seeing that some people make root partitions with 256 bit keys, it seems they expect their password string entropy to determine their "weakest link", or the lowest determiner for the level of security achieved, not the 80 bits plus something level actually provided. It even begs the question why >128 bit keys are offered in the first place. Is this even remotely there? Or am I still missing something big here? Sorry if I make stupid claims, but it is good to get the information out there for other novices also to find when Googling. Thanks, Tero Pesonen _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
