feat(sdk,cmdline): settable segment and root integrity algorithms (DSPX-4736) - #400
feat(sdk,cmdline): settable segment and root integrity algorithms (DSPX-4736)#400dmihalcik-virtru wants to merge 1 commit into
Conversation
…PX-4736)
Adds explicit controls for the two integrity algorithms a ZTDF writer picks,
and makes an unsupported choice fail loudly instead of being silently accepted.
The two are not interchangeable:
- A segment hash is computed over ciphertext AES-GCM actually produced, so
"GMAC" there means reading back a real authentication tag. Both HS256 and
GMAC are valid.
- The root signature covers the aggregate of the segment hashes, which never
passes through AES-GCM. There is no tag to recover, so HS256 is the only
meaningful choice.
sdk:
- Config.withSegmentIntegrityAlgorithm(HS256|GMAC)
- Config.withRootIntegrityAlgorithm(HS256), which throws
IllegalArgumentException for anything else. The option exists so callers
can state the choice explicitly and a CLI can surface the refusal, not to
widen it.
cmdline:
- `encrypt --root-integrity-algorithm` and `--segment-integrity-algorithm`,
with a case-insensitive converter so the flags behave like the equivalents
in the other OpenTDF CLIs, and ${COMPLETION-CANDIDATES} in the description
so the accepted values appear in help.
- The root algorithm is validated before buildSDK(), so an unsupported value
is reported as a picocli usage error (exit 2) rather than after a platform
round trip.
- A test pins the literal flag names into the rendered encrypt help, because
the cross-SDK xtest feature detectors find them by grepping it.
This is the control surface for evaluating DSPX-4703. It does not itself change
how a manifest that already declares a GMAC root is verified on read.
Signed-off-by: Dave Mihalcik <dmihalcik@virtru.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe SDK adds root and segment integrity algorithm configuration. The ChangesIntegrity algorithm configuration
Estimated code review effort: 3 (Moderate) | ~20 minutes Severity of issue fixed: Low Sequence Diagram(s)sequenceDiagram
participant EncryptCommand
participant IntegrityAlgorithmConverter
participant Config
participant TDFConfig
EncryptCommand->>IntegrityAlgorithmConverter: Convert option value
IntegrityAlgorithmConverter-->>EncryptCommand: Return IntegrityAlgorithm
EncryptCommand->>Config: Build integrity configuration
Config-->>EncryptCommand: Return TDFConfig option
EncryptCommand->>TDFConfig: Apply configuration before SDK creation
Suggested reviewers: Merge Risk: ⚪ Minimal · up to This change adds configurable segment and root integrity algorithms with validation and case-insensitive CLI parsing. The supplied coverage addresses accepted and rejected inputs, so no merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 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. A rabbit checks each flag, Comment |
|


Summary
Adds explicit controls for the two integrity algorithms a ZTDF writer picks, and makes an unsupported choice fail loudly instead of being silently accepted.
Rationale
The two algorithms are not interchangeable, and the API previously did not say so:
HS256,GMACHS256onlysdkConfig.withSegmentIntegrityAlgorithm(HS256|GMAC)Config.withRootIntegrityAlgorithm(HS256)— throwsIllegalArgumentExceptionfor anything else. The option exists so callers can state the choice explicitly and a CLI can surface the refusal, not to widen it. It is self-contained and does not reach intoTDF.cmdlineencrypt --root-integrity-algorithmand--segment-integrity-algorithm, with a case-insensitiveITypeConverterso the flags behave like the equivalents in the other OpenTDF CLIs, and${COMPLETION-CANDIDATES}so the accepted values render in help.buildSDK(), so an unsupported value is a picocli usage error (exit 2) rather than a failure after a platform round trip.encryptHelp_advertisesIntegrityAlgorithmFlagspins the literal flag names into the rendered encrypt help, because the cross-SDK xtest feature detectors find them by grepping it. Merging this flips theintegrity_algs/gmac_root_rejectedgates on and stops those cells silently skipping.Scope
This is the control surface for evaluating DSPX-4703, deliberately separated from the fix. It changes what a writer may choose; it does not change how a manifest that already declares a GMAC root is verified on read. That is the stacked follow-up.
Splitting it this way means the xtest exploit cases can run against this branch for a live "before" baseline, then against the fix branch to watch them go red → green.
Public API notes
Two new static factory methods on
Config. Nothing existing changes shape or default behaviour: the segment default staysGMAC, the root default staysHS256.Test plan
CommandTest: 26 tests, 0 failures — run with this commit asHEADand the DSPX-4703 fix commit entirely absent, to confirm the branch stands alone.Coverage added: GMAC rejected for root in three casings, HS256 accepted in two casings (and reaching the later missing-credentials error, proving it was not rejected), both algorithms accepted for segment, an unknown algorithm rejected, converter case-insensitivity, and the help-rendering assertion.
Summary by CodeRabbit
New Features
Bug Fixes
Cross-SDK coverage lives in opentdf/tests#594.