On Wed, Dec 11, 2013 at 17:31:13 CET, anderson jackson wrote: > In the faq it is said that the use of sha1 for the purpose used in Luks is > valid because it is not the cryptographic feature that is used but instead > the time delay for retreaving the master key. No, that is not the statement. The statement is that collision attacks (the SHA1-weakness) are irrelevant for password hasing. > However is this really the case? The output of Sha1 is a 160 bit string. > A password is iterated using PBKDF2(with sha1). But can't I just use all > the possible sha1 values to decrypt the master key and validate it with > the master key checksum? Does this not effectively reduce the possible > passwords for an AES 256 bit volume to a password of 160 bit length? It does. If you can create that table, which you cannot. 2^160 is about 1.5*10^48. The number of atoms in this planet is only 1.33*10^50. So if you can convert the whole planet to storage space and can store one bit in one atom, you can just about do it. Then there is the computing effort: Say, you get 1M hashes/sec with 1W of power. As PBKDF2 runs with around 100'000 iterations on average PC hardware, you then get 1 iterated hashe for 0.1 Joule of power. That means for 2^160 of them, you need 150*10^45 Joules. The sun has an energy output of 3.8*10^26 W. So run the sun for 384*10^18 seconds = 12.8*10^12 years and you have your table. Sounds pretty unrealistig, right? AES-256 does not have a 256 bit key to provide a 2^256-sized key-space. Key-space-wise, at around 100 bit it becomes reliably infeasible for the human race to break things. AES-256 has a 256 bit key, becuase research could reduce the effective key-length and the longer the key, the more effective bits need to be removed by research before brute-forcing becomes feasible. Also note that your password is unlikely to even have 100 bits of entropy. If you actually use a passwored with more than 160 bits of entropy, moving to SHA-256 as hash function may provide an irrelevant security improvement. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
