[openssl-users] OpenSSL vs GPG for encrypting files? Security best practices?

Michael Wojcik Michael.Wojcik at microfocus.com
Fri Nov 2 20:08:35 CET 2018


> From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Nicholas Papadonis <nick.papadonis.ml at gmail.com>
> Sent: Friday, November 2, 2018 14:29

> I read

Where? It's hard for us to determine the quality of your source, or your interpretation of it, if we don't know what it is.

> that the OpenSSL AES-CBC CLI mode is prone to a malleable attack vector

I don't know what "malleable attack vector" is supposed to mean in this context. CBC, regardless of the cipher, has certain well-known vulnerabilities. Those probably aren't a concern for most personal file-encryption use cases.

If you have regulatory/legal requirements, then rolling your own data-protection solution, even using presumed-good crypto implementations, is a Bad Idea.

> and [its] CLI interface should not be use directly for production.

I would certainly be leery of doing so. It's not what the openssl utility is primarily intended or designed for.

There are at least two main drawbacks of using the openssl utility in production:

- It primarily exposes primitives, not complete cryptosystems. That means either you're composing those primitives into a complete cryptosystem yourself, which is a process fraught with danger; or you're using an incomplete cryptosystem. In this case, if you use openssl, where is your integrity protection coming from, for example? How are you handling key management, hygiene, and disaster recovery?

- Usability is minimal (for good reason - it's meant as an ad hoc toolkit). There's no error logging or auditing, and minimal diagnostics. Failure modes are pretty much "write an error message and give up".

> I have also read that GPG is the suggested alternative to OpenSSL CLI due to this.  ...
> I am also curious to why GPG, which is an asymmetric key manager,

GPG is an implementation of the OpenPGP standard, plus additional functionality. It's much more than a "key manager".

> is used for file based encryption when only a single key is required. 

GPG supports symmetric encryption. A web search should turn up thousands of pages describing that feature. (Some will be out of date regarding the default cipher and other details; consult the documentation for the current GPG version. I think the default now might be AES-128 CBC, with SHA1 as the MDC, but I haven't checked.)

> How does GPG solve this malleable  attack vector.

Hard to say without knowing what the "malleable attack vector" is.

GPG *is* intended to provide a complete, if rather minimal, cryptosystem for this use case (symmetric encryption of individual files, under a personal-use threat model). For one thing, it (by default) includes an MDC for integrity validation; for another, it provides slightly more sophisticated features for key hygiene.

We don't really know the parameters of your use case, so it's not really possible to make a reasonable recommendation. Do you have regulatory or statutory requirements, or requirements imposed by some other authority (e.g. an employer)? How sensitive is the data? How are you managing your key? What provisions do you need to make for disaster recovery? How are you addressing file integrity? What does your threat model look like?

This is why the simplest approach is to find a complete system that addresses all your requirements. It may not be free, but then neither is your time and energy - you can pay money, or you can pay in opportunity costs and cognitive load. Of course, many people simply ignore the issues and roll their own systems. Often they'll get away with it. Sometimes it will come back to bite them.

-- 
Micahel Wojcik


More information about the Gnupg-users mailing list