Draft
This page is not complete.
This page lists and briefly describes the cryptographic algorithms commonly supported by browsers, organized by the functions for which they are suitable.
The Web Crypto API provides functions that implement different cryptographic operations, such as sign()
, verify()
, encrypt()
, decrypt()
and so on.
Each operation can be performed by one or more different cryptographic algorithms: the algorithm
argument to the function indicates which algorithm to use. Some algorithms need extra parameters: in these cases the algorithm
argument is a dictionary object that includes the extra parameters.
The table below summarises which algorithms are suitable for which cryptographic operations:
sign() verify() 
encrypt() decrypt() 
digest() 
deriveBits() deriveKey() 
wrapKey() unwrapKey() 


RSASSAPKCS1v1_5  ✓  
RSAPSS  ✓  
ECDSA  ✓  
HMAC  ✓  
RSAOAEP  ✓  ✓  
AESCTR  ✓  ✓  
AESCBC  ✓  ✓  
AESGCM  ✓  ✓  
SHA1  ✓  
SHA256  ✓  
SHA384  ✓  
SHA512  ✓  
ECDH  ✓  
HKDF  ✓  
PBKDF2  ✓  
AESKW  ✓ 
Apart from the four digest algorithms and the HKDF and PBKDF2 key derivation algorithms, all the other algorithms here use keys. Algorithms that use keys can be divided into two sorts:
 publickey or asymmetric cryptosystems: with these systems, you get a key pair: the transformation performed by one of the keys can only be undone with the other key. In the Web Crypto API a key pair is represented as a
CryptoKeyPair
. Typically one key is made public and the other is kept private. When used for digital signatures, the private key is used to sign and the public key to verify. When used for encryption, the public key is used to encrypt, and the private key is used to decrypt.  secretkey or symmetrickey algorithms: with these algorithms there is just one key. The transform performed by the key can only be undone by the same key. In the Web Crypto API a single key is represented as a
CryptoKey
.
Signing algorithms
These algorithms are usable by the sign()
and verify()
functions of the Web Crypto API.
Three of these algorithms  RSASSAPKCS1v1_5, RSAPSS, and ECDSA  are publickey cryptosystems. These systems all use a digest algorithm to hash the message to a short fixed size before signing. The choice of digest algorithm is passed into the SubtleCrypto.generateKey()
or SubtleCrypto.importKey()
functions.
The fourth algorithm  HMAC  is a symmetrickey algorithm. Unlike the other three signing algorithms, it uses the same key for signing and for verification: this means that the verification key must be kept secret, which in turn means that this algorithm is not suitable for many signature use cases. But it can be a good choice when the signer and verifier are the same entity.
RSASSAPKCS1v1_5
The RSASSAPKCS1v1_5 algorithm is specified in RFC 3447.
RSAPSS
The RSAPSS algorithm is specified in RFC 3447.
It's different from RSASSAPKCS1v1_5 in that it incorporates a random salt in the signature operation, so the same message signed with the same key will not result in the same signature. An extra property, defining the salt length, is passed into the SubtleCrypto.sign()
and SubtleCrypto.verify()
functions.
ECDSA
ECDSA (Elliptic Curve Digital Signature Algorithm) is a variant of the Digital Signature Algorithm, specified in FIPS186, that uses Elliptic Curve Cryptography (RFC 6090).
HMAC
The HMAC algorithm calculates and verifies hashbased message authentication codes according to the FIPS 1981 standard.
Encryption algorithms
These are usable by encrypt()
and decrypt()
, as well as wrapKey()
and unwrapKey()
, that use encrypt and decrypt operations under the hood.
One of these algorithms  RSAOAEP  is a publickey cryptosystem. Publickey encryption systems have an advantage over symmetric encryption systems in that the encryption key can be made public: so anyone can send me an encrypted message but only I will be able to decrypt it. However they are typically much slower than symmetric algorithms and the size of message they can encrypt is proportional to the size of the key, so they do not scale well for long messages.
As a result, it's common for an encryption system to use a symmetric algorithm to encrypt the message, then a publickey system to encrypt the symmetric key. This arrangement can confer the benefits of both systems.
The other three encryption algorithms here are all symmetric algorithms, and they're all based on the same underlying cipher, AES (Advanced Encryption Standard). The difference between them is the mode. AES is a block cipher, meaning that it operates on a fixedsize block of bytes. Since the block size is usually smaller than the message to encrypt, it's necessary to specify how to use a block cipher to securely encrypt messages that are longer than the block size, and that's what a mode does. Using an inappropriate mode, or using a mode incorrectly, can completely undermine the security provided by the underlying cipher.
The Web Crypto API support three different AES modes:
 CTR (Counter Mode)
 CBC (Cipher Block Chaining)
 GCM (Galois/Counter Mode).
RSAOAEP
The RSAOAEP publickey encryption system is specified in RFC 3447.
AESCTR
This represents AES in Counter Mode, as specified in NIST SP80038A.
AESCBC
This represents AES in Cipher Block Chaining Mode, as specified in NIST SP80038A.
AESGCM
This represents AES in Galois/Counter Mode, as specified in NIST SP80038D.
One major difference between this mode and the others is that GCM is an "authenticated" mode, which means that it includes checks that the ciphertext has not been modified by an attacker. Authentication helps protect against chosenciphertext attacks, in which an attacker can ask the system to decrypt arbitrary messages, and use the result to deduce information about the secret key. While it's possible to add authentication to the other modes, they do not provide it by default.
Digest algorithms
These algorithms are usable by the digest()
function of the Web Crypto API.
Digest algorithms, also known as cryptographic hash functions, transform an arbitrarily large block of data into a fixedsize output, usually much shorter than the input. They have a variety of applications in cryptography.
SHA1
This algorithm is specified in FIPS 1804, section 6.1. Produces an output 160 bits long.
Note that this algorithm is now considered vulnerable and should not be used.
SHA256
This algorithm is specified in FIPS 1804, section 6.2. Produces an output 256 bits long.
SHA384
This algorithm is specified in FIPS 1804, section 6.5. Produces an output 384 bits long.
SHA512
This algorithm is specified in FIPS 1804, section 6.4. Produces an output 512 bits long.
Key derivation algorithms
These algorithms are usable by the deriveKey()
and deriveBits()
functions of the Web Crypto API.
The deriveBits()
function will derive an array of bits using the algorithm specified. The deriveKey()
function will derive an array of bits using the algorithm specified, and then convert these bits into a CryptoKey object that can be used in other cryptographic operations (primarily encryption, since these algorithms are only used to derive symmetric keys).
The three algorithms listed here have quite different characteristics and are appropriate in different situations.
ECDH
ECDH (Elliptic Curve DiffieHellman) is a keyagreement algorithm. It enables two people who each have an ECDH public/private key pair to generate a shared secret: that is, a secret that they  and noone else  share. They can then use this shared secret as a symmetric key to secure their communication, or can use the secret as input to derive such a key (for example, using the HKDF algorithm).
ECDH is specified in RFC 6090.
HKDF
HKDF is a key derivation function. It's designed to derive some key material from some highentropy input, such as the output of an ECDH key agreement operation.
It's not designed to derive keys from relatively lowentropy input such as passwords. For that, use PBKDF2.
HKDF is specified in RFC 5869.
PBKDF2
PBKDF2 is also a key derivation function. It's designed to derive some key material from some relatively lowentropy input, such as a password. It derives key material by applying a function such as HMAC to the input password along with some salt, and repeating this process many times. The more times the process is repeated, the more computationally expensive key derivation is: this makes it harder for an attacker to use bruteforce to discover the key using a dictionary attack.
PBKDF2 is specified in RFC 2898.
Key wrapping algorithms
This algorithm is usable by the wrapKey()
and unwrapKey()
functions of the Web Crypto API. Note that all the algorithms listed under "Encryption algorithms" can also be used for key wrapping and unwrapping.
Key wrapping algorithms use a symmetric algorithm to encrypt a key, so the key is protected when in storage or transmission in untrusted environments.
AESKW
AESKW is a way to use the AES cipher for key wrapping.
It is specified in RFC 3394.