Replies in-line (non-standardly enclosed with << >>, sorry ;) -----Original Message----- From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] Sent: Friday, July 28, 2017 11:09 AM To: Dan Brown <danibr...@blackberry.com> Cc: tls@ietf.org Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
On Fri, Jul 28, 2017 at 01:37:33PM +0000, Dan Brown wrote: > > 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? You do not want to use /dev/random as seed source. It can block for potentially long times. And the output quality is not better than /dev/urandom. << This is an example of the deprecation of /dev/random, I think (which can be found elsewhere too). Anyway, this whole thread considers resisting the hypothesis of a CSPRNG, such as /dev/[u]random, leaking its internal state. The idea of /dev/urandom is to not block, allowing the internal state to evolve deterministically (if no new entropy input arrives). So, finding one /dev/urandom output would lead to finding another (under this hypothesis), by way of the internal state. By contrast, as I understand it, /dev/random should at least block until it believes it has updated its internal state with a good dose of entropy. Of course, this muddles the hypothesis somewhat, since first we posit a bad PRNG, then we speak of /dev/random acting like a good PRNG, etc. In a way, /dev/random is sort of doing what people are proposing here (the 2 CSPRNG), by trying to ensure that successive random outputs are not deterministically linked by a random state, so are in a sense two "independent" values..., even if the deterministic part of the RNG, the hashing or whatever, fails... >> _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
