Use full SHA-256 dedup lookup key#259
Merged
Merged
Conversation
The deduplication cache keyed entries on a SHA-256 digest truncated to 128 bits. On a dedup hit the log signs an SCT over the *submitted* certificate combined with the cached leaf index and timestamp, so a collision in the lookup key yields an SCT for a certificate that was never incorporated into the log. With a 128-bit key an attacker with a colluding, compromised, or separately vulnerable CA could compute a collision offline (~2^64 work) and obtain a forged SCT. This is the same class of issue as Sunlight's ANT-2026-88EWBS43. Widen LOOKUP_KEY_LEN from 16 to 32 bytes so new entries are keyed on the full SHA-256 digest, closing the collision hole (a collision now costs ~2^128, a multi-target second preimage ~2^96). Without the legacy fallback, this effectively resets the caches in Workers KV and DO storage for existing logs. As no Azul-based log is production, this seems acceptable. The Durable Object dedup ring-buffer record grows from 32 to 48 bytes. Since one sequencing round is serialized into a single DO storage value, and DO values are capped at 128 KiB, lower MAX_POOL_SIZE from 4000 to 2500 (2500 * 48 = 120,000 B < 131,072 B; ceiling 2730) so a batch still fits in one value without chunking. Closes #251
lukevalenta
requested review from
a team,
bwesterb,
cjpatton,
lbaquerofierro and
mendess
as code owners
July 16, 2026 14:23
bwesterb
approved these changes
Jul 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
NOTE(lvalenta): I used AI to help write this PR, but have reviewed and approve all changes. Another approach we could have taken here is storing the signature in the cache too, but that is a more invasive change.
The deduplication cache keyed entries on a SHA-256 digest truncated to 128 bits. On a dedup hit the log signs an SCT over the submitted certificate combined with the cached leaf index and timestamp, so a collision in the lookup key yields an SCT for a certificate that was never incorporated into the log. With a 128-bit key an attacker with a colluding, compromised, or separately vulnerable CA could compute a collision offline (~2^64 work) and obtain a forged SCT. This is the same class of issue as Sunlight's ANT-2026-88EWBS43.
Widen LOOKUP_KEY_LEN from 16 to 32 bytes so new entries are keyed on the full SHA-256 digest, closing the collision hole (a collision now costs ~2^128, a multi-target second preimage ~2^96). Without the legacy fallback, this effectively resets the caches in Workers KV and DO storage for existing logs. As no Azul-based log is production, this seems acceptable.
The Durable Object dedup ring-buffer record grows from 32 to 48 bytes. Since one sequencing round is serialized into a single DO storage value, and DO values are capped at 128 KiB, lower MAX_POOL_SIZE from 4000 to 2500 (2500 * 48 = 120,000 B < 131,072 B; ceiling 2730) so a batch still fits in one value without chunking.
Closes #251