Re: [RFC] Ethernet Cheap Cryptography

[Dawid Ciezarkiewicz <dpc@asn.pl>]

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.