This may get off-topic, but are there good software tools for testing entropy, that could help applications determine if the underlying system is giving them good input?
Michael Hammer Principal Engineer [email protected] Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA -----Original Message----- From: dsfjdssdfsd [mailto:[email protected]] On Behalf Of Krisztián Pintér Sent: Thursday, January 23, 2014 12:40 PM To: [email protected] Cc: [email protected] Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here? [email protected] (at Thursday, January 23, 2014, 4:54:59 AM): > The problem with relying on the OS is that you're not always sure what > the OS is doing. Example: If I run Linux under ESXi on a headless > server, with an SSD for a disk, and I use the Ethernet NIC built into > the motherboard, where is the entropy for /dev/random coming from? you do know what the OS does, you have either a source code, or at least a statement that everything is fine. you choose the OS with this knowledge in mind. it is another issue that in certain systems, the opsys might be not good enough. but i doubt that you can write RFC that is of any use for such special systems. plus, it is still advisable that you only implement your additional entropy collection, and just feed it back to the OS. > Those of us who deal with FIPS 140 and Common Criteria are now being > asked to document entropy sources, we need to make clear what the goal is. me being new here, maybe i just missed it, but i'm not sure what do we want: a, building a secure system b, building a system that can be marketed as secure c, building a FIPS compliant system because i claim that these are very different. if you want to be FIPS compliant, you probably need to do a whole sort of silly things that helps nobody in no way. but again, this won't be too much aided with an RFC, or any "best practices" document. nor i personally care much. marketability of a system can be affected by any number of things, probably boasting a lot of numbered acronyms, like RFCs as well. but i'm not into this kind of psychology. but if we aim at security, the OS can provide the best service here. yeah, windows don't, but really, how secure your application will be on windows anyway? you don't need to go over that level. > The various DRBGs are fine IMHO for handing out bits of random to an > application, and lacking anything better today I would certainly > encourage developers to use one. But the question is how do we seed > the DRBG in the first place? i certainly agree that we are well equipped with good DRBGs (which linux still refuses to include, forget about windows). do you happen to know fortuna, and especially its entropy collection policy? i think it is kind of a cool concept, except does not really solve the problem you mentioned before, namely early entropy gathering. one more point: it is not only about creating good random. you also need to protect it. what sources of entropy do you have that other processes on the same system don't? what information do you leak during the collection phase? a little bit harder problem than a DRBG. _______________________________________________ dsfjdssdfsd mailing list [email protected] https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dsfjdssdfsd mailing list [email protected] https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
