Neil MaddenThe crypto parts of Spring Security are so whacky. I would recommend not using anything at all from this nonsense. https://github.com/spring-projects/spring-security/tree/main/crypto/src/main/java/org/springframework/security/crypto/encrypt
@JPatONeil@neilmadden obviously your perspective is a uniquely valuable one, but specifics for the rest of us that don't know crypto as well would probably help both the users and implementors of spring security.
@JPatONeil Almost every line of code in that package does something wrong from a crypto perspective:
- they have unauthenticated CBC mode encryption as the “standard” option, which also silently uses a fixed zero IV so is completely insecure
- one of the GCM implementations uses BouncyCastle’s “fast” table-lookup AES implementations, which likely has side-channels galore
- the RSA encryption defaults to 1024-bit keys, which are not remotely secure by modern standards
- it also defaults to PKCS#1 v1.5 padding, which is also not secure
- the “raw” RSA implementation actually runs RSA in ECB mode if the message is longer than the modulus allows (quite likely given they use small keys). This is absolutely terrible.
- the “secret” RSA encryption, which attempts to do hybrid encryption (with GCM), generates a random per-message AES key (good) but then treats it as a password and sends it through 1024 rounds of PBKDF2, so is incredibly slow. (It then pointlessly uses AES-256-GCM despite only generating a 128-bit key, again adding overhead for no security reason).
I’m sure there’s more that can be found by a more thorough review, that’s just the stuff that screams at me from 10 minutes looking at it. (And I’m pretty sure they only have GCM at all because I told them to add it years ago, as part of CVE-2020-5408).
Nobody with any crypto knowledge has been involved in developing that library, so why is it in a flagship framework?
@neilmadden Many thanks for your response! I also wonder why such an oversight would be found in such a hugely adopted security framework.