Re: [RFC] Ethernet Cheap Cryptography

[stephen@dino.dnsalias.com (Stephen J. Bevan)]

Pawel Foremski writes:
 > First, ccrypts task is to secure Ethernet, not IP.

Understood, but the vast majority of traffic running over Ethernet
that a user cares about is IP and so IPsec does the job.  Obviously
IPsec cannot handle non-IP traffic but the question is what non-IP
traffic do users want encrypted?


 > Secondly, IPsec won't decrease MSS in TCP encapsulated in PPPoE
 > traffic, for example. 

Various, commercial, IPsec products decrease the MSS for TCP
encapsulated in PPPoE.  I've not checked the Linux 2.6 IPsec code to
see if it does or if it can easily be made to.


 > > b) what traffic other than IP traffic needs to be encrypted.
 > 
 > PPPoE; Ethernet in general.

PPPoE carrying IP can be handled by IPsec as noted above.  That leaves
Ethernet in general.


 > > 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.
 > 
 > Only if the rekeying traffic is the only being transmitted. IMHO a border
 > case.

Unless you mask the size of your (re-)keying traffic by randomly
padding the packets then they can be detected even in the middle of
other traffic.


 > > Indeed, in IPsec, the equivalent of ccrypt is ESP and that's rather
 > > straighforward.  The complicated part is IKE, the userspace component
 > > that handles keying.  It is certainly possible to create something
 > > simpler than IKE (e.g. IKEv2 is somewhat simpler) but the devil is in
 > > the details.
 > 
 > Sure, but that's IMHO little bit off-topic in regard to ccrypt, which is
 > just an encryption back-end (eventually the rekeying daemon will sit in the
 > userspace).

Sure.  However, there has to be a user<->kernel API and the question
is whether what you have now is sufficient when a daemon is added or
whether it will need to change?  If it does need to change it will
need to be backwards compatible or need to be a separate API?

Also at least for IPsec, the kernel knows something about IKE in that
generally IKE traffic is not encrypted by IPsec.  Instead IKE has its
own encryption which it bootstraps using
shared-secrets/certificates/public&preivate key pairs.  In the case of
ccrypt either the ccryptKE protocol would need to bypass ccrypt or you
need to way to start off with known keys, but not the same keys every
time or that can be exploited.