Another look at support for AES and GCM instructions on ARM processors
florian-str opened this issue · comments
More than four years ago, an issue regarding this topic was closed without being solved (#363).
In the meantime the technology has evolved and more and more systems in all device classes are adopting arm64 chips. Apple's decision to adopt their own chips will likely speedup the adoption of arm chips in other devices as well.
Because of this, I think it would be worth reconsidering the implementation.
AEGIS is way faster while being more secure. It's in the development branch of libsodium, and supports ARM CPUs.
ARM support for AES-GCM may eventually be added, but in that context, this is really not a priority.
AEGIS is way faster while being more secure.
sure, but there is still a huge amount of equipment and programs that use AES, and those programs and equipment will be used for decades...
A pull request would be welcome. In the meantime, XChaCha is the best option for portability. If maximum performance on Intel and ARM is actually mandatory, AEGIS is the best option.
AES-GCM doesn't have any advantage over these, and its short nonce size makes it worse. I don't see any use for it in the context of libsodium. And as it was never used by high-level APIs, it may even eventually get removed or deprecated.
Once again, a PR would be the best way to make it happen. Opening a bug report is not.
AEGIS is way faster while being more secure. It's in the development branch of libsodium, and supports ARM CPUs.
Since both AEGIS and GCM fail catastrophically on key/nonce reuse - could you explain how AEGIS is "more secure"?
P.S. I'm not arguing for addition of AES-GCM, though I'd love to see AES-GCM-SIV added.
Doesn't leak the key is the state is leaked. No practical size limits. Larger nonce size, so random nonces are fine and it would work well with the crypto_secretstream API.
and it would work well with the crypto_secretstream API.
