[openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

Dr. Stephen Henson steve at openssl.org
Wed Oct 4 10:22:26 UTC 2017


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


More information about the openssl-dev mailing list