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