Hi All, Since we are talking about AES implementation in OpenSSL, Andy and myself wrote a blog about it (well its actually about this paper claiming that AES is vulnerable to timing attacks but nicely describes how AES is implemented in OpenSSL)
https://securityblog.redhat.com/2014/07/02/its-all-a-question-of-time-aes-timing-attacks-on-openssl/ On Thu, Jul 3, 2014 at 5:23 AM, [email protected] via RT <[email protected]> wrote: > > 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". > >
