From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 23 Nov 2009 15:29:53 +0100 (CET) Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nANETqqE004778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Nov 2009 09:29:52 -0500 Received: from [10.34.32.183] (mazybook.englab.brq.redhat.com [10.34.32.183]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nANETpAh005013 for ; Mon, 23 Nov 2009 09:29:52 -0500 Message-ID: <4B0A9C5F.7030705@redhat.com> Date: Mon, 23 Nov 2009 15:29:51 +0100 From: Milan Broz MIME-Version: 1.0 References: <4B032794.6090104@gmx.net> <20091118054555.GB28949@tansi.org> <4B03C5EE.7010702@gmx.net> <20091118102515.GB30910@tansi.org> <4B03D865.8070905@redhat.com> <4B03F5F2.9080609@redhat.com> <20091119074104.GC8694@tansi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 11/23/2009 02:45 PM, Roscoe wrote: > On Thu, Nov 19, 2009 at 5:41 PM, Arno Wagner wrote: >> If I understand this correctly, this is the "iteration-count" >> parameter to PBKDF2. If so, then RFC 2898 recommends a minimum >> count of 1000 anyways. This is hovever not protection against >> a broken hash, as even a very weak hash should be extremely >> hard to break when iterated 10 times. The main purpose of this >> parameter is to make exhaustive search more expensive. I think >> this should definitely go up to 1000. > > I'd like to point out that this use of PBKDF2 is is not as a KDF but > as a hash function. The recommendations in the RFC 2898 will be from a > KDF perspective. The idea of someone doing an exhaustive search in the > LUKS mk context seems silly (RNG quality aside) You are right, but note for normal exhaustive key search (brute force, because key is random here) you need to know some plain text on the disk (not problem with known FS signature though). Here you have always digest of hashed key (+ known salt). If the PBKDF2 with iterations is very quick and cheap, the exhaustive search for key candidates is much more simpler here than other technique. Adding iterations for mk digest is quite cheap and almost make this search unusable (even if it is just theoretic or silly attack). Or am I missing anything? Milan -- mbroz@redhat.com