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 ; Wed, 17 Nov 2010 23:36: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 81A971218580 for ; Wed, 17 Nov 2010 23:36:49 +0100 (CET) Date: Wed, 17 Nov 2010 23:36:48 +0100 From: Arno Wagner Message-ID: <20101117223647.GA28081@tansi.org> References: <4CE247CB.2030507@redhat.com> <4CE4186C.3030504@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE4186C.3030504@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 I have trouble parsing this. Is it a list-replay to a partially quoted personal message? As a statement to random/urandom, some time ago we discussed that in an entropy-starved installation situation (and basically only there), using /dev/random instead of /dev/urandom would be a good idea under some circumstances, even if it may make key generation slow. For practically all other cases /dev/urandom should be fine. If I remember correctly, the request to allow the use of /dev/randome was only for this special situation or similar others. As to the possible entropy-startved situations, embedded systems and virtualized systems in connection with automatized installation were mentioned. 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. Arno On Wed, Nov 17, 2010 at 07:01:16PM +0100, Milan Broz wrote: > On 11/16/2010 09:58 AM, Milan Broz wrote: > > > > Be very careful before changing default to blocking /dev/random use here. > > Just my personal rant here: > > Why I think using /dev/random is strange idea. > > I think that /dev/urandom should be usable for long term key use. Period. > > If you know about some problem, please fix it. Use better PRNG. Whatever. > > There are many "entropy" sources which fills the entropy pool > and which are (or will be) disputable in several situations. > > Just examples: > > - disk seek as source of entropy. What happens if you replace HDD with SSD > (with constant seek time)? (Recent kernels already disabled it > for non-rotational drives). > > - fully virtualised environment - how we can pretend that events are random > if everything is virtualised and controlled by hypervisor? > Can hypervisor fake events such way that application waiting for /dev/random > input get some mangled values? Is it real risk or not for you? > > - HW random generators. Can you prove that your favourite chip manufacturer > really generates "true random"(tm)? Can anyone fake it by hw manipulation? > (Like manipulating with voltage or whatever.) > > For me seems to be better to have some defined PRNG (pseudo random number generator) > in kernel which is designed with known and open algorithms. > (an example like ANSI X9.31 PRNG based on CTR(AES-128)) > > It is interesting to see how various programs tried to "fix" this problem. > > See Truecrypt with its random pool and hash mixes. > > See gcrypt which tries to get 300 bytes from /dev/random just to initialise > its own "strong random pool". > > ... > > Then read "man urandom" page: > > "A read from the /dev/urandom device will not block waiting for more entropy. As a result, > if there is not sufficient entropy in the entropy pool, the returned values are theoretically > vulnerable to a cryptographic attack on the algorithms used by the driver. > Knowledge of how to do this is not available in the current unclassified literature, > but it is theoretically possible that such an attack may exist. If this is a concern in your > application, use /dev/random instead." > > then (means reading /dev/random): > > " ... so if any program reads more than 256 bits (32 bytes) from the kernel random pool > per invocation, or per reasonable reseed interval (not less than one minute), that should be > taken as a sign that its cryptography is not skilfully implemented." > > Evil application can always exhaust /dev/random pool affecting other users or intentionally > drop applications into state that /dev/random blocks. > > Seems anyone implements some own random pool to avoid this. > > Why every application should try to solve this in the fist place? > Why risk possible mistakes in such critical part of system like key generator > in every application? > > So. The basic idea of cryptsetup is to "setup" volumes and "use" kernel provided > crypto. Not to fix kernel RNG or crypto. Not to implement cryptographic primitives > itself and introduce possible mistakes. > > If the encryption algorithm is broken or proven to not be strong enough - you will > replace it with something better, right? > I think this should apply to /dev/urandom RNG too. > > > I implemented random/urandom selection so you can do whatever you want with it now.. > > But please think about it - If cryptsetup relies on kernel for encryption, it should trust > even its RNG. Even virtual machine with no entropy once seeded should provide some > reliable and nonblocking PRNG. > > BTW I'll be happy if you can provide links to literature and analysis related > to this problem. > > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt > -- 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