From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tansi.org (ns.km10532-04.keymachine.de [87.118.102.195]) by mail.saout.de (Postfix) with ESMTP for ; Thu, 18 Nov 2010 13:40:50 +0100 (CET) Received: from gatewagner.dyndns.org (84-74-164-239.dclient.hispeed.ch [84.74.164.239]) by tansi.org (Postfix) with ESMTPA id 0CD421218583 for ; Thu, 18 Nov 2010 13:40:50 +0100 (CET) Date: Thu, 18 Nov 2010 13:40:48 +0100 From: Arno Wagner Message-ID: <20101118124048.GA8173@tansi.org> References: <4CE247CB.2030507@redhat.com> <4CE4186C.3030504@redhat.com> <20101117223647.GA28081@tansi.org> <4CE4A2AC.4080801@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE4A2AC.4080801@redhat.com> Subject: Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.2.0-rc1 (test release candidate) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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