8

I've already seen some topics on this matter, but I feel like my question hasn't really been answered.

Given the following:

  • AES must be implemented in hardware (i.e. using the AES-NI instruction set) to ensure the best protection against side-channel attacks that target the algorithm's implementation (because of MixColumns operations)
  • Other encryption algorithms such as the Salsa20 family and NORX are less prone to such issues (if well implemented, at least in software)

...can we say that it is safer$^1$ to use such algorithms instead of AES if one may not ensure that AES-NI is properly implemented in the hardware that's being used ?

For instance, if one uses some x86-64 CPU that features this instruction set but whose design is kept secret, can AES be considered safe ? Respectively, are the other algorithms safe(r) on such a platform ?

$^1$Note that NORX is still in its early stages and has yet to win the CEASAR competition as well as withstanding the test of time, so it is only safe "on paper" for now

Dreadlockyx
  • 344
  • 4
  • 13

1 Answers1

10

It basically depends on what you consider side-channel attacks.

If you consider time/cache side channel attacks than chacha20 has been design with resistance to such attacks in mind while AES didn't. In fact, AES is vulnerable to these kind of attacks (as they were invented after AES was designed). But, hardware implementations, such as AES-NI are protected because they don't use caches and execute in constant time.

If you consider also power/electromagnetic side-channels then both algorithms are vulnerable and in this sense the community has researched A LOT more on protections for AES then for Chacha20 which will be significantly harder to protected due to its ARX nature which require expensive masking conversions. So it will be more easy to find protected , pure sw, AES implementations, even in open source. But you need a protected implementation, otherwise you will be vulnerable.

To summarize you have to check which side-channel attacks you want to protect against and the security claims of your implementation. It can't be simplified as "AES needs to use AES-NI" because we can have side-channel protected AES in pure software (see the link above).

Ruggero
  • 7,339
  • 33
  • 42