RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec

[Sean Mullan]

On Tue, 12 Apr 2022 02:48:51 GMT, Michael StJohns <mstjohns at comcast.net> wrote:

> I think deprecating DEFAULT? is wrong.? RFC8017 still has this definition:
> 
> > RSAES-OAEP-params ::= SEQUENCE {
> > hashAlgorithm      [0] HashAlgorithm     DEFAULT sha1,
> > maskGenAlgorithm   [1] MaskGenAlgorithm  DEFAULT mgf1SHA1,
> > pSourceAlgorithm   [2] PSourceAlgorithm  DEFAULT pSpecifiedEmpty
> > }
> 
> and DEFAULT is what you should be getting if you see an empty sequence in the param field.? It's DEFAULT in ASN1 terms, not DEFAULT in terms of what you should use going forward? to create signatures, and the ASN1 DEFAULT won't change.
> 
> In any event, I can't find where RFC8017 says anything about deprecating the defaults.? AFAICT, although there's general guidance to go away from SHA1,? the math suggests that SHA1 is still sufficient for OAEP,? and there's no guidance specific to OAEP's use of SHA1 that I can find other than the requirement in NIST SP800-56B rev 2 to use "Approved Hash Functions" for OAEP. If there's a section in 8017 that you're looking at for this guidance that I missed, you may want to update your comment to point to it.

[https://www.rfc-editor.org/rfc/rfc8017#appendix-A.2.1](https://www.rfc-editor.org/rfc/rfc8017#appendix-A.2.1) (which defines the OAEP-params structure) says:

> o  hashAlgorithm identifies the hash function.  It SHALL be an
>       algorithm ID with an OID in the set OAEP-PSSDigestAlgorithms.  For
>       a discussion of supported hash functions, see [Appendix B.1](https://www.rfc-editor.org/rfc/rfc8017#appendix-B.1).

[https://www.rfc-editor.org/rfc/rfc8017#appendix-B.1](https://www.rfc-editor.org/rfc/rfc8017#appendix-B.1) is a long section discussing hash functions, but I think this text (last two paragraphs) is most relevant:

>   There have also been advances in the cryptanalysis of SHA-1.
>    Particularly, the results of Wang et al.  [[SHA1CRYPT](https://www.rfc-editor.org/rfc/rfc8017#ref-SHA1CRYPT)] (which have
>    been independently verified by M.  Cochran in his analysis [[COCHRAN](https://www.rfc-editor.org/rfc/rfc8017#ref-COCHRAN)])
>    on using a differential path to find collisions in SHA-1, which
>    conclude that the security strength of the SHA-1 hashing algorithm is
>    significantly reduced.  However, this reduction is not significant
>    enough to warrant the removal of SHA-1 from existing applications,
>    but its usage is only recommended for backwards-compatibility
>    reasons.
> 
>    To address these concerns, only SHA-224, SHA-256, SHA-384, SHA-512,
>    SHA-512/224, and SHA-512/256 are RECOMMENDED for new applications.
>    As of today, the best (known) collision attacks against these hash
>    functions are generic attacks with complexity 2L/2, where L is the
>    bit length of the hash output.  For the signature schemes in this
>    document, a collision attack is easily translated into a signature
>    forgery.  Therefore, the value L / 2 should be at least equal to the
>    desired security level in bits of the signature scheme (a security
>    level of B bits means that the best attack has complexity 2B).  The
>    same rule of thumb can be applied to RSAES-OAEP; it is RECOMMENDED
>    that the bit length of the seed (which is equal to the bit length of
>    the hash output) be twice the desired security level in bits.

Also, this is a proposed deprecation ... there is no plan to remove this field. The main intention of this deprecation is to alert users that SHA-1 is being used as it may not be apparent from the "DEFAULT" name, and to make sure that is ok or to think about using something stronger.

@valeriepeng I recommend making the link more specific in the deprecation text to point to https://www.rfc-editor.org/rfc/rfc8017#appendix-B.1

-------------

PR: https://git.openjdk.java.net/jdk/pull/8191