[dandraper]

It's a good idea. CBC without verification is vulnerable as well. An attacker can modify the IV and the value will still decrypt. It's quite easy to change a what plaintext will pop out the other side and the client will be none-the-wiser.

Depends on what kinds of data you're encrypting but if its anything to do with money or health data authenticity is a must.

[zigzag312]

So, when using CBC without verification, attacker with an access to DB won't be able to see original plaintext, but will be able to change the data?

But how can attacker control what plaintext will become, if he doesn't have a key? Wouldn't he be limited to either a random value or a value from another field?

Since IV is constant. It doesn't need to be stored in DB and can be treated like a key. So, attacker (with an access to DB) can't change IV for a server app reading from the DB.

[CodesInChaos]

An attacker who has write access to the database and gets feedback if a decryption was successful can still mount the standard padding oracle against CBC, because the first block acts as IV for the second block.

[zigzag312]

Thanks. So, AES-CBC + HMAC would prevent this, but AES-CBC does not.

How do the following methods compare when using constant IV?

AES-CBC + HMAC (encrypt then MAC) vs AES-GCM-SIV vs AES-SIV

[some_furry]

Be careful how you combine these components: https://soatok.blog/2021/07/30/canonicalization-attacks-agai...

(The linked article talks about CTR + HMAC, but CBC + HMAC is also affected.)