OCaml Forge
SCM

Detail: [#1294] rijndael-fast-alg.c vulnerable to cache timing side channel attack

Bugs: Browse | Download .csv | Monitor

[#1294] rijndael-fast-alg.c vulnerable to cache timing side channel attack

Date:
2013-07-17 14:05
Priority:
3
State:
Closed
Submitted by:
David Sheets (dsheets)
Assigned to:
Nobody (None)
Hardware:
None
Resolution:
Fixed
Severity:
major
Version:
None
Component:
None
Operating System:
None
Product:
None
 
URL:
Summary:
rijndael-fast-alg.c vulnerable to cache timing side channel attack

Detailed description
The S-box lookup tables combined with processor caches open the door to very effective side channel attacks.

See http://cr.yp.to/antiforgery/cachetiming-20050414.pdf for the attack.

See http://www.iacr.org/archive/ches2009/57470001/57470001.pdf for a mitigation.

I was only able to find an implementation of CTR mode which avoids the cache side channel. See djb's NaCl library <http://nacl.cr.yp.to/stream.html> which has both a portable and a Core 2 specialized implementation.

Followup

Message
Date: 2016-06-25 17:36
Sender: Xavier Leroy

The forthcoming release 1.11 of Cryptokit uses the Intel AESNI hardware implementation of AES when available. This should thwart the timing attacks on x86 platforms. The issue remains for other platforms, but as Sylvain Le Gall wrote, there is probably no good, platform-independent solution.
Date: 2013-08-15 21:14
Sender: Sylvain Le Gall

We don't have right now a reasonable alternative to the current algorithm. Also the only thing we probably can do about it is to use the new AES instruction from x86 when available but it will only mitigate attack on this arch.

Quoting Xavier Leroy:
I read a bit about bitslice implementations of AES. It's not as
complicated as I thought, but the show-stopper is that they are fast only when processing N blocks of data at the same time, not one block at a time. Not only this doesn't fit the Cryptokit programming model, but it doesn't apply to some feedback schemes like CBC. So, it's useless for us.

Here is my proposal to close this bug:
I can create a note about this and put it in cryptokit.mli to document this weakness and send me you the patch for review. This will help any user of the library to be aware of the issue and hopefully some one with good knowledge of the issue can provide a patch.
What about documenting

Attached Files:

Changes:

Field Old Value Date By
status_idOpen2016-06-25 17:36xleroy
close_dateNone2016-06-25 17:36xleroy
ResolutionNone2016-06-25 17:36xleroy