libSRTP comes with a build-in crypto backend. That is deprecated for several years already. However, the script configure did not change. The libSRTP supports several external crypto backend by now (NSS, mbed TLS, …), but OpenSSL is the one maintained by its core developers, see https://github.com/cisco/libsrtp/issues/579 for details. Those enable beside the existing AES-CBC also AES-GCM as crypto suites. And leverage AES-NI as a side-effect.
I do not have a full blow toolchain running right now, because I come from a down-down-down-stream project. Therefore, I cannot provide a complete Pull Request. However, I think a CONFIGURE_ARGS += --enable-openssl in the Makefile does the trick for OpenWrt. Digium Asterisk and Teluu PJProject are well tested in that scenario—in PJProject, this the default with its internal libSRTP (see SRTP_OTHER_CFLAGS)—and therefore should not raise any unknown issues.
libSRTP comes with a build-in crypto backend. That is deprecated for several years already. However, the script configure did not change. The libSRTP supports several external crypto backend by now (NSS, mbed TLS, …), but OpenSSL is the one maintained by its core developers, see https://github.com/cisco/libsrtp/issues/579 for details. Those enable beside the existing AES-CBC also AES-GCM as crypto suites. And leverage AES-NI as a side-effect.
I do not have a full blow toolchain running right now, because I come from a down-down-down-stream project. Therefore, I cannot provide a complete Pull Request. However, I think a
CONFIGURE_ARGS += --enable-openssl
in the Makefile does the trick for OpenWrt. Digium Asterisk and Teluu PJProject are well tested in that scenario—in PJProject, this the default with its internal libSRTP (seeSRTP_OTHER_CFLAGS
)—and therefore should not raise any unknown issues.