# Can AES-NI be used to accelerate asymmetric encryption?

AES-NI optimized processors can be used to accelerate AES, which is a symmetric crypto. Can it also be used to accelerate asymmetric crypto?

These are the AES-NI instructions listed by wikipedia:

• AESENC: Perform one round of an AES encryption flow
• AESENCLAST: Perform the last round of an AES encryption flow
• AESDEC: Perform one round of an AES decryption flow
• AESDECLAST: Perform the last round of an AES decryption flow
• AESKEYGENASSIST: Assist in AES round key generation
• AESIMC: Assist in AES Inverse Mix Columns
• PCLMULQDQ: Carryless multiply (CLMUL)

If the asymmetric crypo in question were to use any of these operations, then yes, it could be accelerated by the appropriate hardware instruction.

However, standard asymmetric primitives such as RSA and Diffie-Hellman do not use these sorts of operations. Without knowing specifically what asymmetric algorithm you had in mind, we can conclude the answer is probably "No".

• There's a possible exception with the CLMUL instruction set, which can be helpful for some ECC cryptosystems in $GF(2^q)$ (although it's main justification appears to be AES-GCM). Also, functionally asymmetric encryption of large data blocks almost always uses symmetric encryption for the bulk of the data, thus routinely uses and benefits from AES... instructions. – fgrieu Nov 3 '16 at 7:42
• PCLMULQDQ can certainly be used for ECC acceleration, but take note that it's only for binary-field curves (and not prime-order curves). – Yehuda Lindell Nov 3 '16 at 11:38

Ella Rose's answer is technically a correct answer to the question as asked, but keep in mind that asymmetric crypto is rarely used alone in an actual cryptosystem.

Most real-world asymmetric cryptosystems are asymmetric/symmetric hybrids, where the asymmetric crypto is used only to establish or secure a shared secret that is then used with symmetric crypto.

If the symmetric crypto in that case is AES, then the AES-NI instructions, if available on the host that needs to do AES, can be used to speed up the symmetric cryptography portion of the overall processing compared to doing AES in software, as well as potentially remove a fair chunk of software complexity. (AES isn't that difficult to implement, but the less you need to implement yourself especially in security-critical portions of the software, the less the risk of making a mistake. It's better to focus on implementing the business logic of your application, whatever that is.)

Exactly how much of a benefit this provides will depend on the proportion between the symmetric and asymmetric portions of the cryptographic processing, and how much of a performance boost is provided by using AES-NI rather than doing AES in software.