Modern updates: 0) Consider who you trust to generate "absolute" entropy in the strict sense, and whether that makes any sense to embed in the protocol. If it does not (I suspect it does not), ignore these sub-ideas.
0a) Have a running sequence number on the packets so that anyone can
join in, distributing packets with updated sequence numbers to
show it reflects the state you absorbed from the last sequence number.
0b) Explore partial orderings e.g. lamport timestamps - keep it simple
but clever.
1) incorporate http://www.pcg-random.org/, avoid mersenne
2) Emergent properties of network (instead of individual systems):
2a) http://dankaminsky.com/2012/08/15/dakarand/ for early seeding of
local entropy
2b) consider packet loss and packet arrival timings as a source of
entropy and jitter
2c) functions as a shared but lossy channel, like the satellite
signal or QKD channel
3) Work out the math of a proposed system and compare difficulty of
known attack scenarios - i.e. I compromise host A, what can I learn
about state of machine B, or I dump entropy pool on A, what can I learn
about state of machine B. Might need some new techniques for doing
this automatically alongside design to see what effect proposals
have on this system.
3a) consider effect of direct-broadcast instead of subnet-directed so
that systems receive packets not processed by other systems, or
some other method for complicating analysis of one system given
that another is compromised; i.e. diversification of the RNG
stream and/or local state - and how strong that diversification
is.
On Wed, Mar 19, 2014 at 04:28:08PM -0700, [email protected] wrote:
> I am thinking of making a userland unpredictability distribution
> system, so that expensive HWRNGs may be shared securely amongst
> several machines.
>
> Here's the algorithm from generation to use:
>
> 1) Unpredictability harvested from HWRNG.
>
> 2) Unpredictability mixed with PRNG output to disguise any biases
> present in source. The Mersenne Twister suggests itself due to its
> extremely long period and fast use but I think a CSPRNG is better.
> (Is XOR sufficent and desirable as mix function?)
>
> 3) Unpredictability used as "truly random" input in an extractor to
> map "somewhat random" input (interrupt timing, memory contents, disk
> head settling times) into "strongly random" output. Extractor can
> range from hash to proper extractor functions (look them up, they are
> not what you think). New sponge funtions (keccac, a/k/a SHA-3) are
> promising here.
>
> 4) Unpredictability passed through OWF to occlude state of previous
> systems in this chain.
>
> 5?) Unpredictability ciphered with a randomly-generated key (taken
> from the previous step), rotated periodically.
>
> 6) Unpredictability transmitted over the network.
>
> 7) Recipient ciphers the unpredictability with a randomly-generated
> key, rotated periodically. The randomly-generated key is taken from
> the previous output of step 8 so that data on the wire is never used
> directly to cipher future data sent over the wire (requiring an
> attacker to be able to accurately model step 8).
>
> 8) Recipient repeats steps 2-4 locally. This might simply involve
> dumping it to /dev/random, as one option that requires no changes to
> the client OS.
>
> 9) Unpredictability is used in an application needing it.
>
> Here's my claims:
>
> 1) There is no key distribution to worry about.
>
> 2) Eavesdropping only gets you known-ciphertext. You still have no
> idea about the plaintext, which is random, so you have no general way
> to recognize a successful brute-force attempt on the
> randomly-generated key used by the recipient.
>
> 3) You'd have to figure out how some part of the transmitted data was
> used by the recipient, and work forward with each trial key to see if
> the results match in order to recognize a successful guess at the key
> used in step 7. Would re-ordering data randomly on the recipient be
> useful to thwart this, or is it unnecessary?
>
> 4) The most effective way to compromise such a distribution system
> that I can think of would involve cracking the recipient system, and
> if the enemy can do that, no crypto can help you.
>
> I deliberately used the term cipher instead of en/decrypt because I am
> not sure it matters which direction we go, as long as it doesn't
> introduce any detectable statistical biases in the unpredictability
> (weakening it). For that matter, we could HMAC it. What properties
> should I look for, and what level of assurances?
>
> Can you see any weaknesses or unnecessary steps in this model? I'm
> not sure 5 is necessary (it was just suggested by symmetry).
>
> Regarding the userland daemon, I was thinking of replacing the
> /dev/urandom functionality with a userland daemon, because:
>
> (a) cryptographic operations can be slow, and putting them in the
> kernel, which cannot block, is not desirable
>
> (b) development is easier, this will encourage people to tinker with
> it more
>
> (c) having the kernel perform HTTP requests to get random numbers from
> web sites is inappropriate
>
> I am not sure this is good solution, though... perhaps better
> to have userland daemon which tends the pool.
>
> What I want to do is:
>
> 1) Mix various sources of "untrusted" unpredictability in such a way
> as to make a strong claim as to the mixture. For example, these web
> sites offer free random numbers:
>
>
> http://www.random.org/
> http://www.randomnumbers.info/
> http://www.fourmilab.ch/hotbits/
>
> Why shouldn't I download some numbers from these sites periodically,
> and combine them with the pool? I don't have to update the
> unpredictability count (indeed, this is a PRNG and so tracking
> "actual" unpredictability is somewhat irrelevant). The way I see it,
> if I XOR numbers from these sites with my PRNG output, even if an
> attacker eavesdrops on this traffic, I'm no worse off than if I hadn't
> used them at all. Unpredictability XORed with predictability is still
> unpredictable.
>
> Similarly, I also would like to use ID Quantique's HWRNG based on
> optics, but their modules are sealed and opaque. What I want to do is
> explore what kind of assurances I can make about the output, based on
> assumptions about the attacker's ability to control, predict, or
> observe one of the sources.
>
> 2) Occlude common biases in the HWRNG, which is the main input to the
> daemon.
>
> 3) Combine PRNG components in novel ways.
>
> 4) Create a plug-in framework for PRNG components.
>
> 5) Do it in a language not as prone to security-relevant errors as C
> and containing support for large numbers and bitstrings as first-class
> objects. I'm leaning towards python, heard good things about ruby,
> and open to suggestions that something very different like ocaml might
> be better.
>
> Stumbling blocks that I can see:
>
> 1) Lack of standardization in the naming or semantics of kernel
> facilities, such as the names of devices in /dev.
>
> 2) Lack of support for sockets in the target language.
>
> 3) The use of ioctls for interfacing to sources of unpredictability in
> the kernel.
>
> 4) The use of tty devices to interface to HWRNGs
>
> 5) Multiple clients petitioning the daemon for random bits at once.
> However, this is also a good thing; two consecutive values used by a
> client may not be consecutive outputs from the PRNG subsystem.
>
> Comments?
> --
> http://www.subspacefield.org/~travis/
> Remediating... LIKE A BOSS
>
>
> _______________________________________________
> RNG mailing list
> [email protected]
> http://lists.bitrot.info/mailman/listinfo/rng
--
http://www.subspacefield.org/~travis/
"Computer crime, the glamor crime of the 1970s, will become in the
1980s one of the greatest sources of preventable business loss."
John M. Carroll, "Computer Security", first edition cover flap, 1977
pgptuqDSVxb2Z.pgp
Description: PGP signature
_______________________________________________ RNG mailing list [email protected] https://lists.bitrot.info/mailman/listinfo/rng
