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/465de0e189b2b59090d0eac0acbc42 >> 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
