> Since this may in future cover much more than just AES-NI... Good observation Doctor, done. Attached is the updated text.
diff --git a/doc/crypto/EVP_EncryptInit.pod b/doc/crypto/EVP_EncryptInit.pod index f6e4396..8d7636c 100644 --- a/doc/crypto/EVP_EncryptInit.pod +++ b/doc/crypto/EVP_EncryptInit.pod @@ -433,7 +433,10 @@ for AES. Where possible the B<EVP> interface to symmetric ciphers should be used in preference to the low level interfaces. This is because the code then becomes -transparent to the cipher used and much more flexible. +transparent to the cipher used and much more flexible. Additionally, the +B<EVP> interface will ensure the use of platform specific cryptographic +acceleration such as AES-NI (the low level interfaces do not provide the +guarantee). PKCS padding works by adding B<n> padding bytes of value B<n> to make the total length of the encrypted data a multiple of the block size. Padding is always ***** On Wed, Jul 2, 2014 at 12:08 PM, Stephen Henson via RT <[email protected]> wrote: > On Wed Jul 02 07:12:19 2014, [email protected] wrote: >> Questions on AES-NI and how to enable them have come up twice recently >> on the stack exchanges (like stack overflow). >> >> This patch documents use of the AES-NI instruction by way of the EVP_* >> interface. >> > > Since this may in future cover much more than just AES-NI I'd suggest we say > something like "platform specific cryptographic acceleration such as AES-NI".
EVP_EncryptInit.patch
Description: Binary data
