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

[Andy Polyakov]

> I noticed that you integrated the bit-sliced version of AES in 2012 for
> ARMv7, probably following the work of Bernstein.

Quoting bsaes-armv7 commentary section:

# This implementation is direct adaptation of bsaes-x86_64 module for
# ARM NEON.

Then bsaes-x86_64:

### AES-128 [originally in CTR mode]                            ###
### bitsliced implementation for Intel Core 2 processors        ###
### requires support of SSE extensions up to SSSE3              ###
### Author: Emilia Käsper and Peter Schwabe                     ###

But as already mentioned unlike the original, OpenSSL module supports
all key lengths and more modes including decrypt [and on ARM it's
endian-neutral]. It's also optimized more aggressively than original.
Code referred to in original message appears to be qhasm adaptation of
one used as base for OpenSSL bsaes-x86_64 and as such shares original's
limitations, 128-bit key and encrypt only (no idea about endian neutrality).

> vector permutation (following Gueron's intel contribution, i guess)
> technic is present in the code.

Quoting vpaes-* commentary sections:

## Constant-time SSSE3 AES core implementation.
## version 0.1
##
## By Mike Hamburg (Stanford University), 2009
## Public domain.
##
## For details see http://shiftleft.org/papers/vector_aes/ and
## http://crypto.stanford.edu/vpaes/.

> 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.

Do your homework. If implied question is if different performance in
OpenSSL means that it's achieved at cost of security properties such as
resistance to side channel attacks, then answer would be no, all
security properties are preserved. If that's what you want to figure out
that is.

> 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).

As far as NEON ARMv7 goes there is bit-sliced AES-CTR and GHASH that
utilizes polynomial multiplication. Latter does use referred authors'
ideas, quoting ghash-armv4 commentary section:

# Switch to multiplication algorithm suggested in paper referred
# below and combine it with reduction algorithm from x86 module.
# Performance improvement over previous version varies from 65% on
# Snapdragon S4 to 110% on Cortex A9. In absolute terms Cortex A8
# processes one byte in 8.45 cycles, A9 - in 10.2, A15 - in 7.63,
# Snapdragon S4 - in 9.33.
#
# Câmara, D.; Gouvêa, C. P. L.; López, J. & Dahab, R.: Fast Software
# Polynomial Multiplication on ARM Processors using the NEON Engine.

If you compare results to ones reported in this paper, you'll notice
that  OpenSSL results are significantly better. But not at the cost of
security properties, as already mentioned. Just in case, "switch" means
that there was NEON-based code, and it was too constant-time, but it was
slower.

Note that there is no vpaes-armv7, but you're probably less interested
in it, because if it was present, it wouldn't be used for CTR and by
extension for GCM anyway.