#7 Use `crypto/aes` when it is safe to do so.

Open
opened 1 year ago by yawning · 2 comments

It would be spiffy if this would use the hardware accelerated implementations provided by the runtime library if they aren't broken.

I'm not sure how easy it is to auto-detect this on non-Intel systems, but I guess I could see how the runtime library does it.

Low priority.

It would be spiffy if this would use the hardware accelerated implementations provided by the runtime library if they aren't broken. I'm not sure how easy it is to auto-detect this on non-Intel systems, but I guess I could see how the runtime library does it. Low priority.
Yawning Angel commented 1 year ago
Owner

I'm not sure how easy it is to auto-detect this on non-Intel systems

It's not. It requires assembly.

For added fun, detecting if hardware supports AES-NI (or equivalent) isn't enough, because crypto/aes's support for hardware accelerated AES/GHASH depends on the version of the runtime library.

  • s390x support was added over 2016.
  • amd64 PCLMULQDQ use was added in 2015.

tip also has, ppc64le support for AES, but still uses a vartime GHASH.

> I'm not sure how easy it is to auto-detect this on non-Intel systems It's not. It requires assembly. For added fun, detecting if hardware supports AES-NI (or equivalent) isn't enough, because `crypto/aes`'s support for hardware accelerated AES/GHASH depends on the version of the runtime library. * s390x support was added over 2016. * amd64 PCLMULQDQ use was added in 2015. tip also has, ppc64le support for AES, but still uses a vartime GHASH.
Yawning Angel commented 1 year ago
Owner

crypto/aes's AESNI performance is trash on AMD64, because there is 0 data parallelism, this means that assembly would be sensible and faster.

`crypto/aes`'s AESNI performance is trash on AMD64, because there is 0 data parallelism, this means that assembly would be sensible and faster.
Sign in to join this conversation.
No Milestone
No assignee
1 Participants
Loading...
Cancel
Save
There is no content yet.