crypto/aes: add generic bitsliced implementation

[rolandshoemaker]

The generic pure-Go AES implementation, used when a platform lacks AES-NI hardware support, operates in variable-time. This is a (very) long running issue (see #19413, #16821, #13795, #4299, etc) which is noted in the crypto/aes package documentation.

While documented explicitly in crypto/aes, it may not be obvious to consumers of crypto/tls. In Go 1.16, we deprioritized AES ciphers on systems that lacked hardware support, but despite this there are still scenarios where users who lack AES-NI may end up negotiating AES based ciphers, resulting in usage of a variable-time implementation.

It is probably time to throw out the variable-time generic implementation, and finally add a bitsliced version. This would mean that all of our AES implementations would be constant-time, regardless of the platform. Since this was last considered there have been a slew of reasonable bitsliced implementations developed in the community, so there is a lot of prior art to consult on the best way to go about this.

We'll also need to add a constant-time GHASH implementation for AES-GCM to be constant-time. BearSSL has a novel approach to this, which spreads the bits out to avoid the need for separate carrying: https://www.bearssl.org/constanttime.html#ghash-for-gcm.

We expect bitslicing will result in reduced performance over the current generic implementation, but it seems like that is a reasonable trade-off for having full constant-time platform coverage.

cc @golang/security @FiloSottile

[gabyhelp]

Related Issues and Documentation

• crypto: constant time AES and GCM #19413

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}