Finally we are getting started with the Opaque project. It will be a JavaScript package allowing developers to implement username/password authentication without the need to ever send the password to a server in cleartext.

Sounds simple, but compared to common existing solutions this has quite a serious impact on security. The details matter here. For example one property you want to have is security against pre-computation attacks upon server compromise. Coming up with such a system requires a lot of research work involving advanced knowledge about cryptography.

Luckily for us the research and ground work was already done by others in the last couple years and we can build upon their work. The first essential part was the OPAQUE paper published 2018. Later a couple of IETF members continued the work and started on the OPAQUE Protocol RFC which is in its final stages. In addition to that opaque-ke was created as a Rust library based upon the protocol specs. It was audited and used in production for example by WhatsApp for their end-to-end encrypted backups of messages. Last but not least opaque-wasm demonstrated how opaque-ke could be leveraged to build a WebAssembly implementation to use it in JavaScript.

This is exactly where our project starts. We aim to create a production ready JavaScript package, making it easy to install and use the OPAQUE Protocol with a handful of JavaScript function calls.

In the beta version of our application Serenity we already have WIP implementation. But our goal is to make our Opaque package a well executed stand-alone Open source project which

• is well tested (unit and integration tested)
• typed (using TypeScript)
• easy to use (e.g. sensible defaults regarding cryptography parameters)
• well documented (e.g. API documentation and guides)
• audited (security)

One of the trickiest parts probably will be on how to explain Opaque and it's benefits so engineers with no security background can grasp the idea and why it's so important.

Long term we hope our work has a considerable impact establishing the OPAQUE Protocol as a best practice and help to massively reduce password leaks.

But before that we first need to ship a beta. :) In the next two months we aim to get all the necessary ground work done and do exactly that. If you are excited about our work, feel free to reach out and let us know. Feedback regarding API design, security as well as early beta testers are always welcome.

P.S: One of our favorite parts of the OPAQUE Protocol is that you can sign up or sign in and always reconstruct a so-called export_key only visible to the client (never the server). This key can be used as a private key for asynchronous cryptography allowing developers to implement end-to-end encryption. This makes it a great match for services relying on email/password authentication that would want to offer end-to-end encryption inside their application.