> On Mar 30, 2022, at 10:25 AM, William Roberts <bill.c.robe...@gmail.com>
> wrote:
>
> On Tue, Mar 29, 2022 at 3:40 PM Philip Prindeville
> <philipp_s...@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
