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

[Mats Näslund <[e-mail]>]

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.

[e-mail] wrote:
> 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..>>

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).

> 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.

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.

> 
> 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.

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: [phone]



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