GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Adrian Sanabria (sawaba@infosec.exchange)'s status on Saturday, 29-Mar-2025 23:35:40 JST Adrian Sanabria Adrian Sanabria
    • Kevin Beaumont

    @GossiTheDog doing a webinar in a few weeks, working on the slides

    In conversation about 2 months ago from infosec.exchange permalink

    Attachments


    1. https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/243/944/143/499/981/original/1f2135b681b429cf.jpeg
    • Embed this notice
      Antoinne Sterk (antoinnesterk@cyberplace.social)'s status on Saturday, 29-Mar-2025 06:07:23 JST Antoinne Sterk Antoinne Sterk
      • Kevin Beaumont

      @GossiTheDog They keep chasing the dragon... 🐲

      In conversation about 2 months ago permalink
    • Embed this notice
      Sophie Schmieg (sophieschmieg@infosec.exchange)'s status on Saturday, 29-Mar-2025 23:35:38 JST Sophie Schmieg Sophie Schmieg
      in reply to
      • Kevin Beaumont

      @sawaba @GossiTheDog for small to medium sized businesses that are not doing anything more adventurous than TLS when it comes to cryptography, my advice would be, if there is some free engineering capacity, to turn on 0x11EC (X25519-ML-KEM768) in their TLS config, assuming their stack supports the cipher. (The various different stacks are adding support for that currently)
      That way, you can check if anything breaks, with both Chrome and Firefox negotiating that cipher by default, and Safari rolling out support for it. The main risk is with middleware breaking.
      In that threat model, it may not be the most urgent task, but it's relatively simple, depending on the used TLS stack. You can also turn on the equivalent KEX in SSH (supported in OpenSSH). Otherwise, in that threat model, I wouldn't do much at all (and even these two things are mostly optional, unless there are very strict long term confidentiality concerns).
      Of course, if your threat model is more adventurous, you might want to hire some cryptographers 🙂

      In conversation about 2 months ago permalink
    • Embed this notice
      Sophie Schmieg (sophieschmieg@infosec.exchange)'s status on Saturday, 29-Mar-2025 23:35:39 JST Sophie Schmieg Sophie Schmieg
      in reply to
      • Kevin Beaumont

      @sawaba @GossiTheDog ugh, please don't.

      Yes it's overhyped, and yes consultants give extremely cringe talks about it, but no, this is neither a purely theoretical threat that can be safely ignored, nor is it business as usual when it comes to upgrading. Unless of course you consider potentially having to rip out the entirety of WebPKI and replacing it with something different as business as usual.

      You can see my talk about the practical challenge and the threat model here (about half way through) https://youtu.be/wsnHMvuxy5Q?si=yK6oObpptIQfyOs8

      In conversation about 2 months ago permalink

      Attachments

      1. RWPQC 2024 Session 2: Making Signal Post Quantum and PQC Migration Updates Vol 1
        from SandboxAQ
        Want to learn more about AI and quantum tech? Visit our Academy https://academy.sandboxaq.com/Want to get in touch? Write the Education team at edu@sandbox...
    • Embed this notice
      Sophie Schmieg (sophieschmieg@infosec.exchange)'s status on Saturday, 29-Mar-2025 23:35:39 JST Sophie Schmieg Sophie Schmieg
      in reply to
      • Kevin Beaumont

      @sawaba @GossiTheDog but just in case you don't like watching my YouTube talks, here is the TLDR as to why you might need to care (not everybody has to care, figuring out who does is part of the difficulty):
      a) whether or not you believe the hype about quantum computers, regulatory pressure puts a hard deadline on the migration for 2035. That's ten years. For encryption in transit you have store-now-decrypt-later, which might incentivise you to move faster, although that is somewhat overhyped, as forward secrecy acts as a form of "quantum annoyance", it depends how high you value you long term confidentiality of your data.
      b) PQC algorithms are not easy drop in replacements. They are much, much larger than their classical counterparts, leading to quite a few use cases outright breaking (as the aforementioned WebPKI). Some of these are extremely difficult to migrate as a whole (again, as the aforementioned WebPKI), making 10 years not much time.

      In conversation about 2 months ago permalink
    • Embed this notice
      Sophie Schmieg (sophieschmieg@infosec.exchange)'s status on Saturday, 29-Mar-2025 23:35:39 JST Sophie Schmieg Sophie Schmieg
      in reply to
      • Kevin Beaumont

      @sawaba @GossiTheDog
      I agree that most small to medium companies probably do not have to care about any of this right now. Those that do probably know already. But it's not something that can be simply ignored by everybody.

      The main way to recognize overhyped nonsense is when they talk about inventory and agility. Unfortunately, neither of these terms is completely without merit, but they are the most favorite buzzwords of the hype peddlers. Really both of these boil down to proper key management. Something that is extremely difficult, but not unique or novel with PQC.

      In conversation about 2 months ago permalink
    • Embed this notice
      Adrian Sanabria (sawaba@infosec.exchange)'s status on Saturday, 29-Mar-2025 23:35:40 JST Adrian Sanabria Adrian Sanabria
      in reply to
      • Kevin Beaumont

      @GossiTheDog tl;dr - not a threat, you’ll update it anyway, probably don’t need special tools since we’ve been updating crypto forever

      In conversation about 2 months ago permalink

      Attachments


      1. https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/243/958/918/570/454/original/04ed93080380c7fb.jpeg

      2. https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/243/961/234/517/271/original/16ab0b8b1b907bcf.jpeg

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.