Please add a "non inplace" protect and unprotect API

[ydroneaud]

In my use case, due to the inplace protect/unprotect API, RTP/RTCP packets have to be duplicated before being protected/unprotected.

I believe some memory bandwidth could be saved if libsrtp exposed an API that doesn't process data inplace.

I would imagine the API would be used this way

int send(const void *pkt, size_t pkt)
{
...
    srtp_protect2(ctx, rtp, rtplen, srtp, &srtpsize)
...
}

int receive(const void *pkt, size_t pkt)
{
...
    srtp_unprotect2(ctx, srtp, srtplen, rtp, &rtpsize)
...
}

[bifurcation]

If protect/unprotect were not in-place, wouldn't there just be a copy going on internal to the protect/unprotect call instead of at the application layer?

[ydroneaud]

If protect/unprotect were not in-place, wouldn't there just be a copy going on internal to the protect/unprotect call instead of at the application layer?

It depends on the underliyng crypto primitive implementation.

[bifurcation]

Fair point. You would at least have to copy the header over, since that's not touched by the crypto.

[paulej]

You want libsrtp to allocate memory and copy the packet data? That strikes me as less desirable than doing that in your code since you could, at the very least, create a static buffer to avoid reallocating memory repeatedly.

[bifurcation]

No, I think the request is to allow the application to provide separate input and output buffers. So the application would continue to own the memory.

[paulej]

OK. Then how is that different from:

memcpy(srtp_buffer, input_buffer, sizeof(input_buffer));
srtp_protect(srtp_buffer);

Just the desire of libsrtp to do the memcpy?

[bifurcation]

No, the point is that you can do encryption without any memcpy. Consider the following cases:

void xor(uint8_t *dst, const uint8_t *srcA, const uint8_t *srcB, size_t len) {
    for (size_t i = 0; i < len; i++) {
        dst[i] ^= srcA[i] ^ srcB[i];
    }
}

uint8_t plaintext[BUFFER_SIZE];
uint8_t ciphertext[BUFFER_SIZE];
uint8_t key[BUFFER_SIZE];

// CASE 1: today
xor(plaintext, plaintext, key, BUFFER_SIZE);

// CASE 2: today, with memcpy
memcpy(ciphertext, plaintext, BUFFER_SIZE);
xor(ciphertext, ciphertext, key, BUFFER_SIZE);

// CASE 3: proposed
xor(ciphertext, plaintext, key, BUFFER_SIZE);

When doing an out-of-place encryption, case 3 seems pretty clearly more efficient than case 2. In case 3, you only write once to each memory location in ciphertext; in case 2, you write twice.

[bifurcation]

All that said, this would be a pretty invasive change. We would need to plumb this all the way through from the SRTP-level interface to the low-level crypto interfaces. We could probably minimize the pain by having the in-place SRTP protect call through to an out-of-place version, so that at least we would have one behavior throughout the srtp.c and the cipher APIs. And if it's important for the crypto library to know that whether the encryption is in-place, then you could detect with in == out further down the stack.

@ydroneaud have you done any experimentation to measure the potential benefit here? Even a quick experiment comparing in-place to out-of-place would be helpful in justifying this. You could probably modify the timing tests in cipher_driver.c to get a rough idea; just change add an output buffer to this method and add a memcpy before the encrypt call.

[paulej]

Yeah, SRTP's AES implementation will use the plaintext input as the state table array and operate on it in-place. So, I guess that's the issue here? It would be trivial enough to copy that before operating on it, but either way it results in a copy. I'm not sure that we'd be saving any copying at the end of the day. The state table must get loaded and then the output stored. Using that input as the state table saves that copy. (I'm guessing it's not much savings, honestly. It would be interesting to measure. I think most of the computation is going to be related to sbox lookup, column mixing, etc.

Anyway, perhaps I'm still missing the point, but I assume the ask is for srtp_aes_encrypt(), for example, to first copy the input block and then output that once all the operations are complete into a separate output buffer.

[bifurcation]

Perhaps more to the point (since I expect the internal AES-CTR impl doesn't get much use), the OpenSSL implementation of AES-CTR does exactly case 3 in my taxonomy above:

*(out++) = *(in++) ^ ecount_buf[n];

It would be a trivial change for the internal impl to work this way, assuming the API passed in separate input and output buffers. You would just change this line to the above form instead of using ^=.

So if we had an out-of-place API, there would be no memcpy except for the headers, as noted.

[paulej]

Yeah, something like that'll work. I had my head one-level down further in the AES code itself. That doesn't matter: this code matters.

[munishbansal2000]

Hello, I also have the same request. Has there been any progress on this suggestion?