-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2014.12.10 19.58, Sam Lanning wrote: > 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.
No, because message capture by an adversary does not necessarily occur in the context of the channel, depending on the system and message capture mode. > 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. Talking about things only at the protocol level without incorporating that concept into whole-system-design is generally an indicator of massive failures in system design. I would worry significantly about this decision. > 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. This makes assumptions about the level at which data is captured. > And it will stand up in a court of law as strongly as a chain of > PGP signed emails. We have no evidence that supports this assertion. > * 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 have no evidence that asserts that the "strong" nature of this evidence is meaningful. > * 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. There is zero protective value here. Protection would imply that users would be aware of the invariant and take it into account in their operational planning. This never happens, and can never happen if they're not told about it. I would strongly question, even if we had specific evidence that demonstrated any legal utility, whether deniability was an appropriate invariant to try to convey to users given the incredibly narrow circumstances of its conceptual utility. Simplicity is incredibly important in the design of systems intended to be used in adversarial circumstances, and new invariants are rarely free. How much work has been done to test and ensure that deniability is maintained in Axolotl? The arguments being made here make it clear that no whole-system design input is happening in these systems, a fact which I find distressing. E. - -- Ideas are my favorite toys. -----BEGIN PGP SIGNATURE----- iF4EAREIAAYFAlSI7p0ACgkQQwkE2RkM0wp4cQD+JtxD9bnOTaZgfMiiPSvqCu5X wiv7BF6Q1KcpiIlKEbUA/AmnK7/a55sm3UUlu6AWVpqJb9WKUiLIiHaO+Empy7nF =DqMC -----END PGP SIGNATURE----- _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
