2

I can recover something trivial like a 16-bit AES key in practice. I'm confident that a 64-bit AES key can be recovered. However, I have been unable to find any documentation of the biggest AES key that anyone claims to have recovered in practice. Are such competitions held, and is there a recognized progress meter that is kept?

Edit: I'm talking about brute-forcing intentionally weakened keys, i.e. repeating the first X bits of the key to the end.

2 Answers2

2

Are such competitions held, and is there a recognized progress meter that is kept?

No. It is generally believed that $2^{128}$ AES keyschedule and encryption operations are out of reach for just about anyone. If and when that changes and $2^{128}$ draws in to be a more realistic number perhaps people will do that.

However, I have been unable to find any documentation of the biggest AES key that anyone claims to have recovered in practice.

This is usually not an interesting publishable result unless you also have found some major optimization to some part of the computation and thus not very desirable to do for academics.


As for search speeds:

  • On a CPU - assuming you get lucky with instruction scheduling - one round of AES with a keyschedule computation (very optimistically) costs you about 3 CPU cycles on a single core. For each AES instance there are 10 such steps, so around 30 cycles overall for on-the-fly key scheduling and encryption of one block - using only throughput not latency numbers. This amounts to about 1-2 billion AES key tests per core per second on a modern CPU. Assuming it is one of the beefiest around it has 64 physical cores and two CPUs on a mainboard amounting to say 200 billion AES key tests per second per mainboard. Feasibly a determined attacker can acquire and operate say ten thousand such mainboards amounting to $2\times 10^{15}\approx 2^{50}$ key tests per second. Then a realistic upper bound for how long would want to have this hardware run non-stop would be say 10 years if determined which adds another factor of $\approx 2^{28}$ amounting in total to $2^{78}$ AES keys using 20,000 of the current beefiest CPUs run for 10 years with a highly optimized implementation.
  • As for GPUs: A top-end Nvidia Pascal GPU hits about 32GB/s of AES throughput. That is 2 billion AES instances per second without the keyschedule, with the keyschedule it will probably drop down to ~800 million AES instances per second. Even if we assume that later GPU generations give a 5x performance increase to this number we'd only be looking at the performance of 1-2 additional CPU cores for a lot more power draw, so this is likely not worth it.
  • As for FPGAs, this paper claims around 120Gb/s throughput from an FPGA that has ~150 thousand lookup tables. Nowadays there are FPGAs around that are 25x larger. Using the usual (optimistic) factor of 3 for the keyschedule we're looking at around 8 billion key tests per second and card. This might be worthwhile if you can cool it properly but chances are it's a better investment of power to use more CPUs (which draw comparably much).
  • As for ASICs, this paper claims $678\times 10^{-6}$ bits per clockcycle-gate as the best result (ish). Assuming a GPU-sized die running at say 1GHz this would amount to $2\times 10^{16}$ bits per second or $2^{47}$ AES instances per second. Dividing this by our usual factor yields about $2^{45}$ instances per second. Assuming then that you can in fact produce, power and cool such a large die and somehow stack say 8 into a server mainboard's PCIe slots it would give you $2^{48}$ tests per board or almost $2^{90}$ tests in 10 years using 10,000 boards with 8 GPU-sized dies each running at 1GHz for 10 years.
SEJPM
  • 46,697
  • 9
  • 103
  • 214
0

I presume when you say you can "recover" 16 bit keys you mean by brute forcing. That isn't really recovering a key in the sense of a cryptographic break. Obviously all keys can be recovered that way, just in an insurmountable time.

The longest key that can be recovered is the longest possible key (256 bit), which can be recovered quicker than simple brute force in just over 2^252 time and with 2^40 data.

There is more here.

Modal Nest
  • 1,473
  • 5
  • 18