Why a full Forward Secrecy does not make sense for (something like) Qabel?

By Paul Rösler

 

This article is about to discuss why we decided against full Forward Secrecy when designing the Drop Protocol.

 

Definition Forward Secrecy

With a Forward Secrecy protocol, if the password protected key gets stolen by an attacker, it will not enable him to decrypt older messages. Protocols like Axolotl have this ability.

The Qabel Drop Protocol uses Noise, which only enabels Sender Forward Secrecy or Weak Forward Secrecy. This means, that if the password protected key of identity A gets stolen, messages sent by A can not be decrypted. On the other hand, messages received by A can be decrypted.


Definition of “(something like) Qabel”

Qabel is an asynchronous Multi-Device Protocol. This means, that it is not required for sender and receiver to be online simultaneously, which results in the need to store the sent messages on a server until they are picked up by the receiver. Furthermore, sender and receiver can use multiple devices that constantly send and receive messages. This requires synchronization with the sender as well as the receiver.


Implications of Forward Secrecy on “(something like) Qabel”

There is no known protocol that enables Forward Secrecy for asynchronous communication and does not require a constant exchange of ephemeral keys. Since the private ephemeral keys have to be available on all devices used by an identity to decrypt messages, they have to either be synchronized or be generated and exchanged for every device separately. The synchronization of the private ephemeral keys would not work for an efficient protocol without the encryption using the device key. If this device key would get stolen, the ephemeral private key could be gained, which would break the Forward Secrecy. 

In the case that every device owns and provides its own ephemeral keys, every massage would have to be encrypted and sent to all devices used by the receiving party. For synchronization, the massage would additionally have to be sent to all own devices. This means that one sent massage would have to be transmitted x times, where x is the amount of devices used by the receiving and the sending party.

 

Picture 1: Reading archived messages or cracking the password to obtain the key: When Forward Secrecy is no enhancement

 

Note: This is only a schematic representation and does not show the data saved by Qabel.


Characteristics of the Qabel Drop Protocol 

To provide anonymity, the Qabel Drop Protocol stores massages for multiple receivers together in one drop ID. Since the storing drop server does not know for whom the massages are meant all new stored massages have to be send to all receivers behind a drop ID. The factor x would additionally have to be multiplied with the factor y, which represents the amount of receivers behind one drop ID.

Overall, every receiver would receive an amount of unnecessary massages that large, that it could overload the device or endanger the anonymity.

One possibility for receiving complete Forward Secrecy would be a temporary synchronal channel between two devices that is only established when needed. The implementation of such a channel is currently evaluated.


When is Forward Secrecy (not) useful

Forward Secrecy is only useful in cases where messages could be saved while transmitted but are not saved long term on the device. Since the private key can usually only be stolen from the owners device, saved massages could be stolen in the same move without having to decrypt them using the key.

Since Qabel synchronizes the conversations persistently, stealing the massages off the device would be easier than intercepting the conversation and stealing the private key off the device later on. A temporary channel which guarantees full Forward Secrecy would therefore not be persistent.

 

^1 The implications of Forward Secrecy and the listings of protocol abilities given here are shortened and incomplete due to their complexity. The debate evaluating the pros and cons is available on github. Moxie Marlinspike delivered an extensive overview on the topic here.