Both ed25519 keys and Web Crypto RSA keys are supported "out of the box" in the rs-ucan project, which is the basis for using these as the defaults in Noosphere.
For CID hashing, we currently use blake2b-256 everywhere. Blake2b's main virtue is its speed compared to most plausible alternatives.
This issue is intended to kick off a discussion weighing the pros and cons of our default cryptography in use before we get too comfy with our priors. Some provocations to kick off the discussion:
There is compelling evidence that we should switch to BLAKE3 for hashing; what is the counter-arguement?
Compatibility across ed25519 implementations seems like it could be a real problem; is it worth blessing a (possibly less popular / less available) alternative as our favored default?
Currently we make wide use of ed25519 keys (via
ed25519-zebra
), except on the web where we use RSASSA-PKCS1-v1_5 (via the Web Crypto API).ed25519 has various virtues (small public key size, speedy verification time among them), but also comes with some baggage:
Both ed25519 keys and Web Crypto RSA keys are supported "out of the box" in the
rs-ucan
project, which is the basis for using these as the defaults in Noosphere.For CID hashing, we currently use blake2b-256 everywhere. Blake2b's main virtue is its speed compared to most plausible alternatives.
Recently, there was some thought provoking discussion of the default schemes used in Bluesky: https://staging.bsky.app/profile/gtank.bsky.social/post/3jvsidg6mgh2f And less recently, some discussion on Bluesky about usage of the BLAKE3 hash by n0 computer: https://staging.bsky.app/profile/b5.bsky.social/post/3jv2zaqze5s2x (see also this screencast).
This issue is intended to kick off a discussion weighing the pros and cons of our default cryptography in use before we get too comfy with our priors. Some provocations to kick off the discussion: