Don't do that, then.

[mdlbear]

According to this paper [pdf], AES encryption may be much easier to crack using linear cryptography than is commonly thought. The paper is, however, non-constructive: it makes a plausible case but doesn't actually demonstrate a solution.

The attack's runtime is comparable to performing 64^w encryptions where w is the (unknown) minimum Hamming weight in certain binary linear error-correcting codes (BLECCs) associated with AES-256. If w < 43 then our attack is faster than exhaustive key search; probably w < 10. (Also there should be ciphertext-only attacks if the plaintext is natural English.)

It also gives a construction for a family of encryption algorithms that avoid the problem. The attack does rely on having a large number of plaintext/ciphertext pairs encrypted with the same key, or an even larger amount of ciphertext with known statistics.

The workaround for now would appear to be to use a different random or pseudorandom key for each document (and of course to compress each document before you encrypt it, and use CBC mode encryption). You're left with a key-management problem, but managing that many ID/key pairs is no worse than managing all the document IDs in a hash-based version control system like git. Similarly, systems that use one-time random session keys should be safe as long as they're using compression and CBC mode, and renegotiate their keys frequently.

(From cryptome.)

Comments

[sbisson.livejournal.com]

That's probably why NSA Suite B uses AES with elliptic curve key generation and exchange...