Bug#996978: libsrtp2-1: OpenSSL

Alexander Traud pabstraud at compuserve.com
Mon Oct 25 12:06:00 BST 2021


> the only real use back then [...] was for a random number function

Sounds like I should have raised this before. libSRTP required a crypto library to support AES-GCM based crypto suites [1]. Actually, I use those suites via Digium Asterisk: <https://issues.asterisk.org/jira/browse/ASTERISK-26190>. For that library, Cisco, the maintainer of libSRTP, chose OpenSSL.

The random number generator was another story: The libSRTP team stopped to support an internal generator and expects the application developer to supply its own. Anything can be used, like [0].

Recently, as crypto libraries, users of libSRTP added mbed TLS [2] and NSS [3]. OpenSSL was the primary library. Consequently, two packages, a non-linked, and an OpenSSL-linked would have been great. Now, with the addition of NSS, a third package, an NSS-linked could have been added.

> Do you see a concrete use for alternate TLS engine linkage?

1. OpenSSL is the primary library for libSRTP.

2. The project I am using libSRTP with, Digium Asterisk, is based on OpenSSL. It is wired to use two different crypto libraries.

3. I have to re-test my VoIP/SIP phones, which use AES-GCM, whether everything works, especially because the Cisco implementation is probably using OpenSSL internally.

4. The crypto library is not only about AES-GCM but also changes AES-ICM. Consequently, I have to test not only AES-GCM but all implementations.

5. In libSRTP, a crypto library adds not only AES-GCM but also AES-NI. I have to double-check whether the other crypto libraries actually leverage AES-NI.

None of those points are hard requirements:
to 1. primary does not mean better maintained
to 2. not aware of any issue mixing libraries except more memory
to 3. to avoid that, there is that test suite in libSRTP, which the "others" passed successfully
to 4. same as 3
to 5. the "others" are mature libraries and AES-NI is nothing new

So, yes, there is no hard requirement, at least for me. Perhaps someone else has a hard requirement and tells us. If you close this wish, he has to create a new wish, correct?

[0] <https://gist.github.com/kernigh/d169895a700c6511d08511c005a28d88>
[1] <https://github.com/cisco/libsrtp/pull/34>
[2] <https://github.com/cisco/libsrtp/pull/512>
[3] <https://github.com/cisco/libsrtp/pull/413>



More information about the Pkg-voip-maintainers mailing list