# decrypt AES without whole key

Is there a way to decrypt a AES cipher Text which was encrypted twice with some key, when having a part of this key? (the last 3 bytes of the key are missing)

• There is no obvious (= not requiring cryptanalysis) way other to try every possible 3-byte combination, no. The fact that it was encrypted twice changes nothing. – Thomas Oct 27 '12 at 2:31
• That said, $3 · 8 = 24$ bits, and $2^{24}$ is only about $16$ million tries. Well within range of brute force attacks, if you've got some known text to test against, of course. – Maarten Bodewes Oct 27 '12 at 22:00
• Incidentally, why would anyone bother using AES twice? If that gained you anything, it would already be part of the algorithm. – Stephen Touset Nov 30 '12 at 21:08

As an above comment said, you have $2^{24}$ different combinations to test as the key. However, if you don't have anything to verify with (i.e. the plaintext is still random data), no.

There is no obvious (= not requiring cryptanalysis) way other to try every possible 3-byte combination, no. The fact that it was encrypted twice changes nothing. – Thomas

That said, $3·8=24$ bits, and $2^{24}$ is only about $16$ million tries. Well within range of brute force attacks, if you've got some known text to test against, of course. – owlstead

The fact that it's been encrypted twice doesn't change "nothing," you'd have to decrypt it twice, but that's a negligible factor here.

Assuming it takes 1000 FLOPs per try, and a household computer has a speed of 100 gigaFLOPs; you'd be able to try all 16 million combinations in $2^{24} · 1000/(100 · 10^9)) = 0.16$ seconds.

$0.16$ seconds is "well within range of brute force." The numbers might be off a bit, but they'd have to be off by orders of magnitude for this to cease to be feasible.

The main problem here is to know if your guess is correct. If just AES was used and you don't have the original plaintext, you'd have to guess if the file is correct. If this is part of an archive with a pre-defined format, you could check and see if the headers look realistic.

Incidentally, why would anyone bother using AES twice? If that gained you anything, it would already be part of the algorithm.

What Stephen means is AES already has a scheduled number of rounds that are applied. The number of rounds varies by key size: it's 10, 12 and 14 rounds for a 128-bit, 192-bit and 256-bit keys, respectively.

• Note that using FLOPs (floating point operations per second) is not that useful, since for most crypto algorithms you don't use floating point calculations at all. Better have fast logical, bitwise and integer operations. – Paŭlo Ebermann Dec 5 '12 at 23:37
• @PaŭloEbermann In addition of being somewhat slow, floating-point arithmetic is a very bad choice for crypto as it is not well-defined (different floating-point states and implementations can return slightly different results, which in crypto mean you get garbage) whereas you can hardly mess up unsigned integer arithmetic. – Thomas Dec 6 '12 at 0:13