Hacker News Reader

Comment by rdl | Hacker News Reader

Pluggable crypto algorithms are one of the reasons for a lot of protocols being overly baroque and thus vulnerable (due to implementation flaws), or at least not widely used. This all started due to the export controls in the 1990s -- when you needed to have a US/non-US version anyway, you could then do 10 algorithms. But, if you don't have that concern anymore, it's senseless complexity.

IMO the best way to do all of this is to have one (set of) algorithm per major version of protocol. It's fine to change that (by adding new protocol handling) going forward, and potentially to deprecate old versions too, but cipher negotiation/etc. is otherwise madness-making. That, and shitty encodings, are most of the pain I have when working with stuff.

(The issue raised here of "ECC should be more widely used" is good, though -- I've been looking at blinded ECC algorithms recently.)

View on HN

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.

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?

So if AES were broken you'd want the TLS version bumped, some people to spend a caffeine-fueled week implementing and testing a new ciphersuite while global ecommerce slows to a crawl, and then OS maintainers and IT admins everywhere to get the new openssl/nss/schannel versions installed ASAP?

How is that better than having pluggable ciphers?

I don't really understand the combining of symmetric, asymmetric, and hash under one ciphersuite id namespace either. It's like the SSL/TLS authors had never encountered the DRY concept before. It makes adding or removing a cipher or hash into a tedious exercise, getting particular combinations into RFCs.

If AES is broken, I'm willing to accept flag day hell, in exchange for not having 8908494 possible combinations to test and implement every time before that.

It's much more likely "AES minor vulns found" happens over a period of years; the push to change algorithms happens somewhat more reasonably like most security patches. Taking a year to get rid of MD5, DES, SHA1, etc. through protocol version upgrades isn't any worse than 5-10 (and counting) we got by allowing pluggability.

In the SaaS, browser, and mobile client world, upgrading software and upgrading configs aren't that different in pain, in practice.

If the implementations of hashes and various ciphers are done properly, and the combinations were truly pluggable rather than hardcoded as individual ciphersuites, you don't need to test every combination (other than for interop, to ensure that nobody else has stupid bugs due to not implementing them in a truly pluggable manner). What's the theory, that SHA3-256 that passes basic validation tests and has been audited, still won't hash certain things properly? Or that Salsa20, properly audited and validated, will work with 256 bit ecdsa but not 384 bit?

Getting rid of MD5, DES, and SHA1 is easy with pluggable algorithms. Just remove those ciphersuites from the ssl implementations.

The reason it's a pain in the ass to get rid of those old ciphers and hashes is not that the algorithms are pluggable, it's that nobody wants to force everyone else to upgrade (and force other ssl implementations to implement enough new ciphersuites that the old ones can be removed), right?

Reply on news.ycombinator.com