[SECURITY] AES is Susceptible to Cache-Timing Attacks

[soatok]

Source code:

• https://github.com/bcgit/pc-dart/blob/08d1aaa920e4d00ddf94140f65f952cac48707d1/lib/block/aes_fast.dart#L131-L219
• https://github.com/bcgit/pc-dart/blob/08d1aaa920e4d00ddf94140f65f952cac48707d1/lib/block/aes_fast.dart#L230-L317

The core problem here is the use of a table look-up, which leaks your AES keys through cache-timing.

Relevant papers:

• https://cr.yp.to/antiforgery/cachetiming-20050414.pdf
• https://www.microsoft.com/en-us/research/wp-content/uploads/2006/10/aes-timing.pdf

Mitigation: Bitsliced S-Boxes.

See also: Bitsliced AES Implementation in C

[AKushWarrior]

Okay, so this is a general issue with S-box based AES implementations; notably, the correspondent AES implementation from Bouncy Castle is deprecated with the notice that it should not be used when close observation is possible. The current AES engine in this library is an artifact of the past maintainer's work; I don't know what their reasoning for using the deprecated version was.

This implementation, currently the suggested general-use BouncyCastle implementation, adds operations to compute the other tables from one precomputed table, making a summative cache timing attack infeasible (at least, that's my understanding).

@mwcw do you have thoughts or a plan to resolve this?

[mwcw]

Hi,

I'll port AES engine over and get it tested and released ASAP.

MW

[mwcw]

The AESEngine from bc-java has been ported in as a replacement and version mentioned here replaced.

A release 3.4.0-rc1 has been created.

MW

[soatok]

Don't forget to fix #140 in the same go. (It's a smaller diff than porting a new engine from Java,, and is also important for the security of AES-GCM.)

[mwcw]

https://github.com/bcgit/pc-dart/releases/tag/v3.4.0