8
$\begingroup$

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

|improve this question
$\endgroup$
  • 5
    $\begingroup$ I think it comes down to: "if you don't trust the implementation then don't use it". $\endgroup$ – Maarten Bodewes♦ Jun 13 '17 at 21:47
  • 1
    $\begingroup$ @MaartenBodewes So if I want to go extreme/hardcore, I could use an open hardware platform that runs open source software with proper implementations (and validations) at both levels to be nec plus ultra ? $\endgroup$ – Dreadlockyx Jun 13 '17 at 22:04
  • $\begingroup$ There is nothing wrong with that, unless you distrust the quality of the open source software. There is of course no perfect solution; software is too complex for that. $\endgroup$ – Maarten Bodewes♦ Jun 14 '17 at 15:15
  • $\begingroup$ If AES-NI were not properly implemented and suffered from software-level side-channel attacks, it would be trivial to notice. As it is currently, each instruction (AESENC, AESDEC, AESIMC, etc) take the same number of cycles to retire regardless of the plaintext or the key. As the only way to perform timing attacks on this level is through RDTSC, it is simple to prove that they are not vulnerable to these attacks. That doesn't mean that they aren't vulnerable to, e.g. power analysis attacks, though. $\endgroup$ – forest Feb 23 '18 at 5:00
10
$\begingroup$

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

|improve this answer
$\endgroup$
  • $\begingroup$ do you have a reference for "significantly harder to protected due to its ARX nature which require expensive masking conversions"? That is counter intuitive, as ARX is inherently composed of constant-time (and likely close to constant-power) operations with direct hardware support on the CPU $\endgroup$ – rmalayter Jun 14 '17 at 22:37
  • $\begingroup$ @rmalayter Why should ARX have more "likely close to constant-power" than other CPU instructions ? You can find the state-of-the-art algorithms for masking conversions here (but first order only! higher order seems broken $\endgroup$ – Ruggero Jun 15 '17 at 11:47
  • $\begingroup$ ARX instructions are very close to constant power because the first step in most ARX ciphers is to XOR the (uniformly random) key into the state. Thus very close to 50% of the transistors switch state on every ARX instruction, leading to constant power. I've read quite a few ARX papers and do not recall any having mentioned the need for "expensive masking functions"; will have to read your reference but it seems unnecessary if you have a uniformly random key involved (which is effectively a mask!). $\endgroup$ – rmalayter Jun 15 '17 at 12:31
  • $\begingroup$ @rmalayter actually AES does what you described, chacha20 doesn't. So I'm missing your point. However it might be argued that chacha20 has better DPA resistance due to of low data manipulable by the attacker that comes into the cipher (i.e. the nonce). $\endgroup$ – Ruggero Jun 15 '17 at 13:47
  • $\begingroup$ each quarter round in ChaCha starts with an XOR or addition of one of the key-containing words; I don't see at the moment how this is worse than AES key expansion from a DPA perspective. But it looks like I have some reading to do on DPA in general; I always assumed DPA involved an unrealistic attacker who had enough physical access to measure power consumption of a device very precisely but somehow couldn't just read key material or other memory contents on the device. $\endgroup$ – rmalayter Jun 15 '17 at 14:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.