Crypto: define mechansism status

[randomstuff]

This PR is not intended to be merged for now. It is proof-of-concept for allowed/legacy/disallowed status of cryptographic mechanisms (#2398) and is intended to serve as a reference for discussing this option and a possible presentation style. The exact content would need to be verified/adjusted.

⚠️ Some important wording from the original content might be missing and might need to be brought back.

[randomstuff]

I am highlighting here some changes I made along the way:

• mention PBKDF2-SHA1 (legacy)
• removed KMAC from the list of hash function because it is a MAC
• "Diffie-Hellman" → "Finite Field Diffie-Hellman"
• Removed "The following hash functions MUST NOT be used in any cryptographic operation generating new material due to known weaknesses and vulnerabilities, they MAY only be used for verification of existing material." and "Due to insufficient collision resistance, the following hash functions MUST NOT be used for digital signature or other applications requiring collision resistance. For other usages, they might be used for compatibility and verification ONLY with legacy systems but must not be used in new designs.". Is it really reasonable to say that we can use MD5 or CRC to verify existing material?

[tghosth]

@danielcuthbert @unprovable do you have any thoughts on the suggestions from @randomstuff ?

[unprovable]

Sure, some thoughts:

• Yes it is required to allow MD5 and SHA1 for verification in many old and regulated environments. If you don't permit this, then few financial institutions can ever be ASVS certified. It's short sighted to remove a reasonable control.
• You added in PBKDF2-SHA1 which is a legacy control for verifying old hashes. If we can permit this, then we can permit the text saying that old hashes are verification only (notify that SHA1 is treated with similar concern as we do MD5 etc.)
• For any PBKDF you must state the number of iteration that are considered safe (not sure if this is tue case already here, but it is required for all the other standards we maintain).
• The other two points are fine as I far as I can see.

Hope this helps! M.

[danielcuthbert]

I'm with @unprovable here. The use of MD5 and SHA1 for verification purposes only and I really stress this, VERIFICATION ONLY, is required for many orgs that still use this. I can think of many in ICS/CNI/Financial who do use MD5 in this way and want to be Level 2 and above.

[randomstuff]

Yes it is required to allow MD5 and SHA1 for verification in many old and regulated environments. If you don't permit this, then few financial institutions can ever be ASVS certified. It's short sighted to remove a reasonable control.

Isn't it weird to allow MD5 for verification in general? Isn't it too broken for that?

Should we mention at the top of this appendix that this appendix defines a default standard set of allowed mechanisms and that this might be overloaded in the context of a given project:

• because of technical evolutions (some mechanism has been found to be broken, because of PCQ breakthrough, because new mechanisms has been published since the publication of this ASVS version);
• because of regulation (eg. the application must support GOST crypto).

[jmanico]

• Yes it is required to allow MD5 and SHA1 for verification in many old and regulated environments. If you don't permit this, then few financial institutions can ever be ASVS certified. It's short sighted to remove a reasonable control.

I think it's good that they can't be ASVS certified. They should stop using md5. I don't think, with respect my friends, that this is a good reason to support out of date crypto.

• You added in PBKDF2-SHA1 which is a legacy control for verifying old hashes. If we can permit this, then we can permit the text saying that old hashes are verification only (notify that SHA1 is treated with similar concern as we do MD5 etc.)

For the legacy section only, and not in core requirements, I think is ok.

• For any PBKDF you must state the number of iteration that are considered safe (not sure if this is tue case already here, but it is required for all the other standards we maintain).

Agreed. Depending on what it's used for (key generation vs password storage) these numbers are usually different per use.

[randomstuff]

I think it's good that they can't be ASVS certified. They should stop using md5. I don't think, with respect my friends, that this is a good reason to support out of date crypto.

Yes, that was my thinking as well.

As an counter-example, maybe FooAcme wants to be ASVS Level 3 certifed but don't want to hash their passwords. That's their problem to solve, it does not mean that the requirement about password hashing should go away.

old hashes are verification only

Isn't “we don't generate new MD5s (or other broken hash function) hashes but still accept them for verification” dubious/dangerous? If you accept old broken hashes, it won't stop an attacker from generating new ones. Isn't your verification mostly useless?

(In the general case. It probably depends based on the way hash is used i.e. it's probably not as bad for password hashing than for MAC or signature verification?)

[randomstuff]

@unprovable

You added in PBKDF2-SHA1 which is a legacy control for verifying old hashes. If we can permit this, then we can permit the text saying that old hashes are verification only (notify that SHA1 is treated with similar concern as we do MD5 etc.)

Do we? I had the understanding that HMAC-SHA-1 (and therefore PBKDF2-HMAC-SHA-1) was still considered not-broken in contrast to plain SHA-1 (eg. as used in digital signatures).