"Tener, Stuart B., IT3 , USNR-R" wrote: > Starting from the presumtption that your code is less buggy as > well as faster, would you now consider doing a kernel implementation of > it since the Linux kernel is now going to support encryption? Loop-AES is a kernel implementation. If you meant kernel patch version, look for kernel-2.4.*.diff in the tarball. > The reason I see for it is that if you wish to do encrypted > boot/root, or have raid volumes mounted on boot-up be encrypted the > kernel version will do this much more easily than using loop devices and > provide a smoother form of implementation. I also believe the advantages > of your code (if inclusive) to the kernel would be allowing Linux to > leverage your code for other places where it needs to apply encryptive > technology (network traffic encryption?). Do you realize how many different kernels people use? If you want to provide tens (hundreds?) different patches for all of those kernels, feel free to do so. Loop-AES' solution is to provide one kernel patch version that works with latest stable mainline kernel and externally compiled module version that works with just about any maintained stable kernel out there. Loop-AES supports encrypted root even if loop is compiled as module. See loop-AES' README and build-initrd.sh for more details. > The other question I have is, if RedHat was desirous of > embedding your loop-AES package within their distribution how would you > feel about that? Red Hat people know where loop-AES' source is. Merging that to their distro is their decision. As of this writing, my plan is to support Red Hat kernels no matter what crap they merge to their kernels. Regards, Jari Ruusu <jari.ruusu@xxxxxxxxxx> - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
