I think if we want to provide a security on par of signal/whatsapp/etc forward secrecy is a must.
In terms of revolution mode, I am personally for “secure by default”, rather than the opposite, so forward secrecy should be the default.
Plausible deniability is fairly weak in whisper as it still requires some signing, even when enabled and until we find a good way to exchange the initial key (X3DH), it’s going to be difficult to provide any good guarantee, so I won’t be taking this into consideration for now.
Initial key exchange
The initial key exchange is what the document is trying to solve, as this is actually the hardest part, because signals relies on their server as a form of storage.
The document provides best effort forward secrecy and ensuring that:
- Both parties have successfully received the key before any sym-key encrypted message is exchanged
- We don’t prevent parties to communicate if the key has not been exchanged successfully
Which are very important properties for an asynchronous chat protocol.
X3DH would be a much better solution, but requires some form of storage (a server in signals case) which currently is not easy to replicate with IPFS/Swarm, as lacks of some properties. Smart contracts are an option and could be used for this, I will look at it more carefully.
There’s another option that would help us start a ratchet much faster, but I don’t know how cryptographically secure it would be, and we’d be in uncharted waters (basically we can start a ratchet using the PK of Alice & an ephemeral key sent by Bob, as both uses elliptic cryptography).
Best effort forward secrecy can be upgraded to just forward secrecy with a keepalive or a vanilla double ratchet implementation, as it’s only there to overcome account recovery.
To fit a double ratchet onto whisper it would comes with a cost, which is likely to have to double encrypt messages, or otherwise we would need to find a way to send unencrypted messages on whisper (not sure if it’s currently possible, in any case, the payload would still be unencrypted, but the header won’t be, unless we chose for the encrypted header variant of the algorithm).
If we are willing to pay the cost of double encryption, then we can easily have a double ratchet implementation that is transport agnostic, and can be ported to pss easily.
Multiple devices I believe needs to be treated in the same way group chats are treated, so that a conversation among 2 peers with one peer having 2 devices is the same a group chat with 3 participants, with pairwise encryption among the peers, which makes group management easier and more flexible than using a shared key among the group (same strategy signal has).
Account recovery and recovery of messages is incompatible with forward secrecy by definition, but if we want to provide this feature, I’d say to allow the user to backup his data somewhere, with a warning that we can’t guarantee safety of messages in case of key compromise.
In this case, I think there’s an argument for not using IPFS, and instead rely on a centralized form of storage which provides better access control at the cost of availability of course, but being a non-critical feature I think it might be worth taking the option in consideration.
In terms of Revolution mode, long term maybe, so might be worth thinking about what we want, but we need to get the basics first, we definitely have a long way to go.
Dynamic whisper topic generation
Dynamic whisper topic generation is not too difficult to get working probably, but it might be a bit costly on terms of bandwidth.
It is important that any solution will not compromise the benefits given by a double ratchet, namely that is “fully asynchronous” ( I don’t need any previous message to decrypt the one I just received, so we don’t have to worry about ooo messages / dropped messages etc).
Steps to implement
This is how I would go about implementing it:
Have a solid initial key exchange, using DH, which will need to be a bit synchronous, meaning there’s going to be a lift off phase where messages will be pk encrypted and we won’t be providing PFS for those. The reasoning to have this weaker version first is that this is actually the hardest problem to solve, so we solve it in a naive way first, and the come back to it, I would not want to spend too much time on this as the initial step, where we have quite a few unknowns.
Implement a double ratchet, possibly paying the cost of double encryption, at the same time account recovery needs to be solved, so that a user that has recovered his account can still communicate with a contact. With a plain double ratchet that’s solved quite easily.
Go back to the initial key exchange and fortify, ideally using X3DH backed up by some form of decentralized storage
At this point backup of messages / topic ratcheting