Description
Please note that this is not necessarily an issue with the library. It could be that my understanding of the API is incorrect instead.
I modified the example code in order to set up RTP encryption as AES-128-GCM (I'm using Openssl 1.1.1t) with a 28-byte key, and leaving the RTCP policy unspecified/default.
/*
uint8_t key[30] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D};
*/
uint8_t key[28] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
0x18, 0x19, 0x1A, 0x1B};
//[...]
/*
srtp_crypto_policy_set_rtp_default(&policy.rtp);
srtp_crypto_policy_set_rtcp_default(&policy.rtcp);
*/
srtp_crypto_policy_set_from_profile_for_rtp(&policy.rtp, srtp_profile_aead_aes_128_gcm);
When doing this, srtp_create() returns srtp_err_status_bad_param.
After some investigation, I found that the logic introduced in PR #589 was the reason for this result, because we end up with the following values at the point of the newly added check:
rtp_keylen = 28
rtcp_keylen = 0
input_keylen = 30
I think this is because in this case, the RTCP cipher is effectively left as null, and therefore full_key_length() returns:
SRTP_AES_ICM_128_KEY_LEN_WSALT = 14 + 16 = 30
...which is larger than:
SRTP_AES_GCM_128_KEY_LEN_WSALT = 12 + 16 = 28.
I wonder if the logic could/should be modified in order to take this use case into account? I'm thinking in particular about a scenario where RTP is encrypted but RTCP is not.
Alternatively, is the correct way to use the API to always call both _set_rtp_default() and _set_rtcp_default() as a pair, even for a case where RTCP is not encrypted (in which case, which srtp_profile_t should be passed to _set_rtcp_default()?
Thank you.