Re: PBKDF2 support in the linux kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Samstag, 26. Mai 2018, 14:17:11 CEST schrieb Jeffrey Walton:

Hi Jeffrey,

> On Thu, May 24, 2018 at 5:11 AM, Stephan Mueller <smueller@xxxxxxxxxx> 
wrote:
> > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
> > 
> > Hi Rafael,
> > 
> >> So the problem is that Yu would like to use this for hibernation
> >> encryption
> >> done entirely in the kernel.
> > 
> > But why do you need to perform PBKDF in kernel space?
> 
> I may be mis-parsing things, but using audited kernel code is a matter
> of governance and good security engineering. I don't believe it is not
> a matter of laziness.

I agree that using a well-vetted crypto implementation is the best thing(TM) 
:-)

But there are two competing problems we face in our discussion:

- code should only execute with elevated privileges like kernel space if 
really needed (i.e. PBKDF should not be in the kernel)

- security related code should be vetted (which arguably is the case when the 
discussed PBKDF is part of the kernel)
> 
> If he/she were to add their own userland code then he would surely be
> criticized for rolling his own implementation.

For crypto implementations, the correctness can always be verified using 
public test vectors. For PBKDF, the RFC has them.

The question remains about whether the code is (as much as possible) free of 
security bugs. Here, using well-vetted and reviewed code would make most 
sense.

The problem is that the two conflicting problems do not seem to allow to make 
a straight-forward decision. Some folks think the one problem is valued higher 
than the other. In general, I personally fall into the camp that likes to not 
have code executing with elevated privileges unless absolutely required. I 
understand that others have the opposite view. And I do not know how we can 
reach an agreement.

All I can say is: If you do not want to have a large scale crypto lib like 
libgcrypt in your code tree (which naturally has code that you do not need and 
may cause problems), you may simply use a PBKDF implementation in user space 
and use AF_ALG to access the crypto primitives. This would mean that the code 
size you need in user space could be fairly limited.

Unfortunately I cannot speak about other people's AF_ALG PBKDF implementation. 
The design of libkcapi is such that you can pull individual C files (i.e. only 
those code parts you really need) out of the code tree and add them to your 
project code path (see the bottom of libkcapi's README for details). This way, 
you can minimize the compiled code which would benefit also the overall 
security as the attack surface is kept small. And as long as you simply pull 
these C files, you do not maintain your private code, but you can benefit from 
any updates to libkcapi in the future.

Ciao
Stephan





[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux