Skip to content

CCM multi-chunk streaming; keep 128-bit InitMode check (spec) - #11

Closed
omonien wants to merge 2 commits into
developmentfrom
cursor/feat-ccm-multichunk-spec-2915
Closed

omonien wants to merge 2 commits into
developmentfrom
cursor/feat-ccm-multichunk-spec-2915

Conversation

@omonien

@omonien omonien commented Sep 15, 2026

Copy link
Copy Markdown
Owner

Follow-up to #102, split as requested (“Gerne in 2 PR”).

Depends on / stacked on the lifecycle/API PR (points 1, 3, 5, 6). Please merge that first; until then this diff vs development also includes those commits.

Please merge against MHumm/DelphiEncryptionCompendium:development as omonien:cursor/feat-ccm-multichunk-spec-2915. This listing is on the fork because the agent token cannot open PRs on MHumm.

This PR covers Markus’s CCM multi-chunk / spec points from MHumm#102:

# Request This PR
2 CCM multi-chunk streaming (or a capability so callers can tell) Real multi-chunk: declare total payload length, then Encode/Decode in chunks. SupportsAuthenticatedMultiChunk is True for GCM and CCM. CCM is still not online (B_0 encodes l(m)); one-shot Encode/Decode without a pre-declared length still works
4 InitMode 128-bit check vs original CCM spec vs RFC Check kept. Original CCM (Whiting/Housley/Ferguson), RFC 3610 §1, and NIST SP 800-38C all require a 128-bit block cipher. Other sizes would need a separate specification. AES-GCM (SP 800-38D) is unchanged

CCM multi-chunk (spec-honest)

CCM cannot start until the total payload length is known (B_0 / RFC 3610). Callers can:

  1. One-shot — one Encode/Decode whose Size is the whole message (existing tests).
  2. Several chunks — set AuthenticatedPayloadLength first, then Encode/Decode* , then Done.
  3. One EncodeStream of the full messageDataSize is declared automatically, so internal buffer-sized Encode calls are correct.

Tests

RFC 3610 Packet 1 (23-byte PT, 64-bit tag):

  • TestEncodeMultiChunkUneven — 8+15
  • TestDecodeMultiChunkUneven — 7+16
  • TestEncodeStreamInternalChunks — small StreamBufferSize so one EncodeStream issues several Encode calls
  • TestEncodeStreamMultiChunk — several EncodeStream calls with declared length
  • TestSupportsAuthenticatedMultiChunk (CCM and GCM)

Out of scope

Open in Web Open in Cursor 

cursoragent and others added 2 commits September 15, 2026 13:11
Follow-up to PR MHumm#102 (points 1, 3, 5, 6). Reading CalculatedAuthenticationTag
before Done now raises EDECCipherException. Protected EncodeGCM/EncodeCCM
are unified as EncodeAuthenticated (Decode counterpart too). CCM materializes
the authentication tag in Done so GCM and CCM share one lifecycle. Modes
without prescribed tag lengths document returning an empty array.

Co-authored-by: Olaf Monien <omonien@users.noreply.github.com>
Follow-up to PR MHumm#102 (points 2 and 4). CCM can process several Encode/Decode
chunks when the total payload length is known (AuthenticatedPayloadLength or
a one-shot Size / EncodeStream DataSize). B_0 still encodes l(m) as required
by RFC 3610 / NIST SP 800-38C. InitMode keeps the 128-bit block-size check
for both GCM and CCM; comments cite the original CCM spec, RFC 3610, and
SP 800-38C/38D. SupportsAuthenticatedMultiChunk reports the capability.

Co-authored-by: Olaf Monien <omonien@users.noreply.github.com>
@omonien

omonien commented Sep 15, 2026

Copy link
Copy Markdown
Owner Author

Opened upstream as MHumm#106 — closing this fork listing as duplicate.

@omonien omonien closed this Sep 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants