[dsacco]

Right, that observation is correct on the surface. But the reason why that's almost never done is because the goal of a cryptographic algorithm is to contribute enough safety margin on its own. Instead of encrypting twice, it's better to encrypt with a greater number of rounds, or to come up with a superior algorithm. In practice you sacrifice an unreasonable amount of performance double encrypting in a production environment for a threat model that is fantastically unrealistic.

[dankent]

You find it fantastically unrealistic that a vulnerability could be found for a well known and widely used encryption method?

[dsacco]

Depending on the algorithm: yes. I'm not saying all algorihms that are widely used and well known are extremely unlikely to be broken.

I would happily bet $10,000 that AES will not be broken in the next ten years. I'd make the same bet for several hash functions.

And as a corollary to this point: I think it's incredibly foolish to try and combat the threat of an encryption algorithm being broken by double encrypting a plaintext, including with that algorithm.

[dankent]

I wouldn't take that bet either as I agree that is a very unlikely thing to happen.

Note, though, that you are using the specific word 'algorithm', where as I am talking about 'methods'. Most cryptographic failures are in how the algorithms are implemented or applied, not a problem in the underlying maths.

I would not be nearly so confident about a similar bet that applied to the actual code being widely used for encryption.

[computerex]

> I would happily bet $10,000 that AES will not be broken in the next ten years.

What are you talking about: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

You'd lose the bet so hard. Don't take anything for granted. Even the most supposedly secure and widely used primitives should be scrutinized and are subjects to constant attacks.

[dsacco]

> What are you talking about: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

Read that paper again. Cache timing attacks (and more generally timing attacks) are a subset of side channel attacks, which are not a break in the fundamental design of a cryptographic algorithm. When Bernstein mentions that he considers it a design flaw, that's a misnomer in the mathematical sense: he means that AES is antagonistic to a software implementation that can resist a timing attack, not that the design of the algorithm is fundamentally unsound. This is essentially true for all encryption schemes that utilize lookup tables and S-boxes, which he even mentions in the paper.

This is similar to using acoustic analysis or fault injection for key retrieval - yes, you've done it, but it's not really fair to say you've broken AES whatsoever. That remains a pipe dream. You've merely broken an AES implementation on a particular platform that was not hardened for this threat. Just a few months ago a team came up with a way to retrieve an AES key through acoustic analysis in a paper that was published here on HN. That's not actually the same as a cryptanalysis, the best of which is this: https://eprint.iacr.org/2009/317

There are effective CPU mitigations that allow you to safely implement algorithms in order to avoid this issue - for example, AES-NI theoretically mitigates cache timing attacks. See: http://cseweb.ucsd.edu/~hovav/dist/aes_cache.pdf

So: no, I wouldn't "lose that bet so hard."

[computerex]

I know this is a side channel attack. I know people have used acoustic analysis to retrieve 4096 bit RSA keys, but the attack outlined in the paper is more feasible in real life situations, and systems do get compromised due to implementation details. AES might not be broken as a whole but that doesn't mean you can't attack specific usages.

AES isn't proven to be secure. I don't know about $10k, but I would not bet my life on any hash function not being broken.

[JoachimSchipper]

That's not an (algorithmic) break, but a (side-channel) attack on some implementation. "Break" is precise jargon here; you're right that a particular real-world implementation of a strong algorithm may be weak, but that doesn't contradict anything dsacco said.

Also, please be nice.