[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