[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
