• tblFlip@pawb.social
    link
    fedilink
    arrow-up
    9
    ·
    1 year ago

    im honestly not really surprised anymore. i fully expect to see a lot more of these types of bugs in the coming years

    • Weslee@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      Just wait for quantum computers to take off, our current encryption can be broken with them

        • Weslee@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          Yeah but just think of all the work that needs redoing to the encryption systems around the world.

          Also someone could intercept and save data that has been encrypted with our standard method now and wait for quantum computing to crack it

      • tblFlip@pawb.social
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        absolutely. a lot of currently in use public key schemes may be broken with those. more recently there have been a few newer algorithm such as kyber that do have a chance to hold. think NIST is also holding a bit of a competition, but dont quote me on that. i really dont know alot about post-quantum crypto

      • Bersl@furry.engineer
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 year ago

        At this point, I almost feel like we need to start over with the idea of pipelining in CPUs, as though it were some kind of original sin. The fact that the most basic of errors in pipelined logic are referred to as “hazards” should have been a hint.

        (Edit: only half kidding)

      • Sloan the Serval@pawb.social
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 year ago

        If the vulnerability is part of a feature designed for niche use cases, then it’s far safer than one that affects general use. I highly doubt most people are going to run virtual machines, plus the main target is server hosts that use VMs to run multiple servers of the same type on the same box. I might run a VM at some point in the future, but when I do I’ll take steps to avoid any issues, like only enabling virtualization in the first place when I need it. Sure, that means I need to boot into the UEFI before and after every time I run a VM, but that’s not an issue on the system I’d be running it on. And I’d rather have that inconvenience than have to worry about a vulnerability at all times.

        In short, it’s a matter of risk management.