Cheat sheet update/refactor proposal: JWT for Java AES/GCM usage issue about cheatsheetseries HOT 6 CLOSED

I have simplified the ciphering part using Google Tink API in order to allow users to use this API created and maintained by several crypto specialists.
I have also simplify others code samples of the ciphering section to enhance the readability of the cheat sheet.

from cheatsheetseries.

I think that it is important to clarify some points according to your post:

1. The migration to GitHub has for objective to allow more people to contribute in order to fix the issue in the project like potentially one that have raised.
2. Even if OWASP is a foundation working on security topics, it do not means that we never doing mistake, we are human (and doing this on our spare time) and the open source approach is used to allow eveyone wathever is origin (pro or not) to fix the potential error.
3. OWASP contribution is not reversed to only so called "experts" on some topics, everyone can propose some technical proposal for an security issues and this can be used as foundation to enhance it.
4. The elements that you raised only highlight a paranoic approach usage of AES/GCM and do not proof that the ciphered value can be retrieved (that is the main goal of this section). Feel free to technically proof the inverse...
5. Instead of saying that you suspect that the cheat sheet contains many errors, proof them or better propose a pull request to fix the issue that you have identified.

from cheatsheetseries.

My goal was not to blame anyone, nor do I expect every document to be free of mistakes. I highly respect the volunteers who do this work in their spare time.

I looked at the document because I'm not an expert myself. I don't know all the ins and outs necessary to securely implement JWT and can't review the rest of the document with the appropriate scrutiny. I just noticed the unusual AES construction and from what I learned about encryption, unusual is not a desired property for solutions to standard problems.
While the proposed scheme does not seem to weaken the encryption, I disagree with the notion that not weakening the encryption is reason enough to pile more complexity on top.

You highlighted that you welcome community contributions. Why not use the issue tracker for readers to raise issues and requests for clarification? You can even stick "contributions welcome" labels on these to encourage people to look at potential issues.
Maybe we can get someone else to chime in on this!

from cheatsheetseries.

Thanks vou very much for your feedback and the clarification about your intention.

In order to clarify the error, I have discussed with a crypto specialist about this point and indeed the NONCE and AAD are public so I will update the implementation proposed in this way to remove the DB and pass the NONCE and AAD along the ciphered value to the entity in charge of the deciphering.

Thanks for the proposal for the label I will update the labels and the readme in this way.

from cheatsheetseries.

Thanks for taking the time to clarify! Just a small addendum:
You don't need any AAD in this case. If you don't set it GCM will still work and authenticate the payload.

from cheatsheetseries.

You are welcome, the objective the have this project here is to discuss and handle the issue 😃
Thanks you for your addendum, I will take it in account...

from cheatsheetseries.