JavaEncryptor vulnerable to "padding oracle attack"

[GoogleCodeExporter]

For details, see
https://media.blackhat.com/bh-eu-10/whitepapers/Duong_Rizzo/BlackHat-EU-2010-Duo
ng-Rizzo-Padding-Oracle-wp.pdf

ESAPI 2.0-rc6 is still vulnerable. Among the problems, bit of info can be
leaked because
1) there is still a distinction made between invalid padding and issues
with (lack of) data integrity. This is because a) the authenticity is not
checked FIRST, before decryption is attempted, and b) the
EncryptionException is thrown with two different (end user) error messages.
2) Side-channel timing attack still likely even if order is corrected and
error messages are the same (at least if adversary is local to server where
ESAPI is being used so that fine-grained timing is available). Minimally
ensure that both do the same amount of work or take the same amount of time.

Original issue reported on code.google.com by kevin.w.wall@gmail.com on 4 May 2010 at 4:20

[GoogleCodeExporter]

This should be fixed as of SVN commits made by me on 7/26/2010.
(Specifically SVN revision 1453.)

QA: Usual JUnit tests plus NSA code review (in progress).

Original comment by kevin.w.wall@gmail.com on 31 Jul 2010 at 2:19

• Changed state: Fixed