[dm-crypt] Alternate KDFs (Key Derivation Functions) in cryptsetup

[dm-crypt] Alternate KDFs (Key Derivation Functions) in cryptsetup

[Mike]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

Hi,

I started some work on adding changes to the cryptsetup code to allow for
the use of different KDFs during key derivation, as it's a feature I
believe would be useful. I was thinking of adding both bcrypt and scrypt as
available alternative KDFs that the user may choose from.  As I didn't wish
to alter the current header structure, if there's a different KDF used
during format, that KDF would have to be specified during volume open, as
well any other relevant operations.

If I created a patch for all the changes and submitted them for review,
would there be an interest in incorporating them into the main cryptsetup
branch? I've already incorporated the scrypt reference implementation into
the cryptsetup codebase and confirmed that the official test vectors match
the output. I would also be interested in helping out with any other
updates that might need to be made.

Thanks for your time,
Mike

[-- Attachment #2: Type: text/html, Size: 1000 bytes --]

Re: [dm-crypt] Alternate KDFs (Key Derivation Functions) in cryptsetup

[Milan Broz]

On 18.6.2013 1:47, Mike wrote:
> Hi,
> 
> I started some work on adding changes to the cryptsetup code to allow
> for the use of different KDFs during key derivation, as it's a
> feature I believe would be useful. I was thinking of adding both
> bcrypt and scrypt as available alternative KDFs that the user may
> choose from.  As I didn't wish to alter the current header structure,
> if there's a different KDF used during format, that KDF would have to
> be specified during volume open, as well any other relevant
> operations.
> 
> If I created a patch for all the changes and submitted them for
> review, would there be an interest in incorporating them into the
> main cryptsetup branch? I've already incorporated the scrypt
> reference implementation into the cryptsetup codebase and confirmed
> that the official test vectors match the output. I would also be
> interested in helping out with any other updates that might need to
> be made.

Hi,

if you used the latest code you can see that code is almost ready
to add another KDF.

So definitely there is a plan to add more KDFs in future as needed,
if they are proven to be secure, idealy defined in some standard or RFC,
but I would like to see more widely use before it can become part of main
branch.

Anyway, you can always post patches for testing.
Please attach it to http://code.google.com/p/cryptsetup/issues/detail?id=119
(or send it to this list if you do not want use Google account).

But I definitely prefer if scrypt (or another KDF) is part of crypto library and
cryptsetup uses just wrapper over this library.

(PBKDF2 is implemented in core because of historic reasons and
it is only fallback now - only if configured crypto backend doesn't
provide PBKDF2, internal implementation is used. The same should apply
for other KDF as well.)

Thanks,
Milan

Re: [dm-crypt] Alternate KDFs (Key Derivation Functions) in cryptsetup

[Mike]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

Hey Milan,

Thanks for responding. I'll take a look at what different libraries are
available and see if I can incorporate them instead. Scrypt has been
published by the IETF in a standardized format (
http://tools.ietf.org/html/draft-josefsson-scrypt-kdf-01), but I believe it
is still in draft status. Thanks for considering any contributions, and
thanks for the great work you've done so far on cryptsetup.

Mike


On Tue, Jun 18, 2013 at 6:39 AM, Milan Broz <gmazyland@gmail.com> wrote:

> On 18.6.2013 1:47, Mike wrote:
> > Hi,
> >
> > I started some work on adding changes to the cryptsetup code to allow
> > for the use of different KDFs during key derivation, as it's a
> > feature I believe would be useful. I was thinking of adding both
> > bcrypt and scrypt as available alternative KDFs that the user may
> > choose from.  As I didn't wish to alter the current header structure,
> > if there's a different KDF used during format, that KDF would have to
> > be specified during volume open, as well any other relevant
> > operations.
> >
> > If I created a patch for all the changes and submitted them for
> > review, would there be an interest in incorporating them into the
> > main cryptsetup branch? I've already incorporated the scrypt
> > reference implementation into the cryptsetup codebase and confirmed
> > that the official test vectors match the output. I would also be
> > interested in helping out with any other updates that might need to
> > be made.
>
> Hi,
>
> if you used the latest code you can see that code is almost ready
> to add another KDF.
>
> So definitely there is a plan to add more KDFs in future as needed,
> if they are proven to be secure, idealy defined in some standard or RFC,
> but I would like to see more widely use before it can become part of main
> branch.
>
> Anyway, you can always post patches for testing.
> Please attach it to
> http://code.google.com/p/cryptsetup/issues/detail?id=119
> (or send it to this list if you do not want use Google account).
>
> But I definitely prefer if scrypt (or another KDF) is part of crypto
> library and
> cryptsetup uses just wrapper over this library.
>
> (PBKDF2 is implemented in core because of historic reasons and
> it is only fallback now - only if configured crypto backend doesn't
> provide PBKDF2, internal implementation is used. The same should apply
> for other KDF as well.)
>
> Thanks,
> Milan
>

[-- Attachment #2: Type: text/html, Size: 3150 bytes --]

Re: [dm-crypt] Alternate KDFs (Key Derivation Functions) in cryptsetup

[Arno Wagner]

Last time I checked the IETF draft was expired, which is not good.
A particular problem is that the draft and the paper seems to 
differ in the implementation. Before there is a final draft, there 
is really not much point in adding this to stable. Or we would have 
to go with the paper version, at the very least.

On scrypt itself, I had some more time to look at it, and it makes 
a lot more sense to me now and we definitely want something like it
in the not too distant future. I still would like to see some
independent academic cryptoanalysis of it first. 

From personal experience with the IETF process, I know it can be 
glacially slow though and a test of your patience.

Arno


On Thu, Jun 20, 2013 at 06:14:28PM -0700, Mike wrote:
> Hey Milan,
> 
> Thanks for responding. I'll take a look at what different libraries are
> available and see if I can incorporate them instead. Scrypt has been
> published by the IETF in a standardized format (
> http://tools.ietf.org/html/draft-josefsson-scrypt-kdf-01), but I believe it
> is still in draft status. Thanks for considering any contributions, and
> thanks for the great work you've done so far on cryptsetup.
> 
> Mike
> 
> 
> On Tue, Jun 18, 2013 at 6:39 AM, Milan Broz <gmazyland@gmail.com> wrote:
> 
> > On 18.6.2013 1:47, Mike wrote:
> > > Hi,
> > >
> > > I started some work on adding changes to the cryptsetup code to allow
> > > for the use of different KDFs during key derivation, as it's a
> > > feature I believe would be useful. I was thinking of adding both
> > > bcrypt and scrypt as available alternative KDFs that the user may
> > > choose from.  As I didn't wish to alter the current header structure,
> > > if there's a different KDF used during format, that KDF would have to
> > > be specified during volume open, as well any other relevant
> > > operations.
> > >
> > > If I created a patch for all the changes and submitted them for
> > > review, would there be an interest in incorporating them into the
> > > main cryptsetup branch? I've already incorporated the scrypt
> > > reference implementation into the cryptsetup codebase and confirmed
> > > that the official test vectors match the output. I would also be
> > > interested in helping out with any other updates that might need to
> > > be made.
> >
> > Hi,
> >
> > if you used the latest code you can see that code is almost ready
> > to add another KDF.
> >
> > So definitely there is a plan to add more KDFs in future as needed,
> > if they are proven to be secure, idealy defined in some standard or RFC,
> > but I would like to see more widely use before it can become part of main
> > branch.
> >
> > Anyway, you can always post patches for testing.
> > Please attach it to
> > http://code.google.com/p/cryptsetup/issues/detail?id=119
> > (or send it to this list if you do not want use Google account).
> >
> > But I definitely prefer if scrypt (or another KDF) is part of crypto
> > library and
> > cryptsetup uses just wrapper over this library.
> >
> > (PBKDF2 is implemented in core because of historic reasons and
> > it is only fallback now - only if configured crypto backend doesn't
> > provide PBKDF2, internal implementation is used. The same should apply
> > for other KDF as well.)
> >
> > Thanks,
> > Milan
> >

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare