Class ExampleScenario24
java.lang.Object
co.ankatech.ankasecure.sdk.examples.ExampleScenario24
Scenario 24: Sign-Then-Encrypt Nested Operations
Demonstrates the proper sequence for authenticated encryption: signing plaintext first (inner layer) then encrypting the signature (outer layer). This is the recommended pattern for secure messaging where both authenticity and confidentiality are required.
Why Sign-THEN-Encrypt?
- Authenticity + Confidentiality: Signature proves sender identity, encryption protects content
- Secure messaging pattern: Standard in protocols like S/MIME and PGP
- Order matters: Sign-then-encrypt prevents signature stripping attacks
- Nested JOSE tokens: Creates JWE(JWS) structure per RFC 7516
Steps:
- Generate ML-DSA-65 signing key (post-quantum digital signature)
- Generate ML-KEM-768 encryption key (post-quantum key encapsulation)
- Create plaintext message file
- Sign-then-encrypt: Sign with ML-DSA → Encrypt with ML-KEM (creates JWE(JWS))
- Decrypt-then-verify: Decrypt with ML-KEM → Verify with ML-DSA (reverses process)
- Validate: Original plaintext matches recovered plaintext
- Validate: Signature is cryptographically valid
Key Algorithms:
- ML-DSA-65: NIST FIPS 204 post-quantum signature (192-bit security)
- ML-KEM-768: NIST FIPS 203 post-quantum encryption (192-bit security)
API Endpoints:
- POST /api/key-management/keys (generate signing key)
- POST /api/key-management/keys (generate encryption key)
- POST /api/crypto/stream/sign-encrypt (sign-then-encrypt operation)
- POST /api/crypto/stream/decrypt-verify (decrypt-then-verify operation)
Token Structure:
JWE Header (ML-KEM-768 encrypted symmetric key)
↓
Encrypted Payload:
JWS Header (ML-DSA-65 signature metadata)
↓
JWS Payload: Original plaintext
↓
JWS Signature: ML-DSA-65 signature bytes
- Since:
- 3.0.0
-
Method Summary
-
Method Details
-
main
-