Re: [CryptoAPI-devel] OSI Layer 2 (and 3) Encryption.

[Beau V.C. B. <be...@bo...>]

>On Tue, 23 Apr 2002, Beau V.C. Bellamy wrote:
>> I was wondering if the Crypto-API included support for encrypting the
>> MAC (and IP) layers to provide a more secure networking environment.

>well... if you encrypt MAC's and IP's in the IP packet header... how are
>standard-konforming routers and switches supposed to work w/o getting
>confused?

I'm sorry to confuse and befuddle.  I really meant encrypting just the da=
ta at=20
level 2, not the header.  The ethernet frame data.  I use MAC to describe=
 the=20
whole layer,  perhaps incorrectly.

>or are we talking about some ethernet media being used as completely
>encrypted 'serial' line, w/o the usual ethernet frame structure?

Actually, the ethernet media I was refering to was 802.11 or Wireless=20
Ethernet.  Though, It could probably to appled to wired ethernet if you f=
eel=20
that someone might be able to gain unauthorized access to your network.

>> The idea is to augment WEP or perhaps replace it with a kernel based
>> solution with stronger encryption that would be both vendor neutral an=
d
>> more flexable.

>..what is WEP? can you give me some pointers/URLs? :-)

WEP stands for Wired Enquivalence Privacy.  It is based on a weak keyed X=
ORed=20
encryption algorithm that encrypts the ethernet frame data as it is=20
transmitted.  It is usually implimented in the hardware and It's main pur=
pose=20
is to prevent eavesdropping on wireless traffic.  But... It is also very=20
easily broken with the right software.

http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html

>> I've used FreeS/WAN before but feel it's not very good for this type o=
f
>> application.  After all, I'm not doing tunneling.

>fres/wan is not only for creating tunneling, it also provides means for
>authentification and/or encryption of untunneled connections...

I feel that FreeS/WAN is too heavywieght as all I really want is to encry=
pt=20
the ethernet frames.

>> I would be willing to devote a lot of time to hacking in this type of
>> support.

>I'd like to learn more about what you're going to implement :-)

I'm more than willing to talk about about this further...

>regards,