oprf: reject input and info that overflow the length prefix - #694
Open
dxbjavid wants to merge 1 commit into
Open
oprf: reject input and info that overflow the length prefix#694dxbjavid wants to merge 1 commit into
dxbjavid wants to merge 1 commit into
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
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.
The OPRF and POPRF hashing steps frame each variable-length field with I2OSP(len, 2) as RFC 9497 specifies, and the prefix is built with a uint16 cast over the field length. For the client input, the server-side full-evaluation input, and the DeriveKey info that length is never bounded first, so a value of 65536 bytes or more wraps the two-byte prefix (a 65536-byte input encodes a length of 0) and the value is accepted rather than rejected. scalarFromInfo already guards its info with the same math.MaxUint16 check and returns ErrInvalidInfo, so the eval-path info is fine, but the sibling sites that frame the input and the derive-key info were missed. I came across it while comparing the length-prefix handling across the package and confirmed all three call sites accept an over-length value today. The change adds the same bound at blind, fullEvaluate, and DeriveKey, and keeps the maximum admissible length of 65535 bytes working so valid callers are unaffected.