From: Milan Broz <mbroz@redhat.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT
Date: Mon, 23 Nov 2009 15:29:51 +0100 [thread overview]
Message-ID: <4B0A9C5F.7030705@redhat.com> (raw)
In-Reply-To: <cf657bae0911230545yd7dac2cn2060949990eaf3bb@mail.gmail.com>
On 11/23/2009 02:45 PM, Roscoe wrote:
> On Thu, Nov 19, 2009 at 5:41 PM, Arno Wagner <arno@wagner.name> 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
next prev parent reply other threads:[~2009-11-23 14:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-17 22:45 [dm-crypt] different default key sizes for CREATE and LUKSFORMAT Stefan Xenon
2009-11-18 5:45 ` Arno Wagner
2009-11-18 10:01 ` Stefan Xenon
2009-11-18 10:25 ` Arno Wagner
2009-11-18 11:20 ` Milan Broz
2009-11-18 13:26 ` Milan Broz
2009-11-18 15:17 ` Heinz Diehl
2009-11-19 7:41 ` Arno Wagner
2009-11-19 9:21 ` Heinz Diehl
2009-11-19 12:24 ` Arno Wagner
2009-11-19 12:28 ` Arno Wagner
2009-11-19 13:00 ` Heinz Diehl
2009-11-20 12:14 ` Milan Broz
2009-11-20 15:43 ` Heinz Diehl
2009-11-21 10:47 ` Arno Wagner
2009-11-21 12:40 ` Stefan Xenon
2009-11-21 17:26 ` Arno Wagner
2009-11-19 20:00 ` Stefan Xenon
2009-11-20 12:22 ` Milan Broz
2009-11-23 13:45 ` Roscoe
2009-11-23 14:29 ` Milan Broz [this message]
2009-11-23 15:46 ` Arno Wagner
2009-11-23 16:05 ` Heinz Diehl
2009-11-19 7:28 ` Arno Wagner
2009-11-20 12:43 ` Jonas Meurer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B0A9C5F.7030705@redhat.com \
--to=mbroz@redhat.com \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.