6 comments

[ 3.3 ms ] story [ 30.0 ms ] thread
Interesting, albeit a bit lightweight as compared to the similar document from 1Password: https://support.1password.com/cs/opvault-design/ (yes, I recognize it's a tiny bit apples-to-oranges since 1P has now gone whole hog toward their b2 API)

Speaking of which, I presume Huy doesn't work for Bitwarden, so it's unfortunate they needed some independent blogger to write up their auth scheme. I do realize there's an independent implementation in Vaultwarden, so that's almost better than a spec -- just as long as Vaultwarden was a clean-room impl and thus reading that code is "legally safe."

> it's unfortunate they needed some independent blogger to write up their auth scheme

That's kind of a odd statement, no?

The information is provided by Bitwarden and easily found, for example:

* https://bitwarden.com/help/what-encryption-is-used/

* https://bitwarden.com/blog/end-to-end-encryption-and-zero-kn...

I feel pretty confident is saying that Huy's content is more technical than a blog post about "end to end encryption," and neither hold a candle to the level of specificity in that opvault-design document.

So maybe you found it to be an odd statement, I dunno, but I stand by that it is unfortunate that they needed someone independent person to dive into that level of technical detail

> I do realize there's an independent implementation in Vaultwarden, so that's almost better than a spec -- just as long as Vaultwarden was a clean-room impl and thus reading that code is "legally safe."

Vaultwarden is a server implementation, though.

As the article also points out, the *warden server is little more than a basic REST API, all the cryptographically fun parts happen on the client side, for which there are only the official implementations so far.