Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Cyborg)
  • No Skin
Collapse
Brand Logo

CIRCLE WITH A DOT

  1. Home
  2. Uncategorized
  3. Google has devised a means for securing HTTPS certificates against quantum computing attacks without massive performance hits stemming from the considerably longer size of data required to be included.

Google has devised a means for securing HTTPS certificates against quantum computing attacks without massive performance hits stemming from the considerably longer size of data required to be included.

Scheduled Pinned Locked Moved Uncategorized
33 Posts 19 Posters 1 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • sophieschmieg@infosec.exchangeS sophieschmieg@infosec.exchange

    @andrei_chiffa @dangoodin the issue is the size of the handshake itself. You have to run the entire handshake before you can transmit data. With PQC, what used to be a 32 to 256 byte public key or signature now each becomes 1 to 3.5 KB in size. This is acceptable for the key agreement parts, since we really only need one artifact per party there, but becomes way too expensive when talking about the certificate, i.e. a chain of public keys signed by keys further up.
    Merkle Tree Certificates are a proposal that significantly compresses this certificate chain, at the cost of a more complicated trust management story.

    neilmadden@infosec.exchangeN This user is from outside of this forum
    neilmadden@infosec.exchangeN This user is from outside of this forum
    neilmadden@infosec.exchange
    wrote last edited by
    #23

    @sophieschmieg @andrei_chiffa @dangoodin I’m a bit confused by this. The client is still going to need the public keys, right? So is this just replacing the signatures with a Merkle proof? Have you done a blockchain??!

    1 Reply Last reply
    0
    • tknarr@mstdn.socialT tknarr@mstdn.social

      @thibaultmol @dangoodin ... that can do the job at all to arrive? Without a timeframe, planning a response is a bad idea. You need a response in place before that deadline, but if you rush things you end up with sub-par results that won't hold up against the inevitable advances. So we really need to know if we're on a 5 year deadline vs. 10, 25, 50.

      Personally I think it's closer to 50 than 10.

      i@toot.pouyan.netI This user is from outside of this forum
      i@toot.pouyan.netI This user is from outside of this forum
      i@toot.pouyan.net
      wrote last edited by
      #24
      This is the NSA timeline for PQC. Other countries (EU, UK, etc.) have similar timelines between 2030 and 2035.

      I, however, do not think that we will have any Cryptographically Relevant Quantum Computers (CRQC) in the next decades.

      CC: @thibaultmol@en.osm.town @dangoodin@infosec.exchange
      Link Preview Image
      1 Reply Last reply
      0
      • sophieschmieg@infosec.exchangeS sophieschmieg@infosec.exchange

        @andrei_chiffa @dangoodin the issue is the size of the handshake itself. You have to run the entire handshake before you can transmit data. With PQC, what used to be a 32 to 256 byte public key or signature now each becomes 1 to 3.5 KB in size. This is acceptable for the key agreement parts, since we really only need one artifact per party there, but becomes way too expensive when talking about the certificate, i.e. a chain of public keys signed by keys further up.
        Merkle Tree Certificates are a proposal that significantly compresses this certificate chain, at the cost of a more complicated trust management story.

        i@toot.pouyan.netI This user is from outside of this forum
        i@toot.pouyan.netI This user is from outside of this forum
        i@toot.pouyan.net
        wrote last edited by
        #25
        @sophieschmieg@infosec.exchange it's ironic because CT logs were introduced because we didn't trust CAs. Now we should trust the CA, the cosigners, and the CT logs.

        @andrei_chiffa@mastodon.social @dangoodin@infosec.exchange
        sophieschmieg@infosec.exchangeS 1 Reply Last reply
        0
        • dangoodin@infosec.exchangeD dangoodin@infosec.exchange

          Google has devised a means for securing HTTPS certificates against quantum computing attacks without massive performance hits stemming from the considerably longer size of data required to be included.

          Is anyone following this work?

          Link Preview Image
          Cultivating a robust and efficient quantum-safe HTTPS

          Posted by Chrome Secure Web and Networking Team Today we're announcing a new program in Chrome to make HTTPS certificates secure against ...

          favicon

          Google Online Security Blog (security.googleblog.com)

          neverpanic@chaos.socialN This user is from outside of this forum
          neverpanic@chaos.socialN This user is from outside of this forum
          neverpanic@chaos.social
          wrote last edited by
          #26

          @dangoodin Exciting, but also seems heavily focused on the needs of hyperscalers. Will roll out in Chrome and Cloudflare only at first, others get left behind. Requires a public Merkle tree, no thought seems to have been given to private CAs. And at the same time, Chrome is sabotaging the existing ML-DSA certificates (that already work today, albeit slow), by not implementing them.

          1 Reply Last reply
          0
          • dangoodin@infosec.exchangeD dangoodin@infosec.exchange

            Google has devised a means for securing HTTPS certificates against quantum computing attacks without massive performance hits stemming from the considerably longer size of data required to be included.

            Is anyone following this work?

            Link Preview Image
            Cultivating a robust and efficient quantum-safe HTTPS

            Posted by Chrome Secure Web and Networking Team Today we're announcing a new program in Chrome to make HTTPS certificates secure against ...

            favicon

            Google Online Security Blog (security.googleblog.com)

            S This user is from outside of this forum
            S This user is from outside of this forum
            stonykark@mstdn.ca
            wrote last edited by
            #27

            @dangoodin @briankrebs no, quantum computing is nothing.

            1 Reply Last reply
            0
            • icing@chaos.socialI icing@chaos.social

              @sophieschmieg @dangoodin @filippo 82 pages of RFC…hmmm…must be secure then!😌

              filippo@abyssdomain.expertF This user is from outside of this forum
              filippo@abyssdomain.expertF This user is from outside of this forum
              filippo@abyssdomain.expert
              wrote last edited by
              #28

              @icing @sophieschmieg @dangoodin it's mostly very well-tested stuff from the tlog ecosystem. The Go sumdb has had zero security incidents since 2019. The same is not true of our crypto/x509. But please do report any issues!

              rsalz@ioc.exchangeR 1 Reply Last reply
              0
              • filippo@abyssdomain.expertF filippo@abyssdomain.expert

                @icing @sophieschmieg @dangoodin it's mostly very well-tested stuff from the tlog ecosystem. The Go sumdb has had zero security incidents since 2019. The same is not true of our crypto/x509. But please do report any issues!

                rsalz@ioc.exchangeR This user is from outside of this forum
                rsalz@ioc.exchangeR This user is from outside of this forum
                rsalz@ioc.exchange
                wrote last edited by
                #29

                @filippo @icing @sophieschmieg @dangoodin it's kinda straightforward but it's not trivial

                1 Reply Last reply
                0
                • i@toot.pouyan.netI i@toot.pouyan.net
                  @sophieschmieg@infosec.exchange it's ironic because CT logs were introduced because we didn't trust CAs. Now we should trust the CA, the cosigners, and the CT logs.

                  @andrei_chiffa@mastodon.social @dangoodin@infosec.exchange
                  sophieschmieg@infosec.exchangeS This user is from outside of this forum
                  sophieschmieg@infosec.exchangeS This user is from outside of this forum
                  sophieschmieg@infosec.exchange
                  wrote last edited by
                  #30

                  @i @andrei_chiffa @dangoodin no, the CT logs still function as CT logs in mtc. They do away with the imperfection of CT logs requiring signatures instead of being published immediately, and they use the fact that the CT log itself can function as a certificate, but the trust model isn't relaxed, it's just more complicated.

                  i@toot.pouyan.netI 1 Reply Last reply
                  0
                  • sophieschmieg@infosec.exchangeS sophieschmieg@infosec.exchange

                    @i @andrei_chiffa @dangoodin no, the CT logs still function as CT logs in mtc. They do away with the imperfection of CT logs requiring signatures instead of being published immediately, and they use the fact that the CT log itself can function as a certificate, but the trust model isn't relaxed, it's just more complicated.

                    i@toot.pouyan.netI This user is from outside of this forum
                    i@toot.pouyan.netI This user is from outside of this forum
                    i@toot.pouyan.net
                    wrote last edited by
                    #31
                    @sophieschmieg@infosec.exchange what I'm trying to say is: the number of moving parts, that I need to trust or verify is increasing. And that is not really comforting.

                    Am I missing something here?

                    @andrei_chiffa@mastodon.social @dangoodin
                    sophieschmieg@infosec.exchangeS 1 Reply Last reply
                    0
                    • i@toot.pouyan.netI i@toot.pouyan.net
                      @sophieschmieg@infosec.exchange what I'm trying to say is: the number of moving parts, that I need to trust or verify is increasing. And that is not really comforting.

                      Am I missing something here?

                      @andrei_chiffa@mastodon.social @dangoodin
                      sophieschmieg@infosec.exchangeS This user is from outside of this forum
                      sophieschmieg@infosec.exchangeS This user is from outside of this forum
                      sophieschmieg@infosec.exchange
                      wrote last edited by
                      #32

                      @i @andrei_chiffa @dangoodin you can always request and verify the fallback certificate, which is just a normal cert chain backed by ML-DSA. MTC is an optional optimization mechanism for the browser, that also fixes an issue CT had while we're at it.

                      i@toot.pouyan.netI 1 Reply Last reply
                      0
                      • sophieschmieg@infosec.exchangeS sophieschmieg@infosec.exchange

                        @i @andrei_chiffa @dangoodin you can always request and verify the fallback certificate, which is just a normal cert chain backed by ML-DSA. MTC is an optional optimization mechanism for the browser, that also fixes an issue CT had while we're at it.

                        i@toot.pouyan.netI This user is from outside of this forum
                        i@toot.pouyan.netI This user is from outside of this forum
                        i@toot.pouyan.net
                        wrote last edited by
                        #33
                        @sophieschmieg@infosec.exchange got it! Thanks for the clarification.
                        1 Reply Last reply
                        0
                        Reply
                        • Reply as topic
                        Log in to reply
                        • Oldest to Newest
                        • Newest to Oldest
                        • Most Votes


                        • Login

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • World
                        • Users
                        • Groups