
Ask HN: Is openssl enc a good choice for file encryption? - caivvoacmh
I recently read a blog post[1] where the author shows how to use openssl to encrypt a file that will be uploaded to an untrusted third-party.<p>The encryption process is as follows:<p># Generate RSA key pair<p><pre><code>  openssl genrsa -out backup_key.priv.pem 4096
  openssl rsa -in backup_key.priv.pem -out backup_key.pub.pem -outform PEM -pubout
</code></pre>
# Encrypt the private key (need to enter a password)<p><pre><code>  openssl enc -aes-256-cbc -in backup_key.priv.pem -out backup_key.priv.pem.enc
  rm backup_key.priv.pem
</code></pre>
# Encrypt backup file<p><pre><code>  openssl rand 64 | tee &gt;(openssl enc -aes-256-cbc -salt -pass stdin -in backup.tar.gz 
  -out backup.tar.gz.enc) | 
  openssl rsautl -encrypt -pubin -inkey backup_key.pub.pem -out backup.tar.gz-aeskey.enc
</code></pre>
I&#x27;m not a cryptographer, but knowing that openssl has suffered from numerous vulnerabilities I decided to google `openssl enc` to get a sense of its security. After reading:<p>&quot;if you use `openssl enc`, make sure your password has high entropy&quot;[2]<p>&quot;it looks like openssl enc is still using a very weak KDF&quot;[3]<p>&quot;The commandline utilities in general are fairly minimal wrappers around functionality in libssl and libcrypto, and if you want something complete, polished, convenient, etc. the idea is you should either modify or replace them&quot;[4]<p>I&#x27;m left wondering if using openssl for file encryption is a good choice if security is paramount.<p>Can crypto experts please comment. Thanks in advance.<p>[1]: https:&#x2F;&#x2F;summitroute.com&#x2F;blog&#x2F;2016&#x2F;12&#x2F;25&#x2F;creating_disaster_recovery_backups&#x2F;<p>[2]: https:&#x2F;&#x2F;security.stackexchange.com&#x2F;a&#x2F;29139<p>[3]: https:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;29106&#x2F;openssl-recover-key-and-iv-by-passphrase#comment202222_29139<p>[4]: https:&#x2F;&#x2F;security.stackexchange.com&#x2F;a&#x2F;129067
======
Canada
One problem is there's no authentication. The malicious server could modify
your backup.

Another scary thing about this is the fact that you have to keep track of the
AES key for the backup as well as your private RSA key and its password.
That's going to get nasty for more than a couple of files.

If you're going to do backups like this you're better off just sticking with
GPG.

~~~
matt_wulfeck
Yes Canada is right. Asymmetrical encryption is what you want. You can bake
the signature into all of your hosts that need it, that way they encrypt a
file without needing to know how to decrypt it.

Ask your third-party to supply a gpg public key over a secure channel, then
it's very to encrypt files for them (and only them) to read.

~~~
bwackwat
He is uploading files to an UNTRUSTED third party.

I'm personally curious about the best solution...

@Canada, if the "malicious"(untrusted?) server modifies the backup how could
you decrypt anyway?

~~~
Canada
CBC mode is malleable. I can modify a block and the previous blocks won't be
corrupted. The blocks I modify will silently decrypt, although I won't know
what the output will be. Regardless, the decrypted output may still do
something harmful.

The solution is to generate a hash or a MAC after encrypting. A plain hash
would have to be kept locally because the malicious server could modify it if
stored there. A MAC could be stored on the server, but then it would be
necessary to derive another key for that and store it locally. (Or store the
input for deriving the encryption key and MAC key... in any case, annoying)

GPG takes care of all this for you. Bottom line: Avoid OpenSSL command line
for this kind of thing.

~~~
caivvoacmh
Do I follow correctly that the issue with using `openssl enc` is the cipher
`aes-256-cbc` not providing integrity of the encrypted file?

Even if you wanted to use a more secure cipher according to
[this]([https://security.stackexchange.com/questions/128883/basic-
qu...](https://security.stackexchange.com/questions/128883/basic-question-
regarding-openssl-and-aes-gcm)) `openssl enc` does __not __support the more
secure ciphers that openssl tls does.

Is this the reason to avoid openssl for file encryption?

~~~
Canada
TLS and AES-CBC aren't comparable.

AES-CBC is just a block cipher mode of operation. TLS is a protocol that takes
care of negotiating algorithms for key exchange, bulk encryption (which may be
a block cipher using some mode), authentication, etc. All of these things
combined is the "suite" of ciphers. Implementations provide decent tooling for
managing keys and preferences.

Like TLS, GPG uses a suite of ciphers to do its job and provides tools to
manage it without getting caught up in extremely low level details. Like TLS,
the default suite of algorithms it prefers change with the times, but from a
user perspective it stays the same.

~~~
scottpiper
I'm the author of the blog post in question (and have no idea why HN won't let
me reply to the original post). For some clarity here, the "untrusted" third
party is Google, whom I don't want to read my data, but I trust that they will
not modify my backups. However, in the article I do gzip the files before
encrypting them, and gzip has a CRC-32 check, so if the files were modified,
then after decryption when you attempted to gunzip them, it would error.

I used openssl because I find GPG on servers is awkward to use.

The full article is more clear that I have only one private key, and for all
the nightly backups I'm generating AES keys and encrypting them with the
public key.

~~~
Canada
I don't know why HN disallows reply in certain circumstances. If you replied
to the original post I never would have seen your reply.

If you don't care if the third party can modify your data, then OK. If you did
care though, does this checksum stop "tar xvzf foo.tgz" from writing modified
data immediately? Or does it just tell you at the end?

~~~
scottpiper
Probably just at the end. My goal is disaster recovery (AWS disappears as a
service to the world because an Amazon employee accidentally `rm -rf`
everything, or my own admin `rm -rf`'s my account on accident) so for those
situations, I'm going to need to extract out the data somewhere and then
rebuild, so checking at the end of the extraction and unzip is fine for my
needs.

------
bwackwat
Use AES 256 bit encryption. It looks like you found some openssl command line
tools to do this, which appears fine. (I can't speak on the details of that
particular tool.) Depending on your technology stack, there are probably a
number of tools which can programmatically encrypt and decrypt files.

For example, I use CryptoPP for AES 256 bit encryption in C++.

