summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/modes/ccm128.c
diff options
context:
space:
mode:
authorjsing <>2025-04-18 13:19:39 +0000
committerjsing <>2025-04-18 13:19:39 +0000
commitfb852c976e7cf5b5de76ef0ee7a6211da68406ad (patch)
treeb3eaa246bba788deea85c0a511d862e9dff8c4ef /src/lib/libcrypto/modes/ccm128.c
parent1bca90833184b2940c83743ceff3847131e475df (diff)
downloadopenbsd-fb852c976e7cf5b5de76ef0ee7a6211da68406ad.tar.gz
openbsd-fb852c976e7cf5b5de76ef0ee7a6211da68406ad.tar.bz2
openbsd-fb852c976e7cf5b5de76ef0ee7a6211da68406ad.zip
Remove BS-AES and VP-AES from EVP.
The bitsliced and vector permutation AES implementations were created around 2009, in attempts to speed up AES on Intel hardware. Both require SSSE3 which existed from around 2006. Intel introduced AES-NI in 2008 and a large percentage of Intel/AMD CPUs made in the last 15 years include it. AES-NI is significantly faster and requires less code. Furthermore, the BS-AES and VP-AES implementations are wired directly into EVP (as is AES-NI currently), which means that any consumers of the AES_* API are not able to benefit from acceleration. Removing these greatly simplifies the EVP AES code - if you just happen to have a CPU that supports SSSE3 but not AES-NI, then you'll now use the regular AES assembly implementations instead. ok kettenis@ tb@
Diffstat (limited to 'src/lib/libcrypto/modes/ccm128.c')
0 files changed, 0 insertions, 0 deletions