A nice paper: https://www.schneier.com/blog/archives/2013/10/insecurities_in.html > On Mon, Oct 21, 2013 at 03:12:25PM +0200, Christoph Anton Mitterer wrote: > > On Mon, 2013-10-21 at 13:10 +0200, octane indice wrote: > > > But at this point, what is the quality of the random[1]? > > Well /dev/random (in Linux) should have either high quality entropy,... > > or block... at least that was my understanding (there's currently a > > discussion going on about /dev/[u]random at the well known cryptography > > mailing list)... > > That understanding is unfortunately incorrect. True, /dev/random > will block if it thinks it is low on entropy, but it cannot > reliably know. The problem is that it needs to estimate entropy > for each event it adds, and that can go horribly wrong. In > particular virtualized anvironments can have that effect. > > > BUT,... cryptsetup uses by default unfortunately urandom to generate the > > master key. > > I never really understood why since all arguments pro it seem weak or > > nonsense to me... anyway that's how things are. > > But you can use --use-random to change that. > > Look at the mailing-list archives. It boild down to the simple > fact that if you do crypto in a low-entropy environment, you > better know what you are doing and that the splution to dealing > with such an environment is _not_ obvious and not as simple > as selecting /dev/random. > > > So in principle you should be on the safe side then. > > > > > > Of course you can improve entropy by using stuff like haveged, or a > > TRNG[0],... but I do not really know wheter these also have a positive > > effect on the _quality_ of the entropy or just on the _quantity_. > > There is no difference between quality and quantity when entropy > is concerned. > > Arno > > > > > Cheers, > > Chris. > > > > > > [0] According to Ted Ts'o and others it's not possible to > > spoil /dev/random by seeding it with malicious entropy sources (it just > > wouldn't get better as it was already)... though I must admit that I've > > never understood why this could be like that. > > > > > _______________________________________________ > > dm-crypt mailing list > > dm-crypt@xxxxxxxx > > http://www.saout.de/mailman/listinfo/dm-crypt > > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 > ---- > There are two ways of constructing a software design: One way is to make it > so simple that there are obviously no deficiencies, and the other way is to > make it so complicated that there are no obvious deficiencies. The first > method is far more difficult. --Tony Hoare > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
