This patch supports AEAD_AES_GCM_128_8 with Asterisk trunk. Tested with pjsip 2.1 with AES-GCM patches applied.

pjsip source here:

https://github.com/krisk84/PJSIP

Well, that's a fairly straight forward patch. I might recommend re-ordering the ast_srtp_suite enumeration to line up with the #defined constants, but that's just a nit-pick. Thanks for the contribution!

Kristian, you'll want to go ahead and get your patch on reviewboard to get more eyeballs on it.

Here is the Code Review process on the wiki which describe the general process and how to use reviewboard.

Update crypto suite names to latest draft (10).

I also created a ReviewBoard entry with the latest patch:

https://reviewboard.asterisk.org/r/3350/

Adds srtp/crypto_kernel.h include to res/res_srtp.c for libsrtp 1.5.0

Attached is trivial patch to res/res_srtp.c to also include srtp/crypto_kernel.h

This is related to Kristian's issue here as the libsrtp version 1.5.0 ( https://github.com/cisco/libsrtp ) has rearranged some of the header files, and crypto_kernel.h is not longer included in srtp.h. Without the patch you see:

  [CC] res_srtp.c -> res_srtp.o
res_srtp.c: In function 'ast_srtp_get_random':
res_srtp.c:307: warning: implicit declaration of function 'crypto_get_random'
  [LD] res_srtp.o -> res_srtp.so

The included patch should be backward compatible, and should apply to all versions of Asterisk.

Using libsrtp version 1.5.0 offers OpenSSL support and it's AES optimizations.

abelbeck, thank you for reporting that issue with crypto_get_random. It got its own issue report. Therefore, please, continue with ASTERISK-24436.

A. Sresnewsky, the attached patch targeted the master branch at that time, which created Asterisk 13. If you are looking for a backport of AES-GCM for Asterisk 11, please, do give a rationale why you cannot update to Asterisk 13 and why you want AES-GCM. That raises motivation and might help to find an Asterisk team member or a community member, to create such a patch.

@all
In December 2015, that draft matured to RFC 7714. However in June 2014 with draft revision 13, the crypto suite AEAD_AES_128_GCM_8 got dropped. Furthermore even back than, there was a bug in libSRTP because the key length (actually the master salt) was too long. This patch here relied on the fact that the key length was the same as for AES_CM_128_HMAC_SHA1_80. This is not the case anymore. Therefore, please, let us continue with ASTERISK-26190.

Kristian, I am closing this report because sRTP supports AES-GCM since Asterisk 14. Your patch was a helpful starting point.

If you want to see this variant of AES-GCM (discussed here in this report) to be implemented as well, please, re-open this issue report. In that case, please, specify which products still require/rely on this AES-GCM draft.