Guus Sliepen <[EMAIL PROTECTED]> writes: > On Mon, Sep 29, 2003 at 09:35:56AM -0700, Eric Rescorla wrote: > > > Was there any technical reason why the existing cryptographic > > skeletons wouldn't have been just as good? > > Well all existing authentication schemes do what they are supposed do, > that's not the problem. We just want one that is as simple as possible > (so we can understand it better and implement it more easily), and which > is efficient (both speed and bandwidth).
In what way is your protocol either simpler or more efficient than, say, JFK or the TLS skeleton? > > > And I just ripped TLS from the list. > > > > Define "ripped". This certainly is not the same as TLS. > > Used as a skeleton. Don't ask me to define that as well. It doesn't appear to me that you've used the TLS skeleton. The protocol you described really isn't much more like TLS than it is like STS or JFK. On the other hand, all these back and forth DH-based protocols look more or less the same, except for some important details. > > That's not the same a sdoing a thorough analysis, which can take > > years, as Steve Bellovin has pointed out about Needham-Schroeder. > > True, but we can learn even from the bullet holes. Again, it's important to distinguish between learning experiences and deployed protocols. I agree that it's worthwhile to try to do new protocols and let other people analyze them as a learning experience. But that's different from putting a not fully analyzed protocol into a deployed system. > > Look, there's nothing wrong with trying to invent new protocols, > > especially as a learning experience. What I'm trying to figure > > out is why you would put them in a piece of software rather > > than using one that has undergone substantial analysis unless > > your new protocol has some actual advantages. Does it? > > We're trying to find that out. If we figure out it doesn't, we'll use > one of the standard protocols. Well, I'd start by doing a back of the envelope performance analysis. If that doesn't show that your approach is better, then I'm not sure why you would wish to pursue it as a deployed solution. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]