/cc @agl

We use the vector intrinsics on amd64 whenever they are available on the processor. Are there other specific archs which you are referencing?

I am referring to the algorithms Go uses. As shown in the paper above, certain vector intrinsics could be used to avoid the need for S-boxes, but Go's implementation of AES does use S-boxes, creating a possible side-channel vulnerability on shared machines.

Go does use the amd64 vector intrinsics if available. It uses the sbox code (in crypto/aes/block.go:encryptBlockGo) only for other architectures and for amd64 chips which don't have AESNI. See crypto/aes/cipher_asm.go.

Sorry – by "vector intrinsics" I do not mean AES-NI, but rather SSE3+, which OpenSSL uses for bit-sliced AES.

So then I'm not sure what you are requesting. Do you want us to implement bit-sliced AES for chips which are SSE3+ but not AES-NI? Or do you want us to provide the intrinsics (which ones?) which you will need to do so yourself?

Are >= SSE3+ but < AES-NI chips worth targeting?

As far as I can tell, all the ops the paper uses (which isn't entirely clear - it would be really nice if they had assembly listings) are available now in Go assembly.

Use the bitsliced approach on chips with SSE3+ and no AES-NI. Some low-end
chips produced today lack AES-NI.

Also, please choose at runtime based on CPUID.
On Jan 21, 2016 11:00 PM, "Keith Randall" notifications@github.com wrote:

So then I'm not sure what you are requesting. Do you want us to implement
bit-sliced AES for chips which are SSE3+ but not AES-NI? Or do you want us
to provide the intrinsics (which ones?) which you will need to do so
yourself?

Are >= SSE3+ but < AES-NI chips worth targeting?

As far as I can tell, all the ops the paper uses (which isn't entirely
clear - it would be really nice if they had assembly listings) are
available now in Go assembly.

—
Reply to this email directly or view it on GitHub
#13795 (comment).

So then I'm not sure what you are requesting. Do you want us to implement bit-sliced AES for chips which are SSE3+ but not AES-NI? Or do you want us to provide the intrinsics (which ones?) which you will need to do so yourself?

Are >= SSE3+ but < AES-NI chips worth targeting?

It doesn’t really matter. I would much prefer the generic (no-asm) fallback code to also be constant time. It won’t be fast, though.