From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XRxGuvY8nQK for ; Tue, 18 Jun 2013 15:40:50 +0200 (CEST) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 18 Jun 2013 15:40:49 +0200 (CEST) Received: by mail-ee0-f52.google.com with SMTP id c50so2532677eek.25 for ; Tue, 18 Jun 2013 06:40:48 -0700 (PDT) Message-ID: <51C0632A.2080600@gmail.com> Date: Tue, 18 Jun 2013 15:39:54 +0200 From: Milan Broz MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Alternate KDFs (Key Derivation Functions) in cryptsetup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mike Cc: dm-crypt@saout.de 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