AES implementation is vulnerable to cache-timing attacks

[frozolotl]

As of 5376a55, the AES implementation uses the S-box in a way that is commonly known to be vulnerable to cache-timing attacks.
Cache-timing attacks on AES explains the issue.

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[huly-for-github]

Connected to Huly®: V_0.6-22202

[spytheman]

That commit has nothing to do with AES.

Can you be a bit more specific about what you mean?

[spytheman]

@oskar2517, perhaps you can help explain the details, given that you upvoted the issue?

[frozolotl]

I'm sorry, I guess I was being unclear (it was late and I wanted to sleep). I just mentioned the revision so that it's known which version of the code I found to be vulnerable.

Briefly, the issue is that, as seen in block_generic.v, an input-dependent lookup into the S-Box is performed.
Due to modern (anything after the 90s or so) CPUs ability to cache memory, this lookup is not guaranteed to be constant-time.
This can be abused by attackers to retrieve secrets.

As a mitigation, I would recommend re-implementing this primitive by binding against (not transpiling!) a well-known and high-quality cryptography library.

I haven't checked the other cryptographic algorithms in this repository, but as a precaution, I would recommend doing the same for them.
Implementing them securely is a difficult thing that even experts often struggle with.

[spytheman]

Thanks for the clarification.

[spytheman]

@kimshrier, @joe-conigliaro, @blackshirt what do you think?

[blackshirt]

@kimshrier, @joe-conigliaro, @blackshirt what do you think?

i dont think we have ported native AESNI hardware to support for timing-resistent operations...
there are some alternatives avaliables for this, like this one

• AES with vector permutations from Mike Hamburg.
• Bit slicing technique, like this one's, pure golang bitslices aes bsaes
• or this one

Unfortunately, i dont think we have one of them implemented in v.

I think the good step for this current time just adds a doc (note) on the aes readme (documentations) that states that The AES operations in this package are not implemented using constant-time algorithms. like the go one's.
Until we have timing-resistent one's

[kimshrier]

I would be willing to look into the 2 alternatives mentioned by @blackshirt and see if a pure v implementation is something I could do. I am severely resource constrained (no time for personal projects) at the moment so it might be a while before I could commit some serious time to it.