On Wed, Oct 04, 2017, Matt Caswell wrote: > > As Tomas said - that ship has sailed. In my mind that change was a > mistake. It could have been done in a non-breaking way by introducing a > new header format at that time. >
As regards a new header format. In the case of some of the structures we use there is an appropriate password based encryption ASN.1 AlgorithmIdentifier. The code to encode and decode that format is already in OpenSSL and it is documented in various standards. It is currently used for private key encryption (via PKCS#8) and PKCS#7 EncryptedData format (used by PKCS#12). One of several advantages of using that form is that any new forms we want to support just need to be a new password based encryption algorithm and "enc" handles it automatically. So we'd get scrypt, PBKDF2 and all the older PKCS#12 algorithms automatically. We wouldn't be able to use the current non-standard password based encrytion algorithm without defining our own OID but I can't see why we'd want to use that when much better alternatives are available. In fact if we were feeling particularly adventurous we could output a CMS or PKCS#7 EncryptedData ContentInfo in the enc utility. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
