<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 8, 2013 at 12:13 PM, Kristian Kielhofner <span dir="ltr"><<a href="mailto:kris@kriskinc.com" target="_blank">kris@kriskinc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">JIRA created:<br>
<br>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-22832" target="_blank">https://issues.asterisk.org/jira/browse/ASTERISK-22832</a><br>
<div class=""><div class="h5"><br>
On Thu, Nov 7, 2013 at 10:17 PM, Kristian Kielhofner <<a href="mailto:kris@kriskinc.com">kris@kriskinc.com</a>> wrote:<br>
> This patch is feature complete and has been tested with a pjsip client<br>
> also supporting AES_GCM_128_8.  I'm waiting for my license agreement<br>
> to be approved before I create an issue with a patch to track this.<br>
><br>
> On Thu, Nov 7, 2013 at 12:23 PM, Kristian Kielhofner <<a href="mailto:kris@kriskinc.com">kris@kriskinc.com</a>> wrote:<br>
>> Hello,<br>
>><br>
>>   I'm working on getting AES-GCM mode supported with SRTP.  Long story<br>
>> short it offers significant performance advantages, especially on<br>
>> systems that support AES-NI.<br>
>><br>
>>   There is a branch of libsrtp that supports AES-NI and AES-GCM via openssl:<br>
>><br>
>> <a href="https://github.com/cisco/libsrtp/tree/feature-openssl" target="_blank">https://github.com/cisco/libsrtp/tree/feature-openssl</a><br>
>><br>
>>   IETF draft:<br>
>><br>
>> <a href="http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-10" target="_blank">http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-10</a><br>
>><br>
>>   I'm currently testing support for AES_GCM_128_8 with pjsip and<br>
>> FreeSWITCH (it works).  I'd love to add Asterisk to this list.  I'm<br>
>> working on a patch (I just can't seem to get chan_sip to prefer<br>
>> AES_GCM_128_8) but in the meantime I thought I'd check with the list<br>
>> to see if there's any interest or work done on this already.<br>
>><br>
>> Thanks!<br>
>><br></div></div></blockquote><div><br></div><div style>The patch looks good for the parsing/understanding of the attribute. Thanks for the contribution!</div><div style><br></div><div style>Unfortunately, Asterisk is a little goofy in that it assumed there were only two tag lengths possible (32 or 80). You can take a look where it parses out the encryption_taglen parameter here in chan_sip:</div>
<div style><br></div><div style><div><span class="" style="white-space:pre">                    </span>} else if (!strcasecmp(v->name, "encryption_taglen")) {</div><div><span class="" style="white-space:pre">                               </span>ast_set2_flag(&peer->flags[2], !strcasecmp(v->value, "32"), SIP_PAGE3_SRTP_TAG_32);</div>
</div></div><div><br></div><div style>You'd probably want to eschew the usage of flags and instead store the tag length value directly on the peer. You'd then have to extract that before calling crypto_get_attrib/ast_sdp_srtp_get_attrib - those should probably be updated to take in an enum value specifying the tag length, as opposed to a binary option.</div>
<div style><br></div><div style>Similarly, res_pjsip would need to get updated to parse out a tag length instead of having a 'use 32 instead of 80' option.</div><div style><br></div><div style>In both cases, some care would have to be taken to ensure that DTLS is also configured correctly - I'm not sure if it can use the AES-GCM option as well.</div>
<div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>