Re: [RFC] Ethernet Cheap Cryptography

[Dawid Ciezarkiewicz <dpc@asn.pl>]

On Sunday, 15 October 2006 23:35, you wrote:
> > Hi,
> >  I'd be thankful for your opinions about that idea. Please forgive me any
> > nuances that I didn't know about.
> 
> This limits the system to only talking to one other system on the same 
> link.  I guess you could have per-MAC keys and associate the crypto info 
> with neighbor cache entries.

The idea is to use vlan and macvlan devices to separate encrypted traffic - 
as you can just encrypt vlan device. Other than that - yes ccrypt was 
considered as solution for point-to-point links.

> Likely need a cryptographer to review the protocol -- blindly using the 
> first block of every encrypted packet as the IV smells problematic, for 
> example.

Cryptographic part needs attention. I'm not a cryptographer and no 
cryptographer have checked the idea or code.

And yes - this is little problematic, but I think the solution is good 
enough - there is little chance to inject valid upper level packet, and even 
if such event occur - there is no chance that can carry valid hostile 
information.

The magic function is is_decoded_buffer_valid, which - using upper level 
info - will just drop packets that weren't encrypted correctly. There are 
little chances that spoofed frame after decryption will look like good 
packet - for IPv4 I estimate them to be much less than 1 to 256 * 256 * 32 
(2097152) and this can be rather easily improved.

Injected packets that will not pass such validation will not change stored IV, 
so transmition will not be affected. And even when such frame will pass - it 
will probable consist of garbages - the only effect will be using bad IV in 
the next encryption - so next good frame will be dropped.

If ccrypt will be considered reasonable I was thinking about kernel warnings 
on spoofing tries detection, using simple bad frames counters.