On 11/12/14 01:08, Eleanor Saitta wrote: > 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.
but it may... >> 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. > What is your opinion on forward secrecy. It never has additional UI hints to the user... The UI for SSL/TLS in browsers for example has not changed over the course of its adoption. >> 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. That assumption being that data may be captured at any point. >> 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. No. But for all intents and purposes, it is technically identical. >> * 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. Is there zero protective value in forward secrecy? Of course we can always tell people about it but not give any UI hints... like forward secrecy. > 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? There was a deep technical study here: https://eprint.iacr.org/2014/904.pdf > > 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. Hmm... Sam.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
