Thirty-two bytes. That is the public key size for SLH-DSA at its smallest standardised parameter set, and if you want to understand why Pixel 11 post-quantum secure boot needed a whole new security chip rather than a firmware update to the old one, that number is the most useful place to start.

Pixel 11, Pixel 11 Pro and Pixel 11 Pro XL land on shelves today at $899, $1,099 and $1,299. Every model in the family runs Tensor G6 next to a new Titan M3 coprocessor, and Google’s pitch is that the two together bring post-quantum cryptography to secure boot, a first for a Pixel. Nearly every writeup since the August 12 announcement has bolted that to “harvest now, decrypt later,” the idea that somebody is hoovering up your encrypted traffic today to crack it in 2035 when the hardware exists.

Those are not the same problem, and conflating them buries the more interesting engineering.

What post-quantum secure boot actually defends

Harvest now, decrypt later is a confidentiality attack. It works because a key exchange you performed in 2026 leaves a permanent mathematical trail: capture the handshake, store the ciphertext, and when Shor’s algorithm becomes runnable on real hardware, recover the session key retroactively. The fix is post-quantum key encapsulation, ML-KEM under FIPS 203, and it has to be deployed before the traffic is captured, which is exactly why Chrome and Android TLS have been doing hybrid X25519 plus ML-KEM key agreement for a couple of years now. That work is done in software, it shipped long before this phone, and Titan M3 has nothing to do with it.

Secure boot is an authenticity problem, and signatures do not work retroactively. Nobody captures a boot signature in 2026 and uses it to decrypt anything in 2035. What a cryptographically relevant quantum computer buys an attacker is the ability to forge a new signature against a public key that is already deployed. Which means the threat isn’t to data you sent, it’s to hardware that is still sitting in a pocket when the machine arrives.

That reframing is where the design decision makes sense. Every Pixel 11 ships with seven years of OS and security updates, so a phone bought today is expected to accept signed firmware into 2033. The root public key that authenticates that chain is not a certificate you rotate; on a hardware root of trust it is burned into silicon at manufacture, immutable for the life of the die. If that key is RSA or ECDSA and a working quantum computer shows up inside the support window, every device in the field becomes signable by whoever has the machine. You cannot patch your way out of it, because the thing that verifies the patch is the thing that’s broken.

Google’s own published threat model for post-quantum cryptography says this more bluntly than the marketing does. It ranks firmware signatures as the most urgent signature migration precisely because the verification key is baked in and cannot be updated, while software signatures get a relaxed timeline since their public keys can be swapped and they can lean on lower-level signatures for authenticity. The Pixel 11 is that document turning into a product. The “quantum computers in the future” language in the launch post is doing the work of a much drier sentence: we sell phones with seven-year support commitments and we would like the root key to still mean something at the end of them.

The algorithm Google won’t name

Here is what bothers me. Google announced post-quantum secure boot, said it adopts NIST’s standards, and then declined to say which one. NIST standardised two signature schemes in August 2024, deliberately, and the choice between them is the entire technical story.

ML-DSA under FIPS 204 is the lattice one, formerly CRYSTALS-Dilithium, security resting on Module-LWE and Module-SIS. At ML-DSA-44 you get a 1,312-byte public key and a 2,420-byte signature; at ML-DSA-87 it’s 2,592 and 4,627. It signs and verifies fast, and it is NIST’s general-purpose default. It is also what Android Verified Boot itself is migrating to, alongside KeyMint certificate chains and a remote attestation rebuild, as part of Google’s 2029 deadline for internal PQC migration. During the Android 17 cycle Google Play started generating ML-DSA signing keys for new apps.

SLH-DSA under FIPS 205 is the hash-based one, formerly SPHINCS+, and its security assumption is nothing more exotic than the second-preimage resistance of SHA-2 or SHAKE. No lattices, no algebraic structure for a future cryptanalyst to pull on. The cost is size and speed: SLH-DSA-SHA2-128s produces a 7,856-byte signature, 128f produces 17,088, and if you go up to 256f you are carrying 49,856 bytes per signature. Signing is slow enough to be measured in millions of cycles.

Now look at those numbers again from the perspective of a boot ROM rather than a network protocol, because the asymmetry flips completely. The thing you have to fit into immutable silicon is the public key, not the signature. SLH-DSA’s public key is 32 bytes at category 1, 64 bytes at category 5. ML-DSA’s smallest is 1,312 bytes, forty-one times larger, and every one of those bytes has to live in mask ROM or one-time-programmable fuses that you are paying for in die area and can never change. Meanwhile the signature, the huge part, sits in flash, where 7,856 bytes is a rounding error next to a boot image.

For anything that talks over a wire, that trade is terrible. My read of Project Leap, the BIS and Eurosystem test that pushed post-quantum signatures through TARGET2’s two-trillion-euro-a-day settlement rails, was that the lattice math held fine and the plumbing didn’t: swapping a 256-byte RSA-2048 signature for a Dilithium one blew the payload up roughly thirteenfold and overran message headers that were never built to carry it. In a bank’s ESMIG connector, signature size is the binding constraint. In a phone’s root of trust, it isn’t. Key size is.

Which is why I would put money on Titan M3 running SLH-DSA at the immutable layer and something lattice-based further up the chain once the ROM has handed off, mirroring the split Google’s threat model recommends. I want to be clear that this is inference, not reporting. Google has published nothing, there is no security blog post with the parameter set, and the launch materials stop at the phrase “post-quantum cryptography.” If somebody pulls the Titan M3 firmware apart and finds ML-DSA all the way down, I will eat it.

Why this needed new silicon

The part I keep coming back to is that none of this could have been a software update to Titan M2, and the reason is hashing throughput.

SLH-DSA verification is not one hash. It is a Merkle-tree walk through a hypertree of WOTS+ one-time signatures, thousands of compression function calls per verification, and the cost is dominated almost entirely by the hash primitive rather than by any clever arithmetic. That is a well-documented property of the scheme generally, and it holds for ML-DSA too, where 60 to 80 percent of runtime in typical implementations goes into SHAKE rather than the lattice operations.

The SLotH work presented at NIST’s fifth PQC standardisation conference put hard numbers on what that means for a root of trust. With a dedicated hash unit sitting next to the core, SLH-DSA-SHA2-128s verification lands around 180,000 cycles, which the authors note is actually better than accelerated ECDSA or Dilithium verification on comparably sized root-of-trust targets. The paper’s title tells you the alternative: accelerating SLH-DSA by two orders of magnitude with a single hash unit. Without one, with the CPU doing the hashing in software, you are looking at something in the region of a hundred times worse. Titan M2 is a small in-house RISC-V core running at microcontroller speeds; a hundredfold penalty on a boot-critical verification is not a tuning problem, it is a boot that visibly hangs.

The area cost is why it fits. The full SLotH system covering every FIPS 205 parameter set came in between 63 and 155 thousand gate equivalents, with a Keccak threshold implementation adding roughly another 130. On a modern process that is nothing, a rounding error against a phone SoC, but it is silicon you either taped out or you didn’t. Google didn’t have it in 2021, and there is no firmware that conjures a hash accelerator into an existing die.

There is a second, nastier reason the hardware matters, and it is the one that would keep me up at night if I worked on this. The same SLotH analysis ran a leakage assessment and found that an SLH-DSA implementation doing its hashing on the CPU will rapidly leak the SK.seed master key through power side channels, demonstrated over a hundred-thousand-trace TVLA campaign against a protected unit. On a phone that mostly matters for signing rather than verification, and signing happens in Google’s infrastructure, not in your pocket. But Titan M3 is not only a boot verifier. It is the StrongBox and KeyMint backing store, it holds the SIM and payment credentials, and Google says it carries Common Criteria certification at the level used for bank cards, which for Titan M2 meant testing against AVA_VAN.5, the most punishing vulnerability-assessment level in the scheme. The moment post-quantum key operations move into that box for anything beyond boot, constant-time behaviour in the hash path stops being an optimisation detail and becomes the whole security argument. I have not seen the M3 certificate published yet, and I would like to before I take the SIM-card comparison at face value.

Worth adding that the Titan line has been physically separate from the application processor since the Pixel 3, which shipped a hardened Cortex-M3, and moved to Google’s own RISC-V core with Titan M2 on the Pixel 6. M3 stays RISC-V and is the first refresh in roughly five years. That separation is doing real work here: a boot-time PQC verification that lives on its own die with its own flash and its own hash unit is not sharing caches or memory buses with anything the modem or the OS can reach. Reporting before launch suggested the Pixel 11 also swaps Samsung’s Exynos modem for MediaTek’s M90, which would put another hardware boundary between the baseband and security-critical memory, though Google hasn’t confirmed the modem in its own materials and I’d treat it as unconfirmed.

The rest of the chip

Tensor G6 is a smaller story than the security block, and Google’s own numbers say so quietly. The claims are 25 percent faster web browsing, 15 percent quicker app launches, up to 20 percent better CPU power efficiency, 50 percent more TPU compute, and on-device AI tasks running up to 3.5 times faster while drawing up to 3.5 times less energy, all against Tensor G5 at launch and all measured internally on pre-production hardware. Browsing and app launch are mostly single-threaded, so a 25 percent bump there implies a modest single-core gain from the move to Arm’s new C1 cores, which is underwhelming given the core is brand new.

The process node question resolved after launch, and not in Google’s favour. Months of supply-chain reporting had the G6 as the first TSMC 2nm phone chip; Google never claimed it and never printed a node anywhere in the launch materials, which is what let the rumour run. Peng Yu-chun, Google’s VP of hardware, cleared it up at the Taiwan launch, telling CNA the chip is on TSMC’s enhanced 3nm, the N3P refinement of the same family that carried Tensor G5. So if you saw the “Google still won’t say what fab built it” framing in the first-day coverage, that was true for about 48 hours and isn’t anymore.

A leaked Geekbench listing for the Pro XL points to seven cores, one C1-Ultra at 4.11 GHz, four C1-Pro at 3.38 and two C1-Pro at 2.65, which is one core fewer than Tensor G5. Losing a core while claiming 20 percent better CPU power efficiency is not a coincidence, and I would hold that efficiency figure loosely until somebody runs a sustained workload on retail silicon. Google also commissioned a Counterpoint scorecard concluding that Pixel’s AI experience has the most privacy protection on a phone, which is exactly as persuasive as any vendor-funded comparison against four named rivals.

Priced into a memory panic

All three phones went up $100 over the Pixel 10 line, and the Pro tiers quietly restructured RAM: 16GB is now gated behind the 512GB storage option, with the entry Pro and Pro XL at 12GB. Asked about it, Peng framed rising memory prices as a sector-wide phenomenon hitting supply as well as cost, and said Google is answering with UI and system-level optimisation and more efficient DRAM usage rather than absorbing the hikes.

That is a more honest answer than most, and it is the same squeeze that killed the CMF Phone 3 Pro outright before it shipped. Google has the margin to eat $100 and chose not to; Nothing’s budget arm didn’t have the option at all. Tying RAM capacity to a storage upsell is the sort of thing that reads as a spec-sheet detail now and as a policy in three years.

I’m skipping the GrapheneOS and self-signed-build angle entirely here, because what a post-quantum root of trust means for unlockable bootloaders and third-party OS signing is its own post and probably a longer one than this.

So is it a real upgrade or a checkbox

Both, and the ratio depends on a date nobody can give you. There is no cryptographically relevant quantum computer, the claims of quantum advantage that do get made keep drawing credible second opinions from rivals, and the error-correction results that actually matter are still measured in single-digit improvements to gate fidelity rather than orders of magnitude. Even IBM, a billion dollars into its quantum programme, is not promising you a machine that factors RSA-2048 this decade.

But the root key in this phone has to survive until 2033 and it can never be changed, and I would rather Google shipped the hash unit six years early than six months late. Back in July, writing about Europe’s settlement rails, I said a compact constant-time PQC core was more or less the only way you get post-quantum signing into a phone’s secure enclave without wrecking the battery or opening a side channel. Six weeks later one shipped in a $899 phone. That is a faster turnaround than I expected and it is the good news buried under all the harvest-now-decrypt-later copy.

What I still don’t have is the parameter set, the certificate, or a single independent measurement of what post-quantum verification costs the Pixel 11’s boot time. Somebody needs to dump the firmware or use the available ones and deep dive into it.

Sources

  • Google, “The Pixel 11 series: Your most personal Pixel yet”, blog.google, 12 August 2026
  • Google Store, “Pixel Performance: The Power Behind the Pixel 11 Series”
  • Google Bug Hunters, “Google’s Threat Model for Post-Quantum Cryptography”
  • NIST FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), August 2024
  • Saarinen, “Accelerating SLH-DSA by Two Orders of Magnitude with a Single Hash Unit”, NIST Fifth PQC Standardization Conference
  • Peng Yu-chun, interview with CNA, Pixel 11 Taiwan launch event, August 2026
  • Google Security Blog, Titan M2 and AVA_VAN.5 vulnerability assessment, 2021