Guus Sliepen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
