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 <smuel...@chronox.de> 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
