Hi thanks for the responses. I try not to do crypto for the very reasons you raise - i simply don't know enough and your (good) pointed questions have demonstrated that.
Context:
We are trying for GDPR and other privacy law compliance. We probably need to meet GDPR, US requirements, Australian requirements, Japanese requirements and UK requirements. The data is not hugely critical. It contains names and exercise metrics. It doesn't contain credit card details or anything above the level of names. I don't think it contains addresses but probably does contain names of recognizable organisations which could provide a tuple for identification purposes if the data was compromised.
A mysqldump of the db in production at present is around 170Gb however that is text based and we are using a binary solution based on percola xtrabackup so the final size should be smaller for the current time. The documentation on this by the backup software provider is very simplistic and simply pipes the stream of data through openssl and then gzip:
mariabackup --user=root --backup --stream=xbstream | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.gz.enc
There are thousands of posts that do similar and in non-crypto circles it is the accepted way of doing things. That was my starting point.
I am not using a password but generating keys. The symetric key is generated by "openssl rand -hex 32" which I have read is suitable. The Nonce or IV is generated by "openssl rand -hex 16". These values are used once and then kept for decryption of that file. They in turn are encrypted before storing - see below.
The two keys are held in ram while the backup occurs. They are applied to openssl using the -K and -iv switches. They are then written out to disk. encrypted with a list of public RSA keys and the original deleted from disk. I then package it all up and delete the intervening encrypted files leaving me with an archive with the encrypted backup and several copies of the nonce and key each encrypted by different people's public keys.
The backup regime has not been decided as yet. I expect it will be something like a full backup per week and then either incrementals or differentials on the other days. I expect that the fulls will be kept for 30 days and the deltas for 14days. The database backups will sit on a secured server disk which in turn will be backed up by the hosting provider with whatever process and rotation they use.
I would expect that headers in the backup stream would be predictable, whether they provide a good enough attack surface I don't know. In addition the clients of course know their data that may also provide an attack surface. Finally I have included an encrypted file with a known plain text phrase. Based on your comments, this will probably not get into production but provides an easy way for testing and debugging to check that things are encrypted or not.
The kind of statements that prompted my question was: https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup whose comments suggest that openssl should never be used for production purposes.Their suggestion was GnuPG which isn't suitable for this purpose because it does password/key management that assumes a desktop/laptop environment and manual process. I also looked at ccrypt and mcrypt but then went back to openssl.
Cheers Paul
On Thu, Oct 11, 2018 at 2:12 PM Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote:
On Thu, Oct 11, 2018 at 01:23:41AM +0000, Michael Wojcik wrote:
> - Data recovery from an encrypted backup is tough. With CBC, one bit goes
> astray and you've lost everything after that.
No, a 1 bit error in CBC ciphertext breaks only the current block,
and introduces a 1 bit error into the plaintext of the next block.
After that, you're back in sync.
But yes, indeed "openssl enc" offers little integrity protection.
One should probably break the data into chunks and encrypt and MAC
each chunk with the MAC covering the chunk sequence number, and
whether it is the last chunk.
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
