On Friday 19 November 2010 21:04:25 Matthew Toseland wrote: > 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.. > Changes from 85ffa354f1544bdae6db9e196b6df71314f68e78 toe35b9d353b4b68b120e8cab5edd77c03900014f0: - Start seqnums and message id's at different numbers in each direction. - Indenting. - Create and use a separate cipher in each direction. - Move firstSeqNumUsed to KeyTracker. - Don't wait for an ack when only acking. - Delete onRekey(). - Move all sequence numbers, including watch list offset, to SessionKey. - Move watch list offset, but not the watch list itself, to SessionKey.
<toad_> zidel: you should move the code that uses the sequence numbers to SessionKey as well - That's just refactoring, a matter of cleanliness. [21:31:28] <toad_> zidel: and it's possible to have two SessionKey's live at the same time so having the watch list in (or keyed on somehow) SessionKey would make a lot of sense imho - More serious, probably could cause connection problems IMHO. -------------- 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/20101221/079c505f/attachment.pgp>
