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

[Arno Wagner <arno@wagner.name>]

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.
> </rant>
> 
> 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