Germ is Now Quantum Secure
Germ DM now defaults to post-quantum cryptography (PQC), protecting your messages from being harvested now and decrypted later by a quantum computer. We’re joining Signal and iMessage in deploying ongoing PQC rekeying, bringing this level of security to messaging with AT Protocol identities. We will deprecate non-PQC connections this year, making Germ conversations fully protected by post-quantum encryption.
Germ DM is an end-to-end encrypted messaging app for iOS that isn’t connected to your phone number. It integrates with Bluesky, Blacksky, Mu.Social and other services via the AT Protocol for private messaging via your handle, or lets your build and share burner cards to connect even more discreetly.
We've been carefully watching advances in quantum computing and post-quantum cryptography. Earlier this year, Google announced they’re moving up their deadline for deployment to 2029, aligned with other ecosystem signals of accelerating progress toward cryptographically-relevant quantum computing. We decided to immediately start implementing PQC in Germ. This release reflects our unwavering commitment to your safety and privacy, now and into the future.
Migrating to PQC will take several steps to complete fully. For Germ, the three key steps are:
Protecting initial session establishment from quantum decryption
Protecting the ongoing re-keying of sessions from quantum decryption
Protecting the authenticity of messages and identities with PQC
Today, Germ ships (1) and (2). We plan to move in concert with atproto in migrating to post-quantum authentication.
Our deployment of PQC is only available on iOS 26 and later, as the PQ primitives we need natively ship in iOS 26. Users on older builds of iOS will continue to be able to message, but will be warned that they need to upgrade soon. We expect to deprecate iOS 18 and older when iOS 27 ships this fall, so that we support the two latest versions of iOS. iOS 26 is also the minimum version that supports PQ TLS, protecting your internet traffic from quantum computers.
TwoMLS PQ
At Germ, we have been using the IETF standard Messaging Layer Security as a building block for asynchronously re-keying 1:1 messaging sessions, allowing us to provide the cryptographic functionality we need atop this robustly analyzed building block.
We're grateful for the prior work of pioneers in PQ messaging protocols - iMessage PQ3, and Signal's Sparse Post-Quantum Ratchet. What their designs have in common suggests that the state of the art is now a triple ratchet:
Symmetric ratchets in each direction for forward secrecy
Asymmetric classical re-keying on each round for post-compromise security: asymmetric keys are freshly generated, applied to the symmetric ratchet, and stapled to outgoing messages.
Asymmetric PQ re-keying that does not block the classical re-keying state machine, allowing apps to amortize the relatively large size of PQ public keys and ciphertexts.
As a small team, we're able to use MLS to provide these properties. TwoMLS is a construction we shipped last year, using a MLS group for each member of a conversation as a sending group.
MLS's key schedule provides the symmetric ratchet. We use MLS's propose and commit mechanism to perform the asymmetric ratchet. Unlike Double Ratchet, this allows us to propose multiple keys in-flight without waiting for a response from the other party. This proposal mechanism allows us to use the asymmetric ratchet to statefully update the identities at each end of the conversation.
To perform PQ re-keying, we implemented the Amortized PQ (APQ) MLS Combiner draft. This adds a second PQ MLS group alongside an MLS group using classical cryptography, exporting a shared secret from the PQ group to the classical group to provide hybrid security. To decrypt the messages, an attacker would have to defeat both the classical and PQ cipher suites.
Session Establishment
When Alice messages Bob, Alice fetches an APQ keyPackage for Bob containing both PQ and classical keys. Alice constructs an APQ send group for herself, sending the APQ Welcome to Bob. Bob can finish session establishment with just a classical group to start. In TwoMLS Bob imports a shared secret from Alice's send group, consequently Bob's send group is also protected by the initial PQ key exchange. Bob can then finish his APQ construction as part of re-keying.
PQ Ratchet
For efficiency, our primary means of re-keying is to exchange a PQ Key Encapsulation Mechanism (KEM) Encapsulation Key (EK), then a freshly generated shared secret encrypted to that EK. The shared secret is applied to the PQ half of the APQ group as a PSK, after which the shared secret and Decapsulation Key (DK) can be immediately discarded.
APQ allows us to formalize these key exchanges into shared PQ cryptographic state, using MLS operations to
authenticate this exchange
mix the shared secret with previous shared secret state
export a derived secret from the new shared secret state into a symmetric key schedule
express these operations in wireformats and committing to the transcript of these state changes in each change of the shared cryptographic state machine(s).
PQ Re-Keying
As in the classical ratchet, clients can also initiate an MLS propose-and-commit handshake to update their PQ public keys, e.g. if they wish to roll their long-lived signing identity.
Open Source
We built this TwoMLS PQ layer in a new open-source Rust library with uniffi bindings for exporting into Swift, it’s built on top of the mls-rs implementation of MLS. We’re grateful to Mojtaba Chenani for helping us build this library.
Our library’s documentation contains full message sequence diagrams.
We are at a transitional time for much of the cryptography that underpins the Internet. Germ is rising to meet the challenges of future technologies and threats, and we’re sharing the software we built so that we can help each other across this transition.