Subject: RE: [AVT] The Secure Real-time Transport Protocol : Padding/Bandw idth.

From: "Waterhouse, Richard" <[email-masked]>
Date: Tue, 24 Jun 2003 12:40:25 -0400

We don't use SRTP, but we do use AES. We use Counter Mode. This mode doesn't
have "error extension". Thus after we have encrypted the 48 bytes we can
proceed to throw away 8 of them. When it comes time to decrypt the receiver
can just add 8 bytes of padding on the black side, decrypt, and then throw
away the padding bits on the red side. The problem you are pointing out is
not inherent to AES, it's inherent to the mode you are using with AES.

> ----------
> From:
> [email-masked][SMTP:[email-masked]]
> Sent: 	Tuesday, June 24, 2003 12:08 PM
> To: 	[email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: 	[AVT] The Secure Real-time Transport Protocol :
> Padding/Bandwidth.
> 
> 
> Madam and Sirs,
> 
> I am responsible for Cipher/VoIP implementation at Mindspeed (ex
> Conexant).
> 
> I would like to draw your attention about padding:
> draft-ietf-avt-srtp-05.txt - 4.1.1 :
> <<Each of the three terms in the XOR-sum above is padded with as many
> leading zeros as needed to make the operation well-defined..>>
> 
> By implementing block cipher (as AES), as you experts know already,
> we have been facing the padding method consequence (RFC1423, NIST,..)
> leading to increase bandwidth.
> 
> Example:
> G.711 at 5ms generates a payload of 40 bytes.
> AES blocks are made of 128 bits = 16 bytes.
> 40 / 16 = 2.5: AES will require 3 blocks increasing the encrypted payload
> up to 16 x 3 =48 bytes.
> Hence, AES encryption has impacted the original bandwidth consumption by
> +20%.
> This drawback applies to others codec G.729,...which have been designed to
> save bandwidth.
> This bandwidth increase is not acceptable for many Gtw manufacturers.
> 
> Mindspeed would like to submit to you a new scheme that allows encrypting
> packets which size is not a multiple of AES block size without impacting
> bandwidth
> complying with existing modes ECB, CBC,...
> 
> Please, let me know if this new scheme could contribute to SRTP,
> so I will send you related documents.
> 
> Dr Norbert Rossello.
> Group Leader MindSpeed Cipher Development
> [email-masked]
> 
> Mindspeed Technologies
> BP 161
> 06903 Sophia Antipolis Cedex - France
> www.mindspeed.com
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Euchner Martin <[email-masked]>
Date: Tue, 24 Jun 2003 18:39:38 +0200

Dear all,

I'm very confused by this entire SRTP padding discussion.

My understanding of SRTP is that the document describes a stream-cipher using AES in counter and/or F8 mode. As such, SRTP in this byte-stream mode does not need any padding of the payload, as stream-ciphers do not pad typically. (Note: One can use SRTP with AES with the 40 byte G.711/G.729 payload without any message expansion).

Since the SRTP draft ID provides the possibility of using other crypto mechanisms as an extension, padding might be an issue. Since we have not seen any such extension so far, we can't tell, if padding would be an issue nor how padding should be done for any potential future SRTP encryption mechanism.

My recommendation thus, is that SRTP padding issue be deferred to the future and be solved when there is a need for it. For now it should be sufficient to state, that padding issues should be addressed by the extension documents.

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Tuesday, June 24, 2003 6:08 PM
To:	[email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject:	[AVT] The Secure Real-time Transport Protocol : Padding/Bandwidth.

Madam and Sirs,

I am responsible for Cipher/VoIP implementation at Mindspeed (ex Conexant).

Example:

Dr Norbert Rossello.

Mindspeed Technologies
BP 161