Conversation
kaichaosun
left a comment
kaichaosun
left a comment
There was a problem hiding this comment.
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:
- since message key is already using double ratchet, we can use the hash of message key to help with decryption process.
- 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? |
There was a problem hiding this comment.
Would be good to know how other products solve this problem.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
Is it ok to just hash the key or identifier?
There was a problem hiding this comment.
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`. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
This is confusing to have PI and NextPI for different directions, maybe renaming it.
|
Closing for now. The problem is changing as the system migrates to PostQuantum encryption. Will reintroduce at a later date |
2 participants
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:
chainSecretit appears unnecessary