Cryptography (JCA/JCE)

PBKDF2 only stresses CPU, so it's cheap to crack on GPUs/ASICs. bcrypt, scrypt, and Argon2 are also memory-hard, raising attacker cost much more. The JDK has no built-in for them, so you add a library like Spring Security's PasswordEncoder, jBCrypt, or Bouncy Castle.

Watch for: keyLength in bits not bytes, passing the password as char[] and wiping it, a fresh random salt per user, a high iteration count, handling NoSuchAlgorithmException/InvalidKeySpecException, and comparing hashes in constant time. Also store the parameters so you can upgrade later.

new SecureRandom() gives a strong, non-blocking generator good for almost everything. getInstanceStrong() returns a platform-configured 'strong' algorithm that may block waiting for entropy; reserve it for rare, very high-value secrets like long-lived keys.

A KeyPairGenerator makes a KeyPair (a PrivateKey + PublicKey). The private key goes into Signature.initSign to sign; the public key goes into Signature.initVerify to check. To store/send keys you encode them (X.509 for public, PKCS#8 for private) and rebuild them with a KeyFactory.

Watch for: ignoring or misreading the verify() boolean (always check it), feeding different bytes/encoding on each side, using weak algorithms (SHA-1/MD5, 1024-bit RSA), leaking the private key, and reusing a Signature object across threads. Verify with the trusted public key, not one supplied by the attacker.

When decryption with CBC/PKCS5Padding finds invalid padding, cipher.doFinal throws BadPaddingException (GCM throws the AEADBadTagException subclass). If your app tells an attacker whether padding was valid, they can decrypt data byte by byte — a padding-oracle attack. Reject all decrypt failures identically.

Use RSA when you must encrypt a small secret (like a symmetric key) to someone's public key. For most data, use hybrid encryption, and for modern systems consider elliptic-curve options (ECDH/ECIES) which are smaller and faster.

Keep your own private keys in a keystore and the certificates you trust in a separate truststore. File-based stores are simple but the key bytes live in process memory; an HSM or cloud KMS keeps keys in hardware so they never leave, at the cost of latency and complexity.

Cipher.getInstance asks the JCA provider list for an implementation of your transformation. Different providers (SunJCE, BouncyCastle, FIPS) may support different transformations or defaults, so always use full transformation strings, don't hardcode a provider unless required, and test on the JDK/provider you deploy on.

SecureRandom is provided by named algorithms (NativePRNG reads the OS source, SHA1PRNG is a self-contained generator, DRBG is the modern NIST design). Which you get depends on the platform/provider, so behavior can differ across OSes unless you request one explicitly.