Prefer use of WebCrypto where applicable?

[coolaj86]

I get it if you just want to keep things with libsodium because you're using ed25199 and WebCrypto support for that may never happen, however, as reference material, it might be nice to use WebCrypto where it is compatible, for example:

let seed = new Uint8Array(16);
void crypto.getRandomValues(seed);
console.log(seed);

https://github.com/mylofi/local-data-lock/blob/4bfb9b4ed4ba76941479d3b637e57c601f3fc209/src/ldl.js#L473

I think sodium will work with standard buffers: https://github.com/search?q=repo:sodium-friends/sodium-native%2520crypto_sign_seed_keypair&type=code

[getify]

I only use WebCrypto when libsodium can't do it. Specifically libsodium can't verify signatures other than ed25519, so I use webcrypto for verifying signatures of the other algorithms

The cryptographic primitives in WebCrypto are extremely painful to put it mildly. They're significantly limited compared to libsodium. Since I need libsodium for so many things, it makes sense to me to just use it by default, and only use WebCrypto if necessary.

[getify]

Further, the reason for standardizing on libsodium is because it has so many ports to other languages/stacks (as opposed to webcrypto, which has... well... had a mixed track record in that respect). I want as much interop with, or potential future ports of it, as possible. Just about anywhere that someone might be writing adjacent code, they can get a libsodium distribution. WebCrypto stuff is far less portable (doesn't even work in react-native, for example!).

[coolaj86]

I'm more in the vein of the the philosophy of use the "free" (as in bytes) web tools when they're available, and not having the extra download size - especially for the "must load to use" type of utils (1mb isn't nothing).

For example:

• let bytes = new Uint8Array(16); crypto.getRandomValues(bytes);
• let bytes = new TextEncoder().encode("Hello, World!");

All of Node.js, Bun, and Deno are converging on "Web Standards" and when I'm writing in Go or another sane language, I use the crypto from the standard library there as well.

(and since I'm a sane person, I wouldn't touch React Native - or of any other sort of React - with a 39.5ft pole 😉)

That's not try to convince you to refactor this codebase, but I hope you keep an open mind to native JS in the future - it really is much better now.

I tried to create something just like webauthn-local-client literally 15 years ago, only to get thwarted in the last few months by a browser update the changed iframe and cookie policies (for the better, but completely breaking my code), so I've felt the burn... but I'm so happy things have come along so nicely and are widely available now.

[getify]

it really is much better now.

<rant>it's abysmal, terrible, and hopeless. webcrypto will absolutely never, ever come close to as useful as something like libsodium. I've spent years researching and banging my head against this kind of crypto stuff. web-crypto is possibly one of the most disappointing and poorly designed APIs in the whole web platform, as far as I'm concerned. It's designed by people who must have never written a single line of useful application code.</rant>

I need libsodium for things that web-crypto can't or won't ever do... such as converting between ed25519 and curve25519, etc. Since I need that, and I don't want to just patch-work in a half-dozen other libraries to do so, I'm already paying the cost of libsodium (and yes, I know it's big). As such, sunk-cost wise, it's already "free" to use throughout the rest of the library. So I plan to keep to using it.

[getify]

appreciate the feedback here. :)

but as things stand now, libsodium usage is not really up for debate. closing for now.