6 ms·
> In practice, cryptographic deniability is often disregarded when it comes to court cases or media reporting. That's because implementers fail to follow throu
by loup-vaillant 6y ago
> 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.
- upofadown 6y agoIn 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] [1] https://articles.59.ca/doku.php?id=pgpfan:repudiability https://articles.59.ca/doku.php?id=pgpfan:repudiability
- loup-vaillant 6y agoObviously, 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 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…).
- upofadown 6y agoPlain DH can be MITMed. You need some sort of proof of identity to prevent that. That proof can in theory be tied to a particular message.
- privacylol 6y agoInside of HushChat, libsodium secretstreams are used, which get the job done: https://doc.libsodium.org/secret-key_cryptography/secretstream https://doc.libsodium.org/secret-key_cryptography/secretstre... https://git.hush.is/hush/hushchat https://git.hush.is/hush/hushchat HushChat Protocol is like Signal Protocol, but phone numbers replaced with shielded addresses, fully open source (actually GPLv3 Free Software) and not backdoored.
- minitech 6y ago> and not backdoored. Are you saying that Signal is backdoored? Evidence?
- loup-vaillant 6y agoThis 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. [1]: https://loup-vaillant.fr/articles/crypto-is-not-magic.html https://loup-vaillant.fr/articles/crypto-is-not-magic.html 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.
- rmc 6y agoI 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”