Cryptography, proposed modification to 6.6.4 related to (second) pre-image attacks

[randomstuff]

Current:

6.6.4 [ADDED] Verify that hash functions used in digital signatures are collision resistant and have appropriate bit-lengths to avoid attacks, such as collision or pre-image attacks.

Proposed by Bart Preneel:

6.6.4 [ADDED] Verify that hash functions used in digital signatures are collision resistant and have appropriate bit-lengths to avoid attacks, such as collision or (second) pre-image attacks. For (second) pre-image attacks, output lengths of at least 128 bits are required, while for collision resistance output lengths need to be at least 256 bits.

[randomstuff]

I would have some homework to do to have a better understanding on this topic :)

This may not very easy to understand for the casual reader. Can we give some concrete examples?

[tghosth]

I leave this up to @danielcuthbert's judgement, I am not sure about this one.

[unprovable]

Wouldn't MD5 be a very relevant example here?

[tghosth]

6.6.4 [ADDED] Verify that hash functions used in digital signatures are collision resistant and have appropriate bit-lengths to avoid attacks, such as collision or (second) pre-image attacks. For (second) pre-image attacks, output lengths of at least 128 bits are required, while for collision resistance output lengths need to be at least 256 bits.

So @unprovable do you agree with this wording update?

[danielcuthbert]

I think the wording works. One could maybe make it slightly simpler but then we are splitting atoms and we could, if needed, add a more basic english option to the Appendix

[tghosth]

@randomstuff please can you open a PR?

[randomstuff]

6.6.4 [ADDED] Verify that hash functions used in digital signatures are collision resistant and have appropriate bit-lengths to avoid attacks, such as collision or (second) pre-image attacks. For (second) pre-image attacks, output lengths of at least 128 bits are required, while for collision resistance output lengths need to be at least 256 bits.

OK, I realize I am still trying to understand this. 😄

Why can't we just requires 256 bits? In which cases does the “For (second) pre-image attacks, output lengths of at least 128 bits are required” adds something relevant as opposed to sating: “The output lengths need to be at least 256 bits.”? I am asking this question both out of laziness 😄 of finding the answer for myself and because the casual reader will probably be left wondering the same question so we would probably better be clearer (for the casual reader which knows less about crypto than me) about this?

In practice, I believe that this allows using SHA-1 in HMAC-SHA-1 (this is the only approved usage of a hash function with less than 256 bit of security in the appendix)? Which other situation which would allow using a 128 bit hash function? Should we be more explicit about this in the examples?

[randomstuff]

6.6.4 [ADDED] Verify that hash functions used in digital signatures are collision resistant and have appropriate bit-lengths to avoid attacks, such as collision or (second) pre-image attacks. For (second) pre-image attacks, output lengths of at least 128 bits are required, while for collision resistance output lengths need to be at least 256 bits.

From this wording, I understand that there are use cases where having 128 bit hash output in digital signatures would be OK/allowed and some cases where it would be required to have 256 bits instead. Is that right?

However, the casual reader that I am is left wondering in which cases (in practice) it would be OK to only be (second) pre-image resistant.

Can we come up with practical examples of both cases?

Moreover the only secure hash algorithms which are allowed are 256 bits or more with the exception of SHA-1 which is only approved as part of HMAC-SHA-1. In practices, which algorithm with less than 256 bit output would I use to be conformant to this requirement? SHA-1? Truncated SHA-256?

[randomstuff]

@danielcuthbert @unprovable

[randomstuff]

One case that I am thinking of is OpenID connect at_hash and c_hash claims (of the ID token) which are defined as half of the hash of the access token and authorization code respectively using the hash algorithm associated with the ID token signature or MAC.

In practice, when using HS256, RS256 or ES256, the hash algorithm is SHA-256 so these claims would contain 128-bit truncations of SHA-256 hashes. Would that be allowed by this requirement?

Question: Do we need to make it clear that truncation of approved hash functions is OK? Is it always the case?

Question: I think, that in this example we are in the case where (second) pre-image attack resistance is required? Because the access token and code are generated by the issuer?

6.6.4 [ADDED] Verify that hash functions used in digital signatures

Question: Should that also apply to MAC as well? (eg. JWS with MAC)

[jmanico]

I think we should steer people away from any use of SHA-1 and/or hash truncation. They are only to be used in very specialized and legacy situations. There really is no need for SHA-1 in new development. There are better alternatives.

[unprovable]

@jmanico - @randomstuff is stalking about OpenID which is very much a modern protocol that uses hash truncation. It's still a common practice and if done properly, not a problem whilst allowing for mixing different hash sources.

@randomstuff - for the hashes I recall are in OpenID, they are all longer than 128 bit which helps when you truncate it down to that length. The fact that there are two hashes being truncated (I think?) maintains the resistance to pre-image (as you'd have to bruteforce two halves of two different hashes). Bart may know of a formal proof of this.

[elarlang]

There really is no need for SHA-1 in new development. There are better alternatives.

In my opinion, if there is just "There are better alternatives" - it is not a valid reason to have a requirement to disallow using it. If we have a requirement to disallow it, it must be clear for developers and testers, that if they have it in use, why they need to make the change or what risk they have if they don't do so.

[unprovable]

There really is no need for SHA-1 in new development. There are better alternatives.

In my opinion, if there is just "There are better alternatives" - it is not a valid reason to have a requirement to disallow using it. If we have a requirement to disallow it, it must be clear for developers and testers, that if they have it in use, why they need to make the change or what risk they have if they don't do so.

SHA-1 is deprecated. It shouldn't be used, and I think this NIST article has links that cover the main reasons why.

[randomstuff]

OK, my initial was to clarify this part of the proposed wording:

For (second) pre-image attacks, output lengths of at least 128 bits are required, while for collision resistance output lengths need to be at least 256 bits.

Questions which I think are not clear:

• When is is required to have 128 bits output length and when is it required to have 256 bits output length?
• If the only approved hash function in the document have 256 bits output length, does this distinction makes sense anyway?
• Is it OK to use SHA-256 truncated to 128 bits when all I need is (second) pre-image attacks resistance?
• Should the requirement wording be "Verify that hash functions used in digital signatures or MAC …"?

[randomstuff]

SHA-1 is deprecated. It shouldn't be used, and I think this NIST article has links that cover the main reasons why.

Shall we move the SHA-1 discussion out of here (#2551) because I don't think that's the main topic here?

[randomstuff]

@randomstuff - for the hashes I recall are in OpenID, they are all longer than 128 bit which helps when you truncate it down to that length.

Yes, the hash is output is always at least 256 bit so the truncation is always at least 128 bit.

The fact that there are two hashes being truncated (I think?) maintains the resistance to pre-image (as you'd have to bruteforce two halves of two different hashes). Bart may know of a formal proof of this.

You often/usually only have at_hash and no c_hash.

[jmanico]

In my opinion, if there is just "There are better alternatives" - it is not a valid reason to have a requirement to disallow using it.

I respectfully disagree. SHA-1 has known weaknesses, and there are better alternatives with superior performance characteristics. The collision vulnerabilities, such as those demonstrated by the SHAttered attack, are not theoretical—they are real.

There is no compelling reason to use SHA-1 in new development, and I believe we should guide developers away from it.

Rather than outright disallowing it, I recommend focusing on requirements that promote the use of secure hashes and MACs, rather than simply listing what not to use.

[jmanico]

@jmanico - @randomstuff is stalking about OpenID which is very much a modern protocol that uses hash truncation. It's still a common practice and if done properly, not a problem whilst allowing for mixing different hash sources.

This is for a major protocol with a large team of professional cryptographers. I would not suggest that developers building web apps and API's to do the same. It's a technique that can go badly fast if used incorrectly.

[jmanico]

SHA-1 is deprecated. It shouldn't be used, and I think this NIST article has links that cover the main reasons why.

Thank you for this comment. It's exactly the point I am trying to make and appreciate you chiming in. :)

[elarlang]

In my opinion, if there is just "There are better alternatives" - it is not a valid reason to have a requirement to disallow using it.

I respectfully disagree. SHA-1 has known weaknesses, and there are better alternatives with superior performance characteristics. The collision vulnerabilities, such as those demonstrated by the SHAttered attack, are not theoretical—they are real.

There is no compelling reason to use SHA-1 in new development, and I believe we should guide developers away from it.

Rather than outright disallowing it, I recommend focusing on requirements that promote the use of secure hashes and MACs, rather than simply listing what not to use.

Your willingness to just oppose me is amazing. With what do you disagree? That a requirement need to be based on facts?

Context, gentelmans, context. I was pointing out the expectations for a requirement. The requirement can not stand on the quoted phrases ("There are better alternatives") and expects to have better arguments.

[unprovable]

@jmanico - @randomstuff is stalking about OpenID which is very much a modern protocol that uses hash truncation. It's still a common practice and if done properly, not a problem whilst allowing for mixing different hash sources.

This is for a major protocol with a large team of professional cryptographers. I would not suggest that developers building web apps and API's to do the same. It's a technique that can go badly fast if used incorrectly.

Very strongly agree! But to this point, wouldn't writing such cryptographic code violate 6.2.2? this may be a digressing point, apologies.

[jmanico]

Your willingness to just oppose me is amazing. With what do you disagree? That a requirement need to be based on facts?

This is not personal. Stick to the technical discussion please. This is not about you, at all. I’m saddened to see you think it’s about you when it’s clearly not. It’s about SHA-1. Again Elar, this is not about you and it never was. I disagree with any requirement that encourages the use of SHA-1 in any way. That's my opinion. You don't have to agree. But it's my opinion based on NIST guidelines and the published hash collisions years ago regarding SHA-1.

[jmanico]

Very strongly agree! But to this point, wouldn't writing such cryptographic code violate 6.2.2? this may be a digressing point, apologies. I agree that hash mixing or hash truncation or similar really does violate 6.2.2

[tghosth]

OK, I think we have moved SHA-1 discussion to #2551

@randomstuff where are we with this specific requirement?