Tom Ritter:
On 5 April 2018 at 09:39, Mark Smith mcs@pearlcrescent.com wrote:
The reason Mozilla chose SHA384 over SHA512 is reduced vulnerability to length extension attacks.
This decision was made without the crypto people at Mozilla being involved. We considered it unnecessary and SHA512 would have been fine; but whatever we're not going to change it again for vanity.
Reading through the bug it seems crypto people were consulted, no? Either way, I wonder what https://bugzilla.mozilla.org/show_bug.cgi?id=1105689#c52 implies
("Keep in mind that the implementation design that was created with the security team for this required that we use the system provided crypto instead of NSS if at all possible.")
because three years ago I said at least that we are using NSS on all platforms. Looking at the changes for SHA-348, though, it seems they don't change the game for us or am I missing anything?
brade/mcs: please proceed as you see fit taking my two comments above into account. Having a smaller patch set for the updater related parts, especially for the crypto related ones, is pretty appealing...
- "Remove hashFunction and hashValue attributes"
https://bugzilla.mozilla.org/show_bug.cgi?id=1373267 Mozilla removed support for a hash check of the MAR files that has historically been implemented by including hash values in the update manifest (XML) file that is returned by the update server. Mozilla relies on MAR signatures to verify the integrity of the Firefox MAR files, but in the past we have talked about the value in requiring that two things need to be compromised: the update server as well as a MAR signing key. For that reason, Kathy and I believe we should back out these changes and continue to have our update server return hash values.
SGTM.
+1
Georg