[Cryptography] [cryptography] Underhanded Crypto

[Peter Gutmann]

Jerry Leichter <leichter at lrw.com> writes:

>Anyhow ... are we really in the situation where the complexity of the
>protocols is great enough that we simply *can't* get them right?

I think a major problem with them is the design-by-committee that reached its
apex in IKEv1.  If you look at something like TLS or SSH there are a million
negotiable options, most of which will never be used but that an
implementation has to support in the name of standards-compliance or
flexibility or marketing or whatever (see Ian Grigg's "There is only one
cipher suite and that is #1").  In practice all you need is for both sides to
exchange nonces and DH y values authenticated with RSA or a PSK, and after
that use AES and HMAC for further communications.  No negotiation, no options,
nothing.  This is what you're getting anyway most of the time with TLS (except
for Firefox which inexplicably puts Camellia before AES), but no protocol will
allow you to do that, you need to be able to specify a million options and
parameters, with both SSH and TLS having nondeterministic behaviour where you
have to retrace earlier protocol steps if a parameter or option that arrives
at a later date changes something that you've already done.

It's not that crypto protocols are inherently complex, it's that the process
that creates them yields horribly complex designs.

>Would we be better off with a large variety of "good enough" simple designs
>and implementations which could reasonably be verified,

I don't know if you'd need a large variety, or even a small one, I think the
basic design above would cover the large majority of all cases where a secure
tunnel from A to B is required.  Even if you're using SSH or TLS, you're
probably not doing more than what's described above anyway, just in a really,
really complex roundabout manner.

Peter.