Marc Mutz wrote: > > Sandy Harris wrote: > > > <snip> > > Do the encrypting file systems require anything besides a good block cipher? > > > > No. > > > So what does it take to get a library into the kernel that does at least: > > > > 3DES > > Rijndael > > SHA hash (initialise with fixed constants) > > We have all that already in kerneli. > > > SHA HMAC (initialise with secret key material) > > probably trivial to add. > > > public key primitives (probably signature only) > > > I thought that Pk encryption was only used for key exchange. That could > happily live in userspace. Yes, for IPSEC. But if you want the kernel to authenticate binaries before loading them, then you may need public key stuff in the kernel. > However, I now wonder how authentication is > done? Is is done via symmetric enciphering of the hash value or using > PK? If it's the latter, does all and every IPv6 packet require a PK run? > Good bye performance. For IPSEC, you use the public key stuff to authenticate a key negotiation, preventing a man-in-the-middle from posing as either player and subverting the negotiation. The negotiation produces an encryption key and an HMAC key. Packet authentication is done with the HMAC. This is an SHA or MD5 hash of the packet data, except with the registers in the hashing code initialised from the HMAC key rather than from standard constants. It therefore does more than a simple hash would, authenticating not just that the packet data was not changed in transit but also that the sender knew the HMAC key. > I should look at the RFC's But it's so _much_ stuff. There is shorter > treatment by TimeStep and I'll look at it _now_. > .... > OK, apparently AH consists of a MAC, and that should be SHA HMAC, no? So > where is the need for PK in IPSec other than probably for key exchange? For IPSEC, there's no need I can see. To secure program loads, though, you appear to need some variant of PK to sign the executables. I wonder if that could be in a user-space loader though, rather than the kernel. Or would some variant of the HMAC scheme be enough to control loading? Instead of a signature on each file, just store an HMAC? Checking it shows both that the file is uncorrupted and that the storer had the required key. Overheads are essentially identical to calculating a hash. Methinks you need the hash anyway to verify non-corruption. For a public key signature you need both the hash and the public key operations, so this is much cheaper. Of course this can be subverted by an attacker who has root on the machine, but so can the public key scheme, I think. > > What else is necessary or desirable? Would the maintainers of the various > > packages use such a library? > > Apparently not. The kerneli patch is out there since 1998 and the only > user of this is still loopback crypto. I have not heard of a reason for > why it is not used, except maybe from the FreeS/WAN people: It's not > free of US hands. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
