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

[Nicholas Papadonis]

comments
On Fri, Nov 2, 2018 at 3:09 PM Michael Wojcik <Michael.Wojcik at microfocus.com>
wrote:

> > 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.
>
>
On stackexchange

https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup


> > 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?
>
No regulatory requirements.  I'm a personal user making sure to take best
practices into account for securing data.  I also have the assumption that
there are numerous attack vectors in involved in storing computer data, all
the way back to the design and manufacturing process.  I.e. you need to
design, manufacture and test your own computer to be truly secure.

I want to keep at least two copies of data in different locations for
disaster recovery.  Each copy itself should have a backup stored with it in
case of a bit error.

>
> 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.
>
> Thanks Micahel!

Nicholas

> --
> Micahel Wojcik
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181103/d8caff0f/attachment-0001.html>