I don't think this is simply a case of multiple CSPRNGs. My guess is many TLS implementations don't have visibility into how the CSPRNG operates. That code does however, know which output values will be public and which not. For me, that implies that any good separation scheme applied within the TLS code that differentiates between public and non public outputs is a good plan. Yes, if an attacker can bork your CSPRNG, they may be able to get at the TLS code too sometimes, but I'd argue the defence in depth is worthwhile.
Cheers, S. On 28/07/17 14:37, Dan Brown wrote: > I try below to better explain my points against separated public and private > CSPRNG instances. > > Perhaps the easiest way to get "independent" seeds for the two instances of a > CSPRNG, is to use a third CSPRNG instance to generate the seeds. But then > the problem arises again, if the 3 CSPRNGs are bad enough, (0=seeder, > 1=public, 2=private), there is a risk that: > > Public_nonce=output1=>seed1=output0_for_1=>seed0=>output0_for_2=seed2=>output_2=private_key=TLS_insecurity. > > In short, generally speaking, three bad CSPRNGs do not combine easily into 1 > good CSPRNG. > > (I'm not yet sure if this attack on three CSPRNGs combined applies to > Dual_EC, since it may do something hash-like to the seed (I forgot details), > and also output leaks the next state, not the previous state, as I recall, so > that might break the chain above.) > > The alternative to a 3rd CSPRNG is to get the seeds from directly from a raw > entropy source. In that case, keep in mind that one of the purposes of > CSPRNGs is that raw entropy sources are unreliable (sometimes stall, etc. > [references to be added]) and generally weak on the independence (they are > non-uniform, hence have correlations). CSPRNGs are supposed to correct these > deficiencies, among other things. So, if the 2 seeds are generated directly > from a raw entropy sources (without a CSPRNG), two things may go wrong. > First, deriving one seed from the other might be feasible because of > non-uniformity. A bad CSPRNG might enable this this to be exploited, by > finding one seed from the other. Second, if the entropy source stalls (down > a trickle of low entropy), between too close seed requests - accidentally - > then even a good CSPRNG couldn't cope. > > Maybe, all this wouldn't be a problem on many higher end systems, with high > entropy, so my concern is lower end systems, and also unnecessary > complications of maintaining multiple bad CSPRNGs, potentially to no avail. > > Finally, on systems with a linux-style interface, /dev/urandom and > /dev/random could be used as the two CSPRNGs on some systems (or seed > sources), although I think one of these is now deprecated? > > -----Original Message----- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell > Sent: Friday, July 28, 2017 4:47 AM > To: Eric Rescorla <e...@rtfm.com>; Blumenthal, Uri - 0553 - MITLL > <u...@ll.mit.edu> > Cc: tls@ietf.org > Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's > > > Hiya, > > On 28/07/17 00:50, Eric Rescorla wrote: >> I used the term "separate" here, which was intended to convey this, >> but if people think "independent" or something is better, happy to change. > > I think your change is a fine improvement over -21, thanks. > (And my suggested text was as imperfect as I usually manage:-) > > I'm not clear if implementers will or will not get the ramifications of > "separate" (or "independent"), so I think we ought describe (or reference) at > least one way in which that separation can be achieved. > > I also think we ought at least RECOMMEND separate CSPRNGs. > I'd prefer a MUST myself but since there's no one good way we can describe to > achieve the effect that'd work in all cases, I don't think we can say MUST. > > Cheers, > S. > > >> >> -Ekr >> >> >> On Thu, Jul 27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL < >> u...@ll.mit.edu> wrote: >> >>> Respectfully disagree. Having two cryptographically independent >>> PRNGs, one for public data and one for key material, IMHO is a good >>> idea. Of course, both should be properly seeded - but that's a different >>> issue. >>> >>> Regards, >>> Uri >>> >>> Sent from my iPhone >>> >>> On Jul 27, 2017, at 19:33, Dan Brown <danibr...@blackberry.com> wrote: >>> >>> >>> I don't think 2 CSPRNGs is a good idea. >>> >>> Wasn’t there a few years back some RSA keys with separate p and q, >>> generated independently leading to an attack... >>> >>> Here if the seeds to initialize the RNGS are related, or one is weak, >>> or worst if the seed is a raw source that doesn’t change in the >>> moments between the two CSPRNG inits, that'd be bad, even if the CSPRNGs >>> were good. >>> *From: *Eric Rescorla >>> *Sent: *Thursday, July 27, 2017 6:34 PM >>> *To: *Stephen Farrell >>> *Cc: *tls@ietf.org >>> *Subject: *Re: [TLS] 32 byte randoms in TLS1.3 hello's >>> >>> Spec updated here; >>> https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0ac >>> bc42 >>> 942af9ca77 >>> >>> -Ekr >>> >>> >>> On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell < >>> stephen.farr...@cs.tcd.ie> wrote: >>> >>>> >>>> I've suggested some text for this in a PR [1] based on what people >>>> have said in this thread. >>>> >>>> I'm sure that can be further improved. >>>> >>>> It might be no harm to add more pointers to that appendix from >>>> elsewhere in the spec, and/or to add a list of the various >>>> public/private random numbers that are needed to that appendix. (I'd >>>> be happy to do a pass to identify those if folks basically like this >>>> kind of addition.) >>>> >>>> I also need to figure out how to handle the reference properly:-) >>>> Can do that tomorrow. >>>> >>>> Cheers, >>>> S. >>>> >>>> [1] https://github.com/tlswg/tls13-spec/pull/1068 >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
