Heya, > On 27 May 2016, at 01:49, Stephan Mueller <smuel...@chronox.de> wrote: > Then, the use of the DRBG offers users to choose between a Hash/HMAC and CTR > implementation to suit their needs. The DRBG code is agnostic of the > underlying cipher. So, you could even use Blowfish instead of AES or whirlpool > instead of SHA -- these changes are just one entry in drbg_cores[] away > without any code change.
That's a really nice change and something I've been thinking about for a couple of months as well. Then I came across tytso's ChaCha patches to urandom and was thinking ISA dependent switches between ciphers would make sense, i.e. you get AESNI performance when there's support. > Finally, the LRNG code is completely agnostic of the underlying deterministic > RNG. You only need a replacement of two small functions to invoke the seeding > and generate operation of a DRNG. So, if one wants a Chacha20, he can have it. > If one wants X9.31, he can have it. See section 2.8.3 [1] -- note, that DRNG > does not even need to be a kernel crypto API registered implementation. It's valid criticism that the number of algorithms should be limited. Algorithmic agility is an issue and has caused many real-world security problems in protocols liberally granting crypto primitives to be chosen by the user isn't a good idea. We should think about algorithms that make sense. E.g. TLS 1.3 and HTTP/2 have been moving into this direction. TLS 1.3 will only allow a couple off cipher-suites as opposed to combinatorial explosion with previous iterations of the protocol. I'd suggest sticking to AES-CTR and ChaCha20 for DRNG designs. That should fit almost all platforms with great performance, keep code-base small etc. There's now heavily optimised assembly in OpenSSL for ChaCha20 if you want to take a look: https://github.com/openssl/openssl/tree/master/crypto/chacha/asm But as mentioned in the ChaCha/urandom thread: architecture specific optimisation may be painful and error-prone. > Bottom line, I want to give folks a full flexibility. That said, the LRNG code > is more of a logic to collect entropy and maintain two DRNG types which are > seeded according to a defined schedule than it is a tightly integrated RNG. > > Also, I am not so sure that simply taking a cipher, sprinkling some > backtracking logic on it implies you have a good DRNG. As of now, I have not > seen assessments from others for the Chacha20 DRNG approach. I personally > would think that the Chacha20 approach from Ted is good. Yet others may have a > more conservative approach of using a DRNG implementation that has been > reviewed by a lot of folks. > > [1] http://www.chronox.de/lrng/doc/lrng.pdf Currently reading that paper, it seems like a solid approach. I don't like the approach that user-space programs may modify entropy. It's a myth that `haveged` etc. provide more security, and EGDs have been barely audited, usually written as academic work and have been completely unmaintained. I regularly end up in randomness[sic!] discussions with core language maintainers [0] [1] - they seem to have little understanding of what's going on in the kernel and either use /dev/random as a seed or a Userspace RNG (most of which aren't particularly safe to begin with -- OpenSSL is not fork safe [2] [3], a recent paper found weaknesses in the OpenSSL RNG at low entropy state leaking secrets [4] et cetera). This seems to be mostly the case because of the infamous `random(4)` man-page. With end-users (protocol implementers, core language designers,..) always pointing to upstream, which - of course - is the Linux kernel. I can't really tell from the paper if /dev/random would still be blocking in some cases? If so that's unfortunate. Thanks for your work on this, Aaron [0] https://bugs.ruby-lang.org/issues/9569 [1] https://github.com/nodejs/node/issues/5798 [2] https://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/ [3] https://wiki.openssl.org/index.php/Random_fork-safety [4] https://eprint.iacr.org/2016/367.pdf
signature.asc
Description: Message signed with OpenPGP using GPGMail
