fix: wc_SignatureVerify/Generate allow empty messages#10253
fix: wc_SignatureVerify/Generate allow empty messages#10253MarkAtwood wants to merge 1 commit intowolfSSL:masterfrom
Conversation
wc_SignatureVerify and wc_SignatureGenerate_ex rejected data_len==0 (and data==NULL) with BAD_FUNC_ARG. Signing and verifying an empty message is valid — the hash of an empty string is well-defined for all hash algorithms, and PKCS#1 v1.5 / PSS impose no minimum message length. wc_Hash already handles NULL data with data_len==0 correctly (producing e.g. SHA-256 of ""), so the only change needed is relaxing the argument check in the two wrapper functions. Triggered by Wycheproof RSA PKCS#1 v1.5 test vectors where tcId=1 in every file is a signature over an empty message. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Relaxes argument validation in wc_SignatureVerify and wc_SignatureGenerate_ex so signing/verifying an empty message (data_len == 0) is allowed (including data == NULL), aligning behavior with wc_Hash and enabling Wycheproof empty-message vectors.
Changes:
- Update
wc_SignatureVerifyargument checks to allowdata_len == 0withdata == NULL. - Update
wc_SignatureGenerate_exargument checks to allowdata_len == 0withdata == NULL. - Add clarifying comments about empty-message validity.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| /* Check arguments */ | ||
| if (data == NULL || data_len == 0 || | ||
| /* Check arguments. | ||
| * data may be NULL when data_len is 0 (empty message is valid — |
There was a problem hiding this comment.
These new comments introduce a non-ASCII em dash character (—). This can cause portability/encoding issues for toolchains that assume ASCII-only C sources or have strict source-charset settings. Consider replacing it with an ASCII sequence like '-' or '--' to avoid build problems in constrained environments.
| * data may be NULL when data_len is 0 (empty message is valid — | |
| * data may be NULL when data_len is 0 (empty message is valid - |
| /* Check arguments. | ||
| * data may be NULL when data_len is 0 (empty message is valid — | ||
| * the hash of an empty string is well-defined). */ | ||
| if ((data == NULL && data_len > 0) || |
There was a problem hiding this comment.
This change introduces new behavior (allowing empty-message verify). To prevent regressions, add an automated regression test that verifies a known-good signature over an empty message (including the data == NULL, data_len == 0 case), matching the reported Wycheproof vectors.
| if (data == NULL || data_len == 0 || | ||
| /* Check arguments. | ||
| * data may be NULL when data_len is 0 (signing an empty message). */ | ||
| if ((data == NULL && data_len > 0) || |
There was a problem hiding this comment.
This change introduces new behavior (allowing empty-message signing). Add an automated regression test that signs an empty message (including data == NULL, data_len == 0) and then verifies it, ensuring the previous BAD_FUNC_ARG behavior does not return.
|
Summary
wc_SignatureVerifyandwc_SignatureGenerate_exrejecteddata_len==0withBAD_FUNC_ARG. Signing and verifying an empty message is valid — the hash of an empty string is well-defined for all supported hash algorithms, and PKCS#1 v1.5 / PSS impose no minimum message length.wc_Hashalready handlesNULLdata withdata_len==0correctly (producing e.g. SHA-256 of""), so the only change needed is relaxing the argument check in the two wrapper functions.Triggered by Wycheproof RSA PKCS#1 v1.5 test vectors where
tcId=1in every file is a signature over an empty message.Test plan
tcId=1(empty message) vectors pass/cc @wolfSSL-Fenrir-bot please review