AES CBC without Authentication

[andrew2005]

It was raised in attr-encryptor (attr-encrypted/attr_encrypted#144) that they aren't doing message authentication with CBC. There's a pull request in it's underlying encryptor module to fix it (attr-encrypted/encryptor#15).

This is describe in more detail at http://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding-encryption-and-cryptology/2206#2206.

Is this something that symmetric-encryption is exposed to? As far as I can tell, we're using aes-256-cbc by default?

Cheers

[reidmorrison]

When I did the Stanford Cryptography course they covered the risk of using CBC and other common ciphers without some checksum or authentication mechanism. The way I understand it is that the above risk applies when someone can modify the encrypted data, but in such a way that it can still be decrypted and results in corrupt or invalid data being decrypted.

I don't see how this risk applies to where SymmetricEncryption is used. If someone was able to access our databases and modify encrypted data stored there, then they can quite as easily modify or destroy other un-encrypted data in our databases causing even more harm.

The above risk is more applicable to messaging systems were a man-in-the-middle attack can corrupt data or inject modified data without detection.

[andrew2005]

Thanks!

[jjarmoc]

I'm sorry to comment on a closed issue, but I came across this and wanted to clarify one point (as one of the folks originally concerned with attr_encrypted).

If someone was able to access our databases and modify encrypted data stored there, then they can quite as easily modify or destroy other un-encrypted data in our databases causing even more harm.

While it's true that such a high degree of access to the database is already dangerous for other reasons, it seems to me that this is exactly the sort of risk which database encryption is meant to protect against. What an attacker can do with unencrypted data is irrelevant to the purpose of the encryption, which is to prevent reading or tampering with the associated plaintext. Under the threat model we're assuming here (attacker can read and/or write to the database, perhaps through a SQL injection, compromised credentials, etc.) we want encryption to prevent the capability of recovering or manipulating plaintext. Unauthenticated CBC very likely allows both.

If it's not a concern that an attacker with such access to the database can do these things, what purpose is served by encrypting in the first place?

[reidmorrison]

According to the OpenSSL V1.1 change log it contains an experimental implementation of CMAC that is designed to address these requirements.

Once CMAC support has been fully implemented in OpenSSL, it should be as easy as changing the Symmetric Encryption configuration file from:

cipher_name:  aes-256-cbc

To:

cipher_name:  aes-256-cmac

[jjarmoc]

I'm not sure what their plans are for building a full ciphersuite for CMAC, but both GCM and CCM are supported and provide authenticity.

[reidmorrison]

OpenSSL 1.0.1c supports GCM. To use it, create a new key with cipher_name: aes-256-gcm.
To verify if your installation supports GCM, run this in the console first:

require 'openssl'
cipher = OpenSSL::Cipher.new('aes-256-gcm')

# Bad response:   RuntimeError: unsupported cipher algorithm (aes-256-gcm)
# Good response:    #<OpenSSL::Cipher:0x007fc0754764a8>