Web Cryptography API — why are uages sort of »exclusive«

Question

I am developing an little web application that should allow the user to »bring your own key« in order to encrypt, decrypt, sign and verify data within the browser. Looking at this table (algorithm overview) shows that not all operations for a certain type of Key are actually supported by the Web Cryptography API.

For Instance: Encryption and decryption only with with RSA-OAEP. Signing and verification, on the other hand, is only supported for RSASSA-PKCS1-v1_5 and RSA-PSS. Assuming the user comes along with a key pair in pkcs8 and spki format respectively for the private and public key. I would need to create different »JS CryptoKey Instances« in order to support all actions (en- / decryption AND signing / Verification).

All in All I do not really understand:

• why can't ECDSA or Ed25519 keys used for en- / decryption?
• why can ECDH only be used for key- and bit- derivation while non of the others can?

I hope my memory doesn't trick me, but keys based on elliptic curves support en- / decryption, don't they? Isn't that the same thing for signing and verification?

So, what's the reason behind these sort of »exclusive« possible usages?

Answer 1

The short version of the answer is "you should be asking this on crypto.stackexchange.com", because it's fundamentally a question about how cryptography works, not about security APIs. To put it differently, the API works that way because that's what those primitives can be used for.

To answer your specific points:

• RSA with Optimal Asymmetric Encryption Padding is intended for encryption use, not for other uses. Padding is an essential part of securely encrypting with RSA; naive encryption with a bare RSA key has serious pitfalls. Similarly, RSA with Probabilistic Signature Scheme is a way to securely handle signing with RSA. You can use the same underlying keypair for both (or for PKCS v1.5 if you really must, but you shouldn't, it's obsolete), but the way they are used is different. From a programmer's perspective, RSA-OAEP public keys are a subclass of Asymmetric Encryption Public Keys, and implement the relevant API; RSA-PSS public keys are subclasses of Digital Signature Public Key (as are Ed25519 public keys) and have a different API from encryption public keys.
• Elliptic Curve Digital Signature Algorithm is an algorithm for signing (and verifying signatures), not for encryption. RSA can use the same keys and ~same algorithm for both operations, but that's not universal (and it requires huge key sizes and computationally expensive math to do so securely). Ed25519 is a specific case of the EdDSA (guess what the "DSA" part stands for there) family, also designed specifically for signing/verifying. There do exist elliptic curve algorithms for asymmetric encryption and decryption - see ECIES, the Elliptic Curve Integrated Encryption Scheme - but that's a different algorithm.
• Elliptic Curve Diffie-Hellman is - like all Diffie-Hellman key exchange algorithms - intended neither to encrypt nor to sign date, but instead to allow two parties to mutually agree on an unpredictable secret without revealing the secret to eavesdroppers. Thus, it's usable for deriving a (symmetric) key or other random bitstring - because that's fundamentally what it does, calling it a "key exchange" is arguably a misnomer, the key doesn't exist until the algorithm completes - but not for anything else (though Integrated Encryption Scheme is built on the same computational "problem" that secures DH key exchanges). Note that you can use asymmetric encryption algorithms for securely transmitting a pre-generated key (or other secret) to the other party - this is how RSA is used for key exchanges - but it's less secure, because the sender must encrypt the secret to a public key that has a corresponding private key held by the recipient, and that private key is generally persistent such that it could be compromised later and used to decrypt the secret. DH-based key exchanges usually use "ephemeral" parameters (or "keys") that generated, used once, and then discarded; there is no persisted value that could retroactively be used to compromise the exchanged key.

Answer 2

Each cryptographic algorithm has specific properties which makes it suitable – or unsuitable – for specific purposes. For example, (EC)DSA (which stands for “Digital Signature Algorithm”) produces fixed-sized signatures from arbitrarily-sized messages, so it's impossible to “reverse” the output and get the original message back. This already excludes it from being used for encryption and decryption.

Nonetheless, you can (and should) use (EC)DSA and (EC)DH as building blocks to encrypt data. For example, real-world applications almost always employ hybrid cryptosystems where, for example, (EC)DH is used to produce a shared secret between two parties, (EC)DSA is used to sign the (EC)DH parameters, and then a symmetric cipher like AES encrypts and decrypts data with a key derived from the shared secret. See the Integrated Encryption Scheme (IES) for a formalization of this idea.

Using RSA (with the OAEP padding scheme) to directly encrypt data is usually ill-advised. Not only are you limited to just a few bytes of data (like a symmetric key). You also don't get forward secrecy: If an attacker collects ciphertext and manages to compromise the private key at any point in the future, they can retroactively decrypt all ciphertexts that has ever been encrypted with the corresponding public key.

Answer 3

ECDSA and Ed25519 are algorithms specifically designed for signing and verifying data, and the Elliptic-Curve Diffie-Hellman key-exchange method allows two parties to compute a shared secret securely. ECDH is used in many protocols, such as TLS.

Wikipedia defines encryption as:

the process of transforming information in a way that, ideally, only authorized parties can decode.

So, while methods/algorithms like ECDH and ECDSA are related to encryption, they are fundamentally different. It’s like comparing apples to oranges.

---

I recommend you take a look at the following content:

• The encryption tag.

• The ecdsa tag.

• ”Diffie-Hellman Key Exchange" in plain English.

• Our Cryptography sister-site.