Add support for cryptex

[murillo128]

Implementation of cryptex as per https://github.com/juberti/cryptex

Discussion: https://github.com/juberti/cryptex/issues/5

[pabuhler]

hi, it would be good to get the CI build passing as soon as possible, are you able to fix that or doe you need some help?

[fluffy]

Great to have this on a branch but I would like to see the IETF draft to get further along before we merge it to the main branch.

[murillo128]

@fluffy I agree. My main intent was to get feedback on the changes and spot any issue on the implementation that could impact the spec.

Would be great if it could be thoroughly reviewed so we can confirm that the test vectors can be incorporated into the rfc and be ready to merge the branch as soon as the rfc is ready.

[fluffy]

Given the IETF draft is about at WGLC, we should merge this in once we are happy with the tests.

[pabuhler]

Given the IETF draft is about at WGLC, we should merge this in once we are happy with the tests.

@murillo128 are you able to fix the compile issues? Maybe rebase on master as well?

@paulej have you thought to review these changes ?

[murillo128]

I'll do it later this month when I am back from vacations

[murillo128]

I have also rebased to master and fixed the CI errors of the previous version. Could anyone run the github workflows to check if everything is correct now?

[murillo128]

fixed format and mem leak on deallocating recv sessions on tests

[fluffy]

@bifurcation - Did you ever ger to look at this ?

[bifurcation]

Yes, that's what led to this: https://github.com/juberti/cryptex/issues/31

On Mon, Mar 7, 2022 at 7:19 PM Cullen Jennings @.***> wrote:

@bifurcation https://github.com/bifurcation - Did you ever ger to look at this ?

— Reply to this email directly, view it on GitHub https://github.com/cisco/libsrtp/pull/511#issuecomment-1061275162, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAASOTKHLJ6J64N74CA52CDU62MJVANCNFSM4TL45Z7A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[hakarim740-com-ra]

When will this be merged?

[pabuhler]

hmm, I see this made it to an RFC now, https://datatracker.ietf.org/doc/html/rfc9335 , this was not the case when this code was committed or originally reviewed. I am unsure if the current implementation follows the RFC or not, would need some input from @murillo128 on that. Either way this code needs to be updated before it can be merge. Do you have a use for this code?

[hakarim740-com-ra]

Mainly to be used with WebRTC

[murillo128]

If this gets merged and upstreamed by libwebrtc I will provide a patch for adding support to cryptex in libwebrtc

[pabuhler]

ok, I can update it to work on top of the v3 work if you like, it will give me a chance to better review the code.

[murillo128]

i have rebased the PR and addressed the comments. could we run the tests? not completly sure I did everything correctly

[JonathanLennox]

If you want to test interop, once you have the WebRTC patch, Jitsi Meet's Videobridge supports cryptex, and I should be able to configure an instance to negotiate it in our WebRTC client.

[pabuhler]

@murillo128 I have created a new PR #724 , that tries to merge your changes in to main. It takes a slightly different approach given the non in-place io support that is in main now. With the new API the input buffer is always const, this means that modifying it in-place to create a continues memory block to encrypt is maybe not feasible. The new code will encrypt the csrc list first before encrypting the header extensions and payload in one block. The code also does not currently support encrypting csrc's in gcm mode as today in gcm mode there can only be one call to encrypt. So something needs to change if cryptex is to be supported. The two options I see are:

1. Add support to call encrypt/decrypt multiple times in gcm mode, I think most backends can support this.
2. Change the input buffers from const to non const.

If option 1 is done then it could still be possible to modify the input to supportone call to encrypt when it is detected that this is in-place io. I prefer not to remove the const from the input buffers but it is something that could be discussed. I am not sure of the performance penalty of call encrypt twice, it would probably depend alot on the backend.

[murillo128]

@pabuhler thank you very much for taking the time to work on this!

Removing the const is not my preferred option too, would be great if the gcm apis could be updated to allow multiple calls.

On my experience, some backends (expecially OpenSSL 3.0) have a huge overhead when making multiple calls to the api, but we are already having that performance issue anyway: https://github.com/cisco/libsrtp/issues/645

[pabuhler]

@pabuhler thank you very much for taking the time to work on this!

Removing the const is not my preferred option too, would be great if the gcm apis could be updated to allow multiple calls.

On my experience, some backends (expecially OpenSSL 3.0) have a huge overhead when making multiple calls to the api, but we are already having that performance issue anyway: #645

OK, I will tryout gcm api supporting multiple calls to verify that it is possible. Then at least cryptex can be "functionaly" complete and can look at optimizations afterwards. It is not sure that the performance problems in #645 will be such and issue when making multiple calls to openssl if IV has not changed but time will tell.

[pabuhler]

I managed to get it to fully work with gcm and openssl, cryptex in this mode also requires multiple calls to srtp_cipher_set_aad but it seamed to work. Will look into the other backends.