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

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:
> norbert.rossello@mindspeed.com[SMTP:norbert.rossello@mindspeed.com]
> Sent: 	Tuesday, June 24, 2003 12:08 PM
> To: 	mbaugher@cisco.com; rolf.blom@era.ericsson.se;
> elisabetta.carrara@era.ericsson.se; mcgrew@cisco.com;
> mats.naslund@era.ericsson.se; karl.norrman@era.ericsson.se;
> oran@cisco.com; avt@ietf.org
> 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
> norbert.rossello@mindspeed.com
> 
> Mindspeed Technologies
> BP 161
> 06903 Sophia Antipolis Cedex - France
> www.mindspeed.com
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt