• bunchberry@lemmy.world
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    1 month ago

    Quantum encryption won’t ever be a “thing.”

    All cryptography requires a pool of random numbers as inputs, and while different cryptographic methods are more secure than others, all of them are only as secure as their random number pool. The most secure cipher possible is known as a one-time pad which can be proven to be as secure as a cryptographic algorithm could possibly be, and so the only thing that could possibly lead to it being hacked is a poor random number pool. Since quantum mechanics can be used to generate truly random numbers, you could have a perfect random number pool, combined with a perfect cipher, gives you perfect encryption.

    That sounds awesome right? Well… no. Because it is trivially easy these days to get regular old classical computers to spit out basically an indefinite number of pseudorandom numbers that are indistinguishable from truly random numbers. Why do you think modern operating systems allow you to encrypt your whole drive? You can have a file tens of gigabytes bit and you click it and it opens instantly, despite your whole drive being encrypted, because your CPU can generate tens of gigabytes of random numbers good enough for cryptography faster than you can even blink.

    Random number generation is already largely a solved problem for classical computers. I own a quantum random number generator. I can compare it in various test suites such as the one released by NIST to test the quality of a random number generator, and it can’t tell the different between that and my CPU’s internal random number generator. Yes, the CPU. Most modern CPUs both have the ability to collect entropy data from thermal noise to seed a pseudorandom number generator, as well as having a hardware-level pseudorandom number, such as x86’s RDSEED and RDRAND instructions, so they can generate random numbers good enough for cryptography at blazing speeds.

    The point is that in practice you will never actually notice, even if you were a whole team of PhD statisticians and mathematicians, the difference between a message encrypted by a quantum computer and a message encrypted by a classical computer using an industry-approved library. Yet, it is not just that they’re equal, quantum encryption would be far worse. We don’t use one-time pads in practice despite their security because they require keys as long as the message itself, and thus if we adopted them, it would cut the whole internet bandwidth in half overnight. Pseudorandom number generators are superior to use as the basis for cryptography because the key can be very small and then it can spit out the rest of what is needed to encrypt/decrypt the message from it, and deterministic encryption/decryption algorithms like AES and ChaCha20 are not crackable even by a quantum computer.

    • LonelyNematocyst@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      This is a rather reductive view of quantum cryptography. The two most common applications of it I hear about is the development of encryption algorithms resistant to being broken on quantum computers (the way, say, Shur’s algorithm is known to break RSA) and techniques like quantum key distribution. Both of these are real problems that don’t become meaningless just because one-time pads exist - you need to somehow securely distribute the keys for one-time-pad encryption. That’s why one-time pads aren’t used everywhere (“it would cut the whole internet bandwidth in half overnight” would not have been a sufficient reason - that’d be a tiny price to pay for unbreakable encryption, if it actually worked).

      • bunchberry@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 month ago

        This is a rather reductive view of quantum cryptography.

        Correct = reductive?

        The two most common applications of it I hear about is the development of encryption algorithms resistant to being broken on quantum computers

        First, I was talking about quantum encryption, not quantum cryptography, which is a bit more broad. Second, we already have cryptographic algorithms that run on classical computers that are not crackable by quantum computers, known as lattice-based cryptography which are way more practical than anything quantum cryptography could offer.

        the way, say, Shur’s algorithm is known to break RSA

        Shor’s algorithm. Yes, it breaks asymmetrical ciphers like RSA, but we have developed alternatives already it cannot break, like Kyber.

        and techniques like quantum key distribution

        Classical key exchange algorithms prevent someone from reading your key if they intercept the data packets between you. QKD is entirely impractical because it does not achieve this. Rather than preventing someone from reading your key if they intercept the data packets, it merely allows you to detect if someone is intercepting the data packets. You see, in regular cryptography, you want people to be able to intercept your data. It’s necessary for something like the internet to work, because packets of data have to be passed around the whole world, and it would suck if your packets got lost simply because someone read them in transit, which is why QKD is awful. If a single person reads the data packet in transit then they would effectively deny service to the recipient.

        Both of these are real problems that don’t become meaningless just because one-time pads exist - you need to somehow securely distribute the keys for one-time-pad encryption.

        One-time pad encryption is awful as I already explained, it would cut the entire internet bandwidth in half because if you wanted to transmit 10 gigabytes of data you would also need to transmit 10 gigabyte key. QKD is also awful for the fact that it would be unscalable to an “internet” because of how easy it is to deny service. It also doesn’t even guarantee you can detect someone snooping your packets because it is susceptible to a man-in-the-middle attack. Sure, the Diffie-Hellman Key Exchange is also susceptible to a man-in-the-middle attack, but we solve this using public key infrastructure. You cannot have public key infrastructure for quantum cryptography.

        The only proposed quantum digital signature algorithms are unscalable because they rely on Holevo’s theorem, which basically says there is a limited amount of information about the quantum state of a qubit you can gather from a single measurement, thus creating a sort of one-way function that can be used for digital signatures. The issue with this is that Holevo’s theorem also says you can acquire more information if you have more copies of the same qubit, i.e. it means every time you distribute a copy of the public key, you increase the probability someone could guess it. Public keys would have to be consumable which would entirely prevent you from scaling it to any significantly large network.

        That’s why one-time pads aren’t used everywhere, (“it would cut the whole internet bandwidth in half overnight” would not have been a sufficient reason - that’d be a tiny price to pay for unbreakable encryption, if it actually worked).

        You are living in fairy tale lala land. Come back down to reality. If you offer someone an algorithm that is impossible to break in a trillion, trillion years, and another algorithm that is in principle impossible to break, but the former algorithm is twice as efficient, then every company on the entirety of planet earth will choose the former. No enterprise on earth is going to double their expenses for something entirely imaginary that could never be observed in practice. You are really stuck in delulu town if you unironically think the reason one-time pads aren’t used practically is due to lack of secure key distribution.

        Even prior to the discovery of Shor’s algorithm, we were issuing DHKE which, at the time, was believed to be pretty much an unbreakable way to share keys. Yet, even in this time before people knew DHKE could be potentially broken by quantum computers, nobody used DHKE to exchange keys for one-time pads. DHKE is always used to exchange keys for symmetrical ciphers like AES. AES256 is not breakable by quantum computers in practice as even a quantum computer would require trillions of years to break it. There is zero reason to use a one-time pad when something like AES exists. It’s the industry standard for a reason and I bet you my entire life savings we are not going to abandon it for one-time pads ever.

        • LonelyNematocyst@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          28 days ago

          If you offer someone an algorithm that is impossible to break in a trillion, trillion years, and another algorithm that is in principle impossible to break, but the former algorithm is twice as efficient, then every company on the entirety of planet earth will choose the former. Some companies who pay a lot of money for bandwidth, maybe. “Any company”? Not a chance. Internet is cheap and companies routinely waste money in much more frivolous ways. And for stuff which sells on its security, e.g. messengers like Signal, the advertising value of “our encryption is mathematically unbreakable” would be well worth it. And plenty of individual nerds would opt into it just out of principle, being fully willing to cut their bandwidth in half for fuzzy feelings. Not even to mention military applications. You don’t see such things in reality, because this is, unless I misunderstand something truly massive, impossible. You can’t do unbreakable encryption over the network because you can’t securely share the pad key. Yet, even in this time before people knew DHKE could be potentially broken by quantum computers, nobody used DHKE to exchange keys for one-time pads. Well yes, because that’d be incorrect - by sharing one-time-pad keys with DHKE you’re reducing the security to that of DHKE, so you might as well drop the one-time-pad part and use an ordinary encryption algorithm instead.