Hi all, I've got a series of reviews upstream in Asterisk to build against Openssl 1.1.x and 3.x without OPENSSL_SUPPRESS_DEPRECATED being required, if anyone is curious or wants to track that:
https://gerrit.asterisk.org/c/asterisk/+/18533 https://gerrit.asterisk.org/c/asterisk/+/18525 https://gerrit.asterisk.org/c/asterisk/+/18526 https://gerrit.asterisk.org/c/asterisk/+/18532 https://gerrit.asterisk.org/c/asterisk/+/18534 The review process for non-core developers of Asterisk is a bit slow, so I can't say when they'll get around to merging this... and since it's slated for "master", it will likely only appear in 19.x. A backport to 18.x and 16.x seems unlikely. I did need to add test infrastructure to it to allow running external commands to generate reference test vectors to validate the changes I was making, since certain functionality like OAEP padding in RSA is non-deterministic (there's a random portion of the padding to make asymmetric key encryption be more resistant to pre-imaging attacks), which means that every time you encrypt text, the cipher text will be different (hopefully), and therefore you can't do a bitwise compare against canned strings. This was necessary to ensure that the rewrite from the 1.0.x API (i.e. using SHA1(), RSA_encrypt(), AES_encrypt(), etc.) to instead using the EVP_PKEY and EVP_MD API didn't introduce any regressions. As a result, if we generate RSA encrypted text internally, we validate it by calling "openssl pkeyutl -d ..." to decrypt it, etc. The entire cryptographic suite of Asterisk is a train wreck, from a Best Practices point of view... The use 128-bit AES keys, and ECB, both of which are deprecated... The RSA keys are fixed at 1024 bit, which is also deprecated... and they use RSA for bulk-data encryption, which is never supposed to happen (it's meant for signing or key-exchange, not stream ciphers). I have a proposal for deprecating the current res_crypto resource and replacing it with a redux: https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=49153311 I welcome any comments. Highlights of the proposal are: * supporting stronger AES and RSA key sizes; * deprecating weak block ciphers (like ECB, CBC, etc.) in favor of GCM; * deprecating stream operations with RSA; * adding EC support with NIST curves; * more explicit API's with better sanity checking (e.g. passing input and output buffer lengths); * provider support for keystores like TPM and HSM's; * more test coverage; No idea when I'll get around to doing it... I don't want to sink a lot of time into the effort for naught, if the above relatively simply PR's are going to languish, since this will be a much larger effort and likely more work to get it across the finish line. External enthusiasm for getting this in might speed things along... maybe. Thanks, -Philip _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
