Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

op-co.de

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#81

Post by sneak »

tptacek wrote: post #59
sneak wrote: post #57

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 not political at all - if NSA has had viable attacks against RC4, doing little and not-carefully-scrutinized stuff like this to ensure it continues to be used widely would make a lot of sense.

I'd expect them to go so far as to attempt to stop publication of comparably-performant ciphers that could conceivably take its place. You'll recall the 1974 precedent involving IBM's independent discovery of differential cryptanalysis.

If there's one thing I'm even more vigilant about than distrusting the US government/military, it's not underestimating the lengths to which they will go to achieve their ends.

PS: This has nothing to do with md5.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#82

Post by swombat »

Finster wrote: post #35

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.

I think the NSA gave up the right to the "stupidity not malice" defence when they started planting HUMINT agents in large companies to deliberately insert backdoors into major companies' systems. Malice is there and is obvious.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#83

Post by StavrosK »

pyre wrote: post #78
StavrosK wrote: post #16

Earlier quoted context omitted.

> This is the same kind of thinking I hear daily when people say things like, "Just use bcrypt" without thinking about the consequences I'll say what everyone's thinking: What are the consequences?

The parent seems to be implying (taking other comments into account) that people "cargo cult"-ing on ideas like "just use bcrypt" might work now, but it will become a liability in future when bcrypt is weakened or broken (making it more difficult to get people to switch to the next standard practice).

That's odd, I don't think anyone is taking the advice to mean "use bcrypt for ever", I'd imagine that everyone understands that we use it because it's good enough for the foreseeable future.

An odd point for the GP to make.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#85

Post by thrillgore »

celerity wrote: post #27

This beautifully illustrates the power of open source. One guy was worried enough about security to start checking the crypto source, and was able to alert the community. I hope this leads to a more secure platform.

It was a downgrade during the Android life cycle. I don't want to be "that guy" but someone had to have a good reason to roll back to RC4-MD5 if they were using SHA before.

But hey, you can open an issue about it.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#86

Post by thrillgore »

eksith wrote: post #45

"The change from the strong OpenSSL cipher list to a hardcoded one starting with weak ciphers is either a sign of horrible ignorance, security incompetence or a clever disguise for an NSA-influenced manipulation - you decide!" Survey says: Short-sightedness. Not really ignorance or incompetence (although that may be arguable), but it's certainly not "NSA-influenced manipulation". That's the sort of thing they reserve…

Like it or not, "OMG NSA" is now part of the lexicon in a post-Snowden world. It's how every piece of technology developed Stateside is going to be perceived from here on out.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#87

Post by tptacek »

jafaku wrote: post #71
tptacek wrote: post #4

There's interesting technical content here, but it suffers from its alarmist tone. The MD5 hash function is broken, that is true. However, TLS doesn't use MD5 in its raw form; it uses variants of HMAC-MD5, which applies the hash function twice, with two different padding constants with high Hamming distances (put differently, it tries to synthesize two distinct hash functions, MD5-IPAD and MD5-OPAD, and apply them bo…

What a surprise, tptacek defending Google no matter what... /s

Learn a bit about cryptography and you too can simultaneously be judged an Apple fanboy, a Google defender, and an NSA apologist.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#88

Post by KMag »

tptacek wrote: post #4

There's interesting technical content here, but it suffers from its alarmist tone. The MD5 hash function is broken, that is true. However, TLS doesn't use MD5 in its raw form; it uses variants of HMAC-MD5, which applies the hash function twice, with two different padding constants with high Hamming distances (put differently, it tries to synthesize two distinct hash functions, MD5-IPAD and MD5-OPAD, and apply them bo…

Minor nit: note that a collision after the first MD5 application will result in an HMAC-MD5 collision. The dissimilarity between the two MD5 applications isn't for collision resistance. (The second MD5 application is still mandatory for preventing length extension attacks, and makes key recovery attacks more difficult, among other things.)

Rather, the increased collision resistance comes from the fact that the 64-byte keyed padding puts the MD5 context in a state unknown to the attacker before any of the attacker's data touches the MD5 state. As long as the HMAC key has at least 128 bits of entropy, all possible values of the 128-bit MD5 internal state are nearly equally likely. This makes it much more difficult for an attacker to produce collisions.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#89

Post by JoachimS »

colmmacc wrote: post #29
tptacek wrote: post #4

There's interesting technical content here, but it suffers from its alarmist tone. The MD5 hash function is broken, that is true. However, TLS doesn't use MD5 in its raw form; it uses variants of HMAC-MD5, which applies the hash function twice, with two different padding constants with high Hamming distances (put differently, it tries to synthesize two distinct hash functions, MD5-IPAD and MD5-OPAD, and apply them bo…

There is another technical angle; RC4 is usually quite a lot less CPU intensive than the alternatives available. Not using RC4 can easily mean stuttering video playback, greatly diminished battery life, and even lock ups. Very few users are open to accepting that issues like that are "better" for them. Many RC4 deprecation efforts have faced rollback in the face of issues like this; especially on hard to fix embedded…

Actually, RC4 is pretty memory hungry (with a state of 256 bytes) and performs a lot of read operations that hit main store in small devices.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#90

Post by JoachimS »

tptacek wrote: post #41
ReidZB wrote: post #37

Earlier quoted context omitted.

There are two solutions: use hardware with the AES-NI instruction set, which makes AES blazing fast, or alternatively use a better stream cipher like Salsa20. On my machine, which has an Intel i5-3570k, Salsa20 is about 25% faster (edit: than RC4) Unfortunately, neither solution is easy: only the very latest chips have AES-NI instructions, and not many clients support Salsa20 yet (OpenSSL does not, for example, and i…

Does any TLS stack support Salsa20? I know Adam Langley has a draft for ChaCha+Poly1305, but that's not Salsa20. Either way, I don't think Salsa20 is a realistic suggestion for improving TLS performance.

(disclaimer, I'm one of the Salsa20 in TLS draft authors).

Note that the suggestion of using Salsa20 is to replace RC4 not only to get better performance, but because RC4 is broken (as you know).

Salsa20 (and ChaCha) can be implemented on constrained devices and reach RC4 like performance. On modern architectures the algorithms word based functionality better utilise the HW than RC4 and can reach better performance.

Yes, AES with HW-support such as AES-NI can provide really good performance too. But then we _only_ have AES (and DES/3DES). Do we want to reduce SSL, TLS to a single symmetric encryption primitive? And no stream ciphers?

Post reply on HN