Hacker News Reader

Comment by tptacek | Hacker News Reader

That's a weird conclusion to draw given that negotiated key agreement algorithms are what allows us to swap RSA for ECDSA opportunistically and without jettisoning the rest of the protocol.

Maybe this would make more sense if you could describe what was madness-making about cipher negotiation.

View on HN

It certainly has upsides, but I remember pain when involved in or trying to fix things with diverse algorithms. Maybe the memory of the pain was worse than the pain itself, or the pain was from unrelated causes. Mostly it's "I'm not very good at _____, so I like things to be as simple as possible".

JCE implementation (mostly related to scope, era, etc.) -- admittedly, we only needed a non-US JCE for a few specific things, as part of an overcomplicated financial transfer system.

PGP/OpenPGP; there were lots of reasons this sucked, but multiple ciphersuites didn't help at all.

Free S/WAN was painful too (and really most of IPsec), but it's an example of the higher level problem of "too many layers of indirection and abstraction", not "too many algorithm choices."

(Poking at OpenSSL internals as a consumer of the library and trying to get it to work with some hardware shit made me mostly want to die, too, but part of that is my inferior C skills, and other things specific to OpenSSL and not to the overall concept of multiple algorithms)

OTR, ecash protocols of various types, etc. which used hardcoded algorithms were comparatively painless.

ssh is probably a good counterexample -- relatively flexible choices, although the big shift from v1 to v2 fixed a lot more things than just algorithms.

That last part about openssh suggests that the problem with SSL's cipher choices is not that there are choices; rather it's that the choices are mostly bad, and that they're hardcoded combinations rather than free choice of primitives. MD5/SHA1 lingering for years, and RC4 crippled but limping along and even preferred in some cases because of BEAST, all because there are insufficient, or insufficiently deployed, newer options. Camellia is crippled by not supporting the same ciphersuite variety as AES does in most implementations (openssl ciphers -v 'CAMELLIA', vs openssl ciphers -v 'AES'). That's right, there's no ECDHE+Camellia when talking to any server that's using openssl, it's slow DHE or no PFS at all. What's the point of even having Camellia in a SSL implementation if it's not going to be maintained with current ciphersuites? That's a great example of why hardcoding combinations of primitives is scary.

As a user of Free software consumer cryptography utillities, such as GPG and OTR instant messengers, can I configure stuff any differently to account for these developments?

What can I do to protect myself? Do you forsee projects like these responding to the concerns in the presentation in a timely manner?

Reply on news.ycombinator.com