[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-crypto
Subject:    Re: Wiping free space on encrypted filesystem.
From:       Jari Ruusu <jari.ruusu () pp ! inet ! fi>
Date:       2002-02-23 19:50:16
[Download RAW message or body]

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/

[prev in list] [next in list] [prev in thread] [next in thread]