مدیریت کلید، رازها و حفاظت از دادهKey Management, Secrets & Data Protection

Almost every backend engineer can call AES. Almost nobody can say where that key came from, who can read it, how it gets replaced, or what happens if it leaks tomorrow. That gap — between cryptography and key management — is where companies actually get breached.

Cryptography is a solved problem: nobody is breaking AES-256 today. What breaks is this: a key committed in application.yml; a key unchanged for three years; every service sharing one key; a Kubernetes Secret that is only base64; nobody knowing which secrets a departing teammate had.

Authentication and authorization (OAuth2/JWT/RBAC) live in the spring-security and ms-security chapters and are only referenced here. This chapter is about keys, secrets and the data itself.

1. Fundamentals: what a key really is

A key is just a string of bits; what makes it a key is being unguessable. The measure is entropy: how many of those bits are truly random. A key derived from SHA-256("password123") is 256 bits long but maybe 30 bits of entropy — it falls in seconds. Rule one: take keys from a CSPRNG (a generator whose output cannot be predicted from prior output), never from a human-typed string.

KeyGenerator kg = KeyGenerator.getInstance("AES");
kg.init(256, SecureRandom.getInstanceStrong());
SecretKey dek = kg.generateKey();          // 256-bit AES key

byte[] nonce = new byte[12];
new SecureRandom().nextBytes(nonce);       // 96-bit nonce for GCM

Symmetric crypto uses one key to encrypt and decrypt and is fast (AES, ChaCha20) but has a distribution problem. Asymmetric crypto uses a public/private pair, solves distribution, and is thousands of times slower (RSA, Ed25519, X25519). The real-world rule: asymmetric for key exchange and signatures, symmetric for the data itself — exactly what TLS and envelope encryption do.

AEAD: why "encrypting" is not enough

Encrypt with AES-CBC and an attacker cannot read your data — but they can change it: flipping a byte of ciphertext flips a known byte of plaintext. If that byte is amount, you are having a bad night.

AEAD (Authenticated Encryption with Associated Data) gives confidentiality and integrity: the output carries an authentication tag, and one tampered bit makes decryption throw. The AAD part is authenticated but not encrypted — say tenant_id — which stops an attacker moving ciphertext between rows.

public final class Aead {
    private static final int IV_LEN = 12;    // 96-bit, the NIST-recommended GCM IV size
    private static final int TAG_BITS = 128;

    public static byte[] encrypt(byte[] key, byte[] plaintext, byte[] aad) throws Exception {
        byte[] iv = new byte[IV_LEN];
        new SecureRandom().nextBytes(iv);
        Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
        c.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"),
               new GCMParameterSpec(TAG_BITS, iv));
        if (aad != null) c.updateAAD(aad);        // authenticated, not encrypted
        byte[] ct = c.doFinal(plaintext);
        return ByteBuffer.allocate(IV_LEN + ct.length).put(iv).put(ct).array();
    }

    // decrypt mirrors this with DECRYPT_MODE and the same IV/AAD;
    // if ciphertext or AAD was tampered with, doFinal throws AEADBadTagException.
}

2. The key lifecycle — the heart of the topic

Most teams implement exactly two stages: "make a key" and "use the key". The rest becomes urgent only when it is already too late.

The lifecycle states a cryptographic key moves through, from generation to destruction. — چرخهٔ حیات یک کلید رمزنگاری، از تولید تا نابودی.

stateDiagram-v2
    [*] --> PreActivation: generate (CSPRNG / HSM)
    PreActivation --> Active: activate
    Active --> Active: use (encrypt + decrypt)
    Active --> Deactivated: cryptoperiod ends / rotate
    Deactivated --> Deactivated: decrypt-only (legacy data)
    Active --> Compromised: incident detected
    Deactivated --> Compromised: incident detected
    Compromised --> Destroyed: emergency re-key
    Deactivated --> Destroyed: all data re-wrapped
    Destroyed --> [*]

1. Generation. From a CSPRNG or inside an HSM. A key generated in an HSM that never leaves in plaintext is "non-exportable" — the strongest assurance level.

2. Storage. A key never sits next to the data it protects. A wrapped DEK in the same row is fine (the KEK protects it), but the KEK belongs in a KMS/HSM. Key in the same table as the data = zero encryption.

3. Distribution. Best case, the key never reaches the service: the service has a workload identity and asks the KMS to decrypt on its behalf.

4. Rotation. Creating a new version and encrypting with it while old versions stay valid for decryption. Rotation without versioning means downtime. The window in which one key may be used is its cryptoperiod (NIST SP 800-57): typically at most one to two years for data-at-rest keys, sooner if the volume encrypted under it is large.

5. Revocation. The key stops being used for encryption but may still decrypt — or, on compromise, no use is permitted and you must re-key immediately.

6. Destruction. Securely erasing key material; the stage teams never perform, which is why a ten-year-old backup surfaces with a still-live key. Deliberate destruction is also a powerful tool: crypto-shredding (section 9).

3. Envelope encryption — the DEK/KEK model

If you take one thing from this chapter, take this.

Three practical reasons: (1) size and performance — cloud KMSes encrypt only small payloads directly (AWS KMS caps at 4 KB), so with envelopes just 32 bytes cross the network; (2) cheap rotation — rotating a KEK re-wraps DEKs only; (3) separation of authority — the service never sees the KEK, and every call is audited.

The full envelope-encryption flow for one write and one read. — جریان کامل envelope encryption برای یک نوشتن و یک خواندن.

sequenceDiagram
    participant App as Application
    participant KMS as KMS / Vault (KEK)
    participant DB as Database

    Note over App,DB: WRITE
    App->>KMS: GenerateDataKey(keyId, AES_256, encryptionContext)
    KMS-->>App: plaintextDEK + encryptedDEK
    App->>App: AES-GCM encrypt(payload, plaintextDEK, aad)
    App->>App: zeroise plaintextDEK in memory
    App->>DB: store {ciphertext, iv, encryptedDEK, keyVersion}

    Note over App,DB: READ
    DB-->>App: {ciphertext, iv, encryptedDEK, keyVersion}
    App->>KMS: Decrypt(encryptedDEK, encryptionContext)
    KMS-->>App: plaintextDEK
    App->>App: AES-GCM decrypt -> payload

# 1) create a KEK
aws kms create-key --description "payments-dek-wrapper" \
  --key-usage ENCRYPT_DECRYPT --key-spec SYMMETRIC_DEFAULT
aws kms create-alias --alias-name alias/payments-kek --target-key-id <key-id>

# 2) get a DEK: plaintext copy plus wrapped copy
aws kms generate-data-key --key-id alias/payments-kek --key-spec AES_256 \
  --encryption-context tenant=acme,table=cards --output json
# { "CiphertextBlob": "<base64>", "Plaintext": "<base64>", "KeyId": "arn:..." }

# 3) decrypt - the encryption context must match exactly
aws kms decrypt --ciphertext-blob fileb://dek.bin \
  --encryption-context tenant=acme,table=cards \
  --query Plaintext --output text | base64 --decode > dek.plain

# 4) rotate the KEK: any period from 90 to 2560 days, plus on-demand
aws kms enable-key-rotation --key-id alias/payments-kek --rotation-period-in-days 180
aws kms rotate-key-on-demand --key-id alias/payments-kek

public record Envelope(byte[] ciphertext, byte[] iv, byte[] wrappedDek, String kekVersion) {}

public Envelope protect(String pan, String tenantId) throws Exception {
    var dk = kms.generateDataKey(Map.of("tenant", tenantId, "field", "pan"));
    try {
        byte[] b = Aead.encrypt(dk.plaintext(), pan.getBytes(UTF_8), tenantId.getBytes(UTF_8));
        return new Envelope(Arrays.copyOfRange(b, 12, b.length),
                            Arrays.copyOfRange(b, 0, 12), dk.wrapped(), dk.kekVersion());
    } finally {
        Arrays.fill(dk.plaintext(), (byte) 0);   // wipe the key from memory
    }
}

Key material never belongs in a String: Java strings are immutable and linger on the heap until GC, surfacing in heap dumps, core dumps and sometimes swap. Use byte[]/char[] and zero them after use — this is why KeyStore.PasswordProtection takes char[]. JIT and GC may still leave copies, which is why in truly sensitive systems the key never enters the JVM at all.

4. KMS: from concept to Vault

A KMS holds key material and, instead of handing you the key, performs the operation for you — a shift from "give me the key" to "do this operation". Every serious KMS offers four things: a key policy, versioning, an audit log, and a backing store (software, or HSM-backed with a FIPS certificate).

Vault: four concepts you must know

1. Seal / unseal. Vault starts sealed: its storage is encrypted and even Vault cannot read it. The master key is split with Shamir's Secret Sharing and unsealing needs a quorum of shares — say 3 of 5. In production you use auto-unseal backed by a cloud KMS or HSM.

2. Transit engine — encryption as a service. The key never leaves Vault; you send plaintext and get ciphertext.

vault secrets enable transit
vault write -f transit/keys/payments                    # default type: aes256-gcm96

vault write transit/encrypt/payments plaintext=$(printf '4111111111111111' | base64)
# ciphertext = vault:v1:8SDd3WHDOjf7mq69CyCq...

vault write -field=plaintext transit/decrypt/payments \
  ciphertext="vault:v1:8SDd3WHDOjf7mq69CyCq..." | base64 --decode

vault write -f transit/keys/payments/rotate             # v2 created; v1 still decrypts
vault write transit/keys/payments/config auto_rotate_period=720h   # minimum one hour
vault write transit/rewrap/payments ciphertext="vault:v1:8SDd3W..."  # never sees plaintext
vault write transit/keys/payments/config min_decryption_version=2    # retire v1

vault write -f transit/datakey/plaintext/payments       # envelope: DEK + wrapped copy
vault write -f transit/datakey/wrapped/payments         # wrapped only

3. Dynamic secrets. Instead of one static database user with a static password, Vault creates a user on demand and deletes it when the TTL expires.

vault secrets enable database

vault write database/config/payments-pg \
  plugin_name="postgresql-database-plugin" \
  connection_url="postgresql://{{username}}:{{password}}@pg.internal:5432/payments?sslmode=require" \
  allowed_roles="payments-app" username="vault_root" password="<bootstrap>"

vault write -force database/rotate-root/payments-pg   # now not even you know the root password

vault write database/roles/payments-app db_name=payments-pg \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';" \
  default_ttl="1h" max_ttl="24h"

vault read database/creds/payments-app     # username/password/lease_id, one-hour lifetime

4. Leases. Every dynamic secret has a lease_id and lease_duration; the client must renew or Vault deletes the user.

vault lease renew  database/creds/payments-app/xxxx
vault lease revoke database/creds/payments-app/xxxx
vault lease revoke -prefix database/creds/payments-app   # bulk revocation during an incident

5. HSM — why banks do not settle for software

An HSM (Hardware Security Module) is dedicated hardware for generating, storing and using keys that never releases them in plaintext; access is usually via PKCS#11 (which Java reaches through the SunPKCS11 provider) or KMIP. FIPS 140 is the validation standard for cryptographic modules; certificates are issued through the CMVP, run jointly by NIST and the Canadian Centre for Cyber Security.

Why payments genuinely needs an HSM

1. A PIN must never sit in software memory. When a customer enters a PIN, the device formats it into a PIN block (ISO 9564; formats 0, 1, 3 and today AES-based format 4) and encrypts it immediately. From that instant until the issuer's HSM the PIN never exists in plaintext; operations such as "translate the PIN block from the acquirer key to the issuer key" happen only inside an HSM.

2. Inter-organisation key exchange. The ANSI X9.24 / TR-31 key block standard requires a key to travel with its attributes (what it may be used for) inside an authenticated block, so an attacker cannot repurpose a PIN key as a data key; the phase-3 deadline across the PCI PIN ecosystem was 1 January 2025. A related pattern is DUKPT: every transaction uses a key derived from a base key, so leaking one does not leak the others.

3. Audit obligation. An assessor wants evidence that keys live in a "secure cryptographic device" and that manual operations on plaintext keys use split knowledge and dual control.

The physical ceremony that generates a master key inside an HSM. — مراسم تولید کلید اصلی در محیط پرداخت.

flowchart TD
    A[Ceremony scheduled: date, room, witnesses] --> B[Room swept — phones removed]
    B --> C[HSM set to secure state — tamper seals recorded]
    C --> D[Custodian 1 enters component 1 via smartcard]
    D --> E[Custodian 2 enters component 2 via smartcard]
    E --> F[HSM combines components into the master key]
    F --> G[HSM prints KCV: key check value]
    G --> H[Components sealed in tamper-evident envelopes]
    H --> I[Stored in separate safes, different custodians]
    I --> J[Ceremony log signed by all parties and auditor]

Split knowledge means no single person knows the whole key; dual control means no operation happens with one person present. The KCV is a short fingerprint of the key (the first bytes of encrypting a zero block) letting two parties confirm they hold the same key without revealing it.

6. Secrets in practice: from .env to Kubernetes

A Kubernetes Secret stores values in base64. base64 is an encoding, not encryption: no key, one command to reverse.

kubectl get secret payments-db -o jsonpath='{.data.password}' | base64 --decode

So a Secret is exactly as safe as two things: RBAC on the secrets resource, and etcd encryption at rest. Without both it is a ConfigMap wearing makeup.

# on the control plane; passed via --encryption-provider-config=/etc/kubernetes/enc.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - kms:                    # KMS v2 is stable (GA) since Kubernetes 1.29
          apiVersion: v2
          name: cloud-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
          timeout: 3s
      - identity: {}            # decrypt-only fallback; must always be last

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

GitOps and secrets: two mature patterns

You want everything in git, but secrets must not be in git.

1. Sealed Secrets — encrypt, then commit. A controller in the cluster holds a keypair; you encrypt with the public key and commit the result safely.

kubectl create secret generic payments-db --from-literal=password='S3cr3t!' \
  --dry-run=client -o yaml > secret.yaml

kubeseal --format yaml < secret.yaml > sealed-secret.yaml   # commit this
kubeseal --cert pub-cert.pem --format yaml < secret.yaml    # offline, e.g. in CI
kubeseal --re-encrypt < sealed-secret.yaml > tmp.yaml       # re-seal with the newest key

The default scope is strict: name and namespace are bound into the encryption, so the file will not unseal elsewhere. --scope namespace-wide and --scope cluster-wide loosen that — less safe, not more. Sealing keys renew automatically every 30 days.

2. External Secrets Operator — the secret is never in git, only a pointer.

apiVersion: external-secrets.io/v1
kind: SecretStore
metadata: { name: vault-backend, namespace: payments }
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "kv"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "payments-app"
          serviceAccountRef: { name: payments-app }
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata: { name: payments-db, namespace: payments }
spec:
  refreshInterval: "1h"
  secretStoreRef: { name: vault-backend, kind: SecretStore }
  target: { name: payments-db-secret, creationPolicy: Owner }
  data:
    - secretKey: password
      remoteRef: { key: payments/db, property: password }

How a secret travels from its source of truth to a running pod under GitOps. — مسیر رسیدن یک راز از منبع حقیقت تا پاد در یک استقرار GitOps.

flowchart LR
    Dev[Engineer] -->|writes secret| Vault[(Vault / Cloud KMS)]
    Dev -->|commits reference only| Git[(Git repo)]
    Git --> ESO[External Secrets Operator]
    ESO -->|k8s auth with ServiceAccount| Vault
    Vault -->|secret value| ESO
    ESO -->|creates and refreshes| Sec[K8s Secret]
    Sec -->|mounted as file| Pod[Application Pod]

When a secret reaches git

A leaked secret cannot be "deleted", only invalidated. Rotate first, clean history second — the repo may already be forked or cloned.

gitleaks git --redact -v --report-format sarif --report-path gitleaks.sarif .
gitleaks dir --redact -v .                            # scan the working tree, no git
trufflehog git file://. --only-verified --fail        # is this token still live?
git filter-repo --invert-paths --path config/prod-secrets.yml   # after rotating!

Add the gitleaks hook to .pre-commit-config.yaml for prevention. The mature pattern has three layers: a hook on the laptop, a CI scan with live verification, and a platform-side scan for when someone used --no-verify.

7. Spring Boot in practice

Jasypt — encrypted properties in the same file

<dependency>
  <groupId>com.github.ulisesbocchio</groupId>
  <artifactId>jasypt-spring-boot-starter</artifactId>
  <version>4.0.4</version>   <!-- requires Java 17+ and Spring Boot 3.5+ -->
</dependency>

mvn jasypt:encrypt-value -Djasypt.encryptor.password="$JASYPT_MASTER" \
                         -Djasypt.plugin.value="my-db-password"
export JASYPT_ENCRYPTOR_PASSWORD='...'   # the master key never lives in a file

spring:
  datasource:
    password: ENC(bkHFHmYvL2Nl9DkVc4Yy1V0BqPjF5W...)
jasypt:
  encryptor:
    algorithm: PBEWITHHMACSHA512ANDAES_256   # default in 3.x/4.x
    key-obtention-iterations: 100000          # the default is 1000 - raise it

Spring Cloud Config Server

keytool -genkeypair -alias config-server-key -keyalg RSA -keysize 4096 \
  -dname "CN=Config Server,OU=Platform,O=Example,L=City,S=State,C=US" \
  -keystore server.jks -storetype PKCS12 -storepass changeit -keypass changeit

curl -s localhost:8888/encrypt -d 'my-db-password'   # -> a1b2c3...

encrypt:                       # on the config server itself
  key-store:
    location: file:/etc/config/server.jks
    password: changeit
    alias: config-server-key
    secret: changeit

spring.datasource.password={cipher}a1b2c3d4e5f6...   # in the config git repo

By default the server decrypts before responding — the plaintext crosses the network, so TLS and authentication between service and config server are mandatory. Setting spring.cloud.config.server.encrypt.enabled=false sends ciphertext all the way to the client, but then every client needs the key.

Spring Cloud Vault — the default choice at scale

Since 3.0, configuration is loaded through the ConfigData API: spring.config.import, not bootstrap.yml.

spring:
  config:
    import: "vault://"
  cloud:
    vault:
      uri: https://vault.internal:8200
      authentication: KUBERNETES     # the pod's own identity, no bootstrap secret
      kubernetes:
        role: payments-app
        kubernetes-path: kubernetes
        service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token
      kv:
        enabled: true
        backend: kv
        application-name: payments
      database:
        enabled: true                # dynamic credentials
        role: payments-app
        backend: database
        username-property: spring.datasource.username
        password-property: spring.datasource.password
      config.lifecycle:
        enabled: true                # automatic lease renewal
        min-renewal: 10s

@Service
public class PanCipher {                       // transit: encryption as a service
    private final VaultTransitOperations transit;
    public PanCipher(VaultOperations vault) { this.transit = vault.opsForTransit(); }
    public String protect(String pan)  { return transit.encrypt("payments", pan); }
    public String reveal(String token) { return transit.decrypt("payments", token); }
}

8. Encryption at rest and in transit

In transit means on the wire: TLS 1.3, mTLS between services, sslmode=verify-full for the database. At rest means on disk — with several very different layers whose confusion is the most common audit misunderstanding.

-- PostgreSQL still has no native TDE; the equivalents are disk/filesystem
-- encryption, or column-level encryption:
CREATE EXTENSION IF NOT EXISTS pgcrypto;

CREATE TABLE card (
  id        bigserial PRIMARY KEY,
  pan_enc   bytea   NOT NULL,      -- ciphertext produced in the application
  pan_last4 char(4) NOT NULL,      -- for display
  pan_bidx  bytea   NOT NULL       -- blind index for lookups
);
CREATE INDEX ON card (pan_bidx);

-- Oracle has native TDE. Open the keystore and encrypt a tablespace online:
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN
  IDENTIFIED BY "wallet_pwd" CONTAINER = CURRENT;
ALTER TABLESPACE users ENCRYPTION ONLINE USING 'AES256' ENCRYPT;

CREATE TABLE card (
  id        NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  pan       VARCHAR2(19) ENCRYPT USING 'AES256' NO SALT,  -- native column TDE
  pan_last4 CHAR(4) NOT NULL,
  pan_bidx  RAW(32) NOT NULL
);
CREATE INDEX card_bidx_ix ON card (pan_bidx);

-- Compute the HMAC in the application and send ready bytes; this shows the concept only
SELECT id, pan_last4 FROM card
WHERE  pan_bidx = hmac('4111111111111111', :bidx_key, 'sha256');

SELECT id, pan_last4 FROM card
WHERE  pan_bidx = DBMS_CRYPTO.MAC(
         UTL_I18N.STRING_TO_RAW('4111111111111111', 'AL32UTF8'),
         DBMS_CRYPTO.HMAC_SH256, UTL_RAW.CAST_TO_RAW(:bidx_key));

9. Tokenization, encryption and masking — and PCI-DSS

How tokenization keeps real card data inside one small, audited service. — جریان tokenization و اینکه چطور scope را کوچک نگه می‌دارد.

flowchart LR
    UI[Checkout page] -->|PAN over TLS| TS[Tokenization service<br/>in PCI scope]
    TS -->|encrypted PAN via KMS| TV[(Token vault)]
    TS -->|token: tok_9f3a| ORD[Order service]
    ORD --> BILL[Billing service]
    ORD --> ANA[Analytics]
    BILL -->|token| TS
    TS -->|detokenised PAN| PSP[Acquirer / PSP]

Cardholder data is the PAN, name, expiry and service code; sensitive authentication data (SAD) is full track content, CVV/CVC/CID, and the PIN or PIN block.

The iron rule: SAD is never stored after authorization — not even encrypted. That is requirement 3.3 in PCI DSS v4.0.1, with an exception only for issuers. There must be no column named cvv anywhere: not temporarily, not in logs, not in a staging table.

PAN may be stored but must be rendered unreadable (3.5.1): strong encryption, truncation, tokenization or hashing. A key change in v4: the hash must be keyed (3.5.1.1) — SHA-256(PAN) no longer suffices because the PAN space is enumerable; it must be an HMAC. For display (3.4.1) at most the first six and last four digits, and only for a proven business need.

public static String maskPan(String pan) {           // safe display, not safe storage
    return pan.substring(0, 6) + "*".repeat(pan.length() - 10) + pan.substring(pan.length() - 4);
}

10. Data minimisation, crypto-shredding and auditing

Data minimisation is the simplest and strongest control: data you never stored cannot leak. Three questions before any encryption discussion: do we truly need this field? Full value or a derivative (birth year instead of full date, BIN instead of PAN)? How long must we retain it?

Crypto-shredding is the engineering answer to the right to erasure: give every user or tenant a separate DEK and, to delete, destroy only that key. Encrypted data in every backup, replica and Kafka partition becomes meaningless bytes instantly.

public void forget(String userId) {                  // deletion without touching a row
    kms.scheduleKeyDeletion(dekKeyIdFor(userId));    // AWS enforces a 7-day minimum wait
}

Three common failures: all users share one DEK (destroying it destroys everyone); the key was copied elsewhere and "destruction" catches one copy; and derived data in the analytics warehouse was never encrypted under that key. A legal note: some regulators accept crypto-shredding as deletion and some do not — settle that before relying on it.

Auditing key usage

Record three things: who (the workload identity, not just an IP), on what (the encryption context), and the outcome. Alert on a sudden jump in Decrypt rate from one service (bulk exfiltration), decrypt calls from a service that never made them, and AccessDenied failures on a key (probing).

And note that under envelope encryption KMS call rate no longer tracks data volume: one Decrypt can unwrap a DEK that opens millions of records. So count "how many records were opened with this DEK" at the application level too.

11. Crypto-agility and post-quantum readiness

Crypto-agility is the ability to swap algorithm, key size or library without rewriting the application. Three prerequisites: (1) an identifier next to the data — every ciphertext must declare which algorithm and key version produced it (what vault:v1: does); (2) an abstraction in code — the application talks to a CryptoService, not to Cipher.getInstance(...) scattered across 40 classes; (3) a cryptographic inventory, which PCI DSS v4 formalises in requirement 12.3.3, reviewed at least annually.

A sufficiently large quantum computer running Shor's algorithm breaks RSA and elliptic-curve cryptography. No such machine exists yet, but harvest now, decrypt later is real today: an attacker stores encrypted traffic and opens it ten years later. The good news is that symmetric crypto holds up — Grover reduces search from 2ⁿ to 2^(n/2), so AES-256 keeps an acceptable margin. The problem is key exchange and signatures.

In 2025 HQC was also selected as a backup KEM with different mathematical foundations, so a future attack on lattices would not take everything down at once. On the Java side, JDK 24 added ML-KEM via JEP 496 and ML-DSA via JEP 497; full TLS integration in JSSE is still on the way, while TLS libraries and proxies (OpenSSL 3.5 and later) already support hybrid groups such as X25519MLKEM768.

12. Command cheat sheet