search

otrv4 / otrv4

Off-the-Record Messaging Protocol version 4. -This is a draft- This repository is a mirror of http://bugs.otr.im/otrv4/otrv4
190 stars 21 forks source link

Distributing public keys #31

Closed juniorz closed 7 years ago

juniorz commented 8 years ago

In OTRv3, public keys are send to the other conversation participant in the Reveal Signature and Signature messages, which occurs in the last two steps of the AKE.

However, for the DAKE in OTRv4, both parties need each other´s long-term identity keys at the beginning of the AKE, in order to share keys and authenticate to each other.

How should we do this? If you don´t have the other person´s public key.

So our options are:

  1. Add an extra step where each party will need to query a server for the other person´s public key before starting a conversation
  2. Include the other party´s public key in ψ1 and ψ2 of the AKE. Not sure how this could break security properties.
rosatolen commented 7 years ago

Option one's insecurity is researched in this paper: http://www.jbonneau.com/doc/BM06-OTR_v2_analysis.pdf (Thanks @claucece )

rosatolen commented 7 years ago

In the initial part of the DAKE, we can have I send PKi along with g^i and "I" to the Bob for interactive cases and to the server. And we can have Bob send PKb, along with DRE and the Auth.

If R does not verify the long term PK found on the server or sent along with part 1 of the DAKE, before sending R's first message, then R may send the DRE to the wrong person.

If an adversary only switches out g^i into g^m, then R will send a DRE containing his g^b that only I can decrypt, and R will encrypt a message with g^mb. In this case, the adversary cannot get g^b to decrypt the message. If an adversary switches out PKb for PKm from R's response, then Alice will not be able to verify the Auth.

claucece commented 7 years ago

@rosatolen No, sorry. That is referring to MAC keys.

chelseakomlo commented 7 years ago

I was pointed to CONIKS last week as something which could possibly be useful for this: https://coniks.cs.princeton.edu/

olabini commented 7 years ago

No, coniks is not useful for us.

Sent from my iPhone

On Oct 2, 2016, at 11:08 AM, Chelsea Komlo notifications@github.com wrote:

I was pointed to Coniks last week as something which might possibly be useful to us: https://coniks.cs.princeton.edu/

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

olabini commented 7 years ago

@rosatolen - if I understand what you're describing in your comment, you are talking about a classic MITM attack. This will always be possible if the two sides haven't verified each others public keys, and is nothing we can do anything about.