The advancement of quantum computing poses a significant threat to classical encryption schemes currently in use. While protocols like Off-the-Record (OTR) messaging and OpenPGP have provided encryption in the past, they are not equipped to withstand the power of quantum computers. This necessitates a transition to post-quantum cryptographic algorithms.

PPQM (Privt. Post-Quantum Multi-End Message and Object Encryption) is designed to address these emerging threats by incorporating post-quantum secure algorithms such as ML-KEM(CRYSTALS-Kyber). This ensures that communication remains secure even in the face of future quantum computing advancements.

PPQM builds upon the strengths of the Signal protocol and the OMEMO protocol, but replaces the underlying cryptographic primitives with post-quantum secure algorithms. Specifically, PPQM utilizes ML-KEM for key encapsulation, ensuring that even if quantum computers become capable of breaking traditional encryption, PPQM-secured communications will remain confidential.

Like OMEMO, PPQM supports multi-end encryption, allowing secure message synchronization across multiple devices. Each message is encrypted with a unique key, and headers containing the necessary decryption keys are individually encrypted for each recipient device. These headers and the encrypted payload are transmitted in a <message> stanza.

PPQM maintains compatibility with existing XMPP standards by using extensions like XEP-0060 and XEP-0163 to manage and distribute key material securely.

The use case for PPQM is to protect the content of conversations against quantum-capable adversaries, including scenarios where servers cannot be trusted to maintain the confidentiality of the message content. This includes scenarios such as sharing sensitive corporate information or exchanging intimate messages that must remain confidential even from the server administrators.

PPQM protects against passive and active attackers who can read, modify, replay, delay, and delete messages. However, PPQM does not protect against attacks based on metadata or traffic analysis.

This protocol utilizes a post-quantum adaptation of the Double Ratchet encryption scheme alongside a ML-KEM-based key agreement protocol. The following sections provide the technical details necessary to build an implementation of the PPQM protocol.

The key exchange in PPQM is based on a modified version of the X3DH key agreement protocol, updated to incorporate post-quantum secure components:

key encapsulation method

ML-KEM-1024

hash function

SHA-3 (KMAC256)

info string

"PPQM X3DH"

signed KyberPreKey rotation period

Signed KyberPreKeys SHOULD be rotated periodically, from once a week to once a month.

time to retain old private keys

The private key of the old signed KyberPreKey SHOULD be retained for an additional rotation period to accommodate delayed messages.

number of KyberPreKeys to include in the bundle

The bundle SHOULD always contain around 100 KyberPreKeys.

minimum number of KyberPreKeys

The bundle MUST contain at least 25 KyberPreKeys.

usage of KyberPreKeys

All key exchanges MUST use a KyberPreKey; exchanges that do not use a KyberPreKey MUST be rejected.

associated data

The associated data is created by concatenating the IdentityKeys of Alice and Bob: AD = Encode(IK_A) || Encode(IK_B). Alice is the party that actively initiated the key exchange, while Bob is the party that passively accepted the key exchange.

Signature method

Post-quantum secure signatures using ML-DSA(CRYSTALS-Dilithium) or similar.

The key exchange is performed just-in-time when sending the first message to a device, ensuring that each key exchange message also contains encrypted content as produced by the post-quantum Double Ratchet encryption scheme described below.

NOTE: PPQMMessage.proto, PPQMAuthenticatedMessage.proto and PPQMKeyExchange.proto refer to the protobuf structures as defined in the Protobuf Schemas.

The Double Ratchet encryption scheme is adapted to use post-quantum key material. PPQM uses this protocol with the following parameters/settings:

ratchet initialization

The Double Ratchet is initialized using the shared secret, associated data, and public keys as yielded by the post-quantum key agreement protocol, as explained in the Double Ratchet specification. The ephemeral key pair (ek) used by the key agreement protocol is stored with the session.

MAX_SKIP

As with OMEMO, storing skipped message keys can introduce potential DoS attacks. It is RECOMMENDED to limit the storage to 1000 skipped message keys per session.

deletion policy for skipped message keys

PPQM follows the same guidelines as OMEMO, with skipped message keys being discarded on a FIFO basis when the limit is reached.

authentication tag truncation

Authentication tags are truncated to 16 bytes/128 bits.

CONCAT(ad, header)

CONCAT(ad, header) = ad || PPQMMessage.proto(header)

KDF_RK(rk, dh_out)

KMAC256 using the root key (rk) as HKDF salt, the output of a Diffie-Hellman (dh_out) as HKDF input material, and "PPQM Root Chain" as HKDF info.

KDF_CK(ck)

KMAC256 using a chain key (ck) as the HMAC key, with specified constants for message key and chain key derivation.

ENCRYPT(mk, plaintext, associated_data)

The encryption step uses authenticated encryption consisting of AES-256-GCM.

1. Use KMAC256 to generate key material from the message key (mk).
2. Encrypt the plaintext using AES-256-GCM with the derived key.
3. Authenticate the ciphertext using associated data.

Further information on these functions can be found in the Double Ratchet specification.

If the message requires a key exchange, the key exchange data is placed into a new PPQMKeyExchange.proto structure together with the PPQMAuthenticatedMessage.proto structure.

To account for lost and out-of-order messages, PPQMKeyExchange.proto structures are sent until a response by the recipient confirms successful key exchange. Subsequent messages use the stored header until confirmation is received.

The contents are encrypted and authenticated using a combination of AES-256-GCM with SHA-3(KMAC256) for key derivation.

1. Generate 32 bytes of cryptographically secure random data, called key.
2. Use KMAC256 to generate key material from the key.
3. Encrypt the plaintext using AES-256-GCM with the derived key.
4. Concatenate the key and authentication data, then encrypt them using the Double Ratchet.

The contents are decrypted by reversing the encryption steps.

1. Decrypt the key and authentication data from the PPQMKeyExchange or PPQMAuthenticatedMessage.
2. Use KMAC256 to regenerate the encryption key.
3. Verify the authentication data and decrypt the ciphertext using AES-256-GCM.

To participate in PPQM-encrypted chats, clients need to set up a PPQM library and generate a device id, which is a randomly generated integer between 1 and 2^31 - 1. The device id must be unique for the account.

To determine whether a given contact supports PPQM, the devices node in PEP is consulted. Devices MUST subscribe to &nsdevices; via PEP to stay informed of new devices.

To build a session with a device, fetch its bundle information and use a random PreKey and KyberPreKey to establish a PPQM session.

Upon receiving a PPQM element, check if it contains a <keys> element for your device. If so, proceed with decryption or session establishment as necessary.

An account can signal its desire to stop PPQM communication by sending an <opt-out/> element qualified by the &ns; namespace.

PPQM requires a Pubsub Service that supports persistent items, publish-options, 'max' items, and 'open' access models.

This specification defines the following XMPP namespaces:

• &ns;