All of lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <mbroz@redhat.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test	release	candidate)
Date: Thu, 18 Nov 2010 04:51:08 +0100	[thread overview]
Message-ID: <4CE4A2AC.4080801@redhat.com> (raw)
In-Reply-To: <20101117223647.GA28081@tansi.org>

On 11/17/2010 11:36 PM, Arno Wagner wrote:
> I have trouble parsing this. Is it a list-replay to a
> partially quoted personal message?

Partially. It is just warning that setting default is not just
straightforward.

(I think there is already request for setting default to /dev/random
in Debian.)

> If I remember correctly, the request to allow the use of
> /dev/randome was only for this special situation or similar others.

Sure, this setting affects only volume key generation. Others
are always generated using urandom. 
(See the source in lib/random.c - there is flag CRYPT_RND_NORMAL / KEY.
Only calls marked with KEY quality can use /dev/random.)

> As to the possible entropy-startved situations, embedded systems
> and virtualized systems in connection with automatized installation
> were mentioned. 

I think it is not only about starved situations, thats just practical
impact of using this interface.
Ipsec need to set key too and cannot wait for entropy.
Isn't there the same quality requested if you can record encrypted
communication and analyse it later? (just example)

I sent this "rant" separately because it is just my opinion but
I simply think that /dev/random vs /dev/urandom is bad design.

But it is up to user how to configure cryptsetup - I provided
all needed ways to set it up according to needs
(configure, runtime, libcryptsetup API).

I would prefer some interface to kernel RNG where I can specify
requested quality. Or simply setup urandom to generate strong
data usable always as long term key.
Maybe we get better access to kernel RNG through new userspace API.

I think that many applications which implements its own RNG
(because mixing /dev/random with something into own pool _is_
new RNG) use some tricks. Are these tricks properly documented
and backed by proper analysis? I hope so:-)

> An alternative would be to introduce randomness form the outside,
> but that may again be a security risk. Bottom line, setting
> key-generation to use /dev/random is a specialist option that
> most beople will never need, but that can be very handy in
> some situations.

You can provide pre-generated volume key or you can use /dev/random
if requested in cryptsetup - the option is there.

Milan

  reply	other threads:[~2010-11-18  3:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-16  8:58 [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate) Milan Broz
2010-11-16 11:58 ` Christoph Anton Mitterer
2010-11-17 18:01 ` Milan Broz
2010-11-17 22:36   ` Arno Wagner
2010-11-18  3:51     ` Milan Broz [this message]
2010-11-18  9:43       ` Christoph Anton Mitterer
2010-11-18 12:40       ` Arno Wagner
2010-11-18 13:01         ` Milan Broz
2010-11-19  0:11           ` Arno Wagner
2010-11-19  1:01 ` Arno Wagner
2010-11-19  8:49   ` Milan Broz
2010-11-19 12:08     ` Arno Wagner

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=4CE4A2AC.4080801@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.