Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?

[Krisztián Pintér <[e-mail]>]

[e-mail] (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.