Re: [asterisk-dev] Deprecating res_crypto and replacement
On Tue, Mar 29, 2022 at 8:32 PM wrote: > > 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... > If such changes were made to chan_iax2, I do not see that review getting in for quite a long time due to the necessary deep review and understanding of things. Encryption is not something you mess around with, doubly so for an old module that most people don't know the repercussions of with a protocol that has to be relearned. -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Deprecating res_crypto and replacement
On Tue, Mar 29, 2022 at 7:46 PM Philip Prindeville < philipp_s...@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. -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
