Comment 6 for bug 1175367

You're right about embargoing the fix. The security notice looks good other than that it may be worth noting that a mitm attacker can also carry out the same attacks.

> An attacker have access to memcache can corrupt data. I don't think adding signature before encryption can prevent that.

The difference is that adding a signature before encryption means we reject the corrupted data as invalid, rather than accepting it
and potentially serving attack data to the user. Remember that an attacker can modify the output of the decryption even if they can't read the encrypted data. As currently written, the client will trust that modified data.

> If attacker managed to get a hold of the encryption key, signing key is likely compromised as well.

That may be true, but recommended practice is to make them different keys as I did in my patch, so that you don't end up with subtle related-key attacks. In particular, it is pretty common to have a key re-used in multiple parts of a program result in attacks where signed or encrypted data from one part of a program can be used to attack a different part even if the attacker doesn't actually know the key. The NIST document I reference in the bug report includes more details.

> I would think the benefit of adding signature prior to encryption is to guard against brute force attack on the decryption.

Nope, it's about integrity of the decrypted data, and choosing to not attempt to decrypt the data unless the integrity is verified. For a practical example of the types of attacks this prevents, you can read about the BEAST and CRIME attacks against SSL.