[guardian-dev] Blog post: VoIP Security Architecture

Abel Luck abel at guardianproject.info
Mon Nov 25 07:48:22 EST 2013


If someone already understands the encrypt-then-verify model of OTR, then I think
explaining ZRTP and the SAS to in those terms is fine, because they are essentially
analogous.

However, if we're talking about the % of users who don't already understand OTR, then I
think explaining it so wouldn't be helpful at all.

~abel


Lee Azzarello:
> 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.
> 
> -lee
> 
> 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
> _______________________________________________
> 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/abel%40guardianproject.info
> 
> You are subscribed as: abel at guardianproject.info
> 



More information about the Guardian-dev mailing list