Subject: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-01.txt

From: [email-masked]
Date: Mon, 02 Jul 2018 15:32:22 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Crypto Forum RG of the IRTF.

        Title           : Randomness Improvements for Security Protocols
        Authors         : Cas Cremers
                          Luke Garratt
                          Stanislav Smyshlyaev
                          Nick Sullivan
                          Christopher A. Wood
	Filename        : draft-irtf-cfrg-randomness-improvements-01.txt
	Pages           : 7
	Date            : 2018-07-02

Abstract:
   Randomness is a crucial ingredient for TLS and related security
   protocols.  Weak or predictable "cryptographically-strong"
   pseudorandom number generators (CSPRNGs) can be abused or exploited
   for malicious purposes.  The Dual EC random number backdoor and
   Debian bugs are relevant examples of this problem.  This document
   describes a way for security protocol participants to mix their long-
   term private key into the entropy pool(s) from which random values
   are derived.  This augments and improves randomness from broken or
   otherwise subverted CSPRNGs.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-randomness-improvements/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-irtf-cfrg-randomness-improvements-01
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-randomness-improvements-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-randomness-improvements-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jason Cooper <[email-masked]>
Date: Tue, 3 Jul 2018 13:38:32 +0000

All,

>    otherwise subverted CSPRNGs.

As an engineer working with embedded / constrained systems, it's
refreshing to see this work.  Thanks!

I've not had the opportunity to contribute an RFC before, so I'm
unfamiliar with the process.  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.

Questions the RFC would address:

 - Zero-credit is a safe default, what is a safe margin to credit the
   entropy pool for each shared-secret contribution, if any?

 - Threat model to mitigate: Network observer gaining info about the
   state of the pool.

 - Threat model to mitigate: One or more (all?) peers independently, in
   concert, or in concert with network observer using their knowledge of
   one or more shared secrets to gleen information about the state of
   the entropy pool.

 - Threat model to mitigate: One or more active attackers using chosen
   private/public ephemeral key pairs to manipulate the state of the
   entropy pool.  Possibly by flooding.  This could be limited to the
   number of connections initiated by the client desiring seeding
   material.  Resilience to this threat model would enable servers
   (connection receivers) to take advantage of this source as well.

 - Can this proposed RFC be relied on to 'X' security level independent
   of the long-term private key seeding RFC?  In other words, can it
   provide *any* security if it's the sole seeder of an entropy pool?

Is this a sane idea?  I'm leary of the fact that two parties know the
shared secret (by design), but I think it has good potential at least as
one of many seed sources to a pool.  At a minimum as a non-credit
"stirring" of an existing pool.

Any thoughts or insights would be much appreciated.

Thanks,

Jason.

---

From: Natanael <[email-masked]>
Date: Tue, 3 Jul 2018 16:35:33 +0200

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

> I'm interested in doing an extension /

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.