Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please add a "non inplace" protect and unprotect API #569

Closed
Tracked by #669
ydroneaud opened this issue Sep 27, 2021 · 13 comments
Closed
Tracked by #669

Please add a "non inplace" protect and unprotect API #569

ydroneaud opened this issue Sep 27, 2021 · 13 comments
Milestone

Comments

@ydroneaud
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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

@paulej
Copy link
Contributor

paulej commented Sep 27, 2021

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
Copy link
Contributor

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
Copy link
Contributor

paulej commented Sep 27, 2021

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

paulej commented Sep 28, 2021

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
Copy link
Contributor

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
Copy link
Contributor

paulej commented Sep 28, 2021

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
Copy link

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

@pabuhler
Copy link
Member

This is now supported

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants