,
5 tweets,
2 min read
Read on Twitter
This is pretty funny. As we all know, it's impossible (with current technology) to find a collision with SHA224. HMAC and PBKDF2 are even stronger than simple SHA224, so this should be even more impossibler. (Yes, that is a word, when describing something this impossible).
But there's a trick. When using pbkdf2_hmac() to hash a password, if it's longer than the hash block size, it first hashes it down to the block size, then continues on. That's what we see here: the second string is simply the hash of the first string.
So there's no "hash collision" happening. It just looks like it. To create this, you need to brute-force input strings until you find a binary output string where all the bytes look like ASCII, which takes only about 256 million tries, which is pretty fast to brute-force.
It's like the fraud Craig Wright tried to pull. He was very convincing -- until you realized it was based on a hash of a hash.
BTW, there is no math here. PBKDF2 and HMAC are simple algorithms. The HMAC algorithm is a "key hash", and if the key is longer than the hash block size, it needs to be hashed down first. Here's the graphic from the Wikipedia page:
en.wikipedia.org/wiki/HMAC
en.wikipedia.org/wiki/HMAC
