Is support for SHA-256 and Blake-3 right?

[darobin]

Blake-3 is very useful for streaming verification of large files, but at the same time it's not supported in the browser, which makes it heavy to include.

[bnewbold]

FWIW, for atproto we are a bit split on it. on the one hand we'd like to use it for larger media files (videos) at some point. on the other hand, it tends to have performance-sensitive implementation and ends up pulling in deps and longer builds, even in non-Javascript languages. so being able to not use it until we actually need it would be nice.

(this is my informal take, not an official/formal bsky team consensus)

[darobin]

That's good to hear because I think it reflects conversations happening elsewhere. I'm sort of landing on "we support B3 but implementations should default to SHA and people shouldn't use it unless they have a good reason." It's ungainly, but then again this_is_standards.gif.

[bumblefudge]

SHA2-256 or SHA3-256? something something length-extension attacks (in the case of the former). but the latter is much less common, so I assume you mean SHA2-256. is it worth writing it out as SHA2-256 in the spec?

see also:

w3c/webcrypto#319 (comment)

[mishmosh]

we support B3 but implementations should default to SHA

I think it's worth being very explicit about this for tooling, e.g.:

• MUST default to SHA
• MUST support B3 by flag (if B3 ends up blessed in DASL, given size/ browser concerns)

[achingbrain]

This is worth following along with - w3c/webcrypto#73 - it seems that things are moving towards supporting streams in Web Crypto so we'll be able to use SHA-256 to hash arbitrary streams of data without needing any extra dependencies.

The addition of Blake-3 seems unlikely without people like us pushing for it and even then getting all the relevant parties on board will be difficult and the timescales are likely to be glacial, given the years it's taken to move Ed25519 along.

[darobin]

Ok — I've created a BDASL spec and removed BLAKE3 support.