I talked about the decentralized encrypted messenger Session last month. Since then, I've been thinking about it because people keep talking about it.

In particular, I've been thinking about Session's choice that messages should not be cryptographically deniable. I want to challenge the justification for this choice.

How does Session frame deniability?

Messages encrypted using the Session Protocol are not cryptographically deniable. Here's Session's high-level explanation of this fact:

Cryptographic deniability, or deniable authentication, prevents either party in a conversation from proving the origin of any message to a third party — essentially, Alice can’t cryptographically prove to anyone outside the conversation that Bob was the one who sent a specific message. The problem is that practical applications for deniability are very limited. Court rulings and media reporting both commonly ignore deniability and defer to evidence of the conversation taken directly from the device — like screenshots. One example of deniability as an unsuccessful defense was in the case of the communications between Chelsea Manning and Adrian Lamo.

Deniability is treated as a feature which is nice in theory but not very useful in practice.

How does cryptographic deniability actually work, though?

(Don't worry, I won't get too technical in this section.)

As I see it, framing deniability as a feature that Session has chosen to forego is misleading.

Let's talk about this in physical-world terms. Suppose you write a letter to someone, and you sign your name at the bottom. This signature provides two important properties:

1. Authentication: The repcipient can be sure themself that the letter is authentic (it came from you).
2. Non-repudiation: The recipient can prove to someone else (a judge, for example) that the letter is authentic and came from you.

(For simplicity, let's not get too caught up in the details such as how difficult it is to forge a signature or to modify the letter after it has been signed. Just assume it works.)

In cryptography, we have the same thing, also called signatures. If I sign a message (as I often do with my emails), you can not only verify that I wrote (or at least signed off on) the message (authentication), but also prove to a third party that I did (non-repudiation).

Cryptographic deniability is when you don't have non-repudiation. In other words, if you don't sign your letters, it's easier to deny that you wrote them.

In the physical-world analogy, you can achieve this deniable authentication (authentication without non-repudiation) by writing the letter, sealing it in an envelope, and signing the envelope, rather than the letter. The recipient can verify the signature on the sealed envelope and know whatever it contains is authentic, but once they've opened the envelope, they can't prove to someone else that you wrote what's inside. They could have written their own letter and put it into the open envelope.

In cryptography, you can do something similar using a key that is known by both you and the recipient, and no one else. The recipient can verify that you wrote the message (because they know they didn't write it, and no one else knows the key), but they can't prove to someone else that they didn't write it themself (because they do know the key). By not signing the message, you do not have the property of non-repudiation, meaning (from a cryptographic perspective) that you can deny having authored it.

Framing matters

The ability to deny that you wrote a message is a desired goal of apps like this. We want to be able to have off-the-record conversations. Session argues that deniability from a cryptographic perspective is usually not considered in practice, and therefore it's not important for the Session Protocol.

But remember, deniability is actually the absence of non-repudiation.

Thus, the argument is that because the absence of cryptographic proof of authorship is generally not considered a valid argument in practice, we should provide cryptographic proof of authorship of all messages.

This is like saying, "The courts often find people guilty even without a confession, so you should go ahead and confess to everything you do."

I'm not saying that if your goal is to deny authorship of a message, cryptographic deniability in and of itself is likely to convince lay people in practice; what I'm saying is that cryptographic non-repudation has a lot of potential to hurt your case.

Disclaimers

1. It should be said that by default, Session clients discard cryptographic signatures after verifying them. In most cases, when you send a message to someone on Session, they will still not be able to later prove it (cryptographically) to a third party.

However, let's frame this a different way. When you send a letter to someone, you sign the letter, but you expect them to cross out your signature after opening it. You're still (unnecessarily) giving them proof they could bring to a third party and just expecting them not to keep it.



2. There are two types of deniability. One allows you to deny that you authored a specific message, and the other allows you to deny that you were a party in a conversation at all. I'm focusing on the first in this post.
3. I'm just a person on the internet with opinions. Don't take what I say as authoritative.

Conclusion

Framing matters. Cryptographic non-repudiation is achieved by adding a signature to a message. Cryptographic deniability should be framed as a lack of non-repudiation (or, more specifically, deniable authentication is authentication without non-repudiation). The question Session asks should not be, "Is deniability likely to help my case?" but rather, "Can non-repudiation hurt my case?"