On Thursday, 19 October 2006 05:57, Stephen J. Bevan wrote: > And if the packets come out of order i.e. you get a packet with a new > key followed by a packet with the old key?
As IV from invalid frames are saved ccrypt will synchronize anyway, but I was wrong in one aspect - in current implementation each reorder will cost two frames, not one. This could be possibly reduced to only one, but I must find a time to investigate that more. > If the keying is done manually an attacker won't know when the keys > are changed. However, if keying is coordinated over the same link via > a protocol (as is done with IKE for IPsec) then the attacker can see > (or at least guess) the packets carrying the keying protcol thus know > re-keying is going to occur. Simple random delay should do the trick. > For completness there are also switches that :- > > * take notice of the TOS/DiffServ bits in an IP header and will > re-order based on them Looks like a good reason to change frame type field so it does not look like IP packet. > * will re-order frames due to redundancy, load-balancing, > spanning-tree changes ... etc. In summary - using ccrypt with switches may lead to problems. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
