[21422] in cryptography@c2.net mail archive
Re: Zfone and ZRTP :: encryption for voip protocols
daemon@ATHENA.MIT.EDU (Alex Pankratov)
Sat Mar 18 16:07:52 2006
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Fri, 17 Mar 2006 16:21:47 -0800
From: Alex Pankratov <ap@hamachi.cc>
In-reply-to: <Pine.BSO.4.64.0603171609580.9227@fuyu.mindrot.org>
To: cryptography@metzdowd.com
Cc: Damien Miller <djm@mindrot.org>, Ed Gerck <edgerck@nma.com>,
prz@mit.edu
Damien Miller wrote:
> On Wed, 15 Mar 2006, Ed Gerck wrote:
[snip]
>>"...allows the detection of man-in-the-middle (MiTM) attacks by
>>displaying a short authentication string for the users to read and
>>compare over the phone."
>>
>>Depends on the trust model. May not work.
>
> This is incomplete. The paragraph goes on to say:
>
>>we still get fairly decent authentication against a MiTM attack, based
>>on a form of key continuity. It does this by caching some key material
>>to use in the next call, to be mixed in with the next call's DH shared
>>secret, giving it key continuity properties analogous to SSH.
Here's a quote from the draft -
> We use an analogous baby duck security model to authenticate the DH
> exchange in ZRTP. We don't need to exchange persistent public keys,
> we can simply cache a shared secret and re-use it to authenticate a
> long series of DH exchanges for secure phone calls over a long period
> of time. If we read aloud just one SAS, and then cache a shared
> secret for later calls to use for authentication, no new voice
> authentication rituals need to be executed. We just have to remember
> we did one already.
The draft says that shared secrets are keyed by ZID when stored
in a local cache, where ZID is a unique persistent random ZRTP
endpoint ID.
Unless I am missing something, ZIDs exchanged by peers during a
handshake remain unauthenticated. This means that if both A and
B have cached shared secrets with M, then M can mount MitM
attack against A-B session and both A and B will be under the
impression that they are protected by 'key continuity' from
their previous (A-B) session.
Their SAS won't match of course, but since they see shared secret
being used for KE, they are not likely to bother with SAS check.
Alex
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
