Remove SHA384 and SHA512 - #7
Merged
Merged
Conversation
DanGould
force-pushed
the
rm-sha-384-512
branch
2 times, most recently
from
August 14, 2024 19:07
b458e5f to
1fda5a5
Compare
DanGould
force-pushed
the
rm-sha-384-512
branch
from
September 22, 2026 12:07
1fda5a5 to
18a2bea
Compare
DanGould
marked this pull request as ready for review
September 22, 2026 16:06
Bitcoin HPKE apps don't use them, although SHA512 is used in BIP32 derivation. HKDF-SHA256 is the only KDF the crate exposes now, and the Wycheproof HKDF-SHA384/512 vector files go with the impls. MAX_DIGEST_SIZE stays at the RFC 9180 bound of 64: Kdf is a public trait, and a downstream impl with a wider digest would otherwise overflow the key-schedule buffers at runtime. assert_output_size now checks that bound at monomorphization. A test-only HkdfSha512 keeps the generic Extract and Expand code exercised at a second block size.
DanGould
force-pushed
the
rm-sha-384-512
branch
from
September 22, 2026 17:04
18a2bea to
f82bfc2
Compare
benalleng
approved these changes
Sep 22, 2026
benalleng
left a comment
benalleng
left a comment
Collaborator
There was a problem hiding this comment.
TACK f82bfc2
Ran a test suite in rust-payjoin utilizing this branch upstream
The expand_rejects_more_than_255_blocks test was a bit hard to follow when looking at it in the diff format but with no other context to confuse me I think it is fine.
Everything else is a pretty straightforward net delete, keeping hkdf-sha512 in tests seems logical enough testing against the different widths and covering MAX_DIGEST_SIZE better.
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.
Rebased onto main now that HKDF runs over
bitcoin_hashes(#15).Bitcoin HPKE apps don't use HKDF-SHA384 or HKDF-SHA512. DHKEM(secp256k1, HKDF-SHA256) is the only KEM here and rust-payjoin only instantiates
HkdfSha256, so the two extra KDFs are maintenance surface with no users.bitcoin_hashesstill ships both hashes, so adding them back is aKdfimpl each if anyone needs them.What goes: the two
Kdfimpls and the Wycheproof HKDF-SHA384/512 vector files. The secp256k1 known-answer vectors only ever usedkdf_id1, so KAT coverage is unchanged. The changelog entry for the unreleased 0.20.0 is updated to match.MAX_DIGEST_SIZEstays at the RFC 9180 bound of 64.Kdfis a public trait, and shrinking the constant would turn a downstream impl with a wider digest into a runtime panic in the key schedule.assert_output_sizenow checks the bound at monomorphization instead. A test-onlyHkdfSha512keeps the generic Extract and Expand code exercised at a second block size, since every shipped KDF is now 32 bytes wide.Disclosure: rebase and test cleanup done with Claude Code.