[messaging] Value of deniability
sam at samlanning.com
Wed Dec 10 17:27:51 PST 2014
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
>> * 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 949 bytes
Desc: OpenPGP digital signature
More information about the Messaging