[added cc to FreeS/WAN list and random.c author, and set followup-to] Herbert Valerio Riedel wrote: > > 1. Crypto support (no algorithms). This can go into the official kernel, > > at least once the API is stable. ... > > > 2. Crypto modules. Can probably not to inte the official kernel due to > > crypto export regulations. That doesn't work, at least not for US export regs. Any "crypto-shaped hole" -- any interface or plug-in support that is specifically for cryptography -- is restricted in exactly the same way as the crypto itself. However, if you use a generic multi-purpose interface, such as the Linux kernel modules interface or for IPsec, the interface that netfilter provides, then that interface is not restricted. Can the encrypted file system stuff use such an interface? Could FreeS/WAN? The good news about export regs is that, after two court losses in the Bernstein case (http://www.eff.org/bernstein/) the US gov't "liberalised" their regs so they now partially comply with the Wassenaar agreement (http://www.fitug.de/news/wa/index.html). That agreement says "public domain" code is exempt from its restrictions, period. Until Bernstein, the US ignored that and applied full restrictions. Now they only require notification for export of"public domain" source code. So under current regs, as long as kernel.org does some paperwork (which I think they have) there's no legal problem for crypto in the Linux kernel source. Of course, that does not cover US companies such as Redhat who might want to ship compliled code. It should, since the US has signed the Wassennaar agreement, but ... Also, it does not change the FreeS/WAN project's policy of carefully ensuring that their code is entirely developed outside the US so that even if the US gov't change the rules again, they cannot restrict FreeS/WAN. > some people also suggested splitting the ciphers up into > patented/non-patented, weak/strong, ... Why on Earth would you want either patented or weak ciphers? As I see it, you want only a very few ciphers, ideally only one. Simplicity is a great virtue in security software. Currently, I think the possible collection of crypto in the kernel is: drivers/char/random.c #define for either MD5 or SHA-1 MD4 for the TCP sequence # part ipsec both MD5 and SHA-1 3DES JuanJo's patches for ipsec AES cipher some of SHA-256, -384, -512 loop stuff multiple ciphers As far as I know, these are independent/duplicated. Many kernels will have two copies of MD5, one each in the random and ipsec code. If you use AES in both an encrypted file system and in IPsec, you'll have two copies (versions?) of the AES code. This is not a major problem, but it appears worth fixing. > > 3. Encrypted loop driver. > > > > What do you think? > good point... > > the crypto api itself almost kernel version independent, so it might > well justify splitting it from the cryptoloop application, which is the > biggest headache to keep in sync with the rest of the kernel... > > that's one of the reasons why I started to split off the loop-modifying > stuff into a patch of it's own (loop-jari/hvr patches)... > > now I'll just have to figure out a way to accomplish the split without > letting maintenance get unreasonable... I'd like to see, in the main kernel tree, one good hash and one good cipher. Then use them in all the above places. For AES in IPsec, the default (and the only required) algorithms are AES with 128-bit key and SHA-256. That makes them the obvious choices. You might want somewhat more than that. IPsec would probably want MD5, SHA-1 and 3DES for interoperability, RFC compliance and backward compatibility. I'd suggest the standard kernel not provide these. Keep them as part of FreeS/WAN so they cannot become "contaminated" with US code during kernel maintenance. I don't understand why random.c uses MD4; for all I know there are good reasons to keep it. There may be overhead issues. How fast is SHA-256 compared to MD5 and SHA-1? This mainly a concern for random.c. If you are doing AES, then it is likely both easy and a good idea to add Twofish and Serpent. These were final round AES candidate ciphers, so they've survived intensive analysis and there is code for them with the same interface as AES. Both have completely open licenses. If you're doing SHA-256, it may make sense to do SHA-384 and -512 as well. I think they use much the same code. - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
