Hacker News new | ask | show | jobs
by kragen 406 days ago
This is an excellent comment, but I think it's worth pointing out some lacunae.

The most important one is that we're assuming that nobody finds a weakness in AES-256, so we have to brute-force it instead of taking some kind of shortcut. Historically speaking, that doesn't seem like a sure bet. (Some slight progress has been made on AES, but nothing practically useful yet: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#K...) Similar comments apply to factoring large semiprimes and ECDLP; algorithmic improvements could remove many orders of magnitude from these estimates.

Sometimes, even when weaknesses aren't known in the algorithms themselves, there are weaknesses in how they are applied. The Debian OpenSSL fiasco, which seems to have been accidental, may be the best-known example: all secret keys were generated with only 16 bits of entropy. Reusing IVs for OFB or CTR mode is also catastrophic.

A somewhat pedantic note is that you seem to be using two conflicting definitions of "boil the oceans" in different parts of your comment: to raise them to the boiling temperature while leaving them liquid, at first, and to convert them to vapor, later, since you talk about "refilling them". Converting them to vapor requires several times more energy than that. Also, you dropped an order of magnitude somewhere; raising the oceans to boiling requires 5.46 × 10²⁶ J, not 5... × 10²⁵ as you say. ("545 million exajoules" is correct.)

I used `cal_mean` from units(1) to do the calculation, which is based on the mean specific heat of water from 1° to 100°. I'm not sure that's correct for salt water, though, and in any case that's a minor error.

"about 10,000 times humanity's annual energy consumption" is wrong. 545 million exajoules is about a million years of humanity's energy consumption, which is only about 18 terawatts, excluding agriculture.

As gosub100 pointed out, on average you only have to try 2²⁵⁵ possible keys before finding the right one, not all 2²⁵⁶, but that's only a factor of 2.

10¹⁸ AES attempts per second does seem like a reasonable upper bound, but it's much faster than currently existing encryption hardware. 10¹⁸ Hz is the frequency of 0.3-nanometer X-rays with an energy of about 4000 electron volts. I feel like any computer hardware that is performing operations that fast probably cannot be made out of molecules or atoms. You might be able to build it on the surface of a neutron star or a black hole. Seth Lloyd's Nature paper from 02000 on the "ultimate laptop", "Ultimate physical limits to computation", explores some of the physical phenomena involved, and how fast they could possibly compute: https://faculty.pku.edu.cn/_resources/group1/M00/00/0D/cxv0B...

If we take 10¹⁸ Hz and 2²⁵⁶ cycles as given, it is true that one computer would need 10⁵⁹ seconds to finish the job (4×10⁵¹ years), which is indeed about 2.7 × 10⁴¹ times longer than the universe has existed so far (13.79 billion years). But it's worth pointing out that the universe's lifetime is not yet over; it is expected to continue existing much longer than that: https://en.wikipedia.org/wiki/Timeline_of_the_far_future lists various stages of its future evolution, including the end of star formation in 10¹²–10¹⁴ years, the last star burning out in 1.2 × 10¹⁴ years, 10³⁰ years until all the galaxies fall apart, 2×10³⁶–3×10⁴³ years until all protons and neutrons are gone (if protons decay), 10⁹¹ years until the Milky Way's black hole evaporates, and 10¹⁰⁶–2.1×10¹⁰⁹ years until the last black holes evaporate. If protons are stable, you could definitely build a computer that kept computing for the necessary 10⁵² years.

And (as you point out next!) you could use more than one computer. If you could somehow use 10⁵⁹ computers, you could finish the job in a second, rather than in untold eons. It depends on how many computers you can get!

"10 watts" is a somewhat handwavy estimate. Most of the computers around me, in things like my multimeter and my MicroSD card, use a lot less power than that, often a few milliwatts. (The fact that the MicroSD card doesn't have a monitor and keyboard is irrelevant to using it for AES cracking.) I'm currently working on a project called the Zorzpad, to build a self-sufficient portable personal computing environment on under a milliwatt, something that has become possible recently due to advancements in subthreshold digital logic.

But even a milliwatt may be an overestimate for AES cracking on classical hardware, because reversible logic may be able to drop power consumption by one or more additional orders of magnitude, and as far as we know, there's no lower limit (not even the ones Lloyd's article talks about apply). AES cracking is especially suited for reversible computing, which is why I used it as an example in this comment a week ago: https://news.ycombinator.com/item?id=43850835

It may be worth pointing out that 10⁶⁰ joules (which, despite the possible weaknesses above in its derivation, is certainly a plausible ballpark) is a large number not just measured against Earth, but measured against the Sun and indeed the energy output of the entire Milky Way galaxy.

It's even large compared to the available energy in the Milky Way. If you divide it by c² you get 1.2 × 10⁴³ kg. The Milky Way weighs 1.15 × 10¹² solar masses (https://en.wikipedia.org/wiki/Milky_Way) which turns out to be 2.29 × 10⁴² kg, which is 2.06 × 10⁵⁹ J. So even if you converted the entire galaxy into energy to power your AES crackers, you wouldn't get 10⁶⁰ J.

It's probably worth including AES performance numbers on currently available hardware. You'll still get galactic numbers demonstrating that AES-256 is not currently brute-forceable.

1 comments

Thank you for this correction and additional perspective.

The Debian vulnerability was particularly bad. An AES key with 16 bits of entropy can be broken with the energy used by a single LED for a fraction of a nanosecond.

Reducing entropy covertly is probably the sole purpose of the so-called Intel Management Engine

Happy to contribute!

I'm not sure the Debian vulnerability affected AES keys, but it definitely affected RSA keys.

A single LED is somewhere between 1 milliwatt and 1 watt, so in a tenth of a nanosecond it uses between 100 femtojoules and 100 picojoules. 2¹⁵ AES encryption operations currently require a lot more energy than that. I'm not sure how much, but it's a lot more.

How much does an AES encryption operation take? https://calomel.org/aesni_ssl_performance.html suggests AES-256-GCM runs at 2957 megabytes per second on each core of an "Intel Gold 5412U", which https://www.intel.la/content/www/xl/es/products/sku/232374/i... tells me is a 24-core CPU launched in Q1 of 02023 with a TDP of 185 watts. https://en.wikipedia.org/wiki/Advanced_Encryption_Standard says the AES block size is 128 bits, so 2957MB/s is 185 million blocks per second per core. Dividing 185 watts by 24 cores of that gives 41.7 nanojoules per block. This is probably reasonably representative of energy requirements for current AES hardware implementations. It presumably doesn't include key setup time, and brute-force cracking will do more key setup than normal encryption, but it's probably in the ballpark, especially for dedicated chips ticking through closely related keys. In any case, key setup surely cannot take less than zero energy, so this represents a lower bound.

Running

    openssl speed -elapsed -evp aes-256-gcm
on my own laptop (without -evp, I get "speed: Unknown algorithm aes-256-gcm"), I get 3900 megabytes per second for large block sizes, or 2300 megabytes per second running on battery power.

    The 'numbers' are in 1000s of bytes per second processed.
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
    AES-256-GCM     353329.81k  1012347.01k  2190564.18k  3178319.19k  3791358.63k  3676427.61k
According to

    cat /sys/class/power_supply/BAT0/power_now
I'm using about 12–16 million microwatts to do this, compared to about 6–8 watts when idle. So we can ballpark the AES energy consumption around 7 watts. Dividing that by 2300 megabytes per second, it comes out to about 49 nanojoules per block. This is reassuringly similar to the calomel numbers.

The number for 16-byte blocks is much lower, like 240 megabytes per second on battery and 360 megabytes per second on AC power. This probably tells us key setup takes about an order of magnitude more energy than encrypting a block, but maybe that's just because AMD was optimizing encryption speed over key setup speed.

2¹⁵ times 40 nanojoules is 1.3 millijoules. This is between 13 million and 13 billion times more than the energy used by a single LED for a fraction of a nanosecond.

Also, 2²⁵⁵ times 40 nanojoules is 2.3 × 10⁶⁹ J, a couple billion times larger than your estimate upthread. It's pretty amazing than in 67 nanoseconds my CPU can encrypt something such that it would require, as far as we know, the resources of billions of galaxies to decrypt without knowing the key.

The IME is probably a backdoor, but I don't think we have enough information to say clearly what kind of backdoor.