AES/GCM/NoPadding doesn't work on JDK8

[kravietz]

The AES/GCM/NoPadding encryption seems to have been only tested with BouncyCastle. JDK8 now supports AES/GCM natively but it doesn't seem to work because ESAPI is passing IvParameterSpec to the JCE encryption routine while it's expecting GCMParameterSpec instead.

[kwwall]

Makes sense. At the time when it was written, SunJCE didn't support GCM or CCM, and there is also a small problem that we are trying to support using ESAPI with JDK 1.6 (I know; don't even get me started on that!) and IIRC, SunJCE didn't support GCM or CCM until JDK 7. I can work around that, but it's a royal PITA. So that's why it is like it is. I will try to address this in the next release.

-kevin Sent from my Droid; please excuse typos. On Feb 29, 2016 11:34 AM, "Paweł Krawczyk" [email protected] wrote:

The AES/GCM/NoPadding encryption seems to have been only tested with BouncyCastle. JDK8 now supports AES/GCM natively but it doesn't seem to work because ESAPI is passing IvParameterSpec to the JCE encryption routine while it's expecting GCMParameterSpec instead.

— Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java-legacy/issues/363.

[kravietz]

That's right, GCM is really supported since JDK8 only - I've added it more a placeholder on a todo list and also sent you an email to the @gmail.com address found in the source files.

[kwwall]

Just an FYI...this may be tricky to fix because the current plans are to support whatever JDK 7 supports at least for one more release and GCMParameterSpec won't be in it. While we could resolve this using reflection, I'd prefer not to as that could significantly slow down encryption.

[kwwall]

Sigh. Had GCMParameterSpec extended IVParameterSpec here rather than simply implementing the simple marker interface AlgorithmParameterSpec, this would have worked, or at least I could have made it work more easily. As it is, this is going to be a major undertaking, especially if I want ESAPI to support Also, @kravietz, do you happen to Bouncy Castle supports "additional authentication data" (e.g., as in Cipher.updateAAD())? Last time I checked, it didn't. But seems to me if we want to support GCM from SunJCE, we ought to also support AAD. <sarcasm> As far as it goes, I'm about half way ready to throw out all the ESAPI crypto and replace it to just call Google Tink. But (pardon the pun), that probably would create a big ESAPI Tink stink, as would we would get complaints from all 4 or 5 projects in the world that use ESAPI for crypto that it wasn't backward compatible and they'd complain about having to re-encrypt all their old data that they haven't changed the key for in the last 5 years anyway.

There is no good way forward. had the SunJCE in earlier JDKs supported AES/GCM or AES/CCM, I would have rewritten the ESAPI crypto in 2.0.0.0 to only support authenticated encryption. Since they didn't, I threw together an encrypt-then-MAC hack which has really outlived its usefulness. Once we finally decide to stop supporting JDK 7 in ESAPI though, I may very well burn the current crypto to the ground with no backward compatibility path at all. (So, all 4 or 5 projects using ESAPI crypto, start your complaints now while there is still time. <sarcasm/>

[kravietz]

@kwwall At this stage I believe that maintaining this backwards compatibility is only negatively impacting any future development of ESAPI. What you might want to do is to get rid of the crypto in new ESAPI at all, as it's much better implemented in Tink and libsodium. People who need the old crypto can just stick to the esapi-legacy library. If the new library is renamed (e.g. esapi-lite) they can be used in parallel.

[kwwall]

@kravietz Yeah, my plan for eventually would be to replace swap out the current implementation with Google Tink. (I just added Tink as a recommendation for strong crypto on the 'Should I use ESAPI?' tab.) That said, I think for frameworks, maintaining a backward compatibility path is extremely important, and even if ESAPI were to provide some conversion routines to assist with that, it would still be very painful. If one is using ESAPI crypto at all, it is probably being used to store data-at-rest in databases, etc. And if one has a DB table with a column of encrypted SSNs (say), it is not a trivial task to simply replace one encrypted column with one of a different format. And when you have a half dozen or more applications all accessing those encrypted SSNs and all needing to be lock-step with some new ESAPI version, that's a very hard problem. I don't have any good answers. We might be able to provide some help in terms of some helper utilities, that that doesn't replace lots of planning and extensive testing. So it's the conversion of old encrypted data to the new format that is a real PITA, especially if you have lots of applications that access that encrypted data. That's hard to automate.

P.S.- As great as I think that DJB's NaCl and the libsodium fork of NaCl is, I don't think it would be accepted by a lot of Java shops in corporations. I've worked in corporations where they do not allow any JNI solutions or libraries in their JavaEE shops. (Mostly, because of a paranoid concern about memory leaks.)

[kravietz]

@kwwall That's why I believe having separate esapi-legacy and esapi-new/light might be a good solution to this problem:

• Install esapi-new to use all the new and shiny features
• Need to decrypt those old fields? Keep esapi-legacy in your dependencies.

[kwwall]

"esapi-new" as you are calling it is going to be a complete rewrite... what we have been referring to as ESAPI 3.0. The plan is to make it much more modular rather than the monolithic beast that it now is. So given that, we still have a lot of clean up to do in "esapi-java-legacy".

-kevin

Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.

On Wed, Aug 22, 2018, 16:20 Paweł Krawczyk [email protected] wrote:

@kwwall https://github.com/kwwall That's why I believe having separate esapi-legacy and esapi-new/light might be a good solution to this problem:

• Install esapi-new to use all the new and shiny features
• Need to decrypt those old fields? Keep esapi-legacy in your dependencies.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESAPI/esapi-java-legacy/issues/363#issuecomment-415166133, or mute the thread https://github.com/notifications/unsubscribe-auth/AB3nmy01pKiOXUy3tG1lP5KDOHGGbh8Gks5uTb0BgaJpZM4HlldE .