Argon2 KDF

Hey @borisbadenuf

Welcome to the 1Password Support Community. 🤗 The latest update I have on this topic was posted February 2nd 2023 by our Chief Defender Against the Dark Arts, Jeff Goldberg, over on reddit. You can read that response here:

https://www.reddit.com/r/1Password/comments/10reuwj/comment/j6zlyls/?utm_source=reddit&utm_medium=web2x&context=3

For convenience, I'll copy & paste the content into this thread as well:

For such an excellent question, I am sorry that I once again have to give a vague answer. There is progress in terms of some of our own internal designs and testing, but some of the same barriers remain which include some practical issues around WASM.

Although there are JavaScript implementations of Argon2, we would really like to have all (new) cryptography in the 1Password Rust core, and there is a Rust Argon2 crate that we are happy with. And I am also pleased to say that our Rust core does compile to WASM, but I must also report that it is way too big to actually make use of within a browser. So quite honestly we need to break up parts of our common core so that they can be compiled and loaded separately. And that will involve lots of refactoring that will impact much of the code and build processes. So yes, there is progress, but don't expect anything soon.

The impatient might suggest that we just use a JavaScript Argon2 until we can get our common Rust core working in the browser, but we really, really want to be reducing the number of different implementations of the same protocol being used. Someday, I should write about what was dubbed internally as the Heisenbug (it was really hard to reproduce). It turned out to be because different standard libraries for different development environments did hex encoding slightly differently when the leading byte is Ox00. So as I said, we really want to just have one implementation of Argon2d (and all new crypto).

PBKDF2 increase sets an example

Our upping of PBKDF2 iterations provided a really nice test for many of the things we would need to do to roll out an entirely different KDF. In theory there should have been a single line of code we changed server side to change the new iterations count, as the clients pick those up from the server. And in terms of the user clients, that really is all it took. We did find that there were some special clients (things like the SCIM bridge) which didn't have the flexibility built in. PBKDF2 rounds isn't really an issue for those special clients as they work with randomly generated account passwords to begin with, but we did get to see the kinds of things we will need to look out for in future changes to the KDF. We found a couple of weird client-side timeouts in some clients could safely be removed.

Most importantly we got to put our Quality Assurance processes to the test. Testing vigorously on every platform for every client for the lowest powered devices we support was a major part of the effort. Very few users should even notice any change in unlock speeds. It should continue to feel snappy. For the lowest powered devices it is user noticeable, but not problematic. I don't think any "one line code change" has ever been so comprehensively tested.

The fact that this went so well is extremely encouraging for future rollouts of changes of that sort. We designed the system so that this should be "easy", but this served as a really good test of it.

So again, yes there is progress. But please don't hold your breath.

I hope that helps!

Ben