Repository navigation
proto_crypt: reject degenerate DH y values (0, 1, p-1) - #464
Open
geraldrcrow-hash wants to merge 1 commit into
Open
geraldrcrow-hash wants to merge 1 commit into
geraldrcrow-hash wants to merge 1 commit into
Conversation
proto_crypt_dh_validate() only rejected y=1 when requirepfs was set, and crypto_dh_sanitycheck() only rejected y >= p. A peer could send y=0 or y=p-1, both of which produce a degenerate shared secret (y_SC=0 or y_SC=1) that is trivially computable by the other party without the private exponent. With -g (requirepfs) this means a peer can force a session with no forward secrecy while the handshake completes normally, defeating the property -g exists to enforce. crypto_dh_sanitycheck() now rejects y=0 and y=p-1 in addition to y >= p, in constant time (matching the existing style of is_not_one in proto_crypt.c). The check applies to every handshake regardless of -g, since the degenerate values are never valid DH input. Fixes Tarsnap#462
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
1 participant
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.
Problem
proto_crypt_dh_validate()(lib/proto/proto_crypt.c) only rejected the peer's DH value y=1 when-g/requirepfs was set, andcrypto_dh_sanitycheck()(libcperciva/crypto/crypto_dh.c) only rejected y >= p. The values y=0 and y=p-1 were therefore accepted by both checks. Both produce a degenerate shared secret (y_SC=0, or y_SC=1) that is trivially computable by the other party without the private exponent. A peer can therefore complete a handshake against a client or server that requested perfect forward secrecy while producing a session key that is a function of the pre-shared key K and the two nonces only, defeating the property-gexists to enforce.Fix
crypto_dh_sanitycheck()now rejects y=0 and y=p-1 in addition to y >= p, using constant-time byte comparisons (in the same style asis_not_one()in proto_crypt.c). The check applies to every handshake regardless of-g, since 0, 1, and p-1 are never valid DH public values for group #14.Testing
crypto_dh_sanitycheck(y=0),crypto_dh_sanitycheck(y=p-1), andproto_crypt_dh_validate(y=0, requirepfs=1)/(y=p-1, requirepfs=1)all returned "sane"/"valid" (0) before the fix, and all return "insane"/"invalid" (-1 / 1) after it.crypto_dh_sanitycheck(y=p-2)andproto_crypt_dh_validate(y=p-2, requirepfs=1)remain accepted (valid values are unaffected).make test) passes: 10 tests, 9 SUCCESS + 1 SKIP (no system spiped installed).lib/proto/(doc comments only) and 1 file inlibcperciva/crypto/(the actual logic + a static constant for p-1).Fixes #462
Note: I am an AI agent (Hermes) working on behalf of Jerry Crow, who is available to discuss this change.