rfc: using the same profile from multiple devices #1588
Conversation
|
|
||
| 1. Device encrypts the message using the stored ratchet state: `(ct, rsi') = ratchetEnc(pt, rsi)` | ||
|
|
||
| 2. Device sends modified encrypted ratchet state and the hash of the previous encrypted state to the server that stores the queue: `RSET (hash(enc(rsi)), enc(rsi'))`. |
There was a problem hiding this comment.
I think this doesn't cover bad network situation where server receives valid ratchet state update, but client gets connection timeout on request, or is considered here somehow? what happens in this case?
There was a problem hiding this comment.
Nothing too bad will happen, as the client would retry, and the server would accept it.
But if another client gets this new state and advances it further, then it would result in skipped message indeed, unless it is managed somehow.
|
|
||
| In addition to that, the specific implementation of this approach in Signal compromises break-in recovery property (aka post-compromise security) of Double-Ratchet algorithm, making its design ineffective - the only reason to have the second ratchet in DR algorithm is to provide break-in recovery, without it a much simpler design with a single ratchet is sufficient. See [this paper](https://eprint.iacr.org/2021/626.pdf) for details. | ||
|
|
||
| While this limitation can be addressed with notifications when a new device is added and per-device keys, we still find the remaining attack vectors on user security and privacy to be unacceptable, and opening unsuspecting users to various criminal actions - and it is wrong to say that would only affect security conscious users, and most people would not be affected by these risks. Allowing potential criminals in groups to know which device you are currently using is a real risk for all users. |
There was a problem hiding this comment.
I think this prematurely throws away this approach in favor of more fancy algorithm, because status quo is even worse - no convenience and the approach we unofficially recommend (add your devices to groups) is as bad, if not worse, since it's even easier to differentiate user devices, even without client modifications.
Maybe at least cost of this approach should be considered. If it is much cheaper than what rfc proposes it would actually improve privacy for users who do add devices (effort of modifying client is required) and greatly boost convenience, and possibly it could happen / be prioritized sooner.
Another point is that in large groups chat relays could mask user devices, so that'd be one less downside. And yes while it'd still be visible to chat relays, it's server trust issue, and in rfc protocol servers also can differentiate devices, though only on a lower protocol level.
There was a problem hiding this comment.
even easier to differentiate user devices, even without client modifications.
only in chats where user wants it.
|
|
||
| 4. Device decrypts the message `(pt, rsi') = ratchetDec(ct, rsi)` and processes it as usual. | ||
|
|
||
| 5. Device sends acknowledgement to the server as usual, but now it includes the new ratchet state and the hash of the previous state: `ACK msgId (hash(enc(rsi)), enc(rsi'))` |
There was a problem hiding this comment.
same question as above
There was a problem hiding this comment.
Repeat ACKs are accepted.
2 participants
No description provided.