Post-Quantum message privacy, HPKE & OHTTP

[nothingmuch]

Post quantum message privacy is important in the near term, since a quantum adversarial relays or user's ISP could collect encrypted traffic today and decrypt it later. A global passive adversary is beyond the scope of this post and has more to do with onion or mixnet traffic patterns (#582) or at the very least end to end cover traffic (#679).

If the receiver's public key is not known to a post quantum adversary, the DHKEM shared secret is underdetermined and therefore a the symmetric cipher needs to be attacked wrt all possible shared secrets. However, communicating the receiver key over a PQ secure encrypted channel is a requirement for this assumption to hold, and even if this assumption holds this does not protect metadata privacy because OHTTP traffic could still be decrypted by the adversary.

OHTTP HPKE does not benefit from the same (fragile) information-theoretical security, because the OHTTP keys not ephemeral, but instead are published.

If client to relay and relay to directory communications are secured with TLS, a PQ handshake could be used to address this, protecting a user from their ISP but not from a corrupted relay.

If OHTTP encapsulation and transport level secrecy is broken, the adversary will learn the short IDs shared by clients with no metadata privacy, but the adversary will not only be able to decrypt protocol messages if it learns the receiver's public key.

Instead of, or in addition to relying on the transport layer for PQ secrecy, an alternative OHTTP configuration could also be specified in the URI. However, such PQ keys will generally require an additional round of bootstrapping on the part of the sender. Large, long lived keys such as McEliece could be used for PQ OHTTP encapsulation.

Although not all PQ keys will fit in 7168 bytes, for the end to end encryption we can use a mailbox on the directory to share the receiver's public key.

An extension PQ fragment parameter could specifying the algorithms to use, as well as a short ID where the PQ key can be found.

This payload should be symmetrically encrypted with the receiver key used for KDF, allowing a (padded) key to blend into the normal 7168 random byte pattern the directory observes without any additional data in the BIP 21 URI other this new parameter. With this information a PQ resistant HPKE mode can then be used between the sender and the receiver.

The receiver key can be tweaked with a taproot commitment allowing the PQ key to be authenticated with no additional data in the BIP 21 URI, as long as the internal key is included alongside the PQ key data to allow the TR commitment to be verified.

Katzenpost recently started using X-Wing for its variant of Sphinx. This is a hybrid KEM with small public key (1184 bytes) and ciphertext (1088 bytes), which can fit in the 7168 byte limit and is therefore appropriate for PQ session shared secret derivation. The sender would not need to post an additional PQ session key for the receiver, because a key derived from the initial shared secret could be used as PSK input for the reply HPKE encryption.