[OTR-dev] mpOTR protocol phases and research questions

[Callme Whatiwant]

On Wed, Oct 23, 2013 at 10:13 AM, Greg Troxel <gdt at ir.bbn.com> wrote:
>
> Trevor Perrin <trevp at trevp.net> 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
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>


cheers,
nejucomo