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. - 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
