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

[Michael Hammer <[e-mail]>]

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
[e-mail]
Mobile: [phone]
500 Yosemite Drive Suite 120
Milpitas, CA 95035 USA


-----Original Message-----
From: dsfjdssdfsd [mailto:[e-mail]] On Behalf Of
Krisztián Pintér
Sent: Thursday, January 23, 2014 12:40 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?


[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.

_______________________________________________
dsfjdssdfsd mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dsfjdssdfsd