SHA-3/Keccak

[smarts]

SHA-3 has been published. Why not require (or strongly suggest) support for it as well?

[fmarier]

Why not require (or strongly suggest) support for it as well?

That's certainly something we should add to V2. Adding this requirement to V1 at this point would move us away from having our two shipping compliant implementations.

[smarts]

Why was this removed from the v2 milestone?

[isaacs]

It'd be good to get this included, particularly with some guidance about the algorithm indicator to use, since SHA v3 is really 3 different algorithms depending on the bit count.

As I understand it, the - character delimits the algorithm from the hash, so sha3-512-<hash> is not ideal. It'd be nice to know if we should be using sha3_512-<hash> or keccak512-<hash> or what. Even before there's browser buy-in, Node.js programs using the ssri library could benefit from stronger and more future-proofed integrity values, and we could add support for it there very easily.

Related: npm/ssri#5

[devd]

I think the key question here is browser interest. Do you mind starting a thread on public-webappsec on whether browsers are interested in adding sha3 support for Sri?

…

On Mon, Feb 17, 2020, 5:01 PM isaacs ***@***.***> wrote: It'd be good to get this included, particularly with some guidance about the algorithm indicator to use, since SHA v3 is really 3 different algorithms depending on the bit count. As I understand it, the - character delimits the algorithm from the hash, so sha3-512-<hash> is not ideal. It'd be nice to know if we should be using sha3_512-<hash> or keccak512-<hash> or what. Even before there's browser buy-in, Node.js programs using the ssri <http://npm.im/ssri> library could benefit from stronger and more future-proofed integrity values, and we could add support for it there very easily. Related: npm/ssri#5 <npm/ssri#5> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#11?email_source=notifications&email_token=AABBOGIANZ5AFUA5IGT35RDRDMXORA5CNFSM4BS4IQ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMAFXZA#issuecomment-587226084>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABBOGMEDPYYP4L6WRAAWADRDMXORANCNFSM4BS4IQ3Q> .

[mikewest]

From Chromium's perspective, we're unlikely to be able to easily support primitives that don't make it into BoringSSL. AFAIK, that doesn't yet support SHA-3, and given that @agl has suggested that we consider skipping SHA-3, it's not clear to me whether that's likely to happen.

@isaacs: Can you help me understand why this is valuable to y'all? Does SHA-256/512 not meet your need?

[agl]

Adding primitives costs implementation time, validation & compliance time, and code size. It also has non-linear costs in terms of supporting and testing all the various combinations that it introduces across various protocols.

Since we already have secure hash functions in the form of SHA-256 and SHA-512, we've no plans to support SHA-3 generally.

[isaacs]

This is certainly not a pressing issue, as SHA-512 is still secure, and I'm sure will be for some time.

But, as we saw with md5, and then sha1, "secure" (in a boolean sense) is a temporary state. One of the benefits of SRI as a standard is that it allows for future-proofing by swapping out weaker algorithms for stronger ones over time.

Eventually, I expect that SHA-512 will not be sufficiently secure, and we'll want to migrate to something stronger. SHA3-512 is stronger. Support for SHA3 has been added to Node.js in the latest stable releases, so it'd be nice to have a plan for supporting SHA3 integrity values in npm packages.

I understand the resistance to adding SHA-3 support to browsers, given the lack of urgency and the costs involved. But still, it'd be nice to have some guidance from the SRI specification what a valid SHA-3 SRI would look like, once supported, so that those of us who are ready to support it can do so in a way that is forward compatible.

[annevk]

But it's not clear it will be supported, per the prior two replies, so why would we update the formal standard to suggest otherwise?

[isaacs]

@annevk Seems fine for now, I guess. (Where "now" = "the next few years at least".) If sha-3 ends up being skipped in favor of some other update to make sha2 faster and/or more secure, then we've saved the hassle of adding it.