|To:||Herbert Valerio Riedel <hvr@xxxxxxxxxx>|
|Subject:||Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec|
|From:||Sandy Harris <sandy@xxxxxxxx>|
|Date:||Mon, 21 Oct 2002 19:27:07 -0700|
|Cc:||"David S. Miller" <davem@xxxxxxxxxxxxx>, Mitsuru KANDA <mk@xxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, cryptoapi-devel@xxxxxxxxxxx, design@xxxxxxxxxxxxxxxxxx, usagi@xxxxxxxxxxxxxx|
|References:||<email@example.com> <3DB41338.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>|
|User-agent:||Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0|
Herbert Valerio Riedel wrote:
I think the long term goal should be to get good crypto, at least IPsec and disk encryption,On Mon, 2002-10-21 at 04:41, David S. Miller wrote:
into the mainline, standard Linux kernel. Also ipv6 support. Projects like FreeS/WAN, USAGI
and cryptoapi seem necessary for getting the work done in the first place, but eventually you
want to do away with patch sets and just have all the good stuff built in to the kernel.
One payoff is integration. As I understand it, a current fully-patched kernel has either MD-5
or SHA-1 in the /dev/random driver, both in FreeS/WAN, and possibly both of those plus a
few other hashes in the CryptoAPI stuff. This is silly. The obvious fix is for everyone to use
the CryptoAPI hashes and ciphers.
However, crypto is a special case. The US government (among others) has a long history
of restricting it and, much as we would like to see good crypto in the standard kernel,
there's a good case for being very careful to keep code out of their clutches.
My suggestion would be that the standard kernel incorporate only one good hash
and one good cipher, specifically AES and SHA-256 since (last I looked) those
were en route to becoming requirements for IPsec. Let the FreeS/WAN and
CryptoAPI folk -- outside the US -- maintain the other ciphers and hashes. That
way we have a fallback position if the US goes back to being viciously restrictive.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||rtnetlink interface state monitoring problems., David Woodhouse|
|Next by Date:||IPsec query, Sriram Narasimhan|
|Previous by Thread:||Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec, Herbert Valerio Riedel|
|Next by Thread:||Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec, Jari Ruusu|
|Indexes:||[Date] [Thread] [Top] [All Lists]|