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

[Matt Caswell]

On 02/10/17 20:20, Robin H. Johnson wrote:
> Commit f8547f62c212837dbf44fb7e2755e5774a59a57b (documented in
> 9e8b6f042749ded556380227c9f2db7ffad9a3aa), changed the default digest
> for the 'enc' utility from MD5 to SHA256.
> 
> While I do strongly encourage getting away from MD5, this has the
> unfortunate side effect of silently breaking existing data.
> 
> An old encrypted file would be generated with MD5 as the digest used on
> the passphrase. Then if you tried to decrypt it on a new version of
> OpenSSL, that defaults to SHA256, you'd get just garbage output.
> 
> This recently bit me when trying to decrypt Amanda backups:
> https://github.com/zmanda/amanda/blob/8136c076757d2e54fa7d4df15f002187823d8787/common-src/amcrypt-ossl.sh#L81
> https://github.com/zmanda/amanda/blob/8136c076757d2e54fa7d4df15f002187823d8787/common-src/amcrypt-ossl-asym.sh#L134
> (yes, I'm aware that the asym variant also passes in -nosalt).
> 
> This happens because there is no metadata that conveys what parameters
> were used during encryption. Unless you happen to know exactly which
> version of OpenSSL was used, and what parameters, you risk getting
> garbage data back.
> 
> This can also happen already when the ciphers are mismatched between
> encryption & decryption.
> 
> The -salt option already sets a precedent for adding a header with the
> salt data, and I'd like to extend that, to improve backwards
> compatibility.

I am in favour of a new output format. In fact a new output format has
been discussed before and I believe there was broad support for the idea:

https://github.com/openssl/openssl/pull/2083

That PR didn't turn into anything, but I'm not sure why.

A new output format will help to stop things getting worse if we change
the format again (which I think we should in order to use PBKDF2 and
more iterations). However it won't help handle the historic issue. If
you attempt to decrypt a file that isn't in the new format, you won't
know whether it was generated by OpenSSL 1.1.0 (and is therefore using
SHA256), or whether it was generated by some earlier version (and is
therefore using MD5).

> 
> 1. Encrypted data should include a header block, that OPTIONALLY
>    specifies each of:
>    - cipher & parameters (e.g. salt, padding)
>    - key derivation function & parameters (MD)
> 1.1. Some users might want to leave the fields empty, to increase
>      security by obscurity.

I think we probably should have an option to not write out the header at
all - but not to "increase security by obscurity". Rather it would be
about having the ability to write out a "raw" encrypted file that could
be consumed by some other tool.


> 1.2. This also opens the path to stronger key derivation (PBKDF2)
> 2. During decryption, if no header block is present, and no message
>    digest was specified, the default digest SHOULD be MD5.

Should it? What about compatibility with OpenSSL 1.1.0? We cannot make
breaking changes in 1.1.1, so it has to be compatible with 1.1.0.

Matt