You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: accept a trailing empty final chunk in the count check
A plaintext of exactly k*chunkSize bytes has two valid encodings: k
chunks whose last one is full, or k full chunks followed by an empty
final chunk. Both decrypt to the same bytes, aesstream reads either (the
"full + empty final" row in TestChunkLayout pins it), and whole-object
Decrypt accepts either.
envelopePlaintextSize derived the expected chunk count with
chunkCountFor, which models only the first form, so a blob in the second
form declaring k+1 chunks failed with ErrSizeMismatch. DecryptRange and
PlaintextSize were stricter than Decrypt on the same object, which is
not a distinction this API means to draw.
Compare against the count aesstream derives from the ciphertext layout
instead, via a new exported ChunkCount. chunkCountFor stays as the
producer's rule for writing the header, matching the reference
implementation, and its doc now says so.
The check keeps its purpose: a size wrong by a whole chunk or more still
trips ErrSizeMismatch. A size short by only part of the final chunk now
accounts for the same number of chunks and passes, surfacing instead as
an authentication failure when that chunk is read -- the model the docs
already state for blobs carrying no chunk count. The two lengths are
indistinguishable without reading the chunks.
Also adds the exact-multiple boundary to the cross-implementation
vectors, which had no fixture for it: exact-multiple-go is 3 full chunks,
and the pinned foc-encryption decrypts it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Miroslav Bajtoš <oss@bajtos.net>
0 commit comments