Re: [Cfrg] randomness improvements via DHE/ECDHE, was: [Re: I-D Action: draft-irtf-cfrg-randomness-improvements-01.txt]

[Natanael <[e-mail]>]

Den tis 3 juli 2018 15:39Jason Cooper <[e-mail]> skrev:

> I'm interested in doing an extension /
> follow-on to this RFC that would use ephemeral shared secrets derived
> from DHE or ECDHE.
>
> The scenario being: a constrained device, on first boot, empty entropy
> pool.  It uses it's long-term private key to seed the pool as you've
> outlined.
>
> Then, to strengthen the pool, it does DHE/ECDHE negotiations with
> multiple peers on it's local network.  The ephemeral shared secret from
> each of those negotiations is then fed into the entropy pool.  How to do
> this securely would be the bulk of the proposed RFC.
>

Just remembered having seen this before via the metzdowd mailing list.

Recap:

If you already have enough entropy in the private key / ephemeral secret
for these key exchanges to be completely secure, then you do not need more
entropy.

If you don't, then active attackers or anybody else with a full log of
these data packets can break the scheme by deriving your original secret
and thus decrypting / deriving all other secrets you collected.

Other than that, the entropy gained per key exchange is about equivalent to
the size of the ephemeral secrets used (for some definitions of
entropy...). This is typically something like 256 bits. This is also
assuming those other peers started off with secure entropy! You gain
nothing from peers that have no entropy to add from the start. Also you
don't get much from additional exchanges with the same peer, as an attacker
only need to guess the original input but not subsequent ones.

So assuming your key exchanges are NOT monitored, you only need one
successful exchange with a FULLY trusted peer (at the time of the exchange)
to get enough local entropy. Assuming a network of nodes where none has
sufficient entropy and none has a good entropy source, you can likely NOT
collect enough entropy from this network on any single device to be secure.

Chosen / derived key material is only a problem in a few special cases,
where for example (for some key exchange algorithms) the adversary can
control the output bits of the key exchange. With a secure local algoritm
for including the external entropy into the local pool, this is not
security risk for your pool as it only means nothing were added.

Best case scenario for your algorithm: a bunch of trustworthy and isolated
low power nodes have some entropy, which is *independent* of each other,
but perhaps not enough to be secure (maybe 60 bits or so), and then they
collectively help each other to gather enough entropy. Note: in this case
we would expect the long term key to need replacement once we have enough
entropy, if it's not random enough. All nodes would need to erase their
initial randomness to protect the other nodes too.

Proper entropy seeding is almost always the better alternative. That, or
including good hardware RNG:s.