Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate)

[Arno Wagner <arno@wagner.name>]

On Thu, Nov 18, 2010 at 04:51:08AM +0100, Milan Broz wrote:
> 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.

It has to. No entropy - no security. The entropy does not
nee to be "fresh", but it needs to be there.

> Isn't there the same quality requested if you can record encrypted
> communication and analyse it later? (just example)

Indeed.

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

I don;t think there is anything wrong with /dev/random. 
But /dev/urandom would efinitely need to wait as default 
until it has been properly initialized before beginning
to hand out randomness. That it does not basically 
sisqualkifies it a crypto-generatro. If that is your
point, then I completely agree.

> 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 agree.

> 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:-)

But each one may get it worng. I agree that these are new 
generators and that /dev/random is just used as entropy source 
in this case.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier