[CFRG] Re: SEAL snapshot authenticator over non-SEAL segments: ct_i/tag_i convention

[Nick Sullivan <[e-mail]>]

Hi Younos,

Sorry for the long delay on this. Thanks for reproducing D.20 and D.21
before writing anything. That is what the component vectors are for.

On question 2, your reading is right. raAE defines the split directly:
the AEAD output divides into ct_i, the encrypted segment body, and
tag_i, the authentication tag, and seal-concrete writes the segment as
(ct_i || tag_i) = AEAD.Seal(segment_key, nonce(i), "", P_i). For a
Crypt4GH frame of nonce(12) || ciphertext || tag(16), ct_i is the
middle and tag_i is the last 16 octets. The nonce is not part of the
leaf. It is bound through the tag, since it is an AEAD input.

On question 3, yes. The snapshot authenticators are written over an
abstract segment leaf, leaf(i) = [LH(ct_i)] || tag_i, and nothing in
the digest transcript or the epoch digest tree depends on how the
segment was produced, only on ct_i, tag_i and the leaf order. So a
non-SEAL segment layer is within what the construction carries, and
the next revision will state the ct_i/tag_i convention independently
of EncryptSegment. One caveat to check on your side: the security
argument leans on the tag binding the segment index and finality,
which SEAL gets from its index-derived nonce and AAD. Crypt4GH nonces
are random and its AAD is its own, so in your composition index
binding comes from the transcript's strict ordering alone, and
finality is not bound at all. That is fine if your manifest records
the segment count, which is worth stating in your own design.

On question 1, yes, and I'd take you up on the offer. A vector that
starts from a real Crypt4GH segment and derives leaf(i) is the vector
the appendix is missing. Send it to the list or to me and I'll fold it
into the appendix, credited.

On the hybrid header sealing: outside TLS the published pattern is
https://datatracker.ietf.org/doc/draft-irtf-cfrg-concrete-hybrid-kems/,
which does the transcript binding inside the combiner so you don't
have to add your own, and it drops into HPKE as a KEM. I'd use that
rather than a bespoke binding over the ecdhe-mlkem concatenation.

One more thing. raAE and SEAL now have their own mailing list,
[e-mail], approved by the Security ADs on 28 September and
moderated by John Mattsson and me. Implementation questions like this
one belong there from now on, so I've copied it on this reply.
Subscribe here:
https://mailman3.ietf.org/mailman3/lists/raae.ietf.org/ I'm also
planning a side meeting at IETF 127 in San Francisco, 14 to 20
November, in person or virtually, and an implementer's report on the
Crypt4GH composition would be very welcome there.

Best,
Nick