Hi Stephan,
On 05/24/2018 12:57 AM, Stephan Mueller wrote:
Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers:
Hi Eric,
"Not having to rely on any third-party library" is not an excuse to add
random code to the kernel, which runs in a privileged context. Please do
PBKDF2 in userspace instead.
I second that. Besides, if you really need to rely on the kernel crypto API to
do that because you do not want to add yet another crypto lib, libkcapi has a
PBKDF2 implementation that uses the kernel crypto API via AF_ALG. I.e. the
kernel crypto API is used and yet the PBKDF logic is in user space.
http://www.chronox.de/libkcapi.html
I actually don't see why we _shouldn't_ have PBKDF in the kernel. We
already have at least 2 user space libraries that implement it via
AF_ALG. ell does this as well:
https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/pkcs5.c
One can argue whether this is a good or bad idea, but the cat is out of
the bag.
So from a practical perspective, would it not be better to make this an
explicit kernel API and not have userspace hammer AF_ALG socket a few
thousand times to do what it wants?
Regards,
-Denis
