Marc Mutz wrote: > You seem to be the only person who does _not_ care for efficiency. > loop-AES has it's own crypto stuff, freeS/WAN has it's own crypto > stuff. xyz has it's own crypto stuff. That's very efficient, indeed. > Both from a kernel size and from a developer time pov. My point is that writing layer of code just for fun of writing kernel code is wrong. If the API was something that defined simple and fast low level cipher functions without any other bloat, it would make more sense. > > and speed? > > Speed is secondary. Opinions vary. > Maintainablilty and code auditing is what matters > here. If more modules use common cryptographic routines instead of > everyone implementing their own, bugs get fixed faster and the overall > product is better. Cryptoapi people seem to be very reluctant to fixing bugs, even if said bugs are pointed out to maintainer. One part of auditing cipher code is that they must be tested and run in user space. With AES cipher functions in loop-AES, this is very easy to do. Can you say the same for cryptoapi ciphers? > This is something _you_ don't want, obviously. You rather write the > fivehundreth implementation of AES for kernel space instead of fixing > the existing stuff. That wouldn't be much of a problem if you did stop > bashing cryptoAPI. I don't much care for cryptoapi in its present bloated form. > Yes, your code is better. It is even more performant. Wow. I never expected you to admit that. > But it is an island solution. We don't need that, see? We > need something that is _generic_. CryptoAPI is. At least it is more so > than what other people have come up with. Generic can be fast, unbloated and portable to user space and other operating systems. Cryptoapi isn't any of that. > But whining that everyone starts using cryptoAPI doesn't help. > Sending patches does. Bugging the maintainer to make sure they are > applied, does. Or putting out a release with bugs fixed. Remember, reason for releasing first version of loop-AES was that international crypto patch was just buggy as hell, didn't support distro vendor enhanced kernels, and so on. One of the major flaws that cryptapi still has (and loop-AES doesn't have), is that people can't choose a kernel that _they_ want. Instead, to use lastest cryptoapi version, they have to use a kernel that cryptoapi maintainer choosed to make patches for. There is is world of difference between someone else choosing your kernel for you, and you choosing your kernel for you. > There's more than disc encryption out there! Yep. Regards, Jari Ruusu <jari.ruusu@pp.inet.fi> - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
