CCM multi-chunk streaming; keep 128-bit InitMode check (spec) - #106
Conversation
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>
|
Ok, habe mit diesem gestartet. Frage: SupportsMultiChunk sieht auf den ersten Blick ganz neet aus, aber ist abzusehen, dass es in Zukunft weitere nennenswerte Eigenschaften für solche Authenticated Modes geben wird? Falls ja fände ich ein Set evtl. besser, so wie in Context:TChipherContext.CipherType wie in DECCipherBase TDECCipher. Ich kann das für's Erste aber so übernehmen. |
|
Das finde ich leicht inkonsistent: if FStarted or FPayloadLengthDeclared then FExpectedPayloadLength := AByteLength; Warum? Wenn man das aber auf Exception werfen umbauen sollte, dann könnte man im Fall von FPayLoadLengthDeclared prüfen, ob AByteLength = FExpectedPayloadLength ist ond dann keine Exception werfen. Außer man will die Anwender zum CPU-Zyklen sparen erziehen... ;-) |
|
Hi Markus, danke fürs Mergen und die Hinweise! Zu SupportsMultiChunk: Für den Moment würde ich den Boolean so lassen. Wenn später weitere nennenswerte Eigenschaften für Authenticated Modes dazukommen, können wir das gerne zu einem Set of Capabilities ausbauen (analog zu CipherType) — das wäre dann ein klarer Follow-up. Zu DeclarePayloadLength: Da hast du recht, das ist inkonsistent. Ich würde auf Exception umstellen, außer wenn die Länge bereits deklariert ist und AByteLength gleich FExpectedPayloadLength ist — dann einfach durchlassen. Nach Start bzw. bei abweichender Länge dann Exception. Soll ich das als kleinen Follow-up-PR nachziehen? Viele Grüße |
|
Jupp! ;-)
Olaf Monien ***@***.***> schrieb am Fr., 18. Sept. 2026,
09:54:
… *omonien* left a comment (MHumm/DelphiEncryptionCompendium#106)
<#106 (comment)>
Hi Markus,
danke fürs Mergen und die Hinweise!
Zu SupportsMultiChunk: Für den Moment würde ich den Boolean so lassen.
Wenn später weitere nennenswerte Eigenschaften für Authenticated Modes
dazukommen, können wir das gerne zu einem Set of Capabilities ausbauen
(analog zu CipherType) — das wäre dann ein klarer Follow-up.
Zu DeclarePayloadLength: Da hast du recht, das ist inkonsistent. Ich würde
auf Exception umstellen, außer wenn die Länge bereits deklariert ist und
AByteLength gleich FExpectedPayloadLength ist — dann einfach durchlassen.
Nach Start bzw. bei abweichender Länge dann Exception.
Soll ich das als kleinen Follow-up-PR nachziehen?
Viele Grüße
Olaf
—
Reply to this email directly, view it on GitHub
<#106?email_source=notifications&email_token=AHCTXHID3PSHJ2QZ5XAHJ7L5PTSZZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZSGY4TQMRZGY32M4TFMFZW63VMON2GC5DFL5RWQYLOM5S2KZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5726982967>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHCTXHNIIQJGC7UOKP46TV35PTSZZAVCNFSNUABEKJSXA33TNF2G64TZHMZTENJVGIZDMNJ3JFZXG5LFHM2TINRSGQ3TOMZRGWQXMAQ>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AHCTXHJQUNBXUVKEZNISBDD5PTSZZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZSGY4TQMRZGY32M4TFMFZW63VMON2GC5DFL5RWQYLOM5S2KZLWMVXHJKTGN5XXIZLSL5UW64Y>
and Android
<https://github.com/notifications/mobile/android/AHCTXHLWGRSB6JPSY2MTUGT5PTSZZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZSGY4TQMRZGY32M4TFMFZW63VMON2GC5DFL5RWQYLOM5S2KZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>.
Download it today!
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
Hallo Markus, der kleine Follow-up zu Viele Grüße |
Make TCCM.DeclarePayloadLength fail hard after start or when a different length is declared, while still allowing an idempotent re-declare of the same length. EncodeStream only auto-declares when no length is set yet so multi-chunk streams keep working. Follow-up to #106. Co-authored-by: Olaf Monien <omonien@users.noreply.github.com>
…h-201b CCM: harden DeclarePayloadLength (follow-up to #106)
3 participants
Follow-up to #102 (points 2 and 4). Stacked on the lifecycle/API PR — please merge that first.
SupportsAuthenticatedMultiChunkTrue for GCM and CCMInitMode128-bit vs original CCM / RFCCCM is not online AEAD:
B_0encodesl(m), so total payload length must be known (AuthenticatedPayloadLength, one-shotSize, orEncodeStream.DataSize).Tests: RFC 3610 Packet 1 uneven chunks, EncodeStream internal chunks, capability flag.
Out of scope: ChaCha/Poly1305 (#90); loosening 128-bit for non-AES ciphers.