On Mon, Sep 29, 2003 at 11:54:20AM -0700, Eric Rescorla wrote:

> > 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?

Compared with JFK: http://www.crypto.com/papers/jfk-ccs.pdf section 2.2
shows a lot of keys, IDs, derivatives of keys, random numbers and hashes
of various combinations of the previous, 3 public key encryptions and 2
symmetric cipher encryptions and HMACs. I do not consider that simple.

Compared with the entire TLS protocol it is much simpler, compared with
just the handshake protocol it is about as simple and probably just as
efficient, but as I said earlier, I want to get rid of the client/server

> 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.
> 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.

I will not repeat our motiviations again. Please don't bother arguing
about this.

Met vriendelijke groet / with kind regards,
    Guus Sliepen <[EMAIL PROTECTED]>

Attachment: signature.asc
Description: Digital signature

Reply via email to