7
$\begingroup$

Im trying to understand if nowadays using AES is secure or not, after reading some arguments on Schneier’s blog (to be more exact, a comment to “The NSA Is Breaking Most Encryption on the Internet”) it seems like it is not secure:

Now as the NSA GCHQ et al know very well the more efficient you make the implementation of crypto code the more side channels it has unless extreme caution is observed. One thing we do know is that optimized for speed and minimized number of gates is an almost certain guarantee of side channels no matter how clever you are. Also the NSA knew that developers would not write their own code they would simply download and use the competition candidate code.

As was pointed out and demonstration code exploited implementations of AES were subject to timing attacks that could fully leak the key across a network connection due to "cache hits" on the Intel x86 platform from base level pentiums upwards within weeks of the winning candidate being announced. Even today there are very side channel suseptable AES implementations in use in fact the majority of those implementations on the likes of routers and switches are timing channel cursed as are most application level software implementations that are more than a year or so old...

…at least not if the computer used is connected to external network.
Is this true or just based on assumptions?

|improve this question
$\endgroup$
  • 3
    $\begingroup$ It is possible to implement constant time AES. Either using the AES-NI instructions (extremely fast) or using bitslicing. For parallelizable modes like CTR, bitslicing is relatively fast. Those constant time implementations are gaining popularity, but are still in the minority. $\endgroup$ – CodesInChaos Dec 16 '13 at 16:21
  • 1
    $\begingroup$ Related question: AES timing attacks $\endgroup$ – CodesInChaos Dec 16 '13 at 16:25
  • 2
    $\begingroup$ the author of that comment listed 3 possibilities. Is there a reason you chose the 3rd? I could say similar things about pretty much any cipher. $\endgroup$ – mikeazo Dec 16 '13 at 20:08
11
$\begingroup$

Let's clear some bullshit first:

Now as the NSA GCHQ et al know very well the more efficient you make the implementaiton of crypto code the more side channels it has unless extream caution is observed. One thing we do know is that optomised for speed and minimized number of gates is an almost certain guarentee of side channels no matter how clever you are.

The horrendous spelling issues aside, this is absolute bullshit. On almost any CPU there are only three things in symmetric crypto that introduce side-channels:

  1. Branches dependent on secret data.
  2. Table lookups with an index dependent on secret data.
  3. CPU instructions that take non-constant time/power.

AES suffers from potential side-channel attacks because the obvious implementation of the S-box violates #2, and the obvious implementation of polynomial multiplication violates #1. Both issues can be avoided using trickery, though.

But in general you can optimize all you want as long as you don't branch on secret data, don't do table lookups with secret data and make sure that the CPU instructions you use always take the same amount of power and time (notable violaters of this are multiplication instructions in many lesser-known CPUs).

As to the question in the title, AFAIK Snowden has not published any documents that show cryptanalysis against AES, so AES is still as secure as before. I do not know whether Snowden published documents of the NSA abusing side-channels, however I wouldn't be surprised (or worried) at all if he did. Side-channels were long overlooked and many old implementations suffer from them. Modern day implementations are much more aware and as such don't suffer from them.

|improve this answer
$\endgroup$
  • $\begingroup$ Re: Your comment: "...in general you can optimize all you want as long as you don't branch on secret data.". Surely optimisation makes the code more confusing to understand, hence opens up more possibility of accidentally branching on secret data or not being able to spot when legacy code does so. $\endgroup$ – JW. Apr 30 '14 at 23:43
  • $\begingroup$ @JW. Optimized code is more difficult to understand, that is correct. But there should be no excuse for "accidently branching ons secret data". It's very hard to justify any form of branching in crypto code, as often everything is unrolled anyway, and the very few places where you do branch should be on loops with arbitrary data length. There is no excuse for incorporating legacy code that does not follow the same design principles. These are the burdens you take onto you when you write crypto code, but that doesn't make it "hard", or "almost certainly broken with side channels". $\endgroup$ – orlp May 1 '14 at 0:01

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