Confession time: i still have some apps with salted md5 hashed passwords
So migrate? Hash the hashes with Bcrypt or PBKDF2.
Bcrypt(MD5(password)) is just as effective as Bcrypt(password) at knocking brute force attempts on the head.
Lifetimes of cryptographic hash functions
21–30 of 56 posts
Re: Lifetimes of cryptographic hash functions
#22Earlier quoted context omitted.
it appeared after sha1, receives less attention than sha1, and is slower than sha1... so why use it at all?
Many use it because it wasn't developed by the NSA. It is a default in TrueCrypt, for example.
It's used in Bitcoin as well (after SHA-2) to shorten up addresses. Come to think of it, I think Tor uses it for .onion addresses... which they shorten to 80 bits (of preimage resistance!)
Re: Lifetimes of cryptographic hash functions
#23It's missing the most important ones: Scrypt, PBKDF2, Bcrypt.
https://en.wikipedia.org/wiki/Scrypt
https://en.wikipedia.org/wiki/Bcrypt
https://en.wikipedia.org/wiki/PBKDF2
Scrypt being an absolute nightmare to bruteforce, even for short passwords.
Re: Lifetimes of cryptographic hash functions
#24It's missing the most important ones: Scrypt, PBKDF2, Bcrypt. https://en.wikipedia.org/wiki/Scrypt https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/PBKDF2 Scrypt being an absolute nightmare to bruteforce, even for short passwords. http://i.stack.imgur.com/sOMvu.png
Can you explain why a 40 char text is 1000 times easier to crack than a 10 char password according to the graphic?
Is it assumed you don't use any numbers/symbols and the attacker knows your dictionary?
Re: Lifetimes of cryptographic hash functions
#25It's missing the most important ones: Scrypt, PBKDF2, Bcrypt. https://en.wikipedia.org/wiki/Scrypt https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/PBKDF2 Scrypt being an absolute nightmare to bruteforce, even for short passwords. http://i.stack.imgur.com/sOMvu.png
Can you explain why a 40 char text is 1000 times easier to crack than a 10 char password according to the graphic? Is it assumed you don't use any numbers/symbols and the attacker knows your dictionary?
I think "text" is english + whitespace + punctuation only, whereas "password" is any kind of character.
I didn't create that image, so I'm not 100% sure.
Re: Lifetimes of cryptographic hash functions
#26It's missing the most important ones: Scrypt, PBKDF2, Bcrypt. https://en.wikipedia.org/wiki/Scrypt https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/PBKDF2 Scrypt being an absolute nightmare to bruteforce, even for short passwords. http://i.stack.imgur.com/sOMvu.png
These aren't cryptographic hash functions exactly, though, at least not in the sense that a cryptographer would think. I mean, they will fit just about any definition of a cryptographic hash function you can think of, but really it's not that useful to label them as such. Instead, they're usually called key derivation functions.
On top of that, even if we were to include these in a hash function list, they're decidedly not the most important ones. Most important for password storage and other key derivation, perhaps, but the applications of hash functions are far more general. The preimage resistance of scrypt is reliant on SHA256, for instance.
Re: Lifetimes of cryptographic hash functions
#27Earlier quoted context omitted.
Can you explain why a 40 char text is 1000 times easier to crack than a 10 char password according to the graphic? Is it assumed you don't use any numbers/symbols and the attacker knows your dictionary?
I think "text" is english + whitespace + punctuation only, whereas "password" is any kind of character. I didn't create that image, so I'm not 100% sure.
You're correct. See the original scrypt paper by Percival [1], halfway down page 13, for a description of the categories. The table itself is at the top of page 14.
Re: Lifetimes of cryptographic hash functions
#28>[1] Note that 128-bit hashes are at best 2^64 complexity to break; using a 128-bit hash is irresponsible based on sheer digest length.
Can a short hash which has not been weakened be lengthened by taking two hashes and concatenating?
fixedSalt = "blah"
longerHash = (salt, input) ->
hash(salt + input) + hash(salt + fixedSalt + input)
But is there any valid way to lengthen a too-short hash? Not that it's of practical importance; I'm just curious academically.
Re: Lifetimes of cryptographic hash functions
#29>[1] Note that 128-bit hashes are at best 2^64 complexity to break; using a 128-bit hash is irresponsible based on sheer digest length. Can a short hash which has not been weakened be lengthened by taking two hashes and concatenating? fixedSalt = "blah" longerHash = (salt, input) -> hash(salt + input) + hash(salt + fixedSalt + input) Edit: Never mind. Obviously an attacker would only have to break the first half of t…
This is actually a pretty interesting question. The answer, at least for Merkle-Damgard hash functions (MD5, SHA-1, SHA-2, etc) is that concatenating (or "cascading") hash functions doesn't really improve the strength of the resulting construction.
Merkle-Damgard hash functions look like this:
function MD(M, H, C):
for M[i] in pad(M):
H := C(M[i], H)
return H
Antoine Joux showed that for any MD hash function, generating many collisions is not much more difficult than generating one. Here's how:
1. Take the initial state H[0].
2. Find two single-block messages that collide under C with H[0] as the input state. Call the result H[1].
3. Now find another pair of single-block messages that collide under C with H[1] as the input state. Call the result H[2].
4. Iterate as needed.
What does this mean for cascaded hash functions? Well, consider a hypothetical construction that simply concatenates a 128-bit hash function with a 160-bit function. A plan of attack might look like this:
1. Find 2^80 colliding messages under the 128-bit function. This should take roughly 80 * 2^64 ~= 2^70.3 units of "effort".
2. Evaluate each message under the 160-bit function. There's probably a collision in there somewhere. This will take around 2^80 work, dwarfing what we did in the first step.
Shameless plug: we will have a few problems exploring the consequences of Joux collisions in set seven of the Matasano crypto challenges.
Re: Lifetimes of cryptographic hash functions
#30>[1] Note that 128-bit hashes are at best 2^64 complexity to break; using a 128-bit hash is irresponsible based on sheer digest length. Can a short hash which has not been weakened be lengthened by taking two hashes and concatenating? fixedSalt = "blah" longerHash = (salt, input) -> hash(salt + input) + hash(salt + fixedSalt + input) Edit: Never mind. Obviously an attacker would only have to break the first half of t…
This is actually a pretty interesting question. The answer, at least for Merkle-Damgard hash functions (MD5, SHA-1, SHA-2, etc) is that concatenating (or "cascading") hash functions doesn't really improve the strength of the resulting construction. Merkle-Damgard hash functions look like this: function MD(M, H, C): for M[i] in pad(M): H := C(M[i], H) return H For message M, initial state H, and compression function C…
Ah, so in fact the naive concatenating solution I gave, in addition to being just as easy because the attacker only has to break half of it, is actually even easier because the attacker has two targets to collide with.
What about non-concatenative methods? For example, could you do something like "shift and xor". For example, say you have a 4-byte hash function, so that:
hash(salt + input) : 0x3AF9
hash(salt + fixedSalt + input) : 0x8034
3AF90
xor 08034
= 32FA4