Web Crypto API interoperability

[espoal]

I'm implementing an authentication and authorization platform designed around the Web Crypto API (WCAPI). It all revolves around two examples: ECDH + HMAC (here), or PBKDF2 + HMAC (here). Ideally I would like for WCAPI and wasi-crypto to be interoperable, so that I could use WCAPI in the web environment, and wasi-crypto elsewhere. Unfortunately I found this not to be trivial:

• PBKDF2: WCAPI offers only this method to derive symmetric keys from low entropy secrets. Unfortunately I couldn't find mention of this in the wasi-crypto specification. This would be a blocker for interoperability.
• Reduced options: wasi-crypto has fewer options compared to the WCAPI, which is itself quite limited. Is there a reason behind the choice of algorithms?

Could interoperability with the WCAPI be a goal worth considering?

[jedisct1]

Hi Alberto!

Keep in mind that the current specification is not final; it's a starting point that will get incremental additions.

Key stretching (PBKDF2, Scrypt, Argon2) will be added. But this class of functions is a little bit special. By design, they can consume a lot of CPU and memory from their host. They can also take a long time to return, so they must be non-blocking.

So, they requires special considerations. Implementations considerations, operational considerations, and a non-blocking API probably based on Promises ("futures"), something that the current version of WASI doesn't have. We will eventually address these in another revision of the specification.

The WASI-Crypto specification actually includes a lot of algorithm, more than WebCrypto, including modern algorithms such as post-quantum key exchange systems and permutation-based constructions.

Some of these are required, others are recommended, others are optional. The set of required ones is small, but guarantees interoperability between implementations. This also helps with compliance and keeps implementations smaller, helping with compatibility with constrained devices.

WASI-Crypto cannot encompass everything that WCAPI, OpenSSL, Microsoft's CSP, etc. have. Especially at that point: we want to keep it small and simple to encourage people to implement it. But without preventing runtimes from adding optional or custom algorithms if they want to.

[espoal]

thanks @jedisct1 for the quick answer. I will take care to write tests to check wherever wasi-crypto and web crypto are actually compatible. I expect them to be, but we all know the devil is in the details :)

I will get back to you in case I can't make something work. Feel free to close this issue, or keep it open and I will update it with my findings.