I'm progressing well on the SEC1 implementation. I now have HASH (non
HMAC) , DES and AES working properly.
So it is now time to look at AEAD.
I don't know much yet about crypto algorithm so forgive me if I ask
stupid questions.
The SEC1 doesn't have the IPSEC descriptor that SEC2 has. However, the
SEC Lite Descriptor Programmer's Guide tells us to use the
hmac_snoop_no_afeu descriptor to perform IPSEC.
Are both descriptors (more or less) equivalent ? Can the Talitos driver
be easily modified to use that descriptor ? Are there any limitations or
impossibilities to do so ?
Christophe
On Thu, Apr 24, 2014 at 9:34 AM, leroy christophe
<[email protected]> wrote:
> I'm progressing well on the SEC1 implementation. I now have HASH (non HMAC)
> , DES and AES working properly.
Why DES? More than a decade ago, the first Linux IPsec implementation
refused to do single DES because it was known to be insecure.
http://www.freeswan.org/freeswan_trees/freeswan-1.97/doc/faq.html#noDES.faq
At that time, we had to have DES internally so we could implement triple DES.
We just did not provide single DES in the user interface or the list of cipher
suites we would negotiate.
Today you could consider dropping DES entirely since AES is so widespread,
far faster than triple DES, and thought secure. As of 2001 or so, it roughly
doubled IPsec throughput:
http://www.freeswan.org/freeswan_trees/freeswan-1.97/doc/performance.html#perf.more
Today it probably does even better; there has been a lot of work on
optimising it.
> So it is now time to look at AEAD.
A fine idea. AES-GCM is the first obvious candidate. Newer work includes:
http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-00
There is a competition for new AEAD methods, still in early stages so it
does not yet give any solid results you could implement. Likely worth a
look, though:
http://competitions.cr.yp.to/caesar.html
https://aezoo.compute.dtu.dk/doku.php
> I don't know much yet about crypto algorithm so forgive me if I ask stupid
> questions.
An area that was a problem a decade ago was forward secrecy.
http://www.freeswan.org/freeswan_trees/freeswan-1.97/doc/interop.html#req.features
"FreeS/WAN default is to provide perfect forward secrecy. ... The PFS
settings on the two ends must match. There is no provision in the
protocol for negotiating whether to use PFS; you need to either set
both ends to use it or set them both not to."
The difference is what happens if an enemy gets the keys used in
authenticating connection setup. Without PFS, that lets him obtain
actual encryption keys and read everything sent on those connections,
possibly including old messages he has archived. With PFS he gets no
message content without doing a man-in-the-middle attack (using the
authentication keys to trick servers into giving him data that lets
him get encryption keys), he has to do another such attack every time
you change keys, and there is no way to do one for old messages.
I do not know if the revised RFCs have fixed this, but I am very much
of the opinion that PFS should be the default everywhere.