feat(sdk): DSPX-3309 add hybrid post-quantum key wrapping for KAS (X-Wing, ECDH+ML-KEM)#368
Open
sujankota wants to merge 9 commits into
Open
feat(sdk): DSPX-3309 add hybrid post-quantum key wrapping for KAS (X-Wing, ECDH+ML-KEM)#368sujankota wants to merge 9 commits into
sujankota wants to merge 9 commits into
Conversation
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR implements hybrid post-quantum cryptography (X‑Wing and NIST ECDH+ML‑KEM hybrids) for TDF, including envelope marshaling, wrap-key derivation via HKDF-SHA256 and AES-GCM encryption, TDF manifest integration, comprehensive unit and integration tests, Maven build wiring, and a developer-facing integration test script with documentation. ChangesHybrid Post-Quantum Cryptography
Maven Build Infrastructure
Integration Test Script and Documentation
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces support for hybrid post-quantum key wrapping, specifically X-Wing (X25519 + ML-KEM-768) and NIST hybrid schemes (P-256/P-384 + ML-KEM). It adds new classes for cryptographic operations and ASN.1 envelope management, updates the KeyType enum, and integrates these capabilities into the TDF creation process. Feedback recommends specifying the UTF-8 character set when converting strings to bytes and suggests explicitly referencing the BouncyCastle provider in cryptographic calls to ensure platform consistency and avoid provider ambiguity.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
sdk/src/main/java/io/opentdf/platform/sdk/XWingKeyPair.java (1)
12-13: ⚡ Quick winClear the derived secrets after wrap/unwrap.
sharedSecretandwrapKeystay live until GC on both paths. In the wrapping primitive itself, this is worth clearing in afinallyblock once AES-GCM completes.💡 Suggested fix
import java.security.SecureRandom; +import java.util.Arrays; @@ - SecretWithEncapsulation enc = new XWingKEMGenerator(new SecureRandom()).generateEncapsulated(pub); - byte[] sharedSecret = enc.getSecret(); - byte[] ciphertext = enc.getEncapsulation(); - - byte[] wrapKey = HybridCrypto.deriveWrapKey(sharedSecret, null, null); - byte[] encryptedDek = new AesGcm(wrapKey).encrypt(dek).asBytes(); - return HybridCrypto.marshalEnvelope(ciphertext, encryptedDek); + SecretWithEncapsulation enc = new XWingKEMGenerator(new SecureRandom()).generateEncapsulated(pub); + byte[] sharedSecret = enc.getSecret(); + byte[] ciphertext = enc.getEncapsulation(); + byte[] wrapKey = null; + try { + wrapKey = HybridCrypto.deriveWrapKey(sharedSecret, null, null); + byte[] encryptedDek = new AesGcm(wrapKey).encrypt(dek).asBytes(); + return HybridCrypto.marshalEnvelope(ciphertext, encryptedDek); + } finally { + Arrays.fill(sharedSecret, (byte) 0); + if (wrapKey != null) { + Arrays.fill(wrapKey, (byte) 0); + } + } @@ - byte[] sharedSecret = new XWingKEMExtractor(priv).extractSecret(ciphertext); - byte[] wrapKey = HybridCrypto.deriveWrapKey(sharedSecret, null, null); - return new AesGcm(wrapKey).decrypt(new AesGcm.Encrypted(encryptedDek)); + byte[] sharedSecret = new XWingKEMExtractor(priv).extractSecret(ciphertext); + byte[] wrapKey = null; + try { + wrapKey = HybridCrypto.deriveWrapKey(sharedSecret, null, null); + return new AesGcm(wrapKey).decrypt(new AesGcm.Encrypted(encryptedDek)); + } finally { + Arrays.fill(sharedSecret, (byte) 0); + if (wrapKey != null) { + Arrays.fill(wrapKey, (byte) 0); + } + }Also applies to: 67-73, 87-90
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@sdk/src/main/java/io/opentdf/platform/sdk/XWingKeyPair.java` around lines 12 - 13, In XWingKeyPair.java ensure derived secrets are explicitly cleared after use: locate the methods that perform wrapping/unwrapping (e.g., the wrap/unwrap primitives around sharedSecret and wrapKey) and add try { ... } finally { Arrays.fill(sharedSecret, (byte)0); Arrays.fill(wrapKey, (byte)0); sharedSecret = null; wrapKey = null; } (or equivalent) so both success and exception paths wipe and null out the byte[] secrets; apply the same pattern to the other occurrences noted around the blocks at the other wrap/unwrap usages (lines referenced 67-73 and 87-90).sdk/src/main/java/io/opentdf/platform/sdk/HybridNISTKeyPair.java (1)
203-207: ⚡ Quick winZero the hybrid shared secrets on both paths.
ecdhSecret,mlSecret,combinedSecret, andwrapKeyall remain in heap memory after the DEK is processed. Given this sits at the core crypto boundary, clear them infinallyblocks.💡 Suggested fix
- byte[] combinedSecret = concat(ecdhSecret, mlSecret); - byte[] hybridCt = concat(ephemeralEcPub, mlCiphertext); - byte[] wrapKey = HybridCrypto.deriveWrapKey(combinedSecret, null, null); - byte[] encryptedDek = new AesGcm(wrapKey).encrypt(dek).asBytes(); - return HybridCrypto.marshalEnvelope(hybridCt, encryptedDek); + byte[] combinedSecret = null; + byte[] wrapKey = null; + try { + combinedSecret = concat(ecdhSecret, mlSecret); + byte[] hybridCt = concat(ephemeralEcPub, mlCiphertext); + wrapKey = HybridCrypto.deriveWrapKey(combinedSecret, null, null); + byte[] encryptedDek = new AesGcm(wrapKey).encrypt(dek).asBytes(); + return HybridCrypto.marshalEnvelope(hybridCt, encryptedDek); + } finally { + Arrays.fill(ecdhSecret, (byte) 0); + Arrays.fill(mlSecret, (byte) 0); + if (combinedSecret != null) { + Arrays.fill(combinedSecret, (byte) 0); + } + if (wrapKey != null) { + Arrays.fill(wrapKey, (byte) 0); + } + } @@ - byte[] combinedSecret = concat(ecdhSecret, mlSecret); - byte[] wrapKey = HybridCrypto.deriveWrapKey(combinedSecret, null, null); - return new AesGcm(wrapKey).decrypt(new AesGcm.Encrypted(encryptedDek)); + byte[] combinedSecret = null; + byte[] wrapKey = null; + try { + combinedSecret = concat(ecdhSecret, mlSecret); + wrapKey = HybridCrypto.deriveWrapKey(combinedSecret, null, null); + return new AesGcm(wrapKey).decrypt(new AesGcm.Encrypted(encryptedDek)); + } finally { + Arrays.fill(ecdhSecret, (byte) 0); + Arrays.fill(mlSecret, (byte) 0); + if (combinedSecret != null) { + Arrays.fill(combinedSecret, (byte) 0); + } + if (wrapKey != null) { + Arrays.fill(wrapKey, (byte) 0); + } + }Also applies to: 231-235
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@sdk/src/main/java/io/opentdf/platform/sdk/HybridNISTKeyPair.java` around lines 203 - 207, The shared-secret bytes (ecdhSecret, mlSecret, combinedSecret, wrapKey) in HybridNISTKeyPair must be zeroed after use; wrap the encryption and the corresponding decryption path (the block around deriveWrapKey/encrypt and the block referenced at 231-235) in try/finally so that in each finally you overwrite each secret byte[] (e.g., Arrays.fill(..., (byte)0) or equivalent) and null out references to avoid lingering heap data; ensure you zero ecdhSecret, mlSecret, combinedSecret, and wrapKey regardless of success or exception and do so in the same methods that call HybridCrypto.deriveWrapKey, AesGcm.encrypt, and HybridCrypto.unmarshal/unwrap to guarantee cleanup.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@sdk/src/main/java/io/opentdf/platform/sdk/HybridCrypto.java`:
- Around line 74-100: The ASN.1 parsing can throw IllegalArgumentException and
IllegalStateException (e.g., ASN1ParsingException) which currently escape
normalization; update the code to catch and wrap those in SDKException.
Specifically, in unmarshalEnvelope around the
ASN1InputStream/ASN1Sequence.getInstance calls add handlers for
IllegalArgumentException and IllegalStateException (or a multi-catch alongside
IOException) and rethrow new SDKException(..., e). Also update
readImplicitOctetString to guard the ASN1TaggedObject.getInstance and
ASN1OctetString.getInstance calls with a try/catch for
IllegalArgumentException/IllegalStateException and throw an SDKException with a
clear message; refer to the methods unmarshalEnvelope and
readImplicitOctetString and the BouncyCastle calls ASN1Sequence.getInstance,
ASN1TaggedObject.getInstance, and ASN1OctetString.getInstance when locating
changes.
In `@sdk/src/main/java/io/opentdf/platform/sdk/KeyType.java`:
- Around line 18-20: Add the three new hybrid enum constants to both factory
switch statements so fromAlgorithm(...) and fromPublicKeyAlgorithm(...) return
the correct KeyType for HybridXWingKey, HybridSecp256r1MLKEM768Key, and
HybridSecp384r1MLKEM1024Key; locate the switch in the KeyType enum's
fromAlgorithm(...) method and the switch in fromPublicKeyAlgorithm(...) and add
matching case entries that map the corresponding protobuf algorithm enum values
to these KeyType constants to avoid IllegalArgumentException when those protobuf
values are encountered.
---
Nitpick comments:
In `@sdk/src/main/java/io/opentdf/platform/sdk/HybridNISTKeyPair.java`:
- Around line 203-207: The shared-secret bytes (ecdhSecret, mlSecret,
combinedSecret, wrapKey) in HybridNISTKeyPair must be zeroed after use; wrap the
encryption and the corresponding decryption path (the block around
deriveWrapKey/encrypt and the block referenced at 231-235) in try/finally so
that in each finally you overwrite each secret byte[] (e.g., Arrays.fill(...,
(byte)0) or equivalent) and null out references to avoid lingering heap data;
ensure you zero ecdhSecret, mlSecret, combinedSecret, and wrapKey regardless of
success or exception and do so in the same methods that call
HybridCrypto.deriveWrapKey, AesGcm.encrypt, and HybridCrypto.unmarshal/unwrap to
guarantee cleanup.
In `@sdk/src/main/java/io/opentdf/platform/sdk/XWingKeyPair.java`:
- Around line 12-13: In XWingKeyPair.java ensure derived secrets are explicitly
cleared after use: locate the methods that perform wrapping/unwrapping (e.g.,
the wrap/unwrap primitives around sharedSecret and wrapKey) and add try { ... }
finally { Arrays.fill(sharedSecret, (byte)0); Arrays.fill(wrapKey, (byte)0);
sharedSecret = null; wrapKey = null; } (or equivalent) so both success and
exception paths wipe and null out the byte[] secrets; apply the same pattern to
the other occurrences noted around the blocks at the other wrap/unwrap usages
(lines referenced 67-73 and 87-90).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d2649e03-5d69-4cad-bbe5-02e23e6fc142
📒 Files selected for processing (7)
sdk/src/main/java/io/opentdf/platform/sdk/HybridCrypto.javasdk/src/main/java/io/opentdf/platform/sdk/HybridNISTKeyPair.javasdk/src/main/java/io/opentdf/platform/sdk/KeyType.javasdk/src/main/java/io/opentdf/platform/sdk/TDF.javasdk/src/main/java/io/opentdf/platform/sdk/XWingKeyPair.javasdk/src/test/java/io/opentdf/platform/sdk/HybridCryptoTest.javasdk/src/test/java/io/opentdf/platform/sdk/TDFHybridTest.java
Contributor
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/README.md`:
- Line 79: The fenced code block missing a language tag should be updated to use
a language identifier (e.g., add "text") so markdownlint MD040 is satisfied;
change the opening fence from ``` to ```text for the block that contains the
"[OK] hpqt:..." lines and ensure the closing fence remains ``` so rendering
and linting are correct.
In `@scripts/test-hybrid-pqc.sh`:
- Around line 38-50: The option parsing loop currently reads values for flags
like --algorithms, --platform-endpoint, --kas-url, --attr, --client-id, and
--client-secret without verifying a following argument, which under set -u can
cause a shell error; update the case branches that assign to ALGORITHMS,
PLATFORM_ENDPOINT, KAS_URL, DATA_ATTR, CLIENT_ID, and CLIENT_SECRET to first
validate that "$2" exists and is not another option (e.g., [[ -n "${2-}" &&
"${2:0:1}" != "-" ]]) and if the check fails print the usage/help and exit with
the same misuse exit code (2), leaving the boolean flags (--skip-build,
--skip-kas-check) unchanged.
- Around line 197-198: The envelope-check fails on macOS/BSD because the script
calls `base64 -d` and `xxd`; update the decoding/byte-extraction to be portable
by trying `base64 -d` and falling back to `base64 -D` (or vice versa) when
decoding the `wrapped` variable, and replace the `xxd -p -l 1` usage with an
`od` invocation (e.g. `od -An -tx1 -N1`) to reliably produce the first byte in
hex; modify the assignment around `first_byte=$(... )` and any place referencing
`xxd`/`base64` so it uses this portable approach while preserving the existing
`wrapped` variable and the subsequent `if [[ "$first_byte" != "30" ]]` check.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 9a4a0dd5-861a-469c-9eb2-0033e49a9b50
📒 Files selected for processing (2)
scripts/README.mdscripts/test-hybrid-pqc.sh
Contributor
Contributor
X-Test Failure Report |
sujankota
force-pushed
the
DSPX-3309-hybrid-pq-key-wrapping
branch
from
6e08ea4 to
d666c07
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (3)
scripts/README.md (1)
80-80:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAdd a language tag to the expected-output code fence.
Line 80 still uses an untyped fenced block and will keep triggering MD040.
Proposed fix
-``` +```text [OK] hpqt:xwing: KAS returns hybrid PEM (-----BEGIN XWING PUBLIC KEY-----) [OK] hpqt:secp256r1-mlkem768: KAS returns hybrid PEM (-----BEGIN SECP256R1 MLKEM768 PUBLIC KEY-----) [OK] hpqt:secp384r1-mlkem1024: KAS returns hybrid PEM (-----BEGIN SECP384R1 MLKEM1024 PUBLIC KEY-----) ... [OK] HybridXWingKey: manifest OK (hybrid-wrapped, ASN.1 envelope, no ephemeralPublicKey) [OK] HybridXWingKey: round-trip OK ... All 3 hybrid algorithm(s) passed round-trip.</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@scripts/README.mdat line 80, The fenced expected-output block around the
test output is missing a language tag and triggers MD040; update the openingto include a language (e.g., change the opening fence totext) so the block
is typed and the linter stops flagging it—target the expected-output fenced
block shown in the diff (the multi-line sample starting with "[OK]
hpqt:xwing...") and add the language tag to its opening fence.</details> </blockquote></details> <details> <summary>scripts/test-hybrid-pqc.sh (2)</summary><blockquote> `197-197`: _⚠️ Potential issue_ | _🟠 Major_ | _⚡ Quick win_ **Make wrappedKey decode check portable across GNU/BSD tools.** Line 197 uses GNU-specific `base64 -d` behavior and `xxd`, which can fail on macOS/BSD or minimal environments. <details> <summary>Proposed fix</summary> ```diff +b64decode() { + if printf 'MA==\n' | base64 -d >/dev/null 2>&1; then + base64 -d + else + base64 -D + fi +} + - first_byte=$(base64 -d <<<"$wrapped" 2>/dev/null | xxd -p -l 1 || true) + first_byte=$(b64decode <<<"$wrapped" 2>/dev/null | od -An -tx1 -N1 | tr -d ' \n' || true) ``` </details> ```shell #!/bin/bash set -euo pipefail # Inspect current implementation around the envelope check cat -n scripts/test-hybrid-pqc.sh | sed -n '190,205p' # Show local base64 flag support (illustrates GNU/BSD divergence risk) printf 'supports base64 -d: ' printf 'MA==\n' | base64 -d >/dev/null 2>&1 && echo yes || echo no printf 'supports base64 -D: ' printf 'MA==\n' | base64 -D >/dev/null 2>&1 && echo yes || echo no # Show whether xxd is present (currently an undeclared dependency) if command -v xxd >/dev/null 2>&1; then echo 'xxd: present' else echo 'xxd: missing' fi ``` <details> <summary>🤖 Prompt for AI Agents</summary> ``` Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@scripts/test-hybrid-pqc.sh` at line 197, The current line that sets first_byte using `base64 -d` and `xxd` is not portable; change the decode+hex extraction to use a portable fallback: try `base64 --decode` (or `base64 -D`) and if that fails try `base64 -d`, and replace `xxd -p -l 1` with a portable tool like `od -An -tx1 -N1` (or `hexdump -v -n 1 -e '1/1 "%02x"'`) to extract the first byte; update the assignment to `first_byte=$(printf '%s' "$wrapped" | base64 --decode 2>/dev/null || printf '%s' "$wrapped" | base64 -D 2>/dev/null || printf '%s' "$wrapped" | base64 -d 2>/dev/null | od -An -tx1 -N1 | tr -d ' \t\n')` (or equivalent fallback sequence) so `first_byte` production works on GNU/BSD/macOS and when `xxd` is absent in scripts/test-hybrid-pqc.sh. ``` </details> --- `42-47`: _⚠️ Potential issue_ | _🟠 Major_ | _⚡ Quick win_ **Guard value-taking flags before reading `$2`.** Line 42–47 can crash under `set -u` when a flag is missing its value, bypassing the documented misuse path (`exit 2`). <details> <summary>Proposed fix</summary> ```diff +require_opt_value() { + local opt="$1" + local val="${2-}" + if [[ -z "$val" || "$val" == --* ]]; then + echo "missing value for $opt" >&2 + exit 2 + fi +} + while [[ $# -gt 0 ]]; do case "$1" in --skip-build) SKIP_BUILD=1; shift ;; --skip-kas-check) SKIP_KAS_CHECK=1; shift ;; - --algorithms) IFS=, read -r -a ALGORITHMS <<< "$2"; shift 2 ;; - --platform-endpoint) PLATFORM_ENDPOINT="$2"; shift 2 ;; - --kas-url) KAS_URL="$2"; shift 2 ;; - --attr) DATA_ATTR="$2"; shift 2 ;; - --client-id) CLIENT_ID="$2"; shift 2 ;; - --client-secret) CLIENT_SECRET="$2"; shift 2 ;; + --algorithms) require_opt_value "$1" "${2-}"; IFS=, read -r -a ALGORITHMS <<< "$2"; shift 2 ;; + --platform-endpoint) require_opt_value "$1" "${2-}"; PLATFORM_ENDPOINT="$2"; shift 2 ;; + --kas-url) require_opt_value "$1" "${2-}"; KAS_URL="$2"; shift 2 ;; + --attr) require_opt_value "$1" "${2-}"; DATA_ATTR="$2"; shift 2 ;; + --client-id) require_opt_value "$1" "${2-}"; CLIENT_ID="$2"; shift 2 ;; + --client-secret) require_opt_value "$1" "${2-}"; CLIENT_SECRET="$2"; shift 2 ;; -h|--help) sed -n '2,/^$/p' "$0" | sed 's/^# \{0,1\}//'; exit 0 ;; *) echo "unknown option: $1" >&2; exit 2 ;; esac done ``` </details> <details> <summary>🤖 Prompt for AI Agents</summary> ``` Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@scripts/test-hybrid-pqc.sh` around lines 42 - 47, The parsing for value-taking flags (--algorithms, --platform-endpoint, --kas-url, --attr, --client-id, --client-secret) reads "$2" unguarded which can cause a crash under set -u when a value is missing; update the argument parsing to first validate that a next positional exists and is not another flag (e.g., check that $# -ge 2 and that "$2" does not start with --) before assigning to ALGORITHMS, PLATFORM_ENDPOINT, KAS_URL, DATA_ATTR, CLIENT_ID, or CLIENT_SECRET, and if the check fails print the misuse message and exit 2 to preserve the documented behavior. ``` </details> </blockquote></details> </blockquote></details> <details> <summary>🤖 Prompt for all review comments with AI agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.Inline comments:
In@sdk/src/main/java/io/opentdf/platform/sdk/HybridCrypto.java:
- Around line 129-147: readLength() currently accepts non-canonical DER length
encodings (long-form for values < 0x80 and leading-zero length bytes); fix it by
reading the long-form length bytes into a temporary byte[] (instead of
accumulating immediately), reject if bytes[0] == 0 (leading zero), compute the
decoded len from that array, then compute the minimal number of bytes required
for that len and throw an SDKException if numBytes != minimalBytes (or if len <
0x80 when long-form was used); keep other checks (numBytes==0 or >4 and
overflow) and throw SDKException on violations so unmarshalEnvelope() enforces
strict DER canonical lengths.- Around line 3-5: defaultTDFSalt() currently calls "TDF".getBytes() which
depends on the JVM default charset; change it to use an explicit charset (e.g.,
StandardCharsets.UTF_8) so the HKDF salt is deterministic across platforms;
update the method (defaultTDFSalt) to call
"TDF".getBytes(StandardCharsets.UTF_8) and add the necessary import for
java.nio.charset.StandardCharsets.In
@sdk/src/main/java/io/opentdf/platform/sdk/XWingKeyPair.java:
- Around line 3-10: The XWingKeyPair and HybridNISTKeyPair classes import
non-FIPS BouncyCastle PQC APIs (e.g., XWingKEMGenerator, XWingKEMExtractor,
XWingKeyPairGenerator and ML-KEM equivalents) which break the fips profile;
modify these classes to avoid static references to org.bouncycastle.pqc.* by
either (a) moving PQC-specific code behind a separate optional module or factory
loaded via reflection, or (b) replacing the direct imports with
provider-agnostic interfaces and runtime lookups so the code compiles under the
fips profile when bcprov-jdk18on is absent; update XWingKeyPair and
HybridNISTKeyPair to use the new indirection (factory/reflection/provider
lookup) for generators/extractors/keypair creation (e.g., XWingKEMGenerator,
XWingKEMExtractor, XWingKeyPairGenerator and MLKEM equivalents) so the fips
build no longer requires non-fips BC classes at compile time.
Duplicate comments:
In@scripts/README.md:
- Line 80: The fenced expected-output block around the test output is missing a
language tag and triggers MD040; update the openingto include a language (e.g., change the opening fence totext) so the block is typed and the linter
stops flagging it—target the expected-output fenced block shown in the diff (the
multi-line sample starting with "[OK] hpqt:xwing...") and add the language tag
to its opening fence.In
@scripts/test-hybrid-pqc.sh:
- Line 197: The current line that sets first_byte using
base64 -dandxxdis
not portable; change the decode+hex extraction to use a portable fallback: try
base64 --decode(orbase64 -D) and if that fails trybase64 -d, and
replacexxd -p -l 1with a portable tool likeod -An -tx1 -N1(orhexdump -v -n 1 -e '1/1 "%02x"') to extract the first byte; update the assignment to
first_byte=$(printf '%s' "$wrapped" | base64 --decode 2>/dev/null || printf '%s' "$wrapped" | base64 -D 2>/dev/null || printf '%s' "$wrapped" | base64 -d 2>/dev/null | od -An -tx1 -N1 | tr -d ' \t\n')(or equivalent fallback
sequence) sofirst_byteproduction works on GNU/BSD/macOS and whenxxdis
absent in scripts/test-hybrid-pqc.sh.- Around line 42-47: The parsing for value-taking flags (--algorithms,
--platform-endpoint, --kas-url, --attr, --client-id, --client-secret) reads "$2"
unguarded which can cause a crash under set -u when a value is missing; update
the argument parsing to first validate that a next positional exists and is not
another flag (e.g., check that $# -ge 2 and that "$2" does not start with --)
before assigning to ALGORITHMS, PLATFORM_ENDPOINT, KAS_URL, DATA_ATTR,
CLIENT_ID, or CLIENT_SECRET, and if the check fails print the misuse message and
exit 2 to preserve the documented behavior.</details> <details> <summary>🪄 Autofix (Beta)</summary> Fix all unresolved CodeRabbit comments on this PR: - [ ] <!-- {"checkboxId": "4b0d0e0a-96d7-4f10-b296-3a18ea78f0b9"} --> Push a commit to this branch (recommended) - [ ] <!-- {"checkboxId": "ff5b1114-7d8c-49e6-8ac1-43f82af23a33"} --> Create a new PR with the fixes </details> --- <details> <summary>ℹ️ Review info</summary> <details> <summary>⚙️ Run configuration</summary> **Configuration used**: Organization UI **Review profile**: CHILL **Plan**: Pro **Run ID**: `709afa34-584d-46f7-bfb4-4b12dcd4c629` </details> <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 6e08ea4e829176fd15bccd61ee5e48be3e859ec9 and d666c0788da28cec69d26662e78c68e67c1d1443. </details> <details> <summary>📒 Files selected for processing (10)</summary> * `scripts/README.md` * `scripts/test-hybrid-pqc.sh` * `sdk/pom.xml` * `sdk/src/main/java/io/opentdf/platform/sdk/HybridCrypto.java` * `sdk/src/main/java/io/opentdf/platform/sdk/HybridNISTKeyPair.java` * `sdk/src/main/java/io/opentdf/platform/sdk/KeyType.java` * `sdk/src/main/java/io/opentdf/platform/sdk/TDF.java` * `sdk/src/main/java/io/opentdf/platform/sdk/XWingKeyPair.java` * `sdk/src/test/java/io/opentdf/platform/sdk/HybridCryptoTest.java` * `sdk/src/test/java/io/opentdf/platform/sdk/TDFHybridTest.java` </details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
Contributor
jentfoo
previously approved these changes
May 22, 2026
jentfoo
left a comment
jentfoo
left a comment
Contributor
There was a problem hiding this comment.
No issues spotted, just unfortunate having to bring BC back after just removing it.
mkleene
reviewed
May 26, 2026
Contributor
There was a problem hiding this comment.
I think that this breaks FIPS, at least with BouncyCastle. I'm not sure which other providers are out there but it doesn't seem like there are many.
Since these classes aren't present in the FIPS jar we'd need to include the regular BC jar in order to guarantee that we don't have link errors. The spec says
This specification allows an implementation flexibility as to when linking activities (and, because of recursion, loading) take place, provided that all of the following properties are maintained:
A class or interface is completely loaded before it is linked. A class or interface is completely verified and prepared before it is initialized. Errors detected during linkage are thrown at a point in the program where some action is taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error. A symbolic reference to a dynamically-computed constant is not resolved until either (i) an ldc, ldc_w, or ldc2_w instruction that refers to it is executed, or (ii) a bootstrap method that refers to it as a static argument is invoked. A symbolic reference to a dynamically-computed call site is not resolved until a bootstrap method that refers to it as a static argument is invoked.
which makes me think that a class loader would be justified in throwing a ClassNotFoundException at startup if the regular BC provider is not on the class path. But if the regular provider is on the classpath then the FIPS jar will not work properly because of collisions in the standard and FIPS class names.
If we really want this to work we could put it behind a separate jar and the java SPI maybe?
Contributor
Contributor
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
sdk-pqc-bc/src/main/java/io/opentdf/platform/sdk/pqc/bc/HybridCrypto.java (1)
94-97:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winInteger overflow in length bounds check allows unbounded allocation (DoS).
readLengthcan return up to0x7FFFFFFF, soc.pos + lenoverflows to a negative value and the guard is bypassed, after whichnew byte[len]attempts a ~2 GB allocation. This is reachable on untrusted input duringunwrapDEK: an 8-byte envelope30 06 80 84 7F FF FF FFpasses the SEQUENCE checks and reaches this allocation before any ciphertext-size validation, crashing withOutOfMemoryError.Use overflow-safe subtraction (the same pattern should be applied to
seqEndat line 72, though the strict equality at line 76 currently masks it there).🛡️ Proposed fix
int len = readLength(c); - if (c.pos + len > c.buf.length) { + if (len > c.buf.length - c.pos) { throw new SDKException("context-tagged element length exceeds buffer"); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@sdk-pqc-bc/src/main/java/io/opentdf/platform/sdk/pqc/bc/HybridCrypto.java` around lines 94 - 97, The bounds check on the length read from readLength is vulnerable to integer overflow (c.pos + len), allowing len to wrap negative and bypass the guard; change the check to an overflow-safe form such as verifying len is non-negative and len <= c.buf.length - c.pos before allocating (and throw SDKException if not), and apply the same subtraction-based safety for calculating/validating seqEnd in the same method (e.g., ensure seqEnd is within 0..c.buf.length using seqEnd <= c.buf.length and computed via subtraction to avoid overflow).
♻️ Duplicate comments (2)
sdk-pqc-bc/src/main/java/io/opentdf/platform/sdk/pqc/bc/HybridCrypto.java (2)
185-193:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winPin the HKDF salt input to an explicit charset.
defaultTDFSalt()still uses"TDF".getBytes(), which depends on the JVM default charset and can change the derived wrap key across environments, breaking interoperability.💡 Suggested fix
- d.update("TDF".getBytes()); + d.update("TDF".getBytes(java.nio.charset.StandardCharsets.US_ASCII));🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@sdk-pqc-bc/src/main/java/io/opentdf/platform/sdk/pqc/bc/HybridCrypto.java` around lines 185 - 193, The defaultTDFSalt() function uses "TDF".getBytes() which relies on the platform default charset; change it to use an explicit charset (e.g., StandardCharsets.UTF_8) when converting the literal to bytes so the MessageDigest d = MessageDigest.getInstance("SHA-256") always digests the same input across environments; update imports if necessary to include java.nio.charset.StandardCharsets and keep the same exception handling in defaultTDFSalt().
133-152:⚠️ Potential issue | 🟡 Minor | ⚡ Quick win
readLength()still accepts non-canonical DER length encodings.Long-form encodings for values
< 0x80and leading-zero length bytes are accepted, so multiple encodings map to the same envelope on untrusted input. Reject non-minimal lengths to enforce strict DER (per the earlier suggestion).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@sdk-pqc-bc/src/main/java/io/opentdf/platform/sdk/pqc/bc/HybridCrypto.java` around lines 133 - 152, readLength currently accepts non-canonical DER encodings (long-form for values < 0x80 and leading-zero length bytes). Update readLength(Cursor c) to enforce strict DER: after computing numBytes and reading the bytes into len, throw an SDKException if len < 0x80 (because values < 0x80 must use short-form) and also throw if the most-significant length byte is 0 (leading-zero) when numBytes > 1; you can detect the MSB by inspecting (len >> ((numBytes - 1) * 8)) & 0xFF after the read. Keep existing SDKException usage for errors.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@cmdline/pom.xml`:
- Around line 84-89: The unconditional runtime dependency on artifactId
sdk-pqc-bc causes it to be pulled into FIPS builds; remove the dependency block
from the main dependencies section and place it inside a Maven profile (e.g.,
id="pqc" or id="non-fips") so it is only included when that profile is
explicitly activated, keeping the same groupId/artifactId/version
(${project.version}) and runtime scope; ensure the FIPS build does not activate
that profile (or make the profile opt-in) so omission is enforced by build
configuration rather than documentation.
In `@pom.xml`:
- Line 289: The root pom.xml now lists a fourth module "sdk-pqc-bc" which
diverges from the repo policy expecting three root modules; either remove
"sdk-pqc-bc" from the <module> entries in the root POM to restore the
three-module layout (matching modules sdk/, cmdline/, examples/), or update the
repository build policy/docs to include and describe the new root module
contract and add "sdk-pqc-bc" to that documentation; locate the
<module>sdk-pqc-bc</module> entry in the root pom.xml and apply the chosen fix
(remove the module entry or update the policy/docs accordingly).
In `@sdk-pqc-bc/pom.xml`:
- Around line 34-37: The project uses org.bouncycastle:bcprov-jdk18on without an
explicit version in this module; update the central bouncycastle.version
property from 1.82 to 1.84 in the root dependencyManagement (change the
<bouncycastle.version> value) so this module inherits the patched release, and
audit any LDAP-related code paths that may use BouncyCastle helpers (e.g.,
LDAPStoreHelper or any LDAP filter construction) to ensure metacharacter
neutralization is applied per the 1.84 patch notes.
In `@sdk/src/main/java/io/opentdf/platform/sdk/spi/KemProviders.java`:
- Around line 74-86: The load() method currently returns a mutable HashMap which
violates the class Javadoc and exposes the static cache to external mutation via
KemProviders.registered(); change load() to return an unmodifiable map (e.g.,
wrap the populated map with Collections.unmodifiableMap(...) or use
Map.copyOf(...)) so the static cache and the registered() keySet/view are
immutable; update the return in KemProviders.load() accordingly so the static
cache remains safe from external clear/remove calls and races.
---
Outside diff comments:
In `@sdk-pqc-bc/src/main/java/io/opentdf/platform/sdk/pqc/bc/HybridCrypto.java`:
- Around line 94-97: The bounds check on the length read from readLength is
vulnerable to integer overflow (c.pos + len), allowing len to wrap negative and
bypass the guard; change the check to an overflow-safe form such as verifying
len is non-negative and len <= c.buf.length - c.pos before allocating (and throw
SDKException if not), and apply the same subtraction-based safety for
calculating/validating seqEnd in the same method (e.g., ensure seqEnd is within
0..c.buf.length using seqEnd <= c.buf.length and computed via subtraction to
avoid overflow).
---
Duplicate comments:
In `@sdk-pqc-bc/src/main/java/io/opentdf/platform/sdk/pqc/bc/HybridCrypto.java`:
- Around line 185-193: The defaultTDFSalt() function uses "TDF".getBytes() which
relies on the platform default charset; change it to use an explicit charset
(e.g., StandardCharsets.UTF_8) when converting the literal to bytes so the
MessageDigest d = MessageDigest.getInstance("SHA-256") always digests the same
input across environments; update imports if necessary to include
java.nio.charset.StandardCharsets and keep the same exception handling in
defaultTDFSalt().
- Around line 133-152: readLength currently accepts non-canonical DER encodings
(long-form for values < 0x80 and leading-zero length bytes). Update
readLength(Cursor c) to enforce strict DER: after computing numBytes and reading
the bytes into len, throw an SDKException if len < 0x80 (because values < 0x80
must use short-form) and also throw if the most-significant length byte is 0
(leading-zero) when numBytes > 1; you can detect the MSB by inspecting (len >>
((numBytes - 1) * 8)) & 0xFF after the read. Keep existing SDKException usage
for errors.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7f819728-2b79-47da-871c-2c8e2296b396
📒 Files selected for processing (15)
cmdline/pom.xmlpom.xmlscripts/README.mdsdk-pqc-bc/pom.xmlsdk-pqc-bc/src/main/java/io/opentdf/platform/sdk/pqc/bc/BouncyCastleKemProvider.javasdk-pqc-bc/src/main/java/io/opentdf/platform/sdk/pqc/bc/HybridCrypto.javasdk-pqc-bc/src/main/java/io/opentdf/platform/sdk/pqc/bc/HybridNISTKeyPair.javasdk-pqc-bc/src/main/java/io/opentdf/platform/sdk/pqc/bc/XWingKeyPair.javasdk-pqc-bc/src/main/resources/META-INF/services/io.opentdf.platform.sdk.spi.KemProvidersdk-pqc-bc/src/test/java/io/opentdf/platform/sdk/TDFHybridTest.javasdk-pqc-bc/src/test/java/io/opentdf/platform/sdk/pqc/bc/HybridCryptoTest.javasdk/pom.xmlsdk/src/main/java/io/opentdf/platform/sdk/TDF.javasdk/src/main/java/io/opentdf/platform/sdk/spi/KemProvider.javasdk/src/main/java/io/opentdf/platform/sdk/spi/KemProviders.java
✅ Files skipped from review due to trivial changes (2)
- sdk-pqc-bc/src/main/resources/META-INF/services/io.opentdf.platform.sdk.spi.KemProvider
- sdk/src/main/java/io/opentdf/platform/sdk/spi/KemProvider.java
🚧 Files skipped from review as they are similar to previous changes (2)
- sdk/src/main/java/io/opentdf/platform/sdk/TDF.java
- scripts/README.md
Contributor
mkleene
reviewed
May 29, 2026
mkleene
left a comment
mkleene
left a comment
Contributor
There was a problem hiding this comment.
Overall I think this will work well. Keeps the FIPS story pretty simple and should be simple to consume for customers.
marythought
reviewed
May 29, 2026
marythought
left a comment
marythought
left a comment
Contributor
There was a problem hiding this comment.
DX Review
Strong PR — the SPI + ServiceLoader architecture is clean, the test script is genuinely helpful, and the wire format is well-documented for cross-SDK interop. A few things worth considering:
Design feedback
-
HybridNISTKeyPairdual role.P256_MLKEM768is a static template withpublicKey = null, and.generate()returns a new instance with keys populated — but both are the same type. Nothing prevents calling instance methods on the template, and the API shape suggestsP256_MLKEM768itself holds a keypair. Consider separating the parameters object from the keypair, or making the distinction visible in the type name. -
Duplicated dispatch switch.
HybridCrypto.wrapDEKandBouncyCastleKemProvider.wrapDEKboth switch over the same threeKeyTypes dispatching to the same calls. A fourth algorithm means two switch statements to update. Consider having the provider delegate toHybridCrypto, or removing the dispatcher fromHybridCryptoentirely. -
Auto-discovery gap deserves a defensive error now. The README documents that
fromPublicKeyAlgorithm()doesn't map hybrid protobuf enums. When unrecognized enum values do arrive, the currentdefaultcase throws a bareIllegalArgumentExceptionwith no mention of PQC or what to do. Since the enum mapping can't be added until the protobuf values exist, the fix available now is makingfromPublicKeyAlgorithm()handle unknown values gracefully — either skip with a log warning, or throw an error that says what's happening. Either is better than a rawIllegalArgumentException.
Minor
concat()is defined in three places (HybridCrypto,HybridNISTKeyPair,XWingKeyPair).HybridCrypto.defaultTDFSalt()recomputesSHA-256("TDF")on every call —TDF.javaalready hasGLOBAL_KEY_SALTdoing the same thing.XWingKeyPair.PRIVATE_KEY_SIZE = 32— worth a note that this is a seed, not the full private key.sdk-pqc-bc/pom.xmlhardcodes<maven.compiler.source>11</maven.compiler.source>— intentional divergence from parent?KemProvider.supportedKeyTypes()has no contract about immutability/thread-safety of the returnedSet— matters since this is a public SPI.
Mirrors opentdf/platform PR #3563 which moves the three hybrid PQ/T KEMs
into interop with draft-ietf-lamps-pq-composite-kem-14 and
draft-connolly-cfrg-xwing-kem-10.
Wire format changes:
- All three algorithms now use standard SPKI/PKCS#8 PEM envelopes;
custom XWING/SECP256R1-MLKEM768/SECP384R1-MLKEM1024 block names gone.
AlgorithmIdentifier OIDs select the scheme (X-Wing 1.3.6.1.4.1.62253.25722,
P256+ML-KEM-768 1.3.6.1.5.5.7.6.59, P384+ML-KEM-1024 1.3.6.1.5.5.7.6.63).
- NIST hybrid public-key concat order: mlkemPK || ecPoint
(previously ecPoint || mlkemPK).
- NIST hybrid private-key encoding: mlkemSeed(64) || RFC 5915
ECPrivateKey DER (previously raw padded scalar || mlkemSeed).
- NIST hybrid ciphertext concat order: mlkemCT || ephemeralECPoint
(previously ephemeralECPoint || mlkemCT).
- NIST hybrid combiner:
SHA3-256(mlkemSS || tradSS || tradCT || tradPK || Label) per
draft-14 §4.3, with Label "MLKEM768-P256" / "MLKEM1024-P384". 32-byte
output used directly as AES-256 key; no HKDF wrap step.
- X-Wing wire bytes, combiner, and TDF DEK envelope unchanged.
New file: HybridSpki.java — encode/parse SPKI + PKCS#8 (raw bytes go
directly into OCTET STRING / BIT STRING, matching Go's layout) and
RFC 5915 ECPrivateKey via BC's ASN.1 helpers.
Build verification: mvn test (default) — 162 sdk + 14 sdk-pqc-bc =
176 pass, 0 fail. mvn -P fips,!non-fips clean install -DskipTests —
clean build.
Contributor
X-Test Results✅ java@v0.15.0-main |
Contributor
X-Test Failure Report✅ js@main-main |
mkleene
previously approved these changes
Jun 5, 2026
mkleene
left a comment
mkleene
left a comment
Contributor
There was a problem hiding this comment.
I think this is fine to merge. It would be nice if we had a platform integration test but it looks like the tests repo should handle e2e tests.
Looks good!
Contributor
marythought
reviewed
Jun 5, 2026
marythought
left a comment
marythought
left a comment
Contributor
There was a problem hiding this comment.
Re: Mike's concern about bringing BC back after #367 just removed it — the SPI + ServiceLoader architecture addresses this correctly. The core sdk jar stays BC-free at compile time; sdk-pqc-bc is an optional module gated behind the non-fips profile. The FIPS namespace collision Mike flagged is avoided because sdk-pqc-bc is excluded from the reactor entirely under -P fips,!non-fips.
One remaining gap: FIPS users who attempt hybrid PQC get a generic "no KemProvider registered — add sdk-pqc-bc" error, which is misleading because adding sdk-pqc-bc under FIPS would create the namespace collision Mike described. A more targeted message when running under the FIPS profile (or at least a note that hybrid PQC is not available in FIPS mode) would prevent someone from following the error message into a worse state.
3 tasks
Contributor
|
Companion docs PR: opentdf/docs#343 — updates feature matrix, encrypt options, KASInfo/KeyAccess type reference, and KAS PublicKey docs for hybrid PQC. |
marythought
previously approved these changes
Jun 17, 2026
Contributor
|
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add hybrid post-quantum key wrapping to the Java SDK so TDFs can be protected against "harvest now, decrypt later" attacks while preserving classical security guarantees during the PQC transition.
Introduces three new
KeyTypevalues backed by hybrid KEMs:HybridXWingKey(hpqt:xwing) — X-Wing (X25519 + ML-KEM-768)HybridSecp256r1MLKEM768Key(hpqt:secp256r1-mlkem768)HybridSecp384r1MLKEM1024Key(hpqt:secp384r1-mlkem1024)When a KAS advertises one of these algorithms,
TDF.upsertAndGetNewKeyAccessroutes throughHybridCrypto.wrapDEK, which performs both a classical ECDH/X25519 key agreement and an ML-KEM encapsulation, combines the two shared secrets (HKDF-SHA256 with the standard TDF salt), and uses the result to wrap the DEK with AES-256-GCM. A newhybrid-wrappedkey-access type is emitted; the ephemeral classical public key and ML-KEM ciphertext are packaged together inside an ASN.1 envelope stored inwrappedKey(rather than the separateephemeralPublicKeyfield used for EC-wrapped keys).New supporting classes:
HybridCrypto,HybridNISTKeyPair,XWingKeyPair, plus unit tests and a full-manifest TDF round-trip test.Provider-agnostic implementation
In line with #367's removal of BouncyCastle as a compile dependency, this PR limits BC usage to the only primitives JDK 11 stdlib cannot supply — ML-KEM keygen/encap/decap and X-Wing keygen/encap/decap (the JCA
KEMAPI is JDK21+; ML-KEM in stdlib is 24+).Everything else is stdlib JCA or an existing SDK helper:
SEQUENCE { [0] IMPLICIT OCTET STRING, [1] IMPLICIT OCTET STRING }with multi-byte length support. Noorg.bouncycastle.asn1.*imports. - HKDF — delegates to the existingECKeyPair.calculateHKDF(salt, secret)(RFC 5869, empty info, L=32 — what all three algorithms need).KeyPairGenerator.getInstance("EC"),KeyAgreement.getInstance("ECDH"),AlgorithmParameters.getInstance("EC")withECGenParameterSpec. NoBouncyCastleProviderregistration; consumers control providers viajava.securityas the ADR intends.bcprov-jdk18onis declared at compile/runtime scope in the defaultnon-fipsMaven profile, version pinned via the existing parentdep-management entry.
Out of scope (follow-ups)
fipsprofile support for hybrid PQC — needs verification of whichbc-fipsversion ships ML-KEM and X-Wing and how it registers them.Summary by CodeRabbit
Release Notes
New Features
Tests
Documentation