Re: PBKDF2 support in the linux kernel

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

 



On Thursday, May 24, 2018 11:36:04 AM CEST Stephan Mueller wrote:
> Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki:
> 
> Hi Rafael,
> 
> > On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote:
> > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
> > > 
> > > Hi Rafael,
> > 
> > Hi Stephan,
> > 
> > > > 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?
> > > 
> > > If you retain the password information in the kernel, you could retain the
> > > derived key instead of the passcode.
> > > 
> > > If, however, you ask for the user password during resume, you need some
> > > user space component to query that password. The PBKDF can also be
> > > handled in user space along with the query.
> > 
> > In principle it is possible to pass a key to the kernel from user
> > space, but that doesn't guarantee the key to be a really good one.  It
> > depends on a user space component to do the right thing and IMO that is
> > risky.
> > 
> > And please note that the information contained in hibernation images may
> > be extremely sensitive (keys and similar).
> > 
> > > Or how do you want to handle the passcode?
> > 
> > The idea is to write a passphrase to the kernel via something like sysfs,
> > generate a key from it on the fly and store the key.
> 
> But what is the difference between a passcode and the key derived from it. The 
> derived key should only spread the assumed entropy in the passcode evenly. In 
> addition with its iteration count, it shall ensure that offline brute force 
> attacks of the passcode using stored protected data is made hard.
> 
> So, I do not see why it is risky to do the PBKDF in user space and then hand 
> the key to the kernel at runtime. It does not really matter if the attacker 
> sees the plaintext key or the passcode. If the attacker can access the kernel/
> user communication channel, we have a problem in any case.

OK, we'll follow this advice, thanks!

Best,
Rafael





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

  Powered by Linux