[openssl-dev] about enc 'magic' data and salt handling

[Tom Francis]

> On Jan 13, 2017, at 6:34 PM, Michel <michel.sales at free.fr> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170113/568563b8/attachment.html>