On Tuesday 9. November 2010 14:20:19 Matthew Toseland wrote: > > > 7b2a66a803688e1be8d70f3e8eb3854f7b900242 > > > - You should add and subtract the full overhead. Is HMAC_LENGTH the > > > totality of the overhead apart from what's already accounted for in > > > packet.getLength()? (I.e. the sequence number?) Looks like it is ... > > HMAC_LENGTH is the length of the HMAC. > IMHO the packet length calculations for padding should be based on the full > length. Are they?
It is based on the length of the packet (HMAC, sequence number etc.), not including UDP headers, which sounds right to me since that is what maxPacketSize covers. > Why would paddedLen *ever* be larger than maxPacketSize? I thought one of > the purposes of this was to enable us to generate packets of almost any > size? Granted it can be in old FNP, which is the origin of that code. My bad, looks like it can't happen. > > > e2b0b8ee4e54b95839facdc66c781663e9f5626d > > > - Did you double check that this is all either exclusively your own > > > code or drawn from files that have the GPL2+ headers already? > Actually some of it is copied from various parts of our code, you should > check that those files already have GPL2+ headers (I think they do..) I looked over it again and both IncomingPacketFilterImpl and NewPacketFormat has code from FNPPacketMangler which is GPL2+. The only other thing I can remember copying is ReceivedPacketNumbers into SparseBitmap, but I didn't add any headers to it. > Hmmm. Calling your allocation method getSequenceNumber() is confusing, > especially when packet has a similar method which is just a getter. It > would help to change it to allocateSequenceNumber(). Done (d4fe2f5) > > > "it" here means the window I guess. Should it be updated incrementally > > > i.e. on every packet? > > I don't see why it shouldn't, as only the sequence numbers that are > > outside the window are updated. > > IIRC the window is updated every time we reach half way into it? Half the window is behind the highest received sequence number, and I guess it isn't explained very well... The window is moved every time we get a packet with a higher sequence number. > > > > 2e33916fee9106b0e985f1bf974ed3d8fda40f42 > > > > - Any particular reason for always starting from 0 on new format? > > Done (807ea29) > This starts with the same random sequence number in each direction afaics? > That could be confusing. I changed it in 71325e2 to use different numbers in each direction, so it should be clearer that they are independent. > We should probably restrict the random range to not be too close to > rollover. Especially as we need to be absolutely sure we rekey before we > rollover, if necessary shutting down the connection to avoid sending two > packets encrypted with the same sequence number. The rollover back to 0 isn't a problem, the problem is reusing sequence number (dealt with in another patch), so starting close to the maximum value shouldn't matter. > Also, we had originally planned to have a separate cipher key in each > direction. This should be easy to implement now, and rather harder later > on. Done in 71325e2..8e63721
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
