Blog: Bringing Divvi Up into the Post-Quantum Era

assets/sass/main.scss

@@ -42,6 +42,12 @@ h4 {
 // }
 
 #home-hero {
+  @media (min-width: 768px) {
+    h1 {
+      font-size: clamp(1.5rem, 3.8vw, 2.875rem);
+    }
+  }
+
   .btn {
     width: 320px;
     position: relative;

content/en/blog/2026-10-23-PQ-secure.md

@@ -0,0 +1,49 @@
+---
+author: Tim Geoghegan
+date: 2026-10-23T00:00:00Z
+slug: PQ-secure
+title: "Bringing Divvi Up into the Post-Quantum Era"
+excerpt: "The MPC foundations of Divvi Up were already post-quantum secure, but there was still work to do to close the remaining safety gaps."
+display_support_us_footer: true
+display_inline_newsletter_embed: false
+---
+
+In the spring of this year, our colleagues at [Google](https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/) and [Cloudflare](https://blog.cloudflare.com/post-quantum-roadmap/) announced that they're setting the goal of migrating to post-quantum (PQ) cryptography by 2029. This is a more aggressive target than had previously been accepted in the industry, sending a strong signal that it's time to secure our systems against cryptographically relevant quantum computers (CRQCs).
+
+That's a responsibility that Divvi Up takes very seriously. In this post, we're going to explain the work we've done to make our private aggregation services post-quantum secure. We'll learn how most of the cryptographic primitives powering Divvi Up were already PQ secure and then lay out how we closed the remaining gaps in transport security.
+
+## Post-quantum secure foundations
+
+When thinking about quantum computing, it's very easy to catastrophize and assume that every cryptosystem falls apart right away. But the truth is that quantum computers can only do very specific things that classical computers can't. In particular, [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm) gives a CRQC a big advantage at solving the [discrete logarithm problem](https://en.wikipedia.org/wiki/Discrete_logarithm). The security of signature schemes like RSA or ECDSA rely on the hardness of that problem, in the sense that breaking them is proven to be as computationally expensive as solving discrete logarithms, and thus a computer that can solve that problem significantly faster can attack the asymmetric cryptography that we use widely on the internet.
+
+Divvi Up is built on top of a cryptographic tool for private aggregation called [Verifiable Distributed Aggregation Functions](https://datatracker.ietf.org/doc/draft-irtf-cfrg-vdaf/). VDAFs provide two guarantees. First, they protect the *privacy* of individual contributions to the aggregation. Nobody but the client ever sees an individual measurement, and the servers only learn aggregates. Second, VDAFs protect the *robustness* of aggregations by allowing servers to reject invalid or malformed measurements without learning any individual values.
+
+Divvi Up runs the [Prio](https://www.usenix.org/system/files/conference/nsdi17/nsdi17-corrigan-gibbs.pdf) family of VDAFs. In Prio, the privacy guarantee is realized by using secret sharing to give each server just a share of private inputs which reveals nothing whatsoever about the original input. This is [information-theoretic secure](https://en.wikipedia.org/wiki/Information-theoretic_security), meaning that an attacker who holds one of the shares and wants to learn the private input has no advantage compared to an attacker who is just guessing randomly. Even a fast discrete logarithm solver like a CRQC has no advantage.
+
+On the other hand, Prio's robustness guarantee is not information-theoretic secure, but it is as strong as symmetric ciphers like 128 bit AES. [Grover's algorithm](https://en.wikipedia.org/wiki/Grover's_algorithm) does give CRQCs a theoretical advantage over classical computers here, but it's not big enough to meaningfully affect the security of symmetric cryptography or Prio's validity proofs. If you want to learn more, [check out this post by Filippo Valsorda](https://words.filippo.io/128-bits/).
+
+The result is that the most important protections offered by Divvi Up are already, and always have been, post-quantum secure. But that doesn't mean there wasn't anything to do.
+
+## Transport security
+
+VDAFs are a cryptographic primitive for private aggregation, but they don't make up an entire system you can safely run on the Internet. The validity proofs and secret shared inputs need to be encrypted in transit, or a network attacker would be able to observe both input shares, combine them back together, and violate privacy.
+
+Divvi Up's transport security is specified in the [Distributed Aggregation Protocol](https://datatracker.ietf.org/doc/draft-ietf-ppm-dap/). DAP relies on industry standard transport security protocols to achieve its security goals, namely [Transport Layer Security](https://www.rfc-editor.org/info/rfc9846/) (TLS), [Hybrid Public Key Encryption](https://datatracker.ietf.org/doc/draft-ietf-hpke-hpke/) (HPKE), and optionally [Oblivious HTTP](https://www.rfc-editor.org/info/rfc9458/) (OHTTP).
+
+Unlike Prio, each of these protocols makes heavy use of exactly the kind of asymmetric cryptography that CRQCs threaten. But the good news is that the working groups and communities responsible for each of these standards have been working on quantum-safe updates for a long time now. DAP and Divvi Up get to use all that for free because we built on top of these protocols.
+
+For TLS, the most urgent thing is to enable ciphersuites using the MLKEM768-X25519 hybrid key encapsulation mechanism, to guard against [harvest-now-decrypt-later attacks](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later). This change has already been deployed to Divvi Up's production environments, and any TLS client that supports PQ is already uploading reports over PQ-secure connections. To avoid breaking existing clients, we'll also continue to support TLS connections using exclusively classical cryptography, but we'll disable those ciphersuites at some point in the future.
+
+We also need to serve TLS certificates containing post-quantum keys, signed by post-quantum CAs. No publicly trusted post-quantum CA exists yet, but the IETF's [PLANTS working group](https://datatracker.ietf.org/wg/plants/about/) is working hard on specifying [Merkle Tree Certificates](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/) (MTCs), which are emerging as the web’s solution to scalable quantum-safe TLS certificates. To learn more about MTCs and the work underway at our sibling project Let's Encrypt, check out [this post by Andrew Gabbitas](https://letsencrypt.org/2026/06/03/pq-certs).
+
+DAP uses HPKE for secure asynchronous communication between protocol participants, tunneled within the TLS connections. HPKE was designed to be usable with a variety of ciphersuites and the IETF's HPKE working group has already published a [draft](https://datatracker.ietf.org/doc/draft-ietf-hpke-pq/) updating HPKE with PQ secure configurations. We worked with our friends in the open source community to ensure that the necessary suites are available in the [Rust HPKE package](https://crates.io/crates/hpke). Divvi Up's production environments are already advertising hybrid HPKE ciphersuites, and will drop support for exclusively classical suites in the future.
+
+Finally, DAP can optionally be composed with Oblivious HTTP for stronger privacy protections. To learn more about that, check out [this post about our OHTTP gateway](/blog/ohttp-now-available/). Just like DAP, OHTTP uses HPKE. We've added support for the latest post-quantum ciphersuites to [privacy-gateway-go](https://github.com/cloudflare/privacy-gateway-server-go/pull/76) and [ohttp-go](https://github.com/chris-wood/ohttp-go/pull/37) and have upgraded our OHTTP gateways to advertise post-quantum ciphersuites alongside classical ones, allowing clients that support it to opt into quantum safe cryptography.
+
+Besides this server-side work, clients will also need to update so that they can use PQ ciphersuites in all these protocols. We'll facilitate that by distributing updated clients for Divvi Up in [Rust](https://crates.io/crates/janus-client), [TypeScript](https://github.com/divviup/divviup-ts) and [Java](https://github.com/divviup/divviup-android/).
+
+## A smooth transition to a PQ future
+
+That's all the pieces we need to upgrade to make Divvi Up secure against CRQCs. While the quantum computing threat is real and imminent enough to warrant decisive action, that doesn't mean we have to flip a big switch and leave anyone who isn't ready behind. By building on IETF standards that are easy to deploy using off-the-shelf software components, collaborating with the open source community, and providing graceful upgrade paths allowing users to opt in at their own pace, we can move to PQ security without unnecessary disruption to running systems.
+
+If you’re interested in learning more about how Divvi Up can help your team with secure, private telemetry, [contact us](/contact/).

layouts/partials/divvi/divvi_home_hero.html

@@ -6,7 +6,9 @@
       >
         <div class="pb-3 pt-md-3 pb-md-3" style="max-width: 460px">
           <h1 class="text-white display-3 mb-lg-5">
-            Divvi Up: A privacy respecting telemetry service
+            Divvi Up:<br>
+            A privacy respecting<br>
+            telemetry service
           </h1>
         </div>
       </div>