0

I am planning to use Openssl to encrypt our weekly offsite backups using a keyfile (symmetrical encryption) and after some research I found the following GnuPGP command:

base64 -w0 <keyfile.jpg | gpg --symmetric --passphrase-fd -0 backup.tar.gz

However this generates the following error:

gpg: Warning: using insecure memory!
gpg: Fatal: out of core in secure memory while allocating 32800 bytes


Because of that I tried using OpenSSl and have now this command:

pass=$(sha256sum keyfile.jpg | awk {'print $1'})
openssl aes-256-cbc -md sha512 -salt -a -e -in backup.tar.gz -out encrypted.tar.gz.aes -pass pass:$pass
pass=""

Is that considered to be a secure method for file encryption or was GnuPGP the better option?

Anhofer
  • 1
  • 1
    The OpenSSL utility should never be used for encryption that needs to be secure. It is _not_ designed for security, just as a demonstration for the library. – forest Nov 07 '18 at 01:51

2 Answers2

2

Both of these schemes seem a little overly complex. Try to keep it as simple as possible, because if you ever need to actually decrypt these files, you’re probably already having a bad day cause you’re recovering from a disaster.

I’d also encourage you to use asymmetric keys with gpg for a couple of reasons:

  1. Every message (file) gets a new and random symmetric key
  2. 99% of the guidance on the internet about gpg is based on asymmetric keys, so when you’re having that bad day, it’s going to be easier to find help.

You can also encrypt a file for multiple private key recipients with GPG, and it just encrypts the same session key repeatedly using different public keys. This is great for eliminating the “bus factor of 1” on encrypted backup files.

nbering
  • 3,988
  • 1
  • 21
  • 22
  • Oh, and avoid using the openssl cli for this kind of thing. It’s more of an administrative/development tool... not really meant for production-grade encryption use. – nbering Nov 07 '18 at 00:54
  • Disagree with @nbering; there are near innumerable ways to botch cryptography implementation, no matter what the solution. A solution meeting the requirements for one situation may be totally inappropriate for another. Always use careful research and analysis, and find and consult experts when in doubt. Follow advice from high-reputation domain experts. All tools in the chain must be used properly for encryption to be an effective means of privacy. – Jay Taylor Feb 23 '20 at 23:27
  • @JayTaylor I don't disagree with any particular point you make. I summarized my own findings from past research, where I also sought reputable sources. However, I only have so much time to volunteer to write a summary, and the specifics of technical suggestions do change over time. It's entirely possible this post, already almost two years old now, doesn't age well. For the moment, I think it's still a sound strategy, though a lot of specifics may be left out of my description. – nbering Jun 13 '20 at 16:39
2

... [this gpg command] generates the following error: gpg: Warning: using insecure memory! gpg: Fatal: out of core in secure memory while allocating 32800 bytes

You are trying to use too large of a symmetric key. You are base64 encoding a jpg file and using the entire output as your key. So a large file will produce a large key. Instead of base64 encoding the jpg, you could hash the jpg (as you chose to do in the second script you presented) to produce a reasonably-sized key (a key that does not vary in size with the size of the file). But I'm not recommending you do that...

...I tried using OpenSSl and have now this command:

pass=$(sha256sum keyfile.jpg | awk {'print $1'})

openssl aes-256-cbc -md sha512 -salt -a -e -in backup.tar.gz -out encrypted.tar.gz.aes > -pass pass:$pass

pass=""

In this second case, you are SHA256 hashing the jpg file instead of base64 encoding it... This gives you a more reasonably sized key. Regarding the other parameters in your openssl command: You are now using aes256 in CBC mode (aes-256-cbc). CBC mode is not a good choice. It is better to use GCM or CCM mode with AES256.

hft
  • 4,910
  • 17
  • 32
  • Could you elaborate a little on why GCM or CCM are prefereable to CBC with AES256? – user8675309 Nov 08 '18 at 15:00
  • 1
    CBC mode does not provide authentication and so an attacker can modify ciphertext which thereby modifies the plain text (after decryption). In fact, because the blocks are chained together one after another, flipping a bit in one block of cipher text will flip a bit in the same position in the next block of the plaintext. So it's relatively easy to fiddle with values in dangerous ways given some knowledge of the general structure of the encrypted data. – hft Nov 08 '18 at 21:12
  • `openssl enc` does not support any AEAD modes, including GCM and CCM, and since 1.1.0 (in 2016) the man page explains why not. Also (nit) gpg -c uses the input as password not key; it runs it through S2K to get the key (and then uses that as KEK to wrap the DEK, so it can be combined with publickey-encrypted recipients on the same message) – dave_thompson_085 Aug 03 '19 at 16:24