
Encryption is dead, and we killed it - ratsmack
https://skidpaste.org/i94aYFx0.txt
======
viraptor
Ok, so I'm going to only comment on some parts.

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....](https://www.openssl.org/docs/man1.0.1/crypto/EVP_BytesToKey.html)
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...](https://github.com/openssl/openssl/blob/6f0ac0e2f27d9240516edb9a23b7863e7ad02898/crypto/err/err_prn.c#L39)
)

"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.

------
uiri
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_.

Next: padding oracle attack in OpenSSL. Reported on
[https://blog.cloudflare.com/yet-another-padding-oracle-in-
op...](https://blog.cloudflare.com/yet-another-padding-oracle-in-openssl-cbc-
ciphersuites/) 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.

------
voltagex_
There might be a point here, but it's incomprehensible. Also "anonymous" text
dumps, so no chance of following up with the author.

I wonder what the author hoped to achieve with this?

~~~
powera
Quite possibly "trolling Hacker News".

------
tehabe
I have a distinct boy cries wolf feeling about this. There might be a point
but it isn't that bad or the point is about something complete different.

------
geophile
I do not understand beyond "Open SSL is broken", but it sounds both terrible
and important. Can someone please explain a bit more?

~~~
Nostromov
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. :)

^^ 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...](http://web-in-security.blogspot.rs/2016/05/curious-padding-
oracle-in-openssl-cve.html)

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.

------
EvanAnderson
Cached:
[https://webcache.googleusercontent.com/search?q=cache:ZvFp9_...](https://webcache.googleusercontent.com/search?q=cache:ZvFp9_xtjvoJ:https://skidpaste.org/i94aYFx0.txt+&cd=1&hl=en&ct=clnk&gl=us)

~~~
wtbob
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.

~~~
EvanAnderson
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...)

------
Proof
This is something I would write in a Creative Writing Class back when I was an
Exchange Student in USA. Why is this on HN?

Don't teens know not to do homework on "Snowdays"?

------
powera
I call shenanigans.

