Woops, only just noticed I had replied off list. -- Roscoe On Thu, Feb 4, 2010 at 7:31 AM, Roscoe <eocsor@xxxxxxxxx> wrote: > On Thu, Feb 4, 2010 at 12:42 AM, Milan Broz <mbroz@xxxxxxxxxx> wrote: >> It is not only about master key, there are at least two other consumers >> of RNG output - AF split and secure keyslot wipe. So both "fast" RNG >> and long-term key quality is needed. > > Well, I'm not overly concerned about those. As you say, other > consumers don't need the security margin of MK. > >>>> And exactly this waiting is solved by gcrypt RNG and I do need >>>> to reimplement it in cryptsetup. >>> >>> I do not understand this sentence. >> >> I want to avoid implementing any "please wait and do some random work >> till kernel collects some entropy" loop in cryptsetup. > > That doesn't relate to my suggestion of an option, but certainly does > relate to any use of /dev/random. > >> At least its _implementation_ requires extensive review. >> (If the real in-kernel encryption key is generated using approved source, >> there is no problem. If we XOR it with another source, it is basically new RNG.) > > The great thing about XORing the output of two random functions is > that you're no worse off than if you had just used either function. > (My view of things is we already rely on the user to produce one > unpredictable string, why not for another? If in the worst case they > just hit enter, we're no worse off than if we had only used > /dev/random.) > (Now that we have the options to specify the master key, I can get > this functionality via the use of an external tool obviously, but it > would be slightly more convenient to have a --user-random switch.) > >> If the RNG source is ok for long-term key use, what additional XOR brings here? >> If RNG is not ok, it should not be used at all. > > That is the big question, how good is Linux's RNG early on in an > install environment? > (gcrypt's RNG in FIPS mode will still as mentioned before hinge on /dev/random) > > > On a similar note, I did notice the lavarnd guy commenting about /dev/random: > "The existence of uniformity flaws indicates that the medium quality > random number generators listed above are not cryptographically strong > random number generators. " > -- http://www.lavarnd.org/what/nist-test.html > > > Regards, > > -- Roscoe > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
