<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 November 2013 15:40, elijah <span dir="ltr"><<a href="mailto:elijah@riseup.net" target="_blank">elijah@riseup.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 11/22/2013 12:03 PM, Lee Azzarello wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How could the RTP channel be encrypted prior to key agreement<br>
through a verbal SAS confirmation?<br>
</blockquote>
<br></div>
None of the session encryption keys are derived from the SAS. It is the<br>
other way around. Both the session encryption keys and the SAS are<br>
derived from the result of the unauthenticated DH exchange (in the case<br>
of the first time contact) or preshared key (in some cases where you<br>
have talked previously).<br>
<br>
Failing the SAS doesn't do anything except alert you that you are<br>
probably being MiTM'ed.<br>
<br>
From<br>
<a href="http://zfoneproject.com/docs/ietf/rfc6189.html#SASVerifiedFlag" target="_blank">http://zfoneproject.com/docs/<u></u>ietf/rfc6189.html#<u></u>SASVerifiedFlag</a>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A user interface element (i.e., a checkbox or button) is needed to<br>
allow the user to tell the software the SAS verify was successful,<br>
causing the software to set the SAS Verified flag (V), which<br>
(together with our cached shared secret) obviates the need to perform<br>
the SAS procedure in the next call. An additional user interface<br>
element can be provided to let the user tell the software he detected<br>
an actual SAS mismatch, which indicates a MiTM attack. The software<br>
can then take appropriate action, clearing the SAS Verified flag, and<br>
erase the cached shared secret from this session. It is up to the<br>
implementer to decide if this added user interface complexity is<br>
warranted.<br>
</blockquote>
<br>
In effect, the SAS is just an after the fact authentication of the unauthenticated DH, and it is up to the application to decide how to handle a SAS mismatch.</blockquote><div><br></div><div><br></div><div>In addition to what Elijah said, I think it's worth noting that the SAS can ONLY authenticate the channel if you *recognize the other person's voice*.  If you don't, you can't have any confidence that there isn't a very sophisticated attacker in the middle who is performing a one-second-delayed translation attack.  </div>

<div><br></div><div>The attacker would perform ZRTP with both parties, have 2 native speakers, each listening to Alice and Bob and repeating what they say exactly, *except* when they speak the SAS. In that case, they say the correct SAS for the ZRTP session that they are impersonating.  The non-malicious parties to the call would only notice this if they knew the voice of their communication partner, and realized that this was not who they were talking to.</div>

<div><br></div><div>The security of ZRTP relies on recognizing the other party and/or the difficulty and expense of performing such an attack.</div><div><br></div><div>-tom</div></div></div></div>