Subject: [AVT] The Secure Real-time Transport Protocol : Padding/Bandwidth.

From: [email-masked]
Date: Tue, 24 Jun 2003 18:08:18 +0200

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

---

From: Mats Näslund <[email-masked]>
Date: Tue, 24 Jun 2003 19:15:31 +0200

Dear Dr Rosello,

I suspect that you have misread the spec, possibly caused
by some unclarity on our behalf, in which case I apologize.
More below.

> leading zeros as needed to make the operation well-defined..>>

Note that this does not produce padding of the cipher *output*,
it is a padding of the cipher *input*. Hence, there is no impact
on bandwidth at all (more below).

> This bandwidth increase is not acceptable for many Gtw manufacturers.

If you use SRTP with the default counter mode transform, here is what
will happen:

Let the codec output be denoted m (40 bytes).

1. Form the input to the cipher according to the text you copied above
    from Sect 4.1.1. Denote this (possibly padded) value by IV
    (which will always be 128 bits/16 bytes).

2. Run AES on the session key and the above input, IV, producing
    a 128 bit output which I denote s0.

3. Run AES again on IV+1, IV+2,... producing s1, s2... until at
    least 40 bytes of output has been obtained, denote this total
    output s = s0 || s1 || ,,, (i.e. size(s) >= 40 bytes).

4. Take the XOR of m and the **40 first bytes** of s, producing the
    ciphered output y (which has the same size as m, 40 bytes).
    (Disgard excess bytes of s.)

5. Transmit y.

On the receiver side, excactly the same procedure takes place,
only that "y" takes the place of "m", resulting in retrieving m
back.

> so I will send you related documents.

Since SRTP is very close to passing IESG review (I hope...) I think
adding another mode at this late stage would be highly undesireable.

Moreover, I don't see the need for it as there is no extra bandwidth
consumption implied by the already pre-defined transforms.

Best,

/Mats

----------------------------------------------
Mats Näslund, PhD, Senior Specialist
Communications Security Lab, Ericsson Research
SE-16480 Stockholm, Sweden
Visiting adr: Torshamnsgatan 23, Kista
Phone/Fax: (+46 8) 58533739/4047020