[openssl-dev] AES-GCM for ARM: what is the status of the new work published by

Mon Jul 13 17:45:32 UTC 2015

Hi Andy,
I am very happy that my email caught your attention, and I thank you very 
much for the detailed answers!I will come back to you in 1 day or 2 on the 
technical questions, I will try to do more home works, as you said ;)In the 
meanwhile, I can just say that of course, I saw the code in OpenSSL for 
ARMv8, I went over it but I don't have the skills to understand it. You have 
been the main contributor to the whole ARM part of AES and GCM crypto in 
OpenSSL, so this is why I mentioned you. If I could contribute, I would do 
it, but I am afraid my skills in ASM programming for crypto algorithms are 
close to zero, and the OpenSSL community will keep depending on your 
excellent work for a while. Anyway, I am still learning and I will probably 
make some mistakes of understanding, please be patient with me, and let me 
know if there is some nonsense in what i write.
I noticed that you integrated the bit-sliced version of AES in 2012 for 
ARMv7, probably following the work of Bernstein. And that for ARMv8, the code 
in OpenSSL is using the special AES instructions. It is also good to learn 
that you have been using all the hardware acceleration available in each 
platform (VMULL.P8, VMULL.P64 and PMULL) and that the vector permutation 
(following Gueron's intel contribution, i guess) technic is present in the 
code. I have questions about this vector permutation code, specially on the 
security aspect of it, but I need to do more home works before I can ask. 

I know that some new cortices based on ARMv8 don't have crypto extensions, 
but the risk of not having NEON is very low.
I just want to point out that the paper and code published by the 2 Brazilian 
cryptographers (what i referred to in my previous message), contain 
improvements on both performance and security (they prevent some side channel 
attacks), and both for ARMv7 and ARMv8. While performance matters (a lot!), 
security matters even more, and this is my main concern.
My question, as you understood, relates to ARMv8 32 and 64 bit, but also to 
ARMv7. In fact, I am personally interested only in the ARMv7 code, and only 
for 128bit keys (but who cares about what I need. the community would need, i 
guess, both v7 and v8, and the 3 key lengths of AES).
When I asked about what is the "status", I meant, how much of Gouvea and 
Lopez 's technics are present in OpenSSL code. You answered me on most of the 
technical details, and i need time to process all the information, and you 
also gave good details on the performances. But in fact, my question was more 
about the security aspect of Gouvea and Lopez's work, the way they prevent 
timing attacks. Can you tell us more about what is the situation of the code 
in OpenSSL on that matter?
Thank you for your answers!All the best,Niko

13. Jul 2015 18:16 by appro at openssl.org:

> Hi,
>
>> What is the status of the improvements on security and performance for
>> AES-GCM on ARM published recently by Conrado P. L. Gouvêa, Julio López ?
>>
>> Implementing GCM on ARMv8. Conrado P. L. Gouvêa, Julio López. 2015 [1]
>> Which details also the ARMv7 case, and was presented at the RSA
>> Conference 2015 in the US, 2 months ago.
>> The paper is here [2].
>> The code is available here [3]
>>
>> My question goes primarily to Andy Polyakov.
>>
>> Is there any plan for integrating the code into openssl ?
>
> I don't quite understand... On one hand you effectively imply that
> OpenSSL doesn't have support for ARMv8 crypto extensions, which would
> mean that you didn't do your homework. On the other hand you explicitly
> call on me by name, which would mean that you did some homework...
>
> But in either case. OpenSSL does have support for ARMv8 crypto
> extensions, and there are no "holes" in it in sense that it utilizes all
> available extensions. And both 64- and 32-bit modes of operations are
> supported. Or to be more specific in context of the question ARMv8 AES
> instructions are used to implement AES-CTR and PMULL ones to implement
> GHASH, the GCM components. But unlike referred code OpenSSL code is
> endian-neutral (in sense that can be compiled for either endiannnes) and
> supports all AES key lengths and more encryption modes including
> decrypt. Looking at performance metrics, cycles per processed byte, for
> referred code vs. OpenSSL:
>
>               AES-128-CTR  GHASH
> Cortex A53    1.88/1.46    1.21/1.01
> Cortex A57    1.84/0.93    0.95/1.17
> Apple A7      1.21/1.20    0.51/0.92
>
> OpenSSL code is organized so that AES-CTR and GHASH performance are
> basically additive, so that you would have to add corresponding numbers
> to obtain GCM result.
>
> As it can be seen OpenSSL GHASH is slower on Cortex A57 (but not sum of
> CTR and GHASH) and Apple A7. There is explanation for that. One of GHASH
> implementations parameters is "aggregate factor" that denotes amount of
> multiplications that are performed prior reduction. OpenSSL uses factor
> of 4, while referred code - 8. Higher aggregate factor is on to-do list
> and there is no reason to believe that performance would be worse than
> reported in referred paper.
>
> The paper also discusses non-crypto-extension code. It is a valid
> question, because not all ARMv8 processors implement crypto extensions.
> For example APM X-Gene doesn't, nor does Qualcomm Snapdragon 810. What's
> going to happen there? As for AES. There was open question about which
> NEON implementation would provide best all-round performance, i.e.
> across range of processors. There were three contenders: a)
> straight-forward vtbl-based implementation that can be found in Linux
> kernel source tree; b) vector-permutation AES; c) bit-sliced AES. As it
> turned out it's combination of b) and c) that provides best performance.
> Vector-permutation code is already committed to source tree and existing
> bit-sliced ARMv7 code will be adapted for 64-bit mode. On side note,
> unlike original, OpenSSL bit-sliced AES module supports all key lengths
> and more encryption modes, including decrypt. Performance metrics for
> vector-permutation and bit-slices are collected in vpaes-armv8 module
> (comparison to referred paper is left as exercise for reader). As for
> non-crypto-extension GHASH, options are to be carefully examined and
> course of action is to be determined. [On side note one also have to
> keep in mind that even NEON support is specified to be optional.]
>
>> [1]
>> https://www.rsaconference.com/writable/presentations/file_upload/cryp-w01-secure-and-efficient-implementation-of-aes-based-cryptosystems.pdf
>>
>> [2] >> http://conradoplg.cryptoland.net/files/2010/12/gcm14.pdf
>>
>> [3] >> https://github.com/conradoplg/authenc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150713/8432a373/attachment-0001.html>