Cryptography (JCA/JCE)

You call Cipher.getInstance with a transformation string like "AES/GCM/NoPadding". It has three parts: the algorithm (AES), the mode (how blocks are chained, e.g. GCM or CBC), and the padding (e.g. PKCS5Padding or NoPadding).

Ask KeyGenerator for an algorithm like AES, call init() with the key size (for example 256 bits), then generateKey(). It returns a SecretKey you use to encrypt and decrypt.

Call MessageDigest.getInstance("SHA-256") to get an engine, feed bytes with update(...), then call digest() to get the final hash as a byte[]. digest() finishes the computation and resets the engine for reuse.

Use java.security.SecureRandom to fill a fresh byte array (16 bytes) for each password. Don't use java.util.Random or Math.random - they're predictable. The salt is stored with the hash and doesn't need to be secret, just unique and random.

java.util.Random and Math.random() are predictable: from a few outputs an attacker can compute the seed and predict all future values. For anything security-related (tokens, keys, salts) use java.security.SecureRandom, which is unpredictable.

Get a Signature object with Signature.getInstance("SHA256withRSA"). To sign: call initSign(privateKey), update(data), then sign() to get the signature bytes. To verify: initVerify(publicKey), update(data), then verify(signatureBytes) returns true if it matches.

It is the text you pass to Cipher.getInstance to choose encryption. It has three parts separated by slashes: the algorithm, the mode of operation, and the padding, like "AES/GCM/NoPadding".

Call Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding") to get a Cipher, then cipher.init(...) with a key. The string names the algorithm (RSA), a mode, and the padding scheme used to make encryption safe.

After getInstance you call cipher.init(Cipher.ENCRYPT_MODE, key, params). The key is a SecretKey; SecretKeySpec wraps raw bytes (like a 16- or 32-byte array) into a SecretKey for AES. For decryption you use Cipher.DECRYPT_MODE with the same key.

Use KeyPairGenerator: getInstance("RSA"), initialize(2048), generateKeyPair(). You get a KeyPair with a public key (shareable) and a private key (secret). Symmetric uses KeyGenerator and produces one shared SecretKey instead.

A KeyStore is a password-protected file of keys and certificates. You load() it (or load(null) for empty), store entries under a string alias with a password, then save with store(), and read them back with getKey(alias, password) or getCertificate(alias).

MessageDigest.isEqual compares byte arrays in constant time, so it does not leak how many bytes matched. Arrays.equals returns early on the first mismatch, which an attacker can time to guess a secret byte by byte.

No. SHA-256 via MessageDigest is fast and unsalted, so attackers can brute-force or use rainbow tables. Store passwords with a slow, salted, purpose-built KDF like bcrypt, scrypt, Argon2, or PBKDF2 instead.

Get a SecretKeyFactory for "PBKDF2WithHmacSHA256", build a PBEKeySpec from the password chars, a random salt, an iteration count, and a key length, then call generateSecret(spec).getEncoded() to get the hash bytes.

Store the salt, iteration count, algorithm, and the hash bytes (not the password). On login, re-derive the hash from the entered password using the stored salt and iterations, then compare it to the stored hash with a constant-time check.

A fixed seed makes the output deterministic — the same 'random' values every run — which is fine for tests but disastrous for real secrets, because anyone with the seed (or who guesses it) can reproduce every token or key.

Create one SecureRandom, make a byte[] of the size you need, and call secureRandom.nextBytes(buffer). That fills it with unpredictable bytes. Avoid building random bytes from Random, timestamps, or fixed seeds.

Because Java then lets the provider pick the mode and padding for you. On the default JDK it picks ECB mode, which is insecure: identical plaintext blocks become identical ciphertext, leaking data. Always write the full "AES/mode/padding".

RSA can only encrypt a small chunk smaller than the key size, so doFinal throws if your data is too big. The fix is hybrid encryption: encrypt the data with a fast random AES key, then RSA-encrypt only that small AES key.

Use "AES/GCM/NoPadding" with a GCMParameterSpec that sets the tag length (usually 128 bits) and a unique 12-byte nonce. On encrypt, doFinal appends the authentication tag to the ciphertext automatically. On decrypt, doFinal verifies the tag and throws AEADBadTagException if the data was tampered with.

You pass parameters as a third argument to cipher.init. For CBC/CTR you use IvParameterSpec(iv). For GCM you use GCMParameterSpec(tagLengthBits, nonce), which also sets the authentication tag length. The IV/nonce must be unique per encryption.

Call key.getEncoded() to get the standard byte form. Wrap public-key bytes in X509EncodedKeySpec and private-key bytes in PKCS8EncodedKeySpec, then use KeyFactory.getInstance("RSA").generatePublic/generatePrivate to turn them back into Key objects.

update feeds part of the data into the cipher and may return some processed bytes, but it doesn't finish the operation. doFinal processes the last chunk, applies padding (or the GCM tag), and completes. For small data you just call doFinal once.

A MessageDigest holds running state. update() adds bytes to it; digest() finishes the hash and then auto-resets, so you can hash another message right away. reset() throws away any buffered bytes without producing a hash.

"SHA256withRSA" means: hash the data with SHA-256, then sign that hash with RSA. The "...withRSA" part decides which key type you need — an RSA key. Use "...withECDSA" with an EC key. Mixing them throws InvalidKeyException.

update() feeds the bytes to be signed or verified into the Signature object. You can call it many times to stream large data in chunks; the bytes are accumulated in order. The verifier must feed exactly the same bytes in the same order, then call sign() or verify().

GCM gives encryption plus built-in integrity in one step and is the default choice. CBC only encrypts — it has no integrity check — so by itself it is vulnerable to tampering and padding-oracle attacks. If you must use CBC, you have to add a separate MAC (encrypt-then-MAC). Both need a unique IV per message.

SecureRandom supplies the unpredictable random bytes that keys are built from. If the randomness is predictable, attackers can guess your keys. Use SecureRandom (a strong generator), never new Random(), and let it self-seed.

getInstance("SHA-256") asks the JCA to find any installed provider that supplies that algorithm, picking the highest-priority one. You can also pin a provider by name. Keep the algorithm name in config rather than hard-coded so you can change it without touching code.