about enc 'magic' data and salt handling

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

about enc 'magic' data and salt handling

Michel

Hi,

 

FWIW, just sharing my opinion :

 

Thanks to the team, OpenSSL comes with lots of powerful tools.

They are not always easy to use, but some have no equivalent and are very helpful to test, debug, experiment, learn … all things that looks to me as their primary interest.

Among them is the 'enc' command.

I would like it to be as usefull as other tools but was a little disappointed at first, not only because it lacks some important feature (iteration count, standard KDF, ...) but above all because of the way the salt is handled.

 

I believe it is better to be consistent about the use of the command : if a salt was given to encrypt, it should be given to decrypt (as would be the case for the iv if PBKDF2 is supported).

If we agree on that, the salt would be stored with the encrypted data, *ONLY* when it was generated on the fly.

It will allow us not only to decrypt the data with the right key and iv (not currently possible), but also use OpenSSL to decrypt raw data encrypted by other software(s) using the original password.

 

I was able to work around all that but I now feel that next step will probably be to add some more 'magic' (unfortunately not from Pixar/Disney :-).

I have the conviction it would be better NOT to enforce the proprietary nature of the file.

For example a companion file (same name, different extension) can be use instead.

As I understand there is lot of implications beyond my scope and that allowing to work with external raw data, is not necessarily the main concern of other people, it could be easier,

depending what will be implemented, to just have a new parameter (or another command tool ?) able to separate raw encrypted data from all the new 'magic' (kind of import/export).

 

Regards,

 

Michel.


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: about enc 'magic' data and salt handling

Tom Francis-2

On Jan 13, 2017, at 6:34 PM, Michel <[hidden email]> wrote:

Hi,

 

FWIW, just sharing my opinion :

 

Thanks to the team, OpenSSL comes with lots of powerful tools.

They are not always easy to use, but some have no equivalent and are very helpful to test, debug, experiment, learn … all things that looks to me as their primary interest.

Among them is the 'enc' command.

I would like it to be as usefull as other tools but was a little disappointed at first, not only because it lacks some important feature (iteration count, standard KDF, ...) but above all because of the way the salt is handled.

 

I believe it is better to be consistent about the use of the command : if a salt was given to encrypt, it should be given to decrypt (as would be the case for the iv if PBKDF2 is supported).

If we agree on that, the salt would be stored with the encrypted data, *ONLY* when it was generated on the fly.

It will allow us not only to decrypt the data with the right key and iv (not currently possible), but also use OpenSSL to decrypt raw data encrypted by other software(s) using the original password.

 

I was able to work around all that but I now feel that next step will probably be to add some more 'magic' (unfortunately not from Pixar/Disney :-).

I have the conviction it would be better NOT to enforce the proprietary nature of the file.

For example a companion file (same name, different extension) can be use instead.

As I understand there is lot of implications beyond my scope and that allowing to work with external raw data, is not necessarily the main concern of other people, it could be easier,

depending what will be implemented, to just have a new parameter (or another command tool ?) able to separate raw encrypted data from all the new 'magic' (kind of import/export).

 

Regards,

 

Michel.


The enc command is really just an example, IMO. If you want something that's useful for production purposes (and even follows standards!), I recommend looking at the cms command. It'll encrypt, decrypt, sign (and verify signatures) data in a standards-based format. It's not the easiest thing to use, but it's better to focus on something like that, rather than a proprietary format that was never really intended for real data exchange.

TOM


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: about enc 'magic' data and salt handling

Michel
> If you want something that's useful for production purposes (and even follows standards!),
> I recommend looking at the cms command.

Yes, thanks for pointing out that to me.
However I believe that for production purposes I would even prefer using gpg (thanks to M. Zimmermann).

Regards,

Michel.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: about enc 'magic' data and salt handling

Viktor Dukhovni
In reply to this post by Tom Francis-2

> On Jan 13, 2017, at 7:50 PM, Tom Francis <[hidden email]> wrote:
>
>
> The enc command is really just an example, IMO. If you want something that's useful for production purposes (and even follows standards!), I recommend looking at the cms command. It'll encrypt, decrypt, sign (and verify signatures) data in a standards-based format. It's not the easiest thing to use, but it's better to focus on something like that, rather than a proprietary format that was never really intended for real data exchange.

While CMS is indeed often the more appropriate tool, it has a drawback
for streaming data.  Only the write side can stream.  CMS readers must
hold the entire decrypted object in memory.  For this reason, I've
sometimes used enc(1) with the symmetric random encryption key protected
to a public key, and a separate signed MAC computed over the whole stream.

Otherwise, indeed enc(1) is often more useful for raw symmetric operations
when doing troubleshoots.

--
        Viktor.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev