Going over old emails.
On 10/12/05, Jack Lloyd [EMAIL PROTECTED] wrote:
I prefer a multi-stage design, as described by various people smarter than I
am:
source(s) -- mixer -- pool -- extractor -- X9.31
Did you really mean X9.31 and not X9.17?
--
Resolve is what distinguishes a person who
On Sun, Jul 02, 2006 at 03:25:09AM -0500, Travis H. wrote:
Going over old emails.
On 10/12/05, Jack Lloyd [EMAIL PROTECTED] wrote:
I prefer a multi-stage design, as described by various people smarter than
I
am:
source(s) -- mixer -- pool -- extractor -- X9.31
Did you really mean
Travis H. [EMAIL PROTECTED] writes:
On 2/4/06, Eric Rescorla [EMAIL PROTECTED] wrote:
Look, this design just reduces to a standard cryptographic PRNG with
some of the seed being random and periodically being reseeded by the
random network stream you're sending around. There's no need to
At 01:01 AM 2/4/2006, Travis H. wrote:
Assume further that it is not cost-effective to furnish each with a
HWRNG, even one as inexpensive as a sound card (for example, they may
not have a spare slot on the motherboard nor built-in sound).
...
Suppose that /dev/random is too slow (SHA-1 was never
Assume that one is the sole user of a LAN and that the 10-20 machines
on this network have a need for unpredictable numbers.
Assume further that it is not cost-effective to furnish each with a
HWRNG, even one as inexpensive as a sound card (for example, they may
not have a spare slot on the
Travis H. [EMAIL PROTECTED] writes:
That leaves me with the following design:
That random numbers be sent en clair from the system that can generate
them to the system that needs them, where they are decrypted using a
random key (generated locally by /dev/random) and fed into the system
that
On Sat, 4 Feb 2006, Travis H. wrote:
Suppose that /dev/random is too slow (SHA-1 was never meant to
generate a lot of output) because one of these machines wishes to
generate a large file for use as a one-time pad*. That leaves
distributing bits.
* /dev/random's output is limited by
I can't say I a fan of the idea of having multiple ways of mixing entropy into
the system. In particular, the idea of producing output by XORing your PRNGs
output with the output of a semi-public RNG seems like a bad idea to me,
because an attacker can easily control those values by taking
I've been following this thread for a couple of weeks now, and so
far virtually none of it makes any sense to me.
Back on 10/12/2005 Travis H. wrote:
I am thinking of making a userland entropy distribution system, so
that expensive HWRNGs may be shared securely amongst several machines.
What
On Tue, Oct 18, 2005 at 12:18:57AM -0500, Travis H. wrote:
source(s) -- mixer -- pool -- extractor -- X9.31
Where can I find out more about the design choices for these stages?
Peter Gutmann has several good papers on RNG design, as have some folks
currently or formerly associated with
I can't say I a fan of the idea of having multiple ways of mixing entropy into
the system. In particular, the idea of producing output by XORing your PRNGs
output with the output of a semi-public RNG seems like a bad idea to me,
because an attacker can easily control those values by taking
I am thinking of making a userland entropy distribution system, so
that expensive HWRNGs may be shared securely amongst several machines.
Here's the algorithm from generation to use:
1) Entropy harvested from HWRNG.
2) Entropy mixed with PRNG output to disguise any biases present in
source.
On Wed, Oct 12, 2005 at 04:49:43AM -0500, Travis H. wrote:
I am thinking of making a userland entropy distribution system, so
that expensive HWRNGs may be shared securely amongst several machines.
[...]
Comments?
--
http://www.lightconsulting.com/~travis/ --
We already have enough fast,
13 matches
Mail list logo
