Hi Nikos, On 08/07/2016 09:44, "Nikos Mavrogiannopoulos" <n...@redhat.com> wrote: >On Fri, 2016-07-08 at 08:34 +0000, Fossati, Thomas (Nokia - GB) wrote: >> Hi Nikos, Stephen, >> >> It seems to me that both your views (high resistance to traceability >> and >> low resource investment on server side) can be accommodated in a >> single scheme. >> Going back to the hash chain proposal that Stephen did a few emails >> ago on >> this same thread. If: >> 1. the length of the hash chain is the shortest between the lengths >> each >> peer proposes, and > >Hi, > How would the hash chain matching work for a server handling multiple >clients?
Sorry, I'm not sure I understand the question. Are you asking what happens if there is an Id collision between two separate hash chains? If so, in general the nature of the keyed hash used to produce the chain would help keeping the number of collisions low. In case an Id is a dup, the server can spot the condition and signal it back to the client. Cheers, t _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
