On Friday 18 September 2009, Tero Pesonen wrote: > 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. Since there have been no comments on this, I was wondering if I should rather send questions of this sort on scri.crypt or some such place where these kind of topics are discussed? If so, is the iteration count 10 for the PBKDF2 correct? (So that I am able to formulate my question right and not pass on wrong information.) Thanks, Tero Pesonen _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
