3

I was looking at the WebCrypto crypto libraries coming form the W3C. Looks like only a few cryptosystems are supported, including AES-CBC, AES-CTR, AES-GCM, and RSA-OAEP.

https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/encrypt

Does that mean we're out of luck if we want a different cryptosystem? I'm working on homomorphic encryption and want to use Pallier and order preserving encryption.

A related question is why the new webcrypto API is better than using an existing crypto API such as the Stanford Crypto Library? Stanford Crypto library exposes more useful primitives that makes it possible to implement arbitrary cryptosystems like this Pallier implementation https://mhe.github.io/jspaillier/

2

I was looking at the WebCrypto crypto libraries coming form the W3C. Looks like only a few cryptosystems are supported, including AES-CBC, AES-CTR, AES-GCM, and RSA-OAEP.

First, it is important to understand why we have the Web Crypto API standard at all. It is not designed to be an all-encompassing crypto library for any possible purpose, but specifically to create a secure, inter-operable crypto API to handle a specific set of use cases, so that application developers can be reasonably confident that secure implementations of the specified APIs will be available across multiple user agents.

Does that mean we're out of luck if we want a different cryptosystem?

The Web Crypto API is still under development, so until it's finalized, there's no guarantee. However, I would say that at this point it is more likely for systems and use cases to be removed due to a lack of inter-operable implementations, than added.

A related question is why the new webcrypto API is better than using an existing crypto API such as the Stanford Crypto Library?

It's better because it is built into the user agent. This means that it can't be tampered with by a MitM, an application can't deliver different versions to different users, and so forth. This means that it is much harder to subvert, and that you only need security guarantees from the user agent, not from both the user agent and the crypto library. That said, if it doesn't do what you need, then it doesn't do what you need, and your only option is to look at other options.

1

It sounds like you want to work at a different level of abstraction. A usual developer use-case is of very high-level nature. Think of "make it impossible to read for anyone else but Bob". Or "check if this comes from Alice". If a library provides API that is too low level, people will make mistakes (as in "what is IV? OK, will set it to all zeros").

However, in your case you are actually developing this high-level functionality and you need have a much more fine-grained control over what you are doing. So I wouldn't be surprised that the end-user facing API won't give you all the knobs and handles (like e.g. more exotic algorithms) that you need.

Answering the second question, I don't think it's better, it's just different and may serve different purposes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.