On Wed, Oct 01, 2003 at 10:20:53PM +0200, Guus Sliepen wrote: > > You clearly formulated what we are doing! We want to keep our crypto as > simple and to the point as necessary for tinc. We also want to > understand it ourselves. Implementing our own authentication protocol > helps us do all that. > > Uhm, before getting flamed again: by "our own", I don't mean we think we > necessarily have to implement something different from all the existing > protocols. We just want to understand it so well and want to be so > comfortable with it that we can implement it ourselves.
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. If you insist on not using ESP to encapsulate the packets -- which in my opinion is a silly restriction to put on yourself; the ESP encapsulation is extremely simple, to the point that one of my former employers has a fully functional implementation that works well at moderate data rates on an 8088 running MS-DOS! -- TLS is probably exactly what you're looking for. Note that it's *entirely* possible to use ESP without using IKE for the user/host authentication and key exchange. Nothing is preventing you from using TLS or its moral equiavalent to exchange keys -- and looking at some of the open-source IKE implementations, it's easy to see how this would be a tempting choice. Indeed, there's no reason your ESP implementation would need to live in the kernel; I already know of more than one that simple grabs packets using the kernel's tunnel driver, for portability reasons. However, if for what seem to me to be very arbitrary reasons you insist on using an encapsulation that's not ESP, I urge you to use TLS for the whole thing. As I and others have pointed out here, if you're willing to *pay* for it, you can have your choice of TLS implementations that are simple, secure, and well under 100K. Compare and contrast with the behemoth that is OpenSSL and it's easy to see why you wouldn't want to use the open-source implementation that is available to you now, but there is no reason you could not produce one yourself that was much less awful. You say that you object to existing protocols because you want simplicity and performance. I say that it's not reasonable of you to blame the failures of the existing *open-source implementations* of those protocols on the protocols themselves. I think that both the multiple good, small, simple commercial SSL/TLS implementations and the two MS-DOS IPsec implementations are good examples that demonstrate that what you should object to, more properly, is lousy software design and implementation on the part of many open-source protocol implementors, not lousy protocol design in cases where the protocol design is actually quite good. So if you're going to set out to fix something, I think if you're trying to fix the protocols, you're wasting your effort -- there are existing, widely peer-reviewed and accepted protocols that are *already* about as simple as they can get and still be secure the way users actually use them in the real world. I think that it would make a lot more sense to fix the lousy implementation quality instead; that way you seem much more likely to achieve your security, performance, and simplicity goals. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
