[asterisk-dev] Deprecating res_crypto and replacement

[asterisk at phreaknet.org]

On 3/29/2022 7:09 PM, Joshua C. Colp wrote:
> On Tue, Mar 29, 2022 at 7:46 PM Philip Prindeville 
> <philipp_subx at redfish-solutions.com 
> <mailto:philipp_subx at redfish-solutions.com>> wrote:
>
>     Hi,
>
>     I'm working on replacing res_crypto for a variety of reasons. 
>     It's a poor API that's inflexible.  It uses cryptographically
>     deprecated methods and key sizes.  It doesn't support ECC.  It
>     isn't forward compatible with Openssl-3.0.  It doesn't have any
>     test case coverage. etc.
>
>
> My opinion is that a minimum of changes should be done to allow 
> res_crypto to continue to exist. It's not a module that is really used 
> except in legacy things and func_aes. I'm not even sure how much 
> func_aes is used really. The only time res_crypto has really been used 
> is in legacy modules that did their own crypto kind of thing. I don't 
> think updating res_crypto for the sake of it is worthwhile as of this 
> time.
>
>     I've identified that:
>
>     func/func_aes
>     chan/chan_iax2
>     pbx/pbx_dundi
>     pbx/dundi-parser
>
>     use res_crypto.  Is there out-of-tree stuff that requires it as well?
>
>     Anyway, I'm working on the requirements for the replacement here:
>
>     https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=49153311
>
>
> The page is not accessible.
>
>     And feedback is appreciated.
>
>
> Both chan_iax2 and pbx_dundi are effectively in a maintenance mode. 
> The chan_iax2 module sees some changes as a result of community 
> members still using it, but few. The pbx_dundi module never sees 
> changes. I would be extremely hesitant in any changes to them to take 
> advantage of any changes for the sake of it due to the possibility of 
> regressions, and also any protocol changes that would have to occur if 
> they were expanded for more recent cryptography. The func_aes module 
> would be the only thing I could vaguely see using any improvements but 
> there's nothing to say that it couldn't just be changed to not use 
> res_crypto.

Personally, as an active user of chan_iax2 that has submitted 
improvements to it (with no plans to stop using it), better encryption 
than 1024-bit AES would certainly be welcome from my perspective, as an 
end user. The encryption capabilities of chan_iax2 are pretty nice, but 
they could be better.
I brought this up last year and the feeling at the time was that 
res_crypto should be left alone. 2048-bit or 4096-bit support, whether 
by enhancing res_crypto or something else altogether, would certainly be 
"nice", but if Sangoma wants to stay away from that, that might be that...

NA