Skip to content

Conversation

@jazzz
Copy link
Contributor

@jazzz jazzz commented Nov 26, 2025

This PR adds a draft spec for Ratcheting Private Identifiers (RPIs). RPIs are an extension to DH ratchet based encryption systems that provides a mechanism for privacy preserving payload discovery and conversation binding.

Outstanding Work:

  • Upgrade to HKDF-Extract
  • Unify Sender and Receiver chains
  • Investigate removing chainSecret it appears unnecessary
  • Technical Proof (link: )
  • Replace diagrams with text embedded versions

Copy link
Contributor

@kaichaosun kaichaosun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spec makes sense to me, but I do feel it's complex for metadata protection.
I have following 2 ideas, which is not as private as this spec, but worth to have a discussion:

  1. since message key is already using double ratchet, we can use the hash of message key to help with decryption process.
  2. I'm wondering if we are going to rotate in the identify design, if so, I think the hash of identify could be used in the decryption process.

## Background

End-to-end encrypted chat protocols like Double Ratchet provide strong message privacy and forward secrecy.
However, they don't address a fundamental question: how does a recipient know which key to use for decryption?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good to know how other products solve this problem.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good suggestions ; updated


The problem is similar to receiving an encrypted postcard.
With a single sender, you know who sent it.
With multiple senders, it's unclear whose keys were used during encryption.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it ok to just hash the key or identifier?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately no.

While it would successfully Identify the messages, it sacrifices key security. Specifically it allows the look up which messages correspond to a known key. This enables a birthday paradox type problem which would be catastrophic to message security.

This system specifically creates a chain of identifiers which are independent from the encryption chain for this exact reason.

Each ratchet step updates `PI` and derives an RPI by truncating the updated value.

The system integrates with an external encryption mechanism that provides `RK` and `chainSecret`.
When a DH ratchet step occurs, `NextPI` replaces `PI` and a new `NextPI` is derived from the updated `RK`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good to know more about RK here and when RK gets updated?

If there is no match, the client safely ignores the message as it was not the intended recipient.
To handle dropped or out-of-order messages, clients can precompute several RPIs ahead on the receiving chain.

During initialization, the initiator tells the recipient which `PI` value to use for receiving, as well as which `NextPI` to use for sending.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is confusing to have PI and NextPI for different directions, maybe renaming it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants