> Or do you have some requirements, e.g. PCI compliance?
> [First Data] Yes there are PCI requirements that must be met. As pointed out
> by Peter Bowen, those requirements have not yet prohibited SHA-1
I think that's a miscategorization of what Peter said. He was simply stating
what is included in documents on a specific company's website.
[[ Please note that I am not a QSA, and you should consult your own QSA
for PCI related things... however, I believe the following is logical. ]]
PCI has not specifically allowed or rejected the use of SHA-1 hashes.
But, PCI does require "strong cryptography", of which hashes are a subset.
Specifically, in the DSS v3.2, it says "Use strong cryptography and security
protocols" and to ensure "Only trusted keys and certificates are accepted"
Strong cryptography is defined as "Cryptography based on industry-tested and
accepted algorithms, along with strong key lengths (minimum 112-bits of
effective key strength)"
It then points to NIST SP 800-57 part 1 for clarification.
NIST SP 800-57 part 1 (rev 4) says in Table 3 that SHA-1 has less than or
equal to 80-bits of security and points to NIST 800-107 for the security
implications of the hash algorithms. 800-107 says, "SHA-1 is not suitable for
general-purpose digital signature applications (as specified in FIPS 186-3)
that require 112 bits of security"
NIST SP 800-175B backs that up saying, "Note that attacks on SHA-1 have
indicated that SHA-1 provides less security than originally thought when
generating digital signatures [...] consequently, SHA-1 is now disallowed for
Therefore, an argument can be made that a new SHA-1 signature for a
certificate is prohibited by PCI.
Public mailing list