I have a PHP webapp which encrypts (by AES192-CBC) messages with a random key and a random IV. Everywhere people are saying how amazing are GCM, EAX and authenticated modes (does currently exist safe implementations of them for PHP?), but in my case I just don't need integrity check.

They say auth modes avoid padding oracles (black hat altering ciphertext and analyzing the decryption process) but I'm not sure that my app is vulnerable to that kind of things.

In fact, when asked, the server queries the database and returns the list of decrypted messages (so ciphers aren't directly provided by users). Padding oracles could only happen if the black hat compromises the system (but in this case he could just hijack new requests and storing plaintexts).

Did I totally misunderstood the problem?

  • 1
    Just for clarity, you are storing the ciphertext and the user never provides it to the application? If so, authentication isn't needed. However, I would suggest that you use TLS between the database and the application if they are separate to provide the authentication as the password to the database is sent in the clear otherwise. – user79537 Aug 9 '15 at 17:38
  • app and db aren't separate. user never provides ciphers and encryption keys are generated when user type their password. – Surfer on the fall Aug 9 '15 at 18:40
  • Okay. IMO, authentication is a good idea, but isn't needed in this case. You'll probably get differing opinions, but my opinion is that data at rest doesn't strictly require authentication of the ciphertext, only when it is in transit. – user79537 Aug 9 '15 at 18:44

Padding oracle attacks occur when the attacker is in position to submit encrypted messages and observe the key owner when it tries to decrypt them. The attacker then provides specially crafted messages (based from some piece of the encrypted data that the attacker would love to see decrypted) that decrypt to junk but occasionally decrypt to junk-with-valid-padding; in these cases, the attacker learns some information on the data he is after.

If you are in a context where the defender is a server that computes itself all encryption and decryption, and the encrypted messages cannot be altered by attackers, then the situation explained above does not arise, and padding oracle attacks are irrelevant.

So, in your case, you should be safe from these attacks, provided that indeed malicious people cannot get their hands on your database full of encrypted messages. This raises the question of why you would encrypt the data at all -- normally, you encrypt data to achieve some confidentiality that you could not obtain otherwise. Therefore, encryption on the server makes sense only if attackers are assumed to be able to at least have a look at the database contents. In many situations where attackers can see data, they can also modify the data; and this would bring back the issue of padding oracle attacks, or, more generally, the need for checked integrity.

To put it bluntly, if you encrypt the data but make no effort at maintaining integrity (with a MAC or a nifty authenticated-encryption mode), then you are betting that possible SQL injections attacks on your server will be read-only. It is up to you to decide whether you feel safe enough with that bet.

  • I forgot what is probably the most important detail: in my scheme there isn't a global fixed key to discover hoping the server leaks smthg about it.in fact the client request contain the username and the user-specific encourage key, generated on-the-fly when the user types his pwd. So I think that setting up a padding Oracle on my server requires the attacker to know user pwd, but that means that auth modes are irrelevant at that point. Am I wrong? – Surfer on the fall Aug 10 '15 at 7:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.