رمزنگاری از پایه: AES، RSA، هش و امضای دیجیتالCryptography Foundations: AES, RSA, Hashing & Digital Signatures

Almost every backend engineer writes this line one day:

Cipher cipher = Cipher.getInstance("AES");

It compiles, the tests go green, the feature ships — and three years later an auditor tells you the whole database is effectively unencrypted. Because "AES" in SunJCE means AES/ECB/PKCS5Padding, and ECB means "identical block in, identical ciphertext out".

Cryptography is the one area of software engineering where code can "work" and still be completely wrong: data encrypts, data decrypts, no exception is thrown, and the security is zero. That is why interviewers love it.

We start from zero: each concept gets a concrete picture, then its precise name, then real code, then where it blows up in production.

Assumed background: spring-security and ms-security cover OAuth2, JWT and RBAC. This chapter sits one layer below — the primitives they are built on.

1. What does cryptography actually guarantee?

So whenever somebody says "we encrypted the data", the right question is: which of the three?

Kerckhoffs's principle (1883) says security must depend only on secrecy of the key, never of the algorithm. AES spent 1997–2000 under attack from the whole cryptographic community in an open NIST competition before becoming FIPS 197; your in-house algorithm is a week old. The rule: you do not invent algorithms and do not hand-assemble primitives; you use a mature library and only decide which mode to pick.

2. Base64 is not encryption

Morse code turns text into dots and dashes. Encryption? No — there is no key. Morse is an encoding: a change of representation with no secret. Base64 is the same: binary rendered as 64 text-safe characters so bytes fit inside JSON or an HTTP header.

echo -n 'my-db-password' | base64      # bXktZGItcGFzc3dvcmQ=
echo -n 'bXktZGItcGFzc3dvcmQ=' | base64 -d

3. The foundation of everything: secure randomness

Settle this before AES and RSA, because every key, IV, nonce, salt and token comes from a random source; if it is guessable, the best algorithm is worthless.

java.util.Random looks random but is clockwork with 48 bits of state: observe two outputs and you can predict every future one. Great for simulations, catastrophic for security. SecureRandom is seeded from the OS entropy source so past outputs say nothing about the next.

• entropy: genuine unpredictability, in bits. A 256-bit key produced by Random may hold only 48 bits of real entropy.
• CSPRNG / DRBG: a cryptographically secure pseudo-random generator; NIST calls it a Deterministic Random Bit Generator.

SecureRandom rng = new SecureRandom();        // default; usually non-blocking on Linux
byte[] nonce = new byte[12];
rng.nextBytes(nonce);

// For very long-lived secrets; the algorithm comes from the
// securerandom.strongAlgorithms security property
SecureRandom strong = SecureRandom.getInstanceStrong();

// A safe token for password reset or an API key
byte[] raw = new byte[32];                    // 256 bits of entropy
rng.nextBytes(raw);
String token = Base64.getUrlEncoder().withoutPadding().encodeToString(raw);

4. Symmetric cryptography: AES

4.1 What symmetric means

Symmetric encryption is a gym locker: the same key that locks it also opens it. Fast and simple — with one big problem: how do I get the key to the other side? If I had a secure channel for the key, I would have used it for the message. That chicken-and-egg problem is why asymmetric cryptography exists.

AES (Advanced Encryption Standard, the Rijndael algorithm, standardised as FIPS 197 in 2001):

• The block size is always 128 bits (16 bytes) — independent of key size.
• Key size is 128, 192 or 256 bits; round counts are 10, 12 and 14.
• AES-128 is still perfectly secure; AES-256 is mostly chosen for regulatory requirements and quantum safety margin.

A block cipher only turns exactly 16 bytes into 16 bytes. Your message is 2 MB; how do you split and chain the pieces? The answer is the mode of operation, where 90% of cryptographic mistakes live.

4.2 ECB — the mode you must never use

ECB (Electronic Codebook) encrypts each block independently under the same key — a dictionary mapping every word to a meaningless one: unreadable, but the pattern survives completely. The famous demo is the "ECB penguin": an image still perfectly recognisable after encryption.

Diagram: ECB encrypts each block independently, CBC chains each block into the next.

flowchart LR
  subgraph ECB["ECB - patterns survive"]
    P1[Block 1] --> E1[AES] --> C1[Cipher 1]
    P2[Block 2] --> E2[AES] --> C2[Cipher 2]
  end
  subgraph CBC["CBC - chained"]
    IV[Random IV] --> X1((XOR))
    Q1[Block 1] --> X1 --> D1[AES] --> R1[Cipher 1]
    R1 --> X2((XOR))
    Q2[Block 2] --> X2 --> D2[AES] --> R2[Cipher 2]
  end

4.3 CBC — chaining, IVs and padding

CBC (Cipher Block Chaining) XORs each block with the previous ciphertext block before encrypting. The first block has no predecessor, so we supply a random value: the IV (Initialization Vector). Three facts interviewers ask for:

1. The IV is not secret and is normally stored as a prefix beside the ciphertext.
2. In CBC it must be unpredictable (random), not merely unique — a predictable IV led to BEAST on TLS 1.0.
3. It must never repeat under the same key.

Padding: since AES consumes whole blocks, PKCS#7 (called PKCS5Padding in Java for historical reasons) appends n bytes each holding the value n.

4.4 CTR — turning a block cipher into a stream

CTR (Counter mode) encrypts a counter and XORs the output with the data, turning AES into a keystream generator. No padding, parallelisable, random access — which is why it underpins disk encryption. Its input is a nonce: a number used exactly once under a given key.

4.5 GCM and AEAD — today's default

• AEAD = Authenticated Encryption with Associated Data: one algorithm giving confidentiality and integrity together, so you never combine encryption and a MAC yourself.
• authentication tag: the 16-byte value Java appends to the ciphertext.
• AAD: data not encrypted but included in the tag — say tenantId or recordId. If an attacker copies user A's ciphertext into user B's row the tag fails, killing the ciphertext substitution attack.

AES-GCM = AES in CTR mode + the GHASH function multiplying in the Galois field GF(2^128); the standard is NIST SP 800-38D.

Diagram: how GCM combines CTR-mode encryption with the GHASH authentication tag.

flowchart TD
  K[AES key] --> CTR[CTR keystream]
  N[96-bit nonce, unique per message] --> CTR
  P[Plaintext] --> X((XOR))
  CTR --> X --> C[Ciphertext]
  C --> G[GHASH]
  AAD[Associated data - not encrypted] --> G
  K --> G
  G --> T[128-bit auth tag]
  C --> OUT[nonce + ciphertext + tag]
  T --> OUT

The GCM rules to know by heart:

1. Use a 12-byte (96-bit) nonce — the NIST-recommended length, used directly; any other length goes through GHASH first.
2. A fresh nonce per message: a persisted unique counter (best) or random bytes from SecureRandom.
3. With random nonces, at most 2^32 invocations per key — four billion messages is not a big number in a busy service; precisely why key rotation exists.
4. At most ~64 GB per message (2^39 − 256 bits), and use a 128-bit tag.

C1 XOR C2 = (P1 XOR KS) XOR (P2 XOR KS) = P1 XOR P2

4.6 Decision table: which mode?

Choosing between them is a performance decision, not a security one: on a modern server CPU (AES-NI, or ARMv8 Crypto Extensions) hardware-accelerated AES-GCM wins; without that acceleration ChaCha20-Poly1305 is faster and more cache-timing resistant, using only additions, XORs and rotations. Java has had it since 11 (JEP 329) as "ChaCha20-Poly1305".

4.7 A correct AES-GCM class in Java

import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import javax.crypto.spec.GCMParameterSpec;
import java.nio.ByteBuffer;
import java.security.SecureRandom;

public final class AesGcm {

    private static final String TRANSFORM = "AES/GCM/NoPadding";
    private static final int NONCE_LEN = 12;   // 96 bit — NIST recommendation
    private static final int TAG_BITS  = 128;

    private static final SecureRandom RNG = new SecureRandom();

    private AesGcm() { }

    public static SecretKey newKey() throws Exception {
        KeyGenerator kg = KeyGenerator.getInstance("AES");
        kg.init(256, RNG);
        return kg.generateKey();
    }

    /** Layout: nonce || ciphertext || tag  (Java appends the tag for you) */
    public static byte[] encrypt(SecretKey key, byte[] plaintext, byte[] aad) throws Exception {
        byte[] nonce = new byte[NONCE_LEN];
        RNG.nextBytes(nonce);                            // fresh nonce per message

        Cipher cipher = Cipher.getInstance(TRANSFORM);   // not thread-safe, do not cache
        cipher.init(Cipher.ENCRYPT_MODE, key, new GCMParameterSpec(TAG_BITS, nonce));
        if (aad != null) {
            cipher.updateAAD(aad);
        }
        byte[] ct = cipher.doFinal(plaintext);
        return ByteBuffer.allocate(nonce.length + ct.length).put(nonce).put(ct).array();
    }

    public static byte[] decrypt(SecretKey key, byte[] blob, byte[] aad) throws Exception {
        if (blob.length < NONCE_LEN + TAG_BITS / 8) {
            throw new IllegalArgumentException("ciphertext too short");
        }
        ByteBuffer buf = ByteBuffer.wrap(blob);
        byte[] nonce = new byte[NONCE_LEN];
        buf.get(nonce);
        byte[] ct = new byte[buf.remaining()];
        buf.get(ct);

        Cipher cipher = Cipher.getInstance(TRANSFORM);
        cipher.init(Cipher.DECRYPT_MODE, key, new GCMParameterSpec(TAG_BITS, nonce));
        if (aad != null) {
            cipher.updateAAD(aad);
        }
        return cipher.doFinal(ct);   // a bad tag throws AEADBadTagException — never swallow it
    }
}

5. Where does the key come from? KDFs and envelope encryption

A KDF (Key Derivation Function) turns input material into high-quality keys. Two different families exist, and confusing them is a common error:

// password -> key. A unique salt and a high iteration count are mandatory.
SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] salt = new byte[16];
new SecureRandom().nextBytes(salt);
KeySpec spec = new PBEKeySpec(password /* char[] */, salt, 600_000, 256);
SecretKey aesKey = new SecretKeySpec(f.generateSecret(spec).getEncoded(), "AES");

600,000 is OWASP's current recommendation for PBKDF2-HMAC-SHA256 (about 210,000 for SHA-512).

Since JDK 25 there is a standard KDF API (JEP 510, previewed in JDK 24):

import javax.crypto.KDF;
import javax.crypto.spec.HKDFParameterSpec;

KDF hkdf = KDF.getInstance("HKDF-SHA256");

SecretKey encKey = hkdf.deriveKey("AES",
    HKDFParameterSpec.ofExtract()
        .addIKM(sharedSecret)                      // input keying material
        .addSalt(salt)
        .thenExpand("app:v1:encryption".getBytes(UTF_8), 32));

SecretKey macKey = hkdf.deriveKey("HmacSHA256",
    HKDFParameterSpec.ofExtract()
        .addIKM(sharedSecret)
        .addSalt(salt)
        .thenExpand("app:v1:mac".getBytes(UTF_8), 32));

The info string is not decoration: it performs domain separation, guaranteeing the encryption and MAC keys can never collide.

Envelope encryption is the industry-standard pattern: encrypt data with a random single-use DEK (Data Encryption Key), then wrap the DEK with a KEK (Key Encryption Key) held in an HSM or KMS. Only the wrapped DEK sits beside the data; the KEK never leaves the module. The win: rotation re-wraps DEKs instead of re-encrypting terabytes.

Diagram: the lifecycle states a symmetric key moves through in a managed system.

stateDiagram-v2
  [*] --> Generated: KMS or KeyGenerator
  Generated --> Active: used for encrypt and decrypt
  Active --> Deprecated: rotation, decrypt only
  Deprecated --> Destroyed: all data re-wrapped
  Active --> Compromised: incident
  Compromised --> Destroyed: emergency re-encrypt
  Destroyed --> [*]

CREATE TABLE customer_secret (
    id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id bigint      NOT NULL,
    key_id      text        NOT NULL,               -- which DEK/KEK
    alg         text        NOT NULL DEFAULT 'AES-256-GCM',
    nonce       bytea       NOT NULL,               -- 12 bytes
    ciphertext  bytea       NOT NULL,               -- includes the tag
    created_at  timestamptz NOT NULL DEFAULT now()
);
CREATE INDEX ON customer_secret (key_id);           -- to re-wrap during rotation

CREATE TABLE customer_secret (
    id          NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id NUMBER        NOT NULL,
    key_id      VARCHAR2(64)  NOT NULL,             -- which DEK/KEK
    alg         VARCHAR2(32)  DEFAULT 'AES-256-GCM' NOT NULL,
    nonce       RAW(12)       NOT NULL,
    ciphertext  BLOB          NOT NULL,             -- includes the tag
    created_at  TIMESTAMP WITH TIME ZONE DEFAULT SYSTIMESTAMP NOT NULL
);
CREATE INDEX customer_secret_key_id_ix ON customer_secret (key_id);

6. Asymmetric cryptography: RSA

RSA (1977) rests on one fact: multiplying two large primes is easy, factoring the product is practically impossible — a trapdoor function. The modulus is n = p × q; "RSA-2048" means n is 2048 bits. The public key is (n, e) with e = 65537, the private key (n, d).

6.1 Why RSA never encrypts large data

Mathematically: RSA operates on a number smaller than n, and padding eats part of it. With RSA-2048 and OAEP-SHA-256:

max plaintext = k − 2·hLen − 2 = 256 − 2·32 − 2 = 190 bytes

With PKCS#1 v1.5 it is k − 11 = 245 bytes. Performance-wise: RSA is orders of magnitude slower than AES.

The standard answer is hybrid encryption: put the cargo in a container with an ordinary lock and post only that lock's key through the slot.

Diagram: sender wraps a fresh AES key with the recipient's RSA public key.

sequenceDiagram
    participant S as Sender
    participant R as Recipient
    R->>S: RSA public key
    Note over S: generate random AES-256 key (DEK)
    S->>S: ciphertext = AES-GCM(DEK, message)
    S->>S: wrappedKey = RSA-OAEP(pubKey, DEK)
    S->>R: wrappedKey + nonce + ciphertext + tag
    Note over R: DEK = RSA-OAEP-decrypt(privKey, wrappedKey)
    R->>R: message = AES-GCM-decrypt(DEK, ciphertext)

The sentence to say in an interview: asymmetric for key transport and signatures, symmetric for the data.

6.2 Padding: OAEP versus PKCS#1 v1.5

Textbook RSA is deterministic: one input always yields one output. If the input space is small ("yes"/"no", a card number), an attacker encrypts all candidates and compares. Padding adds randomisation and safe structure.

OAEPParameterSpec oaep = new OAEPParameterSpec(
        "SHA-256", "MGF1",
        MGF1ParameterSpec.SHA256,          // this is the part everybody forgets
        PSource.PSpecified.DEFAULT);

Cipher c = Cipher.getInstance("RSA/ECB/OAEPPadding");
c.init(Cipher.ENCRYPT_MODE, publicKey, oaep);

6.3 Signing with RSA

"Signing is encrypting with the private key" helps intuitively but is technically wrong. The modern RSA signature scheme is RSASSA-PSS, with a different construction, a random salt and a security proof; SHA256withRSA is the PKCS#1 v1.5 signature scheme, not encryption.

Signature signer = Signature.getInstance("RSASSA-PSS");
signer.setParameter(new PSSParameterSpec(
        "SHA-256", "MGF1", MGF1ParameterSpec.SHA256, 32, 1));
signer.initSign(privateKey);
signer.update(message);
byte[] sig = signer.sign();

7. ECC, ECDSA and Ed25519

RSA's mathematics lives on large integers; ECC on points of an elliptic curve. Add a base point G to itself k times and you reach P; going from k to P is easy, going back is practically impossible (the elliptic-curve discrete logarithm problem). The consequence: the same security with far smaller keys.

An ECDSA signature on P-256 is about 64 bytes against 256 for RSA-2048 — a real difference in a JWT or TLS certificate.

• ECDH / X25519: key agreement — both sides exchange public keys and independently derive a shared secret that never travels over the wire. The basis of forward secrecy in TLS 1.3.
• ECDSA: signatures on NIST curves (P-256 / secp256r1).
• EdDSA / Ed25519: the modern signature scheme on an Edwards curve (RFC 8032).

Java has EdDSA since 15 (JEP 339) and the X25519/X448 curves since 11 (JEP 324):

KeyPairGenerator kpg = KeyPairGenerator.getInstance("Ed25519");
KeyPair kp = kpg.generateKeyPair();

Signature s = Signature.getInstance("Ed25519");
s.initSign(kp.getPrivate());
s.update("transfer 100 to account 42".getBytes(UTF_8));
byte[] signature = s.sign();                 // 64 bytes

Signature v = Signature.getInstance("Ed25519");
v.initVerify(kp.getPublic());
v.update("transfer 100 to account 42".getBytes(UTF_8));
boolean ok = v.verify(signature);            // trust this boolean; never compare bytes yourself

// key agreement — never use the raw secret as an AES key, run it through HKDF
KeyAgreement ka = KeyAgreement.getInstance("X25519");
ka.init(myPrivateKey);
ka.doPhase(theirPublicKey, true);
byte[] sharedSecret = ka.generateSecret();

Since Java 21 there is also a standard KEM API (JEP 452):

KEM kem = KEM.getInstance("DHKEM");
KEM.Encapsulated e = kem.newEncapsulator(recipientPublicKey).encapsulate();
SecretKey senderKey = e.key();               // a fresh symmetric key
byte[] capsule = e.encapsulation();          // send this over the wire

SecretKey receiverKey = kem.newDecapsulator(recipientPrivateKey).decapsulate(capsule);

8. Hashing: a fingerprint of data

A cryptographic hash maps any input to a fixed-length output and has three properties:

1. Preimage resistance: given h you cannot find an m with hash(m) = h (cost ≈ 2^256 for SHA-256).
2. Second preimage resistance: given m1 you cannot find m2 ≠ m1 with the same hash.
3. Collision resistance: you cannot find any pair m1 ≠ m2 with the same hash. Here the birthday paradox bites: the cost is only ≈ 2^(n/2), i.e. 2^128 for SHA-256.

A fourth property is the avalanche effect: flipping one input bit changes about half the output bits.

Know the difference between an identical-prefix and a chosen-prefix collision: in the first the attacker builds both documents; in the second he takes two arbitrary, different prefixes (say two contracts with different amounts) and crafts suffixes making the hashes equal. The second is the dangerous one, practical against SHA-1 since 2020 — which is why JDK 25 disabled SHA-1 signatures in TLS 1.2 handshakes by default.

HMAC(K, m) = H( (K ⊕ opad) || H( (K ⊕ ipad) || m ) )

MessageDigest md = MessageDigest.getInstance("SHA-256");
byte[] digest = md.digest("hello".getBytes(UTF_8));

MessageDigest shake = MessageDigest.getInstance("SHAKE256-512");   // added in Java 25

9. Password hashing: a completely different problem

To sign a 10 GB file you want the hash very fast. For a password, speed is your enemy: the attacker who stole your database wants billions of guesses, so we deliberately pick a slow, memory-hungry function. A modern GPU does tens of billions of SHA-256 per second, but only tens of thousands of guesses against bcrypt at a proper work factor, and fewer against a tuned Argon2id, which runs out of RAM.

• salt: a random value unique per user, hashed with the password and stored beside the hash (not secret). It makes precomputed rainbow tables useless and stops two users with the same password sharing a hash — but it does not slow down guessing a specific user; that is the work factor's job.
• pepper: a global secret in the application or an HSM but never in the database; if only the database leaks, the attacker is stuck without it.
• work factor: the cost parameter; in bcrypt it is logarithmic, so cost=12 means 2^12 rounds.
• memory-hard: demanding significant RAM as well as CPU — exactly what erases the GPU and ASIC advantage.

Argon2 won the 2015 Password Hashing Competition (RFC 9106); of its variants (Argon2d, Argon2i, Argon2id) the hybrid is the one to choose. Spring Security's Argon2PasswordEncoder defaults are salt=16, hash=32, p=1, m=16384 KiB, t=2, and BCryptPasswordEncoder defaults to strength=10.

Diagram: verifying a password and transparently upgrading its hash.

flowchart TD
  A[Login request] --> B[Load stored hash by username]
  B --> C{User exists?}
  C -- No --> D[Run a dummy hash anyway] --> E[Generic error]
  C -- Yes --> F[Verify password against stored hash]
  F -- No --> E
  F -- Yes --> G{Hash uses old params?}
  G -- Yes --> H[Re-hash with current params and store]
  G -- No --> I[Issue session]
  H --> I

10. HMAC and the encrypt/MAC ordering

A MAC (Message Authentication Code) is a short tag computed with a shared key: "this came from a key holder and was not modified".

Mac mac = Mac.getInstance("HmacSHA256");
mac.init(new SecretKeySpec(macKey, "HmacSHA256"));
mac.update(payload);
byte[] tag = mac.doFinal();

boolean valid = MessageDigest.isEqual(tag, receivedTag);   // time-constant

Diagram: the correct ordering — authenticate the ciphertext, verify before decrypting.

flowchart LR
  P[Plaintext] --> E[Encrypt] --> C[Ciphertext]
  C --> M[MAC over ciphertext] --> T[Tag]
  C --> S[Send C + T]
  T --> S
  S --> V{Tag valid?}
  V -- No --> R[Reject before decrypting]
  V -- Yes --> D[Decrypt]

With encrypt-then-MAC the receiver checks the tag before anything else and never opens the ciphertext if it fails, so no attacker-controlled data enters the decryption and padding path — the cryptographic doom principle. But the complete answer is: "encrypt-then-MAC is correct, yet I never compose it myself; AES-GCM or ChaCha20-Poly1305 already does it in one API."

11. Digital signatures and non-repudiation

Diagram: signing hashes first, then applying the private key.

sequenceDiagram
    participant Signer
    participant Verifier
    Note over Signer: digest = SHA-256(document)
    Signer->>Signer: signature = sign(privateKey, digest)
    Signer->>Verifier: document + signature
    Note over Verifier: recompute digest from document
    Verifier->>Verifier: verify(publicKey, digest, signature)
    alt valid
        Verifier-->>Signer: accepted
    else invalid
        Verifier-->>Signer: rejected - tampered or wrong signer
    end

A signature is always over a hash, never the document itself — for size and performance.

12. The JCA/JCE architecture in Java

Java is not itself a cryptographic algorithm; it defines a standard socket: you tell Cipher, MessageDigest and Signature what you want and the JCA finds a provider implementing it — SunJCE in software, SunPKCS11 for an HSM or smartcard, BouncyCastle for extras — so you can swap software for a FIPS-validated module without touching code. JCA is the provider framework plus signature/digest/key-generation classes; JCE is the encryption part. Since Java 9 they live in java.base, and since 8u161 the "unlimited strength policy files" are gone.

A transformation string means algorithm / mode / padding; write only "AES" and the provider decides — in SunJCE that decision is ECB.

13. Command cheat sheet

One important trap: openssl enc does not support AEAD modes, so openssl enc -aes-256-gcm gets you nowhere — its streaming design cannot verify the tag before processing all the data. If you must use enc, always pass -pbkdf2 -iter 600000.

14. Gallery of classic mistakes

1. Cipher.getInstance("AES") → ECB. Always the full transformation.
2. A fixed IV/nonce or a counter that resets → nonces repeat after a restart; a counter must be persisted and atomic.
3. A key in code or an env var with no rotation → git history remembers forever.
4. A password used as an AES key without a KDF → "password123".getBytes() truncated to 16 bytes carries a handful of entropy bits.
5. CBC without a MAC → padding oracle.
6. Swallowing AEADBadTagException → switching off the burglar alarm.
7. Arrays.equals for tags/MACs/tokens → timing attack; use MessageDigest.isEqual.
8. SHA-256 for passwords → billions of guesses per second on a GPU.
9. One shared salt for all users → a single rainbow table covers the whole database.
10. hash(secret || message) as a MAC → length extension; write HMAC.
11. Reading alg from the token itself → alg: none and algorithm confusion.

15. On the horizon: post-quantum cryptography

An attacker today cannot open your TLS traffic, but can store it and open it ten years from now: harvest now, decrypt later.

Shor's algorithm on a large enough quantum computer breaks RSA and ECC in one stroke, since both rest on factoring and discrete logarithms. Grover's gives only a square-root speedup, so AES-256 and 384-bit-and-above hashes stay effectively safe — say this in an interview; many assume symmetric cryptography dies too.

In August 2024 NIST published FIPS 203 — ML-KEM (Kyber) for key exchange, FIPS 204 — ML-DSA (Dilithium) for signatures, and FIPS 205 — SLH-DSA (SPHINCS+) as a hash-based backup. NIST IR 8547 then set the timeline: classical public-key algorithms (RSA, ECDSA, EdDSA, ECDH) become deprecated after 2030 and disallowed after 2035.

Java followed: JDK 24 brought ML-KEM (JEP 496) and ML-DSA (JEP 497); JDK 25 finalised the KDF API (JEP 510), added SHAKE128-256/SHAKE256-512 and disabled SHA-1 TLS 1.2 signatures; JDK 26 added HPKE via HPKEParameterSpec on Cipher (RFC 9180), a second PEM API preview (JEP 524), and jarsigner -sigalg ML-DSA-65.

Interview questions

private static final byte[] KEY = "0123456789abcdef".getBytes();
private static final byte[] IV  = new byte[16];

public String encrypt(String data) throws Exception {
    Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
    c.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(KEY, "AES"),
           new IvParameterSpec(IV));
    return Base64.getEncoder().encodeToString(c.doFinal(data.getBytes()));
}