On Sat, Aug 22, 2015 at 05:38:16 CEST, Heinz wrote: > Arno Wagner <arno@...> writes: > > > No, that is not the statement. The statement is that collision attacks > > (the SHA1-weakness) are irrelevant for password hasing. > > Or in other words, SHA1 is secure in this case. But why not always use the > best possible hash algorithm, instead of an option which is at least safe? SHA1 is a "best possible" for this case. Seriously. > I would logically use always the strongest one, purely as a precaution, > and There is no single one-dimensional "safest" measure. It always depends on the scenario. > not what has already demonstrated weaknesses of any kind. I would not want > to wait if SHA1 really holds a long time. :) SHA1 is very, very unlikely to ever have a weakness that makes reversing it easy. It is too old and too well-understood for that. And that would be the only attack that matters. Really, what you advocate makes no sense. It is not readily obvious that it makes no sense, admittedly, hence my explanation. > > 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? > > Yes, but for me a very original presentation. Thanks! > If i am not mistaken, a computing power of at least 10^42 FLOPS would be > needed to effectively go through this area. > 2^160 / 10^42 FLOPS = 1461501 Seconds = 16 Days to break SHA1, but > technically we arrive until approximately 10^18 FLOPS or 1 exaFLOP. Not to "break" it. To reverse it in one instance. To break it, you have to compute that table. > > 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. > > All over 128 bits is really overkill. I completely agree. > I once extracted my masterkey and wonder, why this consists only > of numbers and the letters a-f? > Why not a-z/A-Z? And special characters? A mattetr of encoding. Not a question of security at all, more one of compatibility and convenience. > Okay respect brute-force attacks is a key space of 16^128 in fact > impossible, but why not exploit the maximum of what is possible? :) Simplicity, use of well-knonw components, prevention of over-engineering. All well known and valuable engineering practices. Also note that in order to change the hash, code has to be changed and that comes with the risk of introducing bugs. "If it aint broke, don't fix it" is another very important engineering principle. Listen, I can understand your view. Every budding crypto-nerd goes through it, and I certainly have. But it is something you eventually grow out of when you understand the larger picture. Regards, 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 ---- A good decision is based on knowledge and not on numbers. -- Plato 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 dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
