great, I was about to write up a similiar list :-) so now I'll just have to add some comments of mine... just to clarify something in advance: 1. there is the 'official' kerneli crypto patch, which _still_ suffers from most of the mentioned problems, 2. I've started a new branch, named the cryptoapi re-package/distribution/whatever, which is based on the international crypto patch, and tries to adress the current problems, while giving the oppurtunity to experiment on new approaches. the plan is to either merge back features of it to the official kerneli patch, or maybe to switch entirely to it if it should become reasonable. the cryptoapi distro started as a proof-of-concept, that modularizing it almost completely can be done, in order to defeat the patch-hassle-annoyance argument. so actually this re-packaging does surely doesn't _change_ the kernel source more, as the loop-AES approach does. I'd like to keep open the development to this cryptoapi project, in order to stimulate the exchange of information; and in order to monitor changes which go in by more eyes... so, I've registered at sourceforge while heavy discussions went on here; http://sourceforge.net/projects/cryptoapi/ On Tue, 10 Jul 2001, Dale Amon wrote: > * BUG: block size problem > Has a current work around, Herbert has stated > he will soon have it fixed in code. this one has been fixed, or better, I've already implemented a workaround quite some weeks ago, it's been available in the cryptoapi branch, but this one requires to modify the existing kernel loop.c module, (just like loop-AES does, btw!!) > * BUG: SMP issue > None of us has had to deal with it, but Herbert > has stated he will have it fixed in code soon. it's fixed in CVS already, this one does not require any change to the kernel source. (actually 'fixed' does mean, it works now, but I'm not satisfied completely with the end result in terms of design) I haven't actually done many tests of it yet, just some stress testing on a SMP box, like many concurrent reads/writes on a fully threaded, variable blocksize filesystem, i.e. kernel compiles on XFS, unpacking and diffing kernel sources and alike... > * 2.2 not readable on 2.4 > Question: is this really unknown or are the systems > in question ones that were set up with the old > absolute block number problem? If not, perhaps > it is an issue for study using a small test case. > Is there anyone here who is actually a > mathematician/cryptographer? this one is to be addressed by the planned user space tools (see lateron) I believe the reason to be the blocksize/IV calculation btw. I would have already investigated it, if I had the hardware/hdspace/time to install various kernel & partitions without caring about losing data while experimenting... > * performance loss due to non-reentrancy > Presumably if Herbert fixes the SMP issue, he > sorts this as well. I might note that I play > my Mozart CD on this laptop while editing on a > loopback AES partition and have no problems. since no (spin)locks are involved in the actual fix in CVS, I do not expect major perfomance impact with this... > * kernel bloat. This is probably a non-issue. Linus > will at some point go for hooks into the kernel > for encryption support. The API for that will perhaps > be influenced by kerneli but that will not be the > final word. I do suspect it will have great influence > because everyone is using the new util-linux which > supports the new api for loopback encryption types. > In that sense we are already main stream. > (The util-linux support is mainstream debian now) the actual cryptoapi, without the ciphers and loop encryption module is quite small, I wouldn't call a ~5k module to be any major kernel bloat... something actually planned, but not implemented yet, is a user space suit of cryptoapi tools for: *) converting between different ciphers/passphrases/blocksizes/block chaining modes (this should include a way to migrate from 2.2 encrypted volumes and 2.4. non-512 based encyrption to the to-become-default 2.4-512-byte based encryption style) > I'm pretty sure I remember a kernel discussion on some of > the issues and there is a desire to have one single crypto > API that is available for all purposes, loopback fs or other. > While loopAES is very nice for now, and perhaps some of the code > will find its' way into the kernel, I don't see that as the > likely way things will go for 2.6.x. I'm very sure that a > loopback module will not contain its' own crypto. It will share > it with other tools and applications. We are not going to see > 5 loadable modules providing different services each with its' > own implimentation of AES. ...which leads to a request (for comment) I have; what do you (all who feel interested) thing, should (not) a crypto API allow/provide for? before doing any major redsign, it's required to know what the ones who might use it would want it to look like... :-) maybe the actual api is already ok, and doesn't need any redesign, but only cleanup.. I'll give some points to start arguing with: :) what to provide: *) providing a general (kernel space) service for ciphers (block and stream), digests and closely related cryptographic algorithms. *) /proc interface (already available) *) dynamic selection/loading of ciphers by strings (enums require recompilation when a new cipher is added and are less unique, string based identification may need a few more bytes for storage and logic, but it pays off in terms of flexibility); fits well with /proc interface *) support for algos implemented in hardware (the actual API has already provisions for atomic and non-atomic encryption functions, and sw vs. hw based implementations) *) syscalls to allow user space to encrypt data by cryptoapi (n.b. is surely not efficient, but rather meant for the case, where the user space wants to make use of hardware implementation, or maybe to test the ciphers) *) which other subsystems can benefit from this: *) encrypted network encapsulation (see cipe and freeswan) *) encrypting loop filter (that's the only known use of the cryptoapi as of now) *) filesystems with integrated encryption support (CFS perhaps?) *) swapspace encryption, or for the paranoid ones, encrypting (part of the) RAM :) *) any other ideas? it should be noted, that other things, such as smartcards used for authentification should be done in userspace since it's not required to at all to be done in kernelspace... IMHO (e.g. pam modules, enhanced util-linux tools) greetings, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@xxxxxxxxxx / Finger hvr@xxxxxxx for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
