[guardian-dev] Blog post: VoIP Security Architecture

Lee Azzarello lee at guardianproject.info
Fri Nov 22 17:40:29 EST 2013

Elijah and Dominik,

Thanks for clearing this up. Is it fair to compare the process to OTR
verification or is that just a fool's errand since both protocols
obviously have significant enough complexity as to confuse 99% of all
users? I say this because I've been describing ZRTP key agreement this
way for over two years and you are the first two people in the world
to notice this detail and reference a fact about how it is incorrect.


On Fri, Nov 22, 2013 at 3:40 PM, elijah <elijah at riseup.net> wrote:
> On 11/22/2013 12:03 PM, Lee Azzarello wrote:
>> How could the RTP channel be encrypted prior to key agreement
>> through a verbal SAS confirmation?
> None of the session encryption keys are derived from the SAS. It is the
> other way around. Both the session encryption keys and the SAS are
> derived from the result of the unauthenticated DH exchange (in the case
> of the first time contact) or preshared key (in some cases where you
> have talked previously).
> Failing the SAS doesn't do anything except alert you that you are
> probably being MiTM'ed.
> From
> http://zfoneproject.com/docs/ietf/rfc6189.html#SASVerifiedFlag:
>> A user interface element (i.e., a checkbox or button) is needed to
>> allow the user to tell the software the SAS verify was successful,
>> causing the software to set the SAS Verified flag (V), which
>> (together with our cached shared secret) obviates the need to perform
>> the SAS procedure in the next call. An additional user interface
>> element can be provided to let the user tell the software he detected
>> an actual SAS mismatch, which indicates a MiTM attack. The software
>> can then take appropriate action, clearing the SAS Verified flag, and
>> erase the cached shared secret from this session. It is up to the
>> implementer to decide if this added user interface complexity is
>> warranted.
> 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.
>> It's my understanding that the 1st time two peers agree on a key the
>> RTP channel is in the clear. No prior keys exist so no hash can be
>> transmitted for the DH exchange. It is also my understanding that the
>> nth time these peers communicate the RTP stream is never in the
>> clear. The spec describes the probability of a MitM attack's success
>> on the nth time as mathematically impossible unless the 1st SAS was
>> middled.
> Sure, DH exchanges are usually in the clear, since it is a bootstrap after
> all. But after the first DH, the next call usually uses a cached key.
> -elijah
> _______________________________________________
> Guardian-dev mailing list
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To Unsubscribe
>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>        Or visit:
> https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info
> You are subscribed as: lee at guardianproject.info

More information about the Guardian-dev mailing list