Re: AES-NI: slower than aes-generic?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Heya,

> On 27 May 2016, at 01:49, Stephan Mueller <smueller@xxxxxxxxxx> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux