Thanks Bruno and Erik Jan for the quick and detailed answers!
I
noticed indeed that you are using the Elliptic curves crypto of NaCl on
iOS, which is a smart choice.
And thanks for pointing out the timing
attack (tables and cache) published in 2009.
I am well aware of this
kind of attack on AES and GCM when lookup tables are used, but since
2009, we got some improvements, on intel CPU (AES-NI) at least, which
patches are already included in openssl (Gueron et al). But I agree with
you that for ARM, we are a bit left behind.
About the question if
elliptic curves are safer than AES-GCM, i would say it is a question of
trust.... ECC is way too young for me to trust it. I prefer plain old
"modulo a prime" groups, with their caveats (longer keys, more cpu
intensive) and their limitations (side-channel attacks) but that have
benefited from a huge community of cryptographers, coders and debuggers
for now 40 years.
I believe that, if used correctly, RSA, AES, GCM,
and DHE can be very efficient. And I am a bit afraid of the sudden
euphoria for "magical" curves.
Now if we come back to our subject of
interest, which is ARM and iOS, i would say that the situation is
tricky, but we can find a solution, and I am interested in helping.
For ARMv7 we have NEON VMULL.P8 instructions (from iPhone 3GS and
above, if i am not mistaken, ARM11 doesnt have VMULL.P8)
For ARMv8 we
have much more, including AES HW accel... (this is in iPhone 5S and
above)
You can have a look at :
- About binary polynominal
multiplication for GCM on ARMv7: "Fast Software Polynomial
Multiplication on ARM Processors using the NEON Engine." Danilo Camara,
Conrado P. L. Gouvea⋆, Julio Lopez and Ricardo Dahab. 2010/2013 [1]
their code available here [2] hasn't made it into openssl (AFAIK)
and
- Implementing GCM on ARMv8. Conrado P. L. Gouvêa, Julio López. 2015
[3]
Which details also the ARMv7 case, and was presented at the RSA
Conference 2015 in the US, 2 months ago.
The paper is here [4].
The code
is available here [5].
In addition:
It seems that the openssl
implementation benefits from NEON in the GHASH (coded by Polyakov) since
march 2011 [6] which means GCM timing attack is not possible (no lookup
tables).
Also to be checked, is the AES timing resistant bitsliced
implementation from Bernstein and Schwabe that Bruno referred to in the
linked PDF. It is probable that the ARM version has been integrated into
openssl, but I haven't double checked. If it is not there, then it most
probably is present in [5].
So... I am quite interested in helping
with having a fully secure AES-GCM stack on ARM, including on iOS. Let's
see how to proceed, starting probably from [5] and then integrate it in
OpenSSL? Any idea is welcomed.
Finally, just a small comment: If
AES-GCM is not as secure as ECC, then why are you still using it in the
android implementation of your crypto box? (Dont get me wrong, i prefer
AES-GCM over ECC!)
Also, bouncy castle's implementation of AES-GCM is
known to be slow, not accelerated at all (even on intel) and not even
parallelized. What performances have you got on that?
All the
best,
Niko.
[1]
http://conradoplg.cryptoland.net/files/2010/12/mocrysen13.pdf
[2]
http://conradoplg.cryptoland.net/software/ecc-and-ae-for-arm-neon/
[3]
https://www.rsaconference.com/writable/presentations/file_upload/cryp-w01...
[4]
http://conradoplg.cryptoland.net/files/2010/12/gcm14.pdf
[5]
https://github.com/conradoplg/authenc
[6]
http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/modes/asm/gh...
On 2015-06-19 13:54, abstractj wrote:
Good morning Niko, I hope
you're doing well. Please, notice
that GCM mode
support is not a
limitation of AG iOS, but a restriction from
Apple.
If the
document on
https://github.com/edewit/aerogear-crypto-cordova/blob/master/README.md
[1]
states that GCM is support, it pretty much relates to Android. If
the
> senteces are not clear enough, feel free to file a Jira
https://issues.jboss.org/browse/AGCORDOVA [2].
Answering your
questions:
- Is GCM mode for AES encryption supported on iOS
aerogear crypto module
(and the cordova plugin) ?
No. But, we are
open for suggestions. In the future we plan to make
aerogear-ios-crypto pluggable. Into this way you're free to
go with
CommonCrypto or whatever provider you want.
- If not, how difficult
would it be to use the private API in iOS
CommonCrypto ? I didnt try
it myself, i have just been reading
the code....
I'd say, would
take time and the only way I see today is plugging OpenSSL.
The reason
why NaCl was choosen, was not only the fact of
CommonCrypto not
supporting GCM, but also, because it's safer[1].
If you feel like,
that should be reconsidered. Feel free to create a feature
request
against
https://issues.jboss.org/browse/agios [3]. I
hope it helps.
>
[1] -
https://cryptojedi.org/papers/aesbs-20090616.pdf [4]
>
> --
View this message in context:
http://aerogear-users.1116366.n5.nabble.com/Aerogear-users-AeroGear-Crypt...
[5]
Sent from the aerogear-users mailing list archive at
Nabble.com.
> _______________________________________________
Aerogear-users mailing list
> Aerogear-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-users [6]
Links:
------
[1]
https://github.com/edewit/aerogear-crypto-cordova/blob/master/README.md
[2]
https://issues.jboss.org/browse/AGCORDOVA
[3]
https://issues.jboss.org/browse/agios
[4]
https://cryptojedi.org/papers/aesbs-20090616.pdf
[5]
http://aerogear-users.1116366.n5.nabble.com/Aerogear-users-AeroGear-Crypt...
[6]
https://lists.jboss.org/mailman/listinfo/aerogear-users