3 ms·

Well I'm thinking more along the lines of future-proofing designs. Like right now, should a new protocol use both SHA2 and SHA3, just to be safe?

viraptor 11y ago
"new protocol" is likely going to be less secure than TLS1.2. And TLS1.2 doesn't allow multiple signatures - it's usually in the form of "(hash)-with-(encryption)" (for example oid 1.2.840.113549.1.1.5 - SHA-1 with RSA Encryption) and since that's embedded in the hashed contents, you can't easily add new signatures that require specific parameters.
- MichaelGG 11y ago
  I don't mean related at all to TLS. I mean in general, is the principle of using multiple algorithms that bad? If, in an alternative universe certs were signed with MD5 and SHA1, would that not have been a practical defense to buy some more time? And thus for new, incompatible protocols, is it not a safer choice to use a couple of algorithms? That way if SHA2 or 3 are found to have some terrible weakness, you're still OK. And if practical attacks are found on both, it still might not mean that such attacks work together? There's a bit of precedent in 3DES which just runs the same algorithm 3 times in a row... Which I guess you could do by using the same hash algorithm several times on the same input plus some fixed data or transform. So even though you can find two inputs a and b that h(a) = h(b), you might not be able to get h(f(a)) = h(f(b)) hmm? (Though I understand certain hash attacks will do exactly that for certain values of f.)
Gregordinary 11y ago
In the case of SSL certificates, the SHA-1 or SHA-256 hash algorithm is being used to verify the integrity of the certificate. It assures that the information in the "To be signed" certificate sequence (e.g. domain name, organization, country, etc.) matches what the CA signed. While the motivation to move to SHA-256 is motivated by SHA-1's susceptibility to collisions, the concern for many is that legacy systems may not support SHA-256, meaning older clients won't be able to connect to sites using SHA-256 signed certificates. In general as long as a client is on Windows XP SP3+ or OS X 10.5+ they'll be all set [1]. While this isn't a feature of X.509 certs, if you were to implement "Dual Hashes" (using SHA1/SHA2 as an example), you'd have a scenario where older operating systems may not be able to validate the newer hash and only the older, now insecure hash essentially defeating the purpose. Changing a cert from SHA-1 to SHA-256 in most cases is a matter of reissuing or re-keying your certificate with your CA. Most CAs offer this for free, though some may charge. -- Side note: In the case of document signatures, there is an XML signature standard called XAdES. There are different levels of XAdES signatures, the strongest being XAdES-A [2] where the -A is for "Archive". When you place a signature on a document, to make it valid long term (beyond the expiration date of your certificate) you can add a 3rd party timestamp and embed revocation data into the signature. But what happens when the hash algorithm used by the timestamp server is considered insecure? XAdES allows you to go back and add additional timestamps with newer hash algorithms to make this "future proof". Similar, but not quite the same as what you were suggesting. -- [1] SHA-256 Compatibility: https://support.globalsign.com/customer/en/portal/articles/1499561-sha-256-compatibility https://support.globalsign.com/customer/en/portal/articles/1... [2] XAdES-A: http://www.w3.org/TR/XAdES/#Syntax_for_XAdES-A_form http://www.w3.org/TR/XAdES/#Syntax_for_XAdES-A_form

viraptor 11y ago

"new protocol" is likely going to be less secure than TLS1.2. And TLS1.2 doesn't allow multiple signatures - it's usually in the form of "(hash)-with-(encryption)" (for example oid 1.2.840.113549.1.1.5 - SHA-1 with RSA Encryption) and since that's embedded in the hashed contents, you can't easily add new signatures that require specific parameters.

MichaelGG 11y ago
I don't mean related at all to TLS. I mean in general, is the principle of using multiple algorithms that bad? If, in an alternative universe certs were signed with MD5 and SHA1, would that not have been a practical defense to buy some more time? And thus for new, incompatible protocols, is it not a safer choice to use a couple of algorithms? That way if SHA2 or 3 are found to have some terrible weakness, you're still OK. And if practical attacks are found on both, it still might not mean that such attacks work together? There's a bit of precedent in 3DES which just runs the same algorithm 3 times in a row... Which I guess you could do by using the same hash algorithm several times on the same input plus some fixed data or transform. So even though you can find two inputs a and b that h(a) = h(b), you might not be able to get h(f(a)) = h(f(b)) hmm? (Though I understand certain hash attacks will do exactly that for certain values of f.)

Gregordinary 11y ago

In the case of SSL certificates, the SHA-1 or SHA-256 hash algorithm is being used to verify the integrity of the certificate. It assures that the information in the "To be signed" certificate sequence (e.g. domain name, organization, country, etc.) matches what the CA signed. While the motivation to move to SHA-256 is motivated by SHA-1's susceptibility to collisions, the concern for many is that legacy systems may not support SHA-256, meaning older clients won't be able to connect to sites using SHA-256 signed certificates. In general as long as a client is on Windows XP SP3+ or OS X 10.5+ they'll be all set [1]. While this isn't a feature of X.509 certs, if you were to implement "Dual Hashes" (using SHA1/SHA2 as an example), you'd have a scenario where older operating systems may not be able to validate the newer hash and only the older, now insecure hash essentially defeating the purpose. Changing a cert from SHA-1 to SHA-256 in most cases is a matter of reissuing or re-keying your certificate with your CA. Most CAs offer this for free, though some may charge. -- Side note: In the case of document signatures, there is an XML signature standard called XAdES. There are different levels of XAdES signatures, the strongest being XAdES-A [2] where the -A is for "Archive". When you place a signature on a document, to make it valid long term (beyond the expiration date of your certificate) you can add a 3rd party timestamp and embed revocation data into the signature. But what happens when the hash algorithm used by the timestamp server is considered insecure? XAdES allows you to go back and add additional timestamps with newer hash algorithms to make this "future proof". Similar, but not quite the same as what you were suggesting. -- [1] SHA-256 Compatibility: https://support.globalsign.com/customer/en/portal/articles/1499561-sha-256-compatibility https://support.globalsign.com/customer/en/portal/articles/1... [2] XAdES-A: http://www.w3.org/TR/XAdES/#Syntax_for_XAdES-A_form http://www.w3.org/TR/XAdES/#Syntax_for_XAdES-A_form