Yeah, no. That might take several days. Check out some of the names mentioned in the textfile, such as the Heartbleed Bug and then some of the links, such as 'Damage control'.
Besically, a patch to SSL authentication lead to moar craziness and somehow there's a debate whether the protocol is broken in itself. Well, not broken, but if like everything needs to be rewritten kinda. :)
Edit (looks like I can edit): Sorry, can't edit and it's 4AM losing my mind. There are things that have been exploited 3 years ago and then 1 year ago which are still very much implemented. I think that is the problem.
Thanks, all I see is 'Please turn JavaScript on and reload the page,' which makes me want to comment, 'the web is dead, and we killed it' — but that's not fair.
Odd. I run "NoScript" and the Google web cache doesn't doesn't require me to enable scripting to view cached content. (I'm w/ you re: killing the web...)
First: They're proving that they can generate the encryption key based on password and salt. Which is exactly how you generate the encryption key. "We have the full key. We only used MD5 and didn't write a single line of code." - regardless of whether the key is generated in the described way, everything's fine. This is exactly the input and output elements you'd expect.
Regarding key generation / KDF, you can see it in the official docs as well: https://www.openssl.org/docs/man1.0.1/crypto/EVP_BytesToKey.... which actually say you should probably go with PKCS#5 2.0 instead. But really with high enough count, it shouldn't matter that much if the hash is MD5. Collisions have been found, but it's not collisions you'd be looking for when decrypting messages. You'd need to find the original string from multiple applications of MD5, which does effectively involve bruteforce.
The last part: "The question is, what the hell does this number mean, and how do we interpret these results?" - this is actually something you can find in the source. No need to raise it as an interesting question. (for the curious, it's the CRYPTO_THREAD_ID https://github.com/openssl/openssl/blob/6f0ac0e2f27d9240516e... )
"This number is, also, what the padding oracle is mysteriously spitting out." -> it's actually what your memory fragmentation / aslr is likely spitting out. The number is affected only by the system, not by the contents of the file.
OK, so the first part demonstrates that given a password, OpenSSL generates the symmetric keypair using MD5 and a salt. So what? That doesn't break AES since the only secret thing in the system should be the password/key. The issue is that the entropy of the key is actually half what it is supposed to be. The second half of the key is derivable from the first half. OK, that's pretty bad but still not entirely broken.
There are various complaints about memory management, double free errors and "sloppy" programming. It isn't clear to me that these have any further security implications but I am by no means an expert.
The last part talks about information being leaked when an attempt is made to decrypt using AES with a bad password. It isn't clear - neither to me nor to the author - that this information has any utility in narrowing down the search space for the key.
14 comments
[ 2.8 ms ] story [ 44.7 ms ] threadBesically, a patch to SSL authentication lead to moar craziness and somehow there's a debate whether the protocol is broken in itself. Well, not broken, but if like everything needs to be rewritten kinda. :)
^^ Referring to depreciating the way the auth chains are stacked... Ugh, "MAC-then-Encrypt" @http://web-in-security.blogspot.rs/2016/05/curious-padding-o...
Edit (looks like I can edit): Sorry, can't edit and it's 4AM losing my mind. There are things that have been exploited 3 years ago and then 1 year ago which are still very much implemented. I think that is the problem.
I wonder what the author hoped to achieve with this?
Don't teens know not to do homework on "Snowdays"?
First: They're proving that they can generate the encryption key based on password and salt. Which is exactly how you generate the encryption key. "We have the full key. We only used MD5 and didn't write a single line of code." - regardless of whether the key is generated in the described way, everything's fine. This is exactly the input and output elements you'd expect.
Regarding key generation / KDF, you can see it in the official docs as well: https://www.openssl.org/docs/man1.0.1/crypto/EVP_BytesToKey.... which actually say you should probably go with PKCS#5 2.0 instead. But really with high enough count, it shouldn't matter that much if the hash is MD5. Collisions have been found, but it's not collisions you'd be looking for when decrypting messages. You'd need to find the original string from multiple applications of MD5, which does effectively involve bruteforce.
The last part: "The question is, what the hell does this number mean, and how do we interpret these results?" - this is actually something you can find in the source. No need to raise it as an interesting question. (for the curious, it's the CRYPTO_THREAD_ID https://github.com/openssl/openssl/blob/6f0ac0e2f27d9240516e... )
"This number is, also, what the padding oracle is mysteriously spitting out." -> it's actually what your memory fragmentation / aslr is likely spitting out. The number is affected only by the system, not by the contents of the file.
This is just trolling. It happens.
Next: padding oracle attack in OpenSSL. Reported on https://blog.cloudflare.com/yet-another-padding-oracle-in-op... Looks like it is fixed now.
There are various complaints about memory management, double free errors and "sloppy" programming. It isn't clear to me that these have any further security implications but I am by no means an expert.
The last part talks about information being leaked when an attempt is made to decrypt using AES with a bad password. It isn't clear - neither to me nor to the author - that this information has any utility in narrowing down the search space for the key.