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@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
