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