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@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
