[openssl-users] openssl commandline client use

[Peter Magnusson]

You would be better off with AES-CCM or such for your backup, that
gives you the integrity check.
 i.e. you would be reasonably sure what you decrypt is encrypted with your key.

So the fist question would be why even consider AES-CBC? Somewhere in
the decision process you ought to go "Is the major goal to support
very strange extremely limited legacy embedded environment where
library developers claims CBC is the only option?" and if no: don't
consider CBC. Since you are using OpenSSL, you clearly does not have
any problem that would give you a compelling reason to use CBC.

Using CBC in anything new design does not make much sense.
- CBC is weak against oracle attacks (online interactions with a
decryption oracle)
- CBC has no protection against modifications. If decryption succeeds,
you don't know if the resulting plaintext originated from

However - Your use-case as explained ( openssl enc -aes-256-cbc -k
mypass > backup.xb.gz.enc ) might not be a use-case where the AES-CBC
vulnerabilities are most dangerous though, if the decryption process
is a slow manual process. E.g. Padding oracle attacks against CBC
requires on average 128 decryption to crack one byte, and need an
online oracle (such as e.g. a backup decryption/restore service) to be
executed. With a human entering the decryption key manually for each
attempt, you'd expect the human to get suspicious with thousands of
decryption requests.  But as soon as you want to automate restore
functions and remove the human, you might enable oracle style attacks.

On Thu, Oct 11, 2018 at 6:45 AM Paul Chubb <paul at kinetic.com.au> wrote:
>
> 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
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users