On Tue, 12 Apr 2022 02:48:51 GMT, Michael StJohns <mstjo...@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
