On 11/12/14 00:38, Eleanor Saitta wrote: > On 2014.12.10 19.29, Sam Lanning wrote: > >> On 10/12/14 22:41, Eleanor Saitta wrote: >>> Un-signed and deniable are distinct properties. I'm definitely >>> not arguing against unsigned transcripts; making an active effort >>> to make repudiation difficult is a very different question than >>> designing for the field utility of deniability. > >> Unfortunately it's not that simple. In most cases with security >> protocols, these two are mathematically as useful as each other, >> not-deniable (but with authenticity) is as good as signed. > > That's not remotely clear, on two specific levels, one vastly more > important than the other: > > First, we can talk technically about the integrity and > linkability-to-identity of a channel separate from that of a specific > message. This is where we can talk about specific security goals in > the cryptographic sense. I believe that what I stated is true in this > sense, but only weakly; I'm open to being persuaded here.
The high level concepts in my previous message extend from a single message to a channel. i.e. the contents of a channel can be provably from no one, a single person, or one of two people. > > Second, we can talk about deniability as part of the overall > user-task-completion engineering effort. Adding deniability as a > supported invariant of a system and supporting it throughout the > system lifecycle (including user education, UI design, user task > structuring, and user security planning) is incredibly expensive for > little believable gain, vs. merely not supporting the non-repudiation > of messages. If you intend to design for a security invariant, you > must design for it throughout the system, and at this level, > invariants are neither interchangeable nor cheap. And yes I see the confusion. Some of us have been talking about deniability as a property of the protocol, and some of us have been talking about denibility of the whole system, and arguing for and against respectively. These are two different things. I am actually of the opinion that deniability should be implemented up to, and no further than the protocol. My reasons being as follows: * If we completely discard deniability, but keep authenticity (which of course we want), we require signatures of the data in the channel (see last email). This means that there is cryptographic evidence that each person did send everything they sent. And it will stand up in a court of law as strongly as a chain of PGP signed emails. * We take deniability up to the protocol level. As we have done with Axolotl and TextSecure. This means that there is no longer PGP-like strong cryptographic evidence that people have sent what they did. * we take deniability all the way up through the system to the UI. Now in all honesty, I'm really not sure exactly what this would entail (other than your example of having to "end a conversation" in OTR, and I haven't studied the OTR protocol enough to know why). TextSecure already supports deniability, and there is no UI indication of this whatsoever. It is protecting people without the need for cognitive overhead. Cheers, Sam.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
