I'm new to the list, so apologies if I go off the track here. 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? Is the driver for that particular NIC instrumented to contribute to the entropy pool? Most people don't know, and further don't know how to find out.
I have seen embedded Linux products before where the sole source of entropy was the hard disk. Problem was, the entire system operated off a RAMdisk, so guess how much disk activity there was during runtime? Those of us who deal with FIPS 140 and Common Criteria are now being asked to document entropy sources, including providing measurements of how much entropy is actually there and how fast it can be produced. Looking at one Common Criteria protection profile specifically - the VPN client PP - the developer has the choice of generating cryptographic entropy within the application, or relying on the underlying platform to supply it. But the only way you get to rely on the underlying platform is if that platform itself has been through a PP evaluation and thus quantified the entropy. So if you want to have any hope of passing the evaluation, you're almost forced into doing something yourself. 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? -Jon -----Original Message----- From: dsfjdssdfsd [mailto:[email protected]] On Behalf Of Krisztián Pintér Sent: Wednesday, January 22, 2014 9:52 AM To: Paul Hoffman Cc: Donald Eastlake; [email protected]; Stephen Farrell Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here? Paul Hoffman (at Tuesday, January 21, 2014, 2:28:26 AM): > It still feels very wrong > for us to be suggesting to application developers that they should > be doing their own randomness; they should be asking their OS unless > they are experts, and those experts don't need an RFC. (new to the list, and i'm not sure about the scope or context, so forgive me if i'm talking nonsense.) i agree that the OS should do the work, for multiple reasons, 1, it is better done in a protected environment (aka ring 0), 2, OS has access to more entropy, 3, better have one excellent than many good solutions. that said, what is the list of OS's today that has sound, reviewed RNG? openbsd, ...? so this is pretty thin. _______________________________________________ dsfjdssdfsd mailing list [email protected] https://www.ietf.org/mailman/listinfo/dsfjdssdfsd _______________________________________________ dsfjdssdfsd mailing list [email protected] https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
