61–70 of 91 posts
I'm usually the first to rail against NSA shenanigans but I also believe you shouldn't ascribe to malice what can more easily be explained by stupidity.
Earlier quoted context omitted.
Oh, yes - definitely. I just picked Salsa20 as an example because I already had benchmark data for my machine, and I am familiar with it. But even TLS 1.2 won't help because 1.2 doesn't include ciphers that are screaming-fast without hardware-acceleration. AES-GCM is faster than AES-128-CBC/HMAC-SHA1, but Salsa20-256/HMAC-SHA1 is still twice as fast on my machine. Now if the AES-NI instruction set is available, then…
Does AES-GCM with AES-NI and PCLMULQDQ beat Salsa20+Poly1305 with lots of sessions? I know it's got excellent cycles/byte for a single session, but TLS implementations also need agility.
I don't know the answer offhand, but I would suspect that hardware-accelerated AES-GCM would win. It certainly does in single-threaded, "one-session"-esque tests, and the margin of its victory makes me think that hardware-accelerated GCM would be hard to beat by anything.
On my machine, a single thread/core running nothing but AES-GCM can encrypt/decrypt 8192 byte blocks of data at 1.32 GiB/s (this is using OpenSSL's benchmarking feature). Yes, that's gigabytes, not gigabits. It's literally faster than IO for my SSD. (Salsa20, without a MAC, can do the same at about 0.64 GiB/s.)
When I told OpenSSL to use four threads in parallel, it ranked at 5.01 GiB/s, which is absolutely crazy.
That said, beyond a general leaning towards AES-GCM (simply because it is so fast with hardware acceleration), I don't have any hard data on which would be the victor. But I may just construct some benchmarks to test that out, because it's an interesting question.
Earlier quoted context omitted.
What he's saying is these blanket statements "just use X" is what is broken. Sometime ago it was "just use md5" and we're still suffering through the fallout of that long after md5 has been shown to be broken. Now we're pointing everyone in another direction and at some point that will be broken too. His point is that we need to educate people on the reasons why one algorithm is better than another for certain securi…
And now I'd like to say for the third time that no, there was no "just use MD5" meme in cryptography or in software development, and if TLS is an illustration of anything, it's of not simply leaning on MD5. Once again: the TLS protocol itself is not vulnerable because of MD5, and it's not vulnerable because its designers and implementors both knew about and accounted for the weaknesses of MD5. The author took the opp…
Thank you for your replies tptacek, I've learned much from this discussion. If I could edit my top comment, I would.
Earlier quoted context omitted.
How about both? An engineer on the payroll of NSA, and then stupidity on the part of whoever signed off on the commit?
How about neither? The designers of the SSL3-era ciphersuites knew that MD5 was shady but had few better alternatives because those ciphersuites predate even the SSL3 standard itself and thus readily available SHA1, so they used constructions that remain secure 20 years later even with broken hash cores. And subsequent designers and implementors have swapped RC4 in and out of TLS as needed to mitigate performance pro…
(It's a little hard these days to know what's a "paranoid fantasy", what's an "interesting cypherpunk plot", and what's "a realistic and/or confirmed NSA threat" - at least for me…)
I'm usually the first to rail against NSA shenanigans but I also believe you shouldn't ascribe to malice what can more easily be explained by stupidity.
And you probably shouldn't ascribe to stupidity what can more easily be explained by "not at all stupid or malicious".
I don't remember the timeline, but if you're implementing code for algorithms and you decide to use the defaults "just because", you're being negligent - that is to say being pretty damn stupid.
Earlier quoted context omitted.
What he's saying is these blanket statements "just use X" is what is broken. Sometime ago it was "just use md5" and we're still suffering through the fallout of that long after md5 has been shown to be broken. Now we're pointing everyone in another direction and at some point that will be broken too. His point is that we need to educate people on the reasons why one algorithm is better than another for certain securi…
Has anyone said "just use MD5" to someone who wasn't about to use CRC32 instead?
One particular case I remember was use of md5(md5(md5(unix_timestamp()))) to generate "secure" session tokens.
Earlier quoted context omitted.
And you probably shouldn't ascribe to stupidity what can more easily be explained by "not at all stupid or malicious".
I'm sorry, but I'm only a passing student of cryptography, and I've known that both RC4 and MD5 have been broken for quite some time now. I don't remember the timeline, but if you're implementing code for algorithms and you decide to use the defaults "just because", you're being negligent - that is to say being pretty damn stupid.
Cryptosystems exist in strata: environments, algorithms, constructions, protocols, applications. A careful cryptosystem is designed so that a flaw in one stratum doesn't immediately destroy the entire cryptosystem. Not only did TLS largely succeed in that goal, but it succeeded in part due to the availability of RC4.
So: no. No, no, no.
Earlier quoted context omitted.
Examples please?
RC4 was first used as a mitigation for the BEAST blockwise-adaptive attack on CBC-with-chained-IVs from SSL 3.0 and TLS 1.0, and then again as a mitigation for the "Lucky 13" timing-based CBC padding oracle that remains a problem in TLS 1.2 when block ciphersuites are used.
Earlier quoted context omitted.
And now I'd like to say for the third time that no, there was no "just use MD5" meme in cryptography or in software development, and if TLS is an illustration of anything, it's of not simply leaning on MD5. Once again: the TLS protocol itself is not vulnerable because of MD5, and it's not vulnerable because its designers and implementors both knew about and accounted for the weaknesses of MD5. The author took the opp…
As a computer scientist, it's a joy to discover when you're wrong about things. So I'm enjoying being on the wrong side of the discussion for once, because I'm learning lots. Thank you for your replies tptacek, I've learned much from this discussion. If I could edit my top comment, I would.
Earlier quoted context omitted.
Has anyone said "just use MD5" to someone who wasn't about to use CRC32 instead?
Doubt about this exact case, but I've seen MD5 being (ab)used in a really weird ways, which I attributed to mindless "oh, I'll just use MD5 here, heard it's good for security!" One particular case I remember was use of md5(md5(md5(unix_timestamp()))) to generate "secure" session tokens.