Monoculture

[Perry E. Metzger]

Guus Sliepen <guus at sliepen.eu.org> writes:
> > In that case, I don't see why you don't bend your efforts towards
> > producing an open-source implementation of TLS that doesn't suck.
> 
> We don't want to program another TLS library, we want to create a VPN
> daemon. 

Well, then you might consider using an existing TLS library. It is
rather hard to make a protocol that does TLS things that is both safe
and in any significant way simpler than TLS.

> If you read our response, you'd have seen that we plan to make packet
> encapsulation in tinc work just like ESP, but optionally allow (parts
> of) the IV and HMAC to be omitted.

Unfortunately, those parts are rather dangerous to omit.

0) If you omit the message authenticator, you will now be subject to a
   range of fine and well documented cut and paste attacks. With some
   ciphers, especially stream ciphers, you'll be subject to far worse
   attacks still.
1) If you omit the IV, suddenly you're going to be subject to a
   second new range of attacks based on the fact that fixed blocks
   will always encrypt the exact same way.

We went through all that, by the way, when designing IPSec. At first,
we didn't put in mandatory authenticators, because we didn't
understand that they were security critical. Then, of course, we
discovered that they were damn critical, and that most of the text
books on this had been wrong. We didn't understand lots of subtleties
about our IVs, either. One big hint: do NOT use IVs on sequential
packets with close hamming distance!

So, to summarize, you can't take something "just like ESP" and alter
it and expect to have the same security properties. You can possibly
make some changes to it, but you have to know what you're doing to do
it, and even then it is a dangerous game.

Anyway, here is the central problem. Lots of us have personally gone
through the humbling experience of being involved in the design of
these things and discovering that there are all sorts of things that
are not nearly as obvious as one expected. I, for one, would suggest
that rather than proclaiming what you are going to do, you might want
to ask people what is and is not safe to alter.

BTW, the real argument against the existence of the so-called "Guild"
here is that most of us who would be part of that "Guild" consider
ourselves thoroughly unable to design new cryptographic protocols from
scratch without screwing up the first few times. Or, to put it another
way, if there is a "Guild", it is the "Guild Of People Who Are Aware Of
Their Own Ignorance".

-- 
Perry E. Metzger		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com