-
Notifications
You must be signed in to change notification settings - Fork 469
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
base: main
Are you sure you want to change the base?
Conversation
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? |
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. |
@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. |
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 ? |
I'll do it later this month when I am back from vacations |
There was a problem hiding this 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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
backport changes from master
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? |
fixed format and mem leak on deallocating recv sessions on tests |
@bifurcation - Did you ever ger to look at this ? |
Yes, that's what led to this: juberti/cryptex#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
<#511 (comment)>, 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:
***@***.***>
|
When will this be merged? |
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. |
Mainly to be used with WebRTC |
There was a problem hiding this 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 */ |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
for (unsigned char i = hdr->cc; i > 0; --i) | ||
csrcs[i] = csrcs[i - 1]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
{}
around for
blocks, please.
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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
If this gets merged and upstreamed by libwebrtc I will provide a patch for adding support to cryptex in libwebrtc |
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. |
Implementation of cryptex as per https://github.com/juberti/cryptex
Discussion:
juberti/cryptex#5