E_K(R); that is, R is encrypted with the server's long term key. (I meant to specify that...)
> -----Original Message----- > From: Martin Thomson [mailto:martin.thom...@gmail.com] > Sent: Tuesday, March 28, 2017 11:37 AM > To: Scott Fluhrer (sfluhrer) > Cc: <tls@ietf.org> > Subject: Re: [TLS] The alternative idea I had for token buckets. > > I'm sorry, but I don't understand this proposal. I'm losing you when you say > E(R) without specifying the key that you are using. > > On 28 March 2017 at 10:21, Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> > wrote: > > Here’s how it would work: > > > > > > > > - The server has a long term secret key K, which it never gives out > > > > - When the server wants to give a token to a client, it picks a > > random value R, and securely gives the client the values R and E_K(R) > > > > - When the client wants to use the token, it picks a value i, and > > computes the key Hash( R || i). It uses that key to protect the > > message, and also sends the server the values E(R) and i > > > > - The server decrypts the value E(R) to recover R, it computes > > Hash( R || i) to recover the message key, and then decrypts the > > message > > > > > > > > That way, the server doesn’t have to send the client N different > > tokens… > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
