search

w3c / webappsec-subresource-integrity

WebAppSec Subresource Integrity
https://w3c.github.io/webappsec-subresource-integrity/
Other
70 stars 35 forks source link

SHA-3/Keccak #11

Open smarts opened 9 years ago

smarts commented 9 years ago

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

fmarier commented 9 years ago

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 commented 8 years ago

Why was this removed from the v2 milestone?

isaacs commented 4 years ago

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: https://github.com/npm/ssri/issues/5

devd commented 4 years ago

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 notifications@github.com 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- is not ideal. It'd be nice to know if we should be using sha3_512- or keccak512- 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 https://github.com/npm/ssri/issues/5

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/webappsec-subresource-integrity/issues/11?email_source=notifications&email_token=AABBOGIANZ5AFUA5IGT35RDRDMXORA5CNFSM4BS4IQ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMAFXZA#issuecomment-587226084, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABBOGMEDPYYP4L6WRAAWADRDMXORANCNFSM4BS4IQ3Q .

mikewest commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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.