When UI is as strong as cryptography

Imagine Bob. Some call him a whistleblower and others call him a traitor of the highest degree. He is facing federal punishment for crimes against the state. Specifically, he is being tried for treason, sabotage, and espionage for leaking classified documents to the public. The documents meticulously outline the government's extensive and illegal surveillance of its citizens. Bob is an expert in information security who rarely makes mistakes, but in a moment of doubt, his judgment lapsed — he reached out to his lifelong friend, Alice, revealing his plan to expose the government's illegal tracking of private citizens. He predicted an FBI sponsored media onslaught would promptly follow his revelations to the public. His motivations, he assured her, are patriotic, and he seeks to preserve his good name in her eyes.

The FBI confiscated Alice’s phone as evidence. And while Bob may have slipped up by messaging Alice, he judiciously arranged for the conversation to take place on Signal, a secure messenger known for pioneering cutting edge end-to-end encryption techniques. In this scenario, deniability, a core feature of the Signal protocol, is subject to a stress test. The prosecution seeks to have Bob's messages to Alice included as evidence in the trial. 

To better understand deniability, let's contrast Signal with traditional cryptographic schemes. For instance, using PGP, Bob would sign all outgoing messages with his private key, and Alice verifies those messages with Bob’s public key. Consider cryptographic signatures as a mathematical formalization of a wax seal. The seal, embossed with a unique mark only the sender can produce, assures authenticity. If the letter is illicitly broken open, the damage to the seal conveys clear evidence of tampering. However, unlike wax seals, cryptographic signatures have one serious drawback — Alice now possesses nearly irrefutable proof that Bob authored those messages. In many such cases, we argue, Alice may not want strong proof of this. With deniability, Alice knows a message originated from Bob, yet Alice cannot prove to others that Bob authored this message. 

For those skeptical that deniability is truly a desirable attribute, it’s helpful to consider the design goals of an end-to-end encrypted messenger. Ideally, participants should feel the same level of comfort communicating over the Internet as if they were engaged in a private discussion at home in front of the fireplace. While those of us born into a world mediated by technology have been habituated to accept omnipresent surveillance as the norm, deniability has been a cornerstone of human communication throughout most of history. Violating deniability is akin to hiding a wiretap under your collar prior to an intimate conversation with a trusted confidant.

The Signal protocol achieves deniability through a method known as double ratchet encryption. For a fast and loose description of the protocol, both parties securely exchange shared state (Diffie-Hellman parameters) that updates with each new message, and both parties use that state to derive the exact same symmetric key. Integrity is guaranteed not through signature verification but by checking the attached HMAC. Since both the sender and receiver have the same key, either could have computed the MAC. Therefore, it is impossible to use Alice’s phone to establish cryptographic provenance of Bob’s messages.

Due to Signal’s careful design, Bob can deny he sent those messages so as not to incriminate himself. But the prosecution team is ardent that Alice’s phone is kept on as evidence, so they summon a PhD cryptographer as an expert witness. The witness explains to the judge, in the simplest terms, how the Signal protocol works and why the defense’s assessment is indeed correct — she argues that the phone may not be used as evidence since the provenance of the messages is unverifiable.

In a clever pivot, the prosecution shifts their argument from cryptographic integrity to UI integrity. They navigate through the Signal UI, showing the judge that no deniability capabilities are directly exposed to the user. Moreover, they talk of Alice’s background, noting that she is a librarian with a public record of being outspoken against technology, and she even revels in her tech illiteracy. In fact, Alice only begrudgingly downloaded Signal to humor her privacy conscious friend.

The prosecution argues to great effect that Alice’s messages from Bob are displayed in the Signal UI just as they arrived over the network. Neither is her device rooted nor is her internal storage compromised. They even presented a digital forensics expert who confirmed that Alice’s phone bears no signs of manipulation. And to put a bow on their argument, geolocation data from Alice’s phone definitively shows that, from the time that she received Bob’s messages until the time she was intercepted by law enforcement, she remained alone and thus was not aided by some tech savvy accomplice.

After contemplating all the data, the judge acknowledges the cryptographic strength of Signal but sees no reason to question the integrity of the UI, which lacks a straightforward route for nontechnical users to manipulate received messages. Thus, he concludes, Bob’s messages to Alice can be used as evidence in the case. 

Obviously, this is an entirely invented scenario, but it underscores the point that legal deniability does not necessarily follow from the properties of cryptographic deniability.

However, one simple interface tweak could potentially offer the best of both worlds. The missing piece here appears to be an “edit” option. By edit, we don’t mean editing in the conventional sense, in which the sender edits an outgoing message to, say, fix a typo (although that is also a nice feature). Rather, after the incoming message’s MAC is checked and decrypted, that version on disk should be editable. If that message is edited, nothing happens at the protocol level. The edited version is not sent back to the sending party and it wouldn’t make much sense if it were.

In practice, no one actually uses this new edit feature. It only exists to confound the establishment of provenance and to strengthen plausible deniability. The feature’s mere presence makes it trivial for users of all technical levels, even Alice, to have doctored any received messages. In the case of our hypothetical, the expert witness would show how Alice could simply have long-pressed Bob’s messages and edited them to her liking, making the case for deniability airtight. 

In sum, while we typically expect advancements in cryptography and number theory to lay the foundation for our privacy, sometimes a slight UI tweak is all that’s needed to give the math some teeth.