[openssl-users] openssl commandline client use

[Paul Chubb]

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 at dukhovni.org>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181011/e5cb9537/attachment.html>