On Wed, Oct 23, 2013 at 10:13 AM, Greg Troxel <[email protected]> wrote: > > Trevor Perrin <[email protected]> writes: > >> Deniability is achieved because any party could forge records of >> communication with other parties that a 3rd-party judge could not, >> post-facto, cryptographically distinguish from actual records. >> >> Because such forgery is possible, "malleablility" of transcripts isn't >> necessary, and the OTR / mpOTR rigamarole around "modifiable >> transcripts" and publishing signing/MAC keys becomes unnecessary. If >> you can *forge* transcripts from scratch, there's no need to modify >> existing ones. > > It seems that the hard property is to simultaneously achieve: > > deniability > > authentication to the counterparty in real time >
I haven't read many of the references in this thread, but I did read the Whisper Systems blog post [1]. Presumably my question would be answered in them, but even if it's general knowledge to this list's members, it might be nice to spell it out for posterity. Doesn't a shared secret which is deterministically generated from three DH exchange secrets (pictured in [2]) g^aB, g^Ab, and g^ab prove to each party all of the following: 1. The remote party knows the long-term private key (A or B) or else they cannot derive the session secret (Because: DH required for session derivation input). 2. The derived session secret is fresh and unique to the current session (Because: A knows a is fresh, and B knows b is fresh). 3. An eavesdropper cannot know A, B, a, or b unless it is told by the relevant party, or they solve the discrete log problem (Because: DH). 4. Knowledge of the session secret requires knowing either (A and a) or (B and b) and seeing the public messages (Because: DH + session derivation). Are those four sufficient to count as "authenticating the counterparty in real time"? If not, which properties are missing? Alleged property 1 seems sufficient for ensuring the derived session secret requires the long term identity key pairs. Alleged property 2 seems sufficient for "real time" - it ensures the session secret is unique to a given session and both parties are justified in believing that, so long as they have reliable entropy. Alleged properties 3 and 4 seem sufficient for ensuring eavesdroppers cannot impersonate either party, nor deduce the session secret. BTW- [1] isn't explicit about session secret derivation, but I'm *assuming* that Hash( Sort( [g^aB, g^Ab, g^ab] ) ) provides the necessary properties. [1] https://whispersystems.org/blog/simplifying-otr-deniability/ [2] https://whispersystems.org/blog/images/otr-simplified.png > confidentiality, which means more than encryption, but also being > sure that you are encrypting in a key that only the authorized > counterparty has > > It seems that OTR does all of this, and I don't understand how you > propose to get the second two properties with unsigned DH. > > > _______________________________________________ > OTR-dev mailing list > [email protected] > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > cheers, nejucomo _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
