RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4
Michael StJohns
mstjohns at comcast.net
Fri Apr 22 18:07:30 UTC 2022
On 4/22/2022 1:21 PM, Weijun Wang wrote:
> Compare encoded instead of decoded digest in RSA signature verification.
>
> -------------
>
> Commit messages:
> - RFC 8017 8.2.2 Step 4
>
> Changes:https://git.openjdk.java.net/jdk/pull/8365/files
> Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=8365&range=00
> Issue:https://bugs.openjdk.java.net/browse/JDK-8285404
> Stats: 30 lines in 2 files changed: 3 ins; 26 del; 1 mod
> Patch:https://git.openjdk.java.net/jdk/pull/8365.diff
> Fetch: git fetchhttps://git.openjdk.java.net/jdk pull/8365/head:pull/8365
>
> PR:https://git.openjdk.java.net/jdk/pull/8365
This is a weird one. AFAICT the way it was being done is valid and
allowed by RFC8017 - I would have closed the bug report as notabug.
Here's the relevant text from RFC8017:
> 4. Compare the encoded message EM and the second encoded message
> EM'. If they are the same, output "valid signature";
> otherwise, output "invalid signature".
>
> Note:*_Another way to implement the signature verification operation is to
> apply a "decoding" operation (not specified in this document) to the
> encoded message to recover the underlying hash value, and then compare
> it to a newly computed hash value._*
> This has the advantage that it requires less intermediate storage
> (two hash values rather than two encoded messages), but the
> disadvantage that it requires additional code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220422/eaadcb8c/attachment.htm>
More information about the security-dev
mailing list