On Saturday 13 November 2010 17:43:48 Martin Nyhus wrote: > On Tuesday 9. November 2010 19:49:39 Matthew Toseland wrote: > > What are your thoughts on this issue? IMHO the moment we encrypt two > > packets with the same key and the same sequence number game over. We need > > to be absolutely sure we will rekey before that happens, and if the rekey > > fails we will disconnect. The other option - using a very long counter - > > is interesting, possibly in combination. What does the packetFormat branch > > do now? > > I agree that we can't let the sequence numbers wrap since we use them for > crypto. c73cce16..026a2845 implements the first solution you mentioned, > refusing to send packets until after a new rekey (and starts one when needed > of course). b2ca18a8 improves it sligthly by starting the rekey 100 packets > before we would stop sending (this number should probably be higher, or based > on how fast we send packets).
Ok. However IMHO packet numbers need to be per-key, and it is possible for two keys to temporarily be live at once (at least it should be, implementing it that way in old FNP fixed some largish issues). > > As for the message ids, we are safe for now because the window is so small, > but I'll try to add some more checks just to make sure. > Changes from e20d271a81a6520049e6658536fe4c43a7c387b8 to 85ffa354f1544bdae6db9e196b6df71314f68e78 - Per-peer RNG now used for padding length as well as contents. - Never reuse the sequence number we started at when we rekeyed. Refuse to send packets until the next rekey completes. - Bugfixes related to NUM_SEQNUMS not being maxint. - Start rekeying 100 packets before we would hit the buffers. - Separate lock for sequence numbers. - Rename getSequenceNumber to allocateSequenceNumber. - Comments. - Logging. 7618b16d0448ec6a470c16a7f7d9d6eb9e6f137e - IMHO sequence number should be a property of the SessionKey. It is possible to have two keys used at the same time for a while because of timing issues, the two sides don't always agree on which is valid. You don't use SessionKey but maybe you should? Otherwise having a single sequence number potentially for two keys can cause problems. Having only a single key caused problems in practice when two connection setups complete at once. I appreciate this might cause quite a bit of refactoring.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101119/a6042dd5/attachment.pgp>
