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

Add support for cryptex #511

Open
wants to merge 18 commits into
base: main
Choose a base branch
from
Open

Add support for cryptex #511

wants to merge 18 commits into from

Conversation

murillo128
Copy link

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

Discussion:
juberti/cryptex#5

srtp/srtp.c Outdated Show resolved Hide resolved
@pabuhler
Copy link
Member

pabuhler commented Nov 9, 2020

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?

srtp/srtp.c Show resolved Hide resolved
srtp/srtp.c Outdated Show resolved Hide resolved
srtp/srtp.c Outdated Show resolved Hide resolved
srtp/srtp.c Outdated Show resolved Hide resolved
@fluffy
Copy link
Member

fluffy commented Dec 27, 2020

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

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

fluffy commented Jul 26, 2021

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

@pabuhler
Copy link
Member

pabuhler commented Aug 9, 2021

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

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

Copy link
Contributor

@paulej paulej left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I appreciate that there is test code to go with the implementation, because I'll admit I didn't check every field to ensure the math is right.

/* Get CSRCs block position or profile if no CSRCs */
uint32_t *csrcs = (uint32_t *)hdr + uint32s_in_rtp_header;
/* Move CSRCS so block is contiguous with extension header block */
for (unsigned char i = hdr->cc; i > 0; --i)
Copy link
Contributor

@paulej paulej Aug 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to do this vs. memcpy() or memmove()? Loops are usually slower, but maybe this doesn't matter.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just thought it would be easier to review the change and check it was spec compliant, I can change it to memcpy or memmove if needed

@murillo128
Copy link
Author

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

fixed format and mem leak on deallocating recv sessions on tests

@fluffy
Copy link
Member

fluffy commented Mar 8, 2022

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

@bifurcation
Copy link
Contributor

bifurcation commented Mar 8, 2022 via email

@hakarim740-com-ra
Copy link

When will this be merged?

@pabuhler
Copy link
Member

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

Mainly to be used with WebRTC

Copy link
Contributor

@bifurcation bifurcation left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would hold on merging this until a few more folks chime in saying they'll use it. Otherwise it's unnecessary complexity.

@@ -333,6 +333,8 @@ typedef struct srtp_policy_t {
int *enc_xtn_hdr; /**< List of header ids to encrypt. */
int enc_xtn_hdr_count; /**< Number of entries in list of header */
/**< ids. */
unsigned int use_cryptex; /**< Encrypt header block and CSRCS with */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this should be int for consistency with other flags, or bool to match the "v3" API.

@@ -149,6 +149,7 @@ typedef struct srtp_stream_ctx_t_ {
int *enc_xtn_hdr;
int enc_xtn_hdr_count;
uint32_t pending_roc;
unsigned int use_cryptex;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same int/bool comment here.

Comment on lines +1755 to +1756
for (unsigned char i = hdr->cc; i > 0; --i)
csrcs[i] = csrcs[i - 1];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{} around for blocks, please.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or even better, memmove.

/* Change profiles by cryptex values */
if (xtn_profile_specific == 0xbede) {
xtn_hdr_profile_and_value = htonl(0xc0de << 16 | xtn_hdr_length);
} else if (xtn_profile_specific == 0x1000) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is incorrect. The low-order bits don't have to be zero.

cf. https://github.com/cisco/libsrtp/blob/main/srtp/srtp.c#L1638

@murillo128
Copy link
Author

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

@pabuhler
Copy link
Member

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.

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

Successfully merging this pull request may close these issues.

None yet

8 participants