On 11/10/18 09:47, Peter Magnusson wrote:
> 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.
I'd just point out that CCM and other AEAD modes are not supported in
the openssl enc app.
Matt
>
> 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 <p...@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-us...@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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
