[OTR-dev] mpOTR protocol phases and research questions

[Trevor Perrin]

On Wed, Oct 23, 2013 at 12:09 PM, Callme Whatiwant <nejucomo at gmail.com> wrote:
>
> 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"?

Yeah, that's basically it.


> 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.

Probably better to sort on public values (instead of private).

Also you want to include the public keys and any other identity or
negotiated info as input to the KDF (this is standard practice, and
helps with security proofs and preventing "identity misbinding" type
issues).

So we're talking about something more like:

K = SHA256(g^aB || g^Ab || g^ab || Apub || Bpub || apub || bpub)

or even:

K = SHA256(g^aB || g^Ab || g^ab || all_handshake_messages)

HKDF could also be considered...


Trevor