Hi Ted,
I'm not really here to criticize or judge the past. AF_ALG exists now. It
is being used. Can we just make it better? Or are we going to whinge at
every user that tries to use (and improve) kernel features that (some)
people disagree with because it can 'compromise' kernel security?
Another point of view is that it was arguably a mistake, and we
shouldn't make it worse.
Fair enough. I'm just voicing the opposite point of view. Namely that
you have created something nice, and useful. Even if it turned out not
quite like you thought it would be in hindsight.
Also, if speed isn't a worry, why not just a single software-only
implementation of SHA1, and be done with it? It's what I did in
e2fsprogs for e4crypt.
If things were that simple, we would definitely not be having this exchange.
Lets just say we use just about every feature that crypto subsystem provides
in some way.
What I'm saying here is if you need to code PBPDF2 in user-space, it
_really_ isn't hard. I've done it. It's less than 7k of source code
to implement SHA512:
https://ghit.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ext2fs/sha256.c
and then less than 50 lines of code to implement PBPDF2 (I didn't even
bother putting in a library such as libext2fs):
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/misc/e4crypt.c#n405
This is all you would need to do if we don't put PBPDF2 in the kernel.
Is it really that onerous?
No. And in fact if you read upthread you will notice that I provided a
link to our implementation of both PBKDF1 & 2 and they're as small as
you say. They do everything we need. So I'm right there with you.
But, PBKDF uses like 4K iterations (for WiFi passphrase -> key
conversion for example) to arrive at its solution. So you have
implementations hammering the kernel with system calls.
So we can whinge at these implementations for 'being lazy', wring our
hands, say how everything was just a big mistake. Or maybe we can do
something so that the kernel isn't hammered needlessly...
Regards,
-Denis
