5 ms·

Historically, NIST had provided transition guidance to Federal agencies circa March 2006 to begin migrating to SHA-2[1], officially deprecated SHA-1 for digital

Historically, NIST had provided transition guidance to Federal agencies circa March 2006 to begin migrating to SHA-2[1], officially deprecated SHA-1 for digital signature generation use between 2011 and 2013[2], and outright disallowed it with exception for the same circa November 2015[3]. FWIW, the memo from the horse's mouth[4]: > To protect your security, Windows operating system updates are dual-signed using both the SHA-1 and SHA-2 hash algorithms to authenticate that updates come directly from Microsoft and were not tampered with during delivery. Due to weaknesses in the SHA-1 algorithm and to align to industry standards Microsoft will only sign Windows updates using the more secure SHA-2 algorithm exclusively. I'd imagine orchestrating this push is a real cluster. Would be interesting hear perspective from the inside. [1] https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions https://csrc.nist.gov/projects/hash-functions/nist-policy-on... [2] https://doi.org/10.6028/NIST.SP.800-131A https://doi.org/10.6028/NIST.SP.800-131A [3] https://doi.org/10.6028/NIST.SP.800-131Ar1 https://doi.org/10.6028/NIST.SP.800-131Ar1 [4] https://support.microsoft.com/en-us/help/4472027/2019-sha-2-code-signing-support-requirement-for-windows-and-wsus https://support.microsoft.com/en-us/help/4472027/2019-sha-2-...

dspillett 8y ago
> updates are dual-signed using both the SHA-1 and SHA-2 hash algorithms > Due to weaknesses ... and ... industry standards Microsoft will only sign Windows updates using the more secure SHA-2 algorithm exclusively. This seems like a half step to me. I assume the used both as a transitional process: use both until all consumers of the signed content support the better, then drop the older standard. I wonder why they've not done the same and replaced SHA-1 with a more recent algorithm, so they can easily deprecate SHA-2 if/when needed at a later date? All the code and processes already support multiple hashes/signatures so that wouldn't be a problem. Or is the next accepted standard not yet fully decided yet? Or do they think SHA-2 will last long enough that SHA-3 (assuming that is the generally accepted next step) will be supplanted at least once before SHA-2 needs deprecating so there is no point implementing that now?
- blattimwind 8y ago
  > SHA-3 (assuming that is the generally accepted next step) That's just the thing, SHA-3 isn't the generally accepted successor to SHA-2. The "go to" hash function is still SHA-2, or BLAKE2.

dspillett 8y ago

> updates are dual-signed using both the SHA-1 and SHA-2 hash algorithms > Due to weaknesses ... and ... industry standards Microsoft will only sign Windows updates using the more secure SHA-2 algorithm exclusively. This seems like a half step to me. I assume the used both as a transitional process: use both until all consumers of the signed content support the better, then drop the older standard. I wonder why they've not done the same and replaced SHA-1 with a more recent algorithm, so they can easily deprecate SHA-2 if/when needed at a later date? All the code and processes already support multiple hashes/signatures so that wouldn't be a problem. Or is the next accepted standard not yet fully decided yet? Or do they think SHA-2 will last long enough that SHA-3 (assuming that is the generally accepted next step) will be supplanted at least once before SHA-2 needs deprecating so there is no point implementing that now?

blattimwind 8y ago
> SHA-3 (assuming that is the generally accepted next step) That's just the thing, SHA-3 isn't the generally accepted successor to SHA-2. The "go to" hash function is still SHA-2, or BLAKE2.