
Researchers identify first flaws in AES - fogus
http://www.net-security.org/secworld.php?id=11474
======
bonzoesc
I guess once SHA-3 is done, NIST better start research on the next symmetric
cipher. The attack only knocks off two bits now, but attacks only get better
with time.

Note that you should be using accepted standards for key management anyways.
NIST believes that AES-128 has 128 bits of strength, and AES-256 has 256 bits
of strength [1, page 63], which they find "Acceptable" until 2031 [1, page
65]; the catch is that any individual key should be expired after a few years.
This is called a "cryptoperiod," and the longest they recommend using a key is
five years [1, page 55].

By this standard, keep using AES-256, but change your keys every year, and be
prepared to migrate to a new cipher at some point within the next decade or
two.

[1]:
[http://csrc.nist.gov/publications/drafts/800-57/Draft_SP800-...](http://csrc.nist.gov/publications/drafts/800-57/Draft_SP800-57-Part1-Rev3_May2011.pdf)

~~~
tptacek
The total cost to the industry of adopting AES was enormous. That implies that
deprecating it would at present impose costs that far outweigh the benefits,
because replacing AES will be expensive, and there are at present minimal
practical benefits to doing so. Remember, plenty of critical systems have been
fielded that rely on RC4 and DES-EDE, both of which are also (for all intents
and purposes) unbroken in their most common usage.

For Hacker News, the far more important thing to point out is that no matter
what block cipher you use, you are _never_ going to get burnt by research like
this, but you are _almost certain_ to be completely boned by implementation
errors.

~~~
quanticle
I would consider key management to be a greater problem than implementation,
at this point. There are many verified, open-source, freely-licensed
cryptography libraries out there. You shouldn't be rolling your own
implementation.

Unfortunately, key management is still a difficult problem. Without secure
keys, even the most secure encryption becomes nothing more than an
inconvenience.

~~~
tptacek
Everyone says this, because Applied Cryptography (not a good book) says it.
But no, the problem of coming up with a good 128 bit or 256 bit key is not the
hardest part of getting a cryptosystem working. Plenty of static-keyed
systems, in which keys are more or less guaranteed to come from /dev/random,
end up totally busted.

You seem to be thinking that when I say "implement", I mean, "building an AES
core library from scratch". No. I mean properly _using_ a well tested, totally
sound AES library in a way that doesn't leave your application totally boned.

~~~
cperciva
I've seen a lot of broken key management. People using MD5(passphrase) (
_cough_ OpenSSH _cough_ ) as a key, people downloading public keys over
insecure networks and not verifying them at all, people distributing secret
keys along with software destined to be run on hostile systems...

I'm happy to say that systems which try to generate random passwords do tend
to generate securely random passwords, though. /dev/random has been a huge
help there.

~~~
tptacek
You wouldn't want to leave anyone with the impression that they're mostly fine
as long as their keys are securely generated.

~~~
cperciva
No, of course not. That's why I work so hard to point out the ways that people
get crypto wrong (and how to do it right).

I'm just saying that key management is absolutely not a solved problem yet.

~~~
tptacek
Yeah yeah, not arguing, just wanted us both on the record on this point.
Crypto: dangerous.

------
cperciva
Note: This attack requires a large amount of RAM. They may have saved a few
operations, but they increased the total _cost_ by many orders of magnitude
over a brute-force search because they need a larger machine.

Also note: An attack taking 2^126.1 operations to break AES-128 is not 2^1.9
times faster than brute force; it's 2^0.9 times faster than brute force. A
brute force search on a 128-bit key takes _on average 2^127 operations_.

In short, this is definitely in the "interesting new method to explore" column
rather than the "interesting attack" column.

~~~
burgerbrain
_"Note: This attack requires a large amount of RAM. They may have saved a few
operations, but they increased the total cost by many orders of magnitude over
a brute-force search because they need a larger machine."_

Is this terribly relevant though? Deep Crack was a quarter of a million
dollars (90s dollars) as I recall.

~~~
tptacek
Yes. The entire concept of cryptanalysis revolves around cost factors. It is
very relevant when a new avenue of attack costs more than brute force in its
best known mode of implementation.

That doesn't make the research a dead end, but it further reduces the
relevance of this work to engineers.

------
dchest
Paper and slides: [http://research.microsoft.com/en-
us/projects/cryptanalysis/a...](http://research.microsoft.com/en-
us/projects/cryptanalysis/aes.aspx)

~~~
phillmv
Ah!

Novel cryptanalysis technique reduces practical AES key length by about 2
bits.

~~~
eru
Which is quite an achievement.

------
nikcub
Does anybody remember or have a citation for the story about how the NSA made
some recommended changes to Rijndael, but nobody understood them at the time?
This was back in the mid-90s, during the AES/DES replacement assesment and
competition period.

It was then only years later that the NSA changes were understood to be
strengthening the cypher against an attack type that was unknown to the public
at the time, but that the NSA obviously knew about. I remember there were also
suspicions that the NSA were attempting to weaken the algorithm, much as they
did with DES.

It was the case that the NSA were always 10-15 years ahead of the public in
crypto (or even longer in terms of the discovery of public key crypto). I
wonder if their old proposed changes to Rijndael have anything to do with
this, or if they knew about this type of attack but still recommended AES.

Apologies for being vague about the story - but I do remember those details. I
can't recall where I heard about it.

~~~
dchest
You're misremembering, twice. There was a story about mysterious S-boxes
selected by NSA for DES
[http://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.27...](http://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.27s_involvement_in_the_design).
Those S-boxes turned out to be designed to resist differential attacks, which
were only known to NSA at that time. This doesn't count as weakening at all.

The difference between AES and Rijndael is only in that AES has a fixed block
size of 128 bits and a key size of 128, 192, or 256 bits, whereas Rijndael can
be specified with block and key sizes in any multiple of 32 bits, with a
minimum of 128 bits and a maximum of 256 bits.
([http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#De...](http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Description_of_the_cipher))

------
seagaia
Well, we certainly won't have to worry about it for _now_. But that doesn't
mean we shouldn't worry about it, of course.

It's a ways off in terms of orders of magnitude for how fast our computers
now, and I don't think computers will be growing at that rate in terms of
power unless new breakthroughs are found.

~~~
sp332
If you couldn't crack it before, you still can't crack it now. This attack
only makes it 4 times easier to break, not even an order of magnitude.

~~~
eru
If you count in binary, 2 bits are two orders of magnitude.

------
snorkel
Don't panic yet. It still requires a trillion machines for billions of years
to brute force.

