Cross-project request... looking for input on a rewrite of Asterisk's res_crypto.c module

[Philip Prindeville]

> On Mar 30, 2022, at 10:25 AM, William Roberts <bill.c.roberts at gmail.com> wrote:
> 
> On Tue, Mar 29, 2022 at 3:40 PM Philip Prindeville
> <philipp_subx at redfish-solutions.com> wrote:
>> 
>> Hi,
>> 
>> I'm trying to develop a newer replacement module for Asterisk's res_crypto that is (for now) 1.1.x compatible but can be easily updated to 3.0 (and maybe even easily add provider support for TPM escrowed secrets, etc).
> 
> Just an FYI to see if you're aware of the tpm2 provider:
> https://github.com/tpm2-software/tpm2-openssl


Yeah, I'm aware of it... I just haven't provisioned a VM with it for testing.


> 
>> 
>> I'm collecting requirements before I get started.
>> 
>> https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=49153311


Hmm... strikes me (after the fact) that you have to be signed into the Wiki to see this page.  Not sure why.


>> 
>> The modules in Asterisk that use res_crypto are:
>> 
>> func/func_aes.c
>> chan/chan_iax2.c
>> pbx/pbx_dundi.c
>> pbx/dundi-parser.c
>> 
>> as well as any independent third-party modules (but I'm not aware of what they might be).
>> 
>> The code is rife with assumptions, such as only AES128 and RSA1024 are to be used, that only AES-EBC chaining is used, and that it's safe to block-cipher with RSA.  Signing digests, RSA padding and AES ciphers are hard-coded.  As are buffer sizes. (So you see why a rewrite is needed...)
>> 
>> This is the tip of the proverbial iceberg.
>> 
>> Anyway, more eyes on the problem are always a good thing.
> 
> Godspeed


Thanks.


> 
>> 
>> Thanks,
>> 
>> -Philip