> In practice, cryptographic deniability is often disregarded when it comes to court cases or media reporting.
That's because implementers fail to follow through.
The signal protocol enables deniability, but the signal application does not. For a communication app to deliver actual deniability it needs at least to provide the ability to add, remove, and edit messages locally, with timestamps and everything. That edit feature must be easy to use, and easy to find. Ideally, it would be advertised when you first use the app. It must be crystal clear to any judge that screenshots from this app is no better than "he said, she said".
For offline protocols where messages stay online for a long period of time (file encryption, and Signal to a lesser extent), we should also have an easy way to forge messages to oneself. With protocols from the Noise framework, this is easy to implement. From a user's perspective, we just need a "forge false message to self" button, where you specify the "fake sender". Only then can encrypted files be reduced to a "he said, she said" situation.
Cryptographic deniability is not enough. We need plausible deniability, and that can only be achieved when (i) forgeries are easy, and (ii) everybody knows it.
In the first case you would have to explicitly accuse your correspondent of forging a message from you for this to work. Most people would not be willing to do that to the people they chat with on IM. You would be using an excuse specifically created by the system for the purpose of saying something and then falsely denying that you had sad it. Who would believe that is not exactly what had happened? If someone actually did forge a message from you then few would believe that actually happened.
Quoting myself here: forgeability uses a simple technical approach to create a much more complicated question of credibility.[1]
Obviously, if Alice is writing to Bob, repudiability is weakened in two ways:
1. She can't convince Bob she didn't write the message: it's written right there on Bob's phone, and he'd remember if he'd tamper with it.
2. If Bob starts showing Alice's message around, she can't pretend he misremembered, as would be possible with an oral conversation. She'd have to flat out call him a liar.
---
> using a system that is deliberately designed to allow you to say something then deny having said it might also cause extra suspicion.
Not if everyone used such a system. There's a difference between building & using your own obscure deniable chat application, and WhatsApp and Signal themselves enabling this.
> In practice [repudiability] has very little value. It is unlikely that the feature is worth the extra risk of the complexity it would take to implement it.
Deniable schemes are not more complex.
There's just one simple condition: use Diffie-Hellman key exchanges instead of signatures. The result will likely be simpler than a scheme that relies on signatures. I've implemented both key exchanges and signatures with elliptic curves (X25519 and Ed25519 specifically), and I'm telling you, key exchange is significantly simpler and harder to get wrong. (For the anecdote, I screwed-up once in my cryptographic work, and it was the signatures).
See https://noiseprotocol.org for fairly simple key exchange based protocols, with various properties one might care about (key compromise impersonation, resistance against replay-attacks, anonymity to third parties…).
The beauty with DH based schemes like Noise is that when Alice sends a message to Bob, Bob doesn't quite get a cryptographic proof that Alice sent a message. Bob gets a cryptographic proof that Alice or Bob sent a message. Bob only know it came from Alice because he did not send the message to himself.
He could have, though. So he can't (cryptographically) prove to the rest of the world that the embarrassing message really came from Alice. At best, he can prove that the message came from [Alice or Bob], but he'll have to disclose his private key to do it. But as soon as he discloses his own key, anyone can forge messages to him.
(Note: it is possible, still without using signatures, to make sure Bob is not fooled by forged messages from the outside even if his key was leaked: he only have to provide a freshly generated ephemeral key pair into the mix, which necessarily hasn't leaked yet. This provides what we call Key Compromise Impersonation resistance, so we can't force Matrix goggles on him just be cause we stole his key. Unfortunately, this requires Bob to provide that ephemeral key, and that only really works with online protocols. On a PGP-like system, this means that we have to chose between deniability or KCI resistance: if you use signatures, you lose deniability, and if you use only DH, you lose KCI resistance. My personal opinion is that one should be responsible for their own keys. Therefore, I'd sacrifice KCI resistance before I sacrifice deniability.
>That proof can in theory be tied to a particular message.
It's a good point that a signature is needed, so code is not simpler.
But it can't be tied cryptographically to a particular message. The DH generates a shared key, and the signature proves that a DH exchange happened. But the signature proves nothing about the message, the signature isn't over the message. The receiver has access to the shared key and thus can forge messages.
> > That proof can in theory be tied to a particular message.
> It's a good point that a signature is needed, so code is not simpler.
A common misconception. One that I would forgive, if I didn't already linked to a counter-example in this very thread: https://noiseprotocol.org
Noise protocols don't use signatures. Their existence proves beyond the shadow of a doubt that mutual authentication can be achieved without signatures. Here's an example:
Before the protocol
-------------------
sa : Alice's private key
SA : Alice's public key (known to Bob)
sb : Bob's private key
SB : Bob's public key (know to Alice)
Protocol
--------
Alice:
ea = random
EA = public_key(ea)
send -> EA, SA
Bob:
eb = random
EB = public_key(eb)
send -> EB, SB
Alice:
verifies that SB is indeed Bob's key
ee = DH(ea, EB)
es = DH(ea, SB)
se = DH(sa, EB)
key = HASH(ee, es, se)
Bob:
verifies that SA is indeed Alice's key
ee = DH(eb, EA)
es = DH(sb, EA)
se = DH(eb, SA)
key = HASH(ee, es, se)
At this point, Alice and Bob have a mutually authenticated, secret, shared session key. We only needed key exchange (and hashing) to achieve that.
Now if you need a public key infrastructure, that's another matter. Stuff like certificate does require signatures. But that's a separate matter from the protocol itself, which can verify the trustworthiness of a key buy a simple lookup. For instance, an IoT device can hold a copy of its Company's public key. Or, Alice and Bob could have met in a crypto party.
HushChat Protocol is like Signal Protocol, but phone numbers replaced with shielded addresses, fully open source (actually GPLv3 Free Software) and not backdoored.
This quote from GP's link could possibly be interpreted as "Signal does not look very trustworthy":
> Signal requires phone numbers and is a centralized service. HushChat is completely anonymous and decentralized and requires absolutely no metadata be given to any centralized third parties. Signal is also not fully open source, the backend servers are NOT OPEN SOURCE, and so, Signal should be considered "open core" and not fully open source. HushChat is Free Software! We are about your freedom, Moxie cares about his Silicon Valley friends.
I believe Signal requires phone numbers to be usable at all. I maybe vaguely recall plans to get rid of this restriction, but I'm not sure.
The Signal protocol is explicitly designed to trust servers as little as possible, so even if the server code were proprietary, that doesn't mean much.
Ultimately, HushChat and Signal are probably chasing slightly different goals. HushChat seems to be focused on privacy at all costs. Signal is focused on privacy for everyone. There's a usability tradeoff here, between usability and security.
---
While I'm at it, the following quote rubs me the wrong way:
> Are you rolling your own crypto like stupid people?
> No. We use the industry standard libsodium to provide cryptographic primitives: […]
My first objection here is that there's nothing wrong with writing your own implementation of known primitives. The problem when you do so is taking the time to get it right¹, which is why it is almost always much cheaper to just use an existing crypto library.
My second objection is that they are designing and implementing their own protocol. Not that there's anything wrong with that, but they are suggesting it's easier than implementing a primitive. In my experience, it's not. It tends to take less time, but it's also more delicate. Overall, it evens out.
Really, I don't fault them for what they do here. But it sucks that they have to defend against the "rolling your own crypto" in this way.
I think there have been screenshots of group chats where politicians have said something embarassing. This is a case where the politician would have no problem saying “That's a fake”
I'm no cryptographer but I can see that messages are signed before they are encrypted, for no obvious reason. That's failing the cryptographic doom principle (https://moxie.org/2011/12/13/the-cryptographic-doom-principl...) and so should be taken with care.
OTOH the drop of Signal Protocol features makes sense in their appreciation of real world: as soon as an attacker has full control of the device all the protections fail. This is probably the number one source of working attack anyway
The news here is that Session is dumping Signal Protocol in favour of something simpler. So not so much forward secrecy and denyability. They do not think such features are worth the cost in complexity.
Is it simpler ? I only posted because there were a lot of talks about Signal on the front page and I remember Session using Signal's UI and protocol without the phone number (+tor backbones). They say the signal protocol is hard to shoehorn into a decentralized structure, hence the change.
If you studied networking in computer science, "the session protocol" means something between the presentation and transport layers in the iso 7 layer model.
Anything above level 3 in the osi model is pretty useless distinction, and even the useful levels the distinction is just a bogus description of the status quo, rather than something truly useful.
Sometime last year I tried Session and while the idea sounds great it needs a lot more attention before I can use it in anger - but I'm a fan of the idea.
Yet another closed source, centralized ostensibly private chat client? If it actually gets a decent user base it should probably be bridged, but otherwise I don't really care.
Exact opposite, based on Monero and Signal code, decentralised by relying on service nodes that anyone can run, implementing it's own onion routing. Honestly, on paper, it looks pretty good.
The core problem is that devs are Australians and can be secretly compelled to backdoor their app via Assistance and Access Act.
HushChat protocol is superior to Session in every way, which relies on centralized servers, Javascript frameworks, and a small set of "masternode" servers to pass your encrypted chats, which is easily Eclipse Attacked.
Cryptocoins which are based on Monero have no protocol-level encrypted data, HUSH is based on an improved version of Zcash Protocol, which does.
HushChat does have some forms of "plausible deniability", such as: It is impossible to tell how many people you are communicating with, it could be anywhere between 0 and 8 people and look like a normal network transaction. Also, every normal network transaction looks like a HushChat, there is no way to tell which transactions are chats and which are not. They all look the same at the protocol level.
Yes, you must pay for your privacy when using HUSH. If you are not paying for your privacy, you are the product, and don't have any. 1 HUSH = 10000 encrypted messages, on average.
The killer feature set of a messaging system that will allow it to crush WhatsApp, Signal, Session, etc:
* Fully open source ( app, nodes, everything )
* End-to-end encryption ( obviously )
* Rotating keys for deniability. Basically just create time valid subkeys and periodically post the private key to the subkeys. Probably once a day would be sufficient.
* Full message export/import including tweaking and faking messages. It isn't really deniable if you can't show you could easily fake some past messages.
* Fully capable Linux client, so that we aren't forced to use an untrusted and possibly backdoored phone to use it.
* Extra secure time bucketed send/receive if you want to avoid timing attacks on location.
* Hash section bucketed messages along with the bucket by time. For example, if your public key is 4BC56..., you can request all messages sent to 4BC* and get them all, so it isn't then obvious who exactly you are.
* Subkey unique per communication partner. This way gaining someones subkey for a time period doesn't let you potentially capture other packets you know are encrypted and decrypt them too...
* URL based identity. Post your public key to URL; tada that URL can then be used as your identity. Have a bunch of different secure countries host free identity upload sites.
* Group chat which just makes it so you communicate every message to every other partner in the group chat and vice versa. Any other way wouldn't be secure.
* Message size padding to private size based packet matching.
* Automatic sending of periodic messages to bogus destinations. This way it is not immediately apparent if you are sending something out or not. Preferably this would include adding random people and engaging in nonsense chat sessions with them for random amounts of time. Only the client on the other end would know if it is a bogus message or not.
* Message nodes completely wipe all data hourly ( for regular messages ) or daily ( for the daily grouped messages )
* Message nodes all ban any client attempting to download more than a certain threshhold of data. Publish the banned clients publicly. Expose the watchers.
* No registration. Basically anyone should be able to send/receive through whichever node they wish that has available bandwidth. You send an encrypted chunk with a destination ID. Others can download chunks tagged with some hash part of the destination.
* Central "saturation tracking node" that receives saturation from all registered nodes in the system and just publishes a file on a URL for whoever wants it to figure out which node they will use to communicate that isn't over-saturated.
* Can post a set of nodes you listen on to your URL with public key periodically so clients know how to start communication with you. Once established; switch to unsaturated nodes...
The following features are somewhat irrelevant:
* Onion routing. Just connect to the service through any number of other onion routing systems. No need to put all our eggs in one basket. Use a private VPN + Tor to connect to the system. Done.
That's only needed if you sign with those keys. DKIM for instance. If your protocol is based on key exchanges (as Signal is), you don't really need to rotate anything, because recipients can always fake messages coming to them. (Group discussions however may be another matter.)
That said, there are other reasons to rotate keys, typically to diminish the probability and the impact of leaks.
That's because implementers fail to follow through.
The signal protocol enables deniability, but the signal application does not. For a communication app to deliver actual deniability it needs at least to provide the ability to add, remove, and edit messages locally, with timestamps and everything. That edit feature must be easy to use, and easy to find. Ideally, it would be advertised when you first use the app. It must be crystal clear to any judge that screenshots from this app is no better than "he said, she said".
For offline protocols where messages stay online for a long period of time (file encryption, and Signal to a lesser extent), we should also have an easy way to forge messages to oneself. With protocols from the Noise framework, this is easy to implement. From a user's perspective, we just need a "forge false message to self" button, where you specify the "fake sender". Only then can encrypted files be reduced to a "he said, she said" situation.
Cryptographic deniability is not enough. We need plausible deniability, and that can only be achieved when (i) forgeries are easy, and (ii) everybody knows it.