RE: Galois/Counter Mode of Operation in SRTP

Hi David,

> I'm not quite sure what you mean.  The additional authenticated 
> data needs to be presented to the AEAD algorithm as a single 
> input, so to speak.
> With GCM (and most other crypto algorithms), it is possible 
> to implement an init/update/final interface, or equivalently, 
> a scatter/ gather interface (like the iovec used by writev).  
> An API like this allows the calling application to avoid copying 
> data before calling crypto.  So with the AAD definition that I'd 
> outlined below, it would be possible to GCM-protect a packet like
this:
> gcm_auth_only(roller_counter, 4);
> gcm_auth_only(rtp_header, 12);
> gcm_auth_enc(rtp_payload);

I was, rather, thinking in terms of the SRTP security layer which, in
some applications, may be presented with the entire RTP packet, and not
with its parts (header and payload) separately. Consequently, for the
"plaintext" data in the format you stated earlier 

   plaintext = rtp_payload || ROC || rtp_header

in order to use the call sequence you mentioned, I think, such
application layer should be doing some memcpy-ing, or making some
pointer calculations.

In case the format for the AES-GCM input is defined as

    plaintext = rtp_header || rtp_payload || ROC

the memcpy-ing seems to be less of an overhead as the [rtp_header ||
rtp_payload] part is the entire RTP packet and operation can be done as
follows:

   gcm_auth_only(roller_counter, 4);
   gcm_auth_only(rtp_packet, ...);

Obviously, such overhead is not huge, but sometimes each little piece
counts. Does this make a better sense ?

> Table 2 of http://eprint.iacr.org/2004/193.pdf has 
> a performance comparison.
Thanks for the reference, this helps.

I was also wondering what are the plans (if such exist) of accommodating
the AES-GCM into the SRTP RFC ?

Thanks,
Eugene.

-----Original Message-----
From: David McGrew [mailto:mcgrew@xxxxxxxxx] 
Sent: Thursday, March 29, 2007 2:40 PM
To: Eugene Nechamkin
Cc: Lee Dilkie; ietf-rtpsec
Subject: Re: Galois/Counter Mode of Operation in SRTP

Hi Eugene,

On Mar 29, 2007, at 1:41 PM, Eugene Nechamkin wrote:

>
> Hi David,
>
> I can think of the following pro-s for the AES-GCM compared with the 
> drawbacks of the current AES-CM in SRTP:
>       - computational overhead related to HMAC-SHA1 (even with the HW
> accelerations)
>       - ambiguity with the choice of the Auth Tag length: 80 bits ? 32
bits 
> ?
>       - more than one computational algorithms involved in SRTP
processing 
> (with the corresponding HW and/or SW penalty).
>       - not future proof: the SHA1 problem may be potentially
affecting the 
> current SRTP ciphers. I realize that this may be not the most serious 
> concern due to the presence of HMAC.

agreed, I bet that HMAC-SHA-256 is quite slow on short packets!

>       - the ability of the SRTP to offer the crypto methods allowing
the 
> simple (cheep) HW implementations are very important for a wide 
> variety of the voice and video-over-IP devices, especially the ones 
> with the integrated networking functionality.
>       - as AES-GCM is becoming increasingly included or even mandated
in 
> other areas of the network security (e.g. MACsec, IKEv2, TLS), the 
> devices can easily benefit from re-use of the GCM implementation.
>
> I agree, the fact that auth tag of AES-GCM cannot be truncated is 
> somewhat restricting. However, this may be a drawback which many 
> applications/devices can compromise on given other advantages of GCM.
>
> One of the justifications for Authentication and Encryption to be 
> separate is the ability of the authentication to prevent (or
> remedy) the
> DoS attacks when the device is bombarded with the arbitrary fabricated

> (or modified) packets and, consequently, chokes on the decryption of 
> these packets. Such separation can be viewed as an advantage over the 
> AEAD provided that the time required for calculation of the 
> authentication tag is significantly less than the time for the 
> decryption process. With the cipher suites required by SRTP (AES-CM 
> and HMAC-SHA1), this does not seem to be the case. I think, this 
> criteria may be even used as a condition for the AES-GCM suitability 
> for the particular application. So, potentially, the absence of the 
> separate authentication procedure in AES-GCM cannot be considered as a

> fundamental drawback compared to the current SRTP.
>
> I would also basically agree with the way how the "plain text" can be 
> defined to accommodate the RTP header and ROC in AES-GCM. However, I 
> was wondering why not to define the "plain text" as follows:
>
>       plaintext = RTP_Packet || ROC
>
> where
>       RTP_Packet = rtp_header || rtp_payload
>
> This seems to be easier on the device - no need for re-packaging the 
> RTP packet.

I'm not quite sure what you mean.  The additional authenticated data
needs to be presented to the AEAD algorithm as a single input, so to
speak.

With GCM (and most other crypto algorithms), it is possible to implement
an init/update/final interface, or equivalently, a scatter/ gather
interface (like the iovec used by writev).  An API like this allows the
calling application to avoid copying data before calling crypto.  So
with the AAD definition that I'd outlined below, it would be possible to
GCM-protect a packet like this:

gcm_auth_only(roller_counter, 4);
gcm_auth_only(rtp_header, 12);
gcm_auth_enc(rtp_payload);


>
> My biggest issue would be to evaluate how much of the memory toll the 
> AES-GCM requires to achieve the performance comparable (or higher) 
> with the standard [AES-CM+HMAC-SHA1] combo. If somebody knows of such 
> estimations, would be great to hear this.

Table 2 of http://eprint.iacr.org/2004/193.pdf has a performance
comparison.  AES-HMAC-SHA1 looks pretty bad in the comparison; I think
that the implementation was not well optimized (it was taken right from
openssl).  This data suggests that GCM would do well here,  
though as always performance can vary across different systems.   It  
would be good to do a code size comparison as well.

David

>
> Thanks,
> Eugene.
>
>
> -----Original Message-----
> From: David McGrew [mailto:mcgrew@xxxxxxxxx]
> Sent: Thursday, March 29, 2007 7:05 AM
> To: Lee Dilkie; Eugene Nechamkin
> Cc: ietf-rtpsec
> Subject: Re: Galois/Counter Mode of Operation in SRTP
>
> Hi Lee and Eugene,
>
> I agree that this is potentially useful.  I've discussed it with a few
> people, and would like to look into it more.  Russ Housley kindly
> offered to sponsor a document (back when he was security AD :-)  I  
> would
> be interested to hear your thoughts on some of the aspects that I've
> been looking into.
>
> Here are some of the pros and cons.  In many software  
> implementations of
> SRTP, HMAC-SHA1 is the single biggest computational cost, because that
> algorithm is relatively slow on shorter packets, while AES CTR has
> performance that is uniform across different packet lengths.  So  
> AES GCM
> could potentially address this performance issue, because it performs
> well as long as a decent amount of memory can be used to
> store some precomputed data that is used in the authentication.
> Applications that have a bit of memory to spare for precomputation can
> benefit from better performance, while applications that don't will  
> have
> a performance that is probably no worse than current
> performance with the SRTP default cryptoalgorithms.   In hardware,
> AES GCM wins hands down (though it is not clear how important hardware
> implementations are, at least in the short term).
>
> One con is that GCM could not be used with an authentication tag  
> length
> of four bytes, as is sometimes done with HMAC-SHA1, because GCM  
> can't be
> truncated.  However, I expect that this is OK, since the SRTP  
> default of
> ten bytes seems to be acceptable in many applications.
>
> There is a minor technical issue with the use of GCM or any other
> AEAD method in SRTP, in the way that the SRTP ROC is authenticated.
> The SRTP authenticated data is formed as
>
> input_to_MAC = rtp_header || encrypted_payload || ROC
>
> ... and the authenticated-but-not encrypted data is split by the
> encrypted_payload.  What we'd want to do is to define the AEAD  
> inputs as
>
>                      plaintext = rtp_payload
> additional_authenticated_data = ROC || rtp_header
>
> Probably this technical point is no big deal.  An easy way to
> accommodate this would be to write a spec defining "how to use AEAD in
> SRTP".
>
> I'd definitely like to get some implementation experience with AES-  
> GCM
> in SRTP, to see how things work out in practice.
>
> best regards,
>
> David
>
> On Mar 29, 2007, at 3:52 AM, Lee Dilkie wrote:
>
>>
>> Not having heard of this before, I read the draft you quoted and I'm
>> intrigued. Looks like a natural fit for a 0-byte overhead SRTP
>> algorithm that includes message integrity without adding a per-packet
>> header.
>>
>> If anybody does have more info, please post to the list.
>>
>> Thanks,
>>
>> Lee Dilkie
>> Mitel
>>
>> Eugene Nechamkin wrote:
>>> Hi all,
>>>
>>> The draft "draft-mcgrew-auth-enc-02" defines the AES-GCM (Galois/
>>> Counter Mode of Operation) cipher for authenticated encryption. For
>>> some voice/video-over-IP applications, this method seems to be a
>>> plausible alternative to the "standard" AES-CM in SRTP. I was
>>> wondering if anybody can point me to such discussions or  
>>> publications
>
>>> on possibility of using the AES-GCM in SRTP.
>>>
>>> Thanks,
>>> Eugene Nechamkin,
>>> Broadcom Corp.
>>>
>>>