Are we using Java Crypto API Securely ?
summary
Concrete failures, not high-level warnings: JCA has insecure defaults and ambiguous docs, demonstrated with code that shows setSeed misuse producing deterministic RNG output and with examples where the ECB default silently breaks confidentiality. The session shows working code and a lab repo, recommends AES-GCM + 256-bit keys over legacy modes, specifies RSA >= 2048, PBKDF iterations ≈ 20,000 or more and suggests Argon2/Bcrypt for passwords, and points to provider/config fixes that actually work.
AI-written summary · about
chapters (9)
- 0:00Start
- 3:56Java Cryptography Architecture (JCA)
- 7:55Cryptographically Secure Pseudo-Random Number Generator (CSPRNG)
- 14:08Encryption/Decryption
- 15:58TRANSFORMATION_STRING
- 21:03Properties/Strength/Applications
- 23:17Message Authentication Code
- 24:24Digital Signatures
- 27:17Why should you care about Crypto ?
related talks
41mHow to Use Java Cryptography API Securely
52mCryptography 101 for Java developers
48mCryptography 101 for Java developers
52mUnlocking the unknowns: Cryptography Essentials for Spring Developers
34mUnlocking the unknowns: Cryptography Essentials
01h 01mBroken crypto is broken
23mJS Bringing Crypto to the Masses
37mKeeping Your Java Applications Secure - Cryptographic Improvements and Best Practices
