Re: [Cfrg] SRTP with SHA2?

Jon Callas <jon@callas.org> Fri, 01 July 2011 22:27 UTC

Return-Path: <jon@callas.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7D111E80FB for <cfrg@ietfa.amsl.com>; Fri, 1 Jul 2011 15:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.494
X-Spam-Level:
X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToDDN6JOb-kc for <cfrg@ietfa.amsl.com>; Fri, 1 Jul 2011 15:27:35 -0700 (PDT)
Received: from merrymeet.com (unknown [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 45F4811E8085 for <cfrg@irtf.org>; Fri, 1 Jul 2011 15:27:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 9D3EB2E107 for <cfrg@irtf.org>; Fri, 1 Jul 2011 15:28:11 -0700 (PDT)
Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09750-01 for <cfrg@irtf.org>; Fri, 1 Jul 2011 15:28:09 -0700 (PDT)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 4381F2E101 for <cfrg@irtf.org>; Fri, 1 Jul 2011 15:28:09 -0700 (PDT)
Received: from ba0301b-dhcp217.apple.com ([17.193.15.217]) by keys.merrymeet.com (PGP Universal service); Fri, 01 Jul 2011 15:27:31 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 01 Jul 2011 15:27:31 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Jon Callas <jon@callas.org>
In-Reply-To: <E04A0D4E9A590848A5B84212DFD59B4B02B035A32C@palmail02.lsi.com>
Date: Fri, 01 Jul 2011 15:27:30 -0700
Message-Id: <597874AF-C28E-43AE-AD8F-402D1A89C8E9@callas.org>
References: <E04A0D4E9A590848A5B84212DFD59B4B02B035A32C@palmail02.lsi.com>
To: "Severns-Williams, Christine E (Christine)" <Christine.SevernsWilliams@lsi.com>
X-Mailer: Apple Mail (2.1084)
X-PGP-Encoding-Format: MIME
X-PGP-Encoding-Version: 2.0.2
Content-Type: multipart/signed; boundary="PGP_Universal_90FBED5B_ECF6AB71_D065C845_62C6BB0F"; protocol="application/pgp-signature"; micalg="pgp-sha1"
X-Virus-Scanned: Maia Mailguard
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] SRTP with SHA2?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2011 22:27:37 -0000

On Jun 30, 2011, at 10:40 AM, Severns-Williams, Christine E (Christine) wrote:

> Hi All,
>   I’m not sure this is really the right mail list for this question.  But I see SHA2 being added to many security protocols (IPsec, TLS, etc) and discussion of other algorithms fading such as MD5.
>  
> I know SRTP supports AES-CM (128, 192, 256), AES-f8, and there is a draft for AES-CCM and AES-GCM (128 and 256).
>  
> Has anyone considered or is looking at using/adding SHA2 to the SRTP protocol?     Just curious.
>  
> I know the digest size is larger but it could still be truncated. 

You could, but there's no real need, and a number of reasons not to.

SRTP uses HMAC-SHA1 for integrity, and even provides for truncated integrity. If you believe that 80 bits of security is enough and that lots of times 32 bits is fine, then SHA256 is overkill. HMACs don't have the weaknesses that a straight hash does. You don't gain anything by using a truncated SHA256, security-wise.

(The truncated integrity is reasonable in many applications, particularly those where the payload is simply media. If the media has other integrity checks in it, even better. Suppose, for example, that the total payload was audio on the X codec, and if the X codec gets thrown into a bogus state, it will discard the packet. In this case, not only does the codec supply secondary authentication, but should a bad packet actually be inserted into the media stream, the only effect of that is an audio glitch. Almost certainly that glitch will just be a blip of noise.)

However, SHA256 is slower than SHA1, and since you're using it in an HMAC, you're having to do two hashes. That's big, from a performance point of view.

In many environments, the lion's share of the crypto cost for SRTP is that SHA1 HMAC. It is often over 2/3 of the total cost. Switching to SHA256 could bring the integrity cost to 80% or more of the total crypto cost, as well as driving it up, not down.

The real need for SRTP is to find an integrity check that's faster. That's something that ZRTP (RFC 6189) does. (Full disclosure: I'm a ZRTP co-author.) Some ZRTP implementations found that 75% of the cost of the crypto was that HMAC. So ZRTP provides the option to use the one-pass MAC feature of the Skein-512 hash function, which is one of the SHA3 finalists. (Full disclosure: I'm a Skein co-author, as well.) Not only is Skein-512 faster than SHA1, often running at 2/3 the speed of SHA1, but the one-pass MAC means you're only doing one hash, not two. That means that a Skein-MAC has only 1/3 the cost of HMAC-SHA1! It also has at least as good security as SHA256, so you get both better security and better performance.

(In the name of the algorithm, the -512 refers to the internal state size of Skein, not the output size. All three variants of Skein (256, 512, 1024) can have any length output. When you might want whatever internal state size is a long discussion that I could bore you at great length on. I believe that Skein-512 is adequate for any reasonable use.)

	Jon