5 ms·

> People claimed all the basics were done, that we "only" needed to scale. This claim is fundamentally different from what you quoted. > But who's prepping fo

by fxwin 1y ago

> People claimed all the basics were done, that we "only" needed to scale. This claim is fundamentally different from what you quoted. > But who's prepping for unlimited energy today? It's about tradoffs: It costs almost nothing to switch to PQC methods, but i can't see a way to "prep for unlimited energy" that doesn't come with huge cost/time-waste in the case that doesn't happen

bee_rider 1y ago
Anyway, what does prepping for unlimited energy look like? I guess, favoring electrical over fossil fuels. But for normal people and the vast majority of companies, that looks like preparing for mass renewable electricity anyway, which is already a good thing to do.
- fxwin 1y ago
  could also be just massively scaling up energy consumption with little concern for efficiency (since limitless would imply very low cost), which would probably be a bad idea for renewables, and in case of not-so-cheap energy also very expensive
- thesz 1y ago
  With limitless energy you can have "fossil fuel" synthesized from air and water [1] and use existing "fossil fuel" infrastructure. [1] https://www.wired.com/2012/10/fuel-from-air/ https://www.wired.com/2012/10/fuel-from-air/
thayne 1y ago
> It's about tradoffs: It costs almost nothing to switch to PQC methods, It costs: - development time to switch things over - more computation, and thus more energy, because PQC algorithms aren't as efficient as classical ones - more bandwidth, because PQC algorithms require larger keys
- fxwin 1y ago
  all of which are costs that pale in comparison to having your data compromised, depending on what it is
- throw0101a 1y ago
  > It costs: Not wrong, but given these algorithms are mostly used at setup, how much cost is actually being occurred compared to the entire session? Certainly if your sessions are short-lived then the 'overhead' of PQC/hybrid is higher, but I'd be curious to know the actually byte and energy costs over and above non-PQC/hybrid, i.e., how many bytes/joules for a non-PQC exchange and how many more by adding PQC. E.g. > Unfortunately, many of the proposed post-quantum cryptographic primitives have significant drawbacks compared to existing mechanisms, in particular producing outputs that are much larger. For signatures, a state of the art classical signature scheme is Ed25519, which produces 64-byte signatures and 32-byte public keys, while for widely-used RSA-2048 the values are around 256 bytes for both. Compare this to the lowest security strength ML-DSA post-quantum signature scheme, which has signatures of 2,420 bytes (i.e., over 2kB!) and public keys that are also over a kB in size (1,312 bytes). For encryption, the equivalent would be comparing X25519 as a KEM (32-byte public keys and ciphertexts) with ML-KEM-512 (800-byte PK, 768-byte ciphertext). * https://neilmadden.blog/2025/06/20/are-we-overthinking-post-quantum-cryptography/ https://neilmadden.blog/2025/06/20/are-we-overthinking-post-... "The impact of data-heavy, post-quantum TLS 1.3 on the Time-To-Last-Byte of real-world connections" (PDF): * https://csrc.nist.gov/csrc/media/Events/2024/fifth-pqc-standardization-conference/documents/papers/the-impact-of-data-heavy-post-quantum.pdf https://csrc.nist.gov/csrc/media/Events/2024/fifth-pqc-stand... (And development time is also generally one-time.)
  - thayne 1y ago
    For an individual session, the cost is certainly small. But in aggregate it adds up. I don't think the cost is large, and I agree that given the tradeoff, the cost is probably worth it, but there is a cost, and I'm not sure it can be categorized as "almost nothing".
- djmdjm 1y ago
  > - development time to switch things over This is a one time cost, and generally the implementations we're switching to are better quality than the classical algorithms they replace. For instance, the implementation of ML-KEM we use in OpenSSH comes from Cryspen's libcrux[1], which is formally-verified and quite fast. [1] https://github.com/cryspen/libcrux https://github.com/cryspen/libcrux > - more computation, and thus more energy, because PQC algorithms aren't as efficient as classical ones ML-KEM is very fast. In OpenSSH it's much faster than classic DH at the same security level and only slightly slower than ECDH/X25519. > - more bandwidth, because PQC algorithms require larger keys For key agreement, it's barely noticeable. ML-KEM public keys are slightly over 1Kb. Again this is larger than ECDH but comparable to classic DH. PQ signatures are larger, e.g. a ML-DSA signature is about 3Kb but again this only happens once or twice per SSH connection and is totally lost in the noise.

by fxwin 1y ago

bee_rider 1y ago

Anyway, what does prepping for unlimited energy look like? I guess, favoring electrical over fossil fuels. But for normal people and the vast majority of companies, that looks like preparing for mass renewable electricity anyway, which is already a good thing to do.

fxwin 1y ago
could also be just massively scaling up energy consumption with little concern for efficiency (since limitless would imply very low cost), which would probably be a bad idea for renewables, and in case of not-so-cheap energy also very expensive
thesz 1y ago
With limitless energy you can have "fossil fuel" synthesized from air and water [1] and use existing "fossil fuel" infrastructure. [1] https://www.wired.com/2012/10/fuel-from-air/ https://www.wired.com/2012/10/fuel-from-air/

thayne 1y ago

> It's about tradoffs: It costs almost nothing to switch to PQC methods, It costs: - development time to switch things over - more computation, and thus more energy, because PQC algorithms aren't as efficient as classical ones - more bandwidth, because PQC algorithms require larger keys

fxwin 1y ago
all of which are costs that pale in comparison to having your data compromised, depending on what it is
throw0101a 1y ago
> It costs: Not wrong, but given these algorithms are mostly used at setup, how much cost is actually being occurred compared to the entire session? Certainly if your sessions are short-lived then the 'overhead' of PQC/hybrid is higher, but I'd be curious to know the actually byte and energy costs over and above non-PQC/hybrid, i.e., how many bytes/joules for a non-PQC exchange and how many more by adding PQC. E.g. > Unfortunately, many of the proposed post-quantum cryptographic primitives have significant drawbacks compared to existing mechanisms, in particular producing outputs that are much larger. For signatures, a state of the art classical signature scheme is Ed25519, which produces 64-byte signatures and 32-byte public keys, while for widely-used RSA-2048 the values are around 256 bytes for both. Compare this to the lowest security strength ML-DSA post-quantum signature scheme, which has signatures of 2,420 bytes (i.e., over 2kB!) and public keys that are also over a kB in size (1,312 bytes). For encryption, the equivalent would be comparing X25519 as a KEM (32-byte public keys and ciphertexts) with ML-KEM-512 (800-byte PK, 768-byte ciphertext). * https://neilmadden.blog/2025/06/20/are-we-overthinking-post-quantum-cryptography/ https://neilmadden.blog/2025/06/20/are-we-overthinking-post-... "The impact of data-heavy, post-quantum TLS 1.3 on the Time-To-Last-Byte of real-world connections" (PDF): * https://csrc.nist.gov/csrc/media/Events/2024/fifth-pqc-standardization-conference/documents/papers/the-impact-of-data-heavy-post-quantum.pdf https://csrc.nist.gov/csrc/media/Events/2024/fifth-pqc-stand... (And development time is also generally one-time.)
- thayne 1y ago
  For an individual session, the cost is certainly small. But in aggregate it adds up. I don't think the cost is large, and I agree that given the tradeoff, the cost is probably worth it, but there is a cost, and I'm not sure it can be categorized as "almost nothing".
djmdjm 1y ago
> - development time to switch things over This is a one time cost, and generally the implementations we're switching to are better quality than the classical algorithms they replace. For instance, the implementation of ML-KEM we use in OpenSSH comes from Cryspen's libcrux[1], which is formally-verified and quite fast. [1] https://github.com/cryspen/libcrux https://github.com/cryspen/libcrux > - more computation, and thus more energy, because PQC algorithms aren't as efficient as classical ones ML-KEM is very fast. In OpenSSH it's much faster than classic DH at the same security level and only slightly slower than ECDH/X25519. > - more bandwidth, because PQC algorithms require larger keys For key agreement, it's barely noticeable. ML-KEM public keys are slightly over 1Kb. Again this is larger than ECDH but comparable to classic DH. PQ signatures are larger, e.g. a ML-DSA signature is about 3Kb but again this only happens once or twice per SSH connection and is totally lost in the noise.