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.
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:
- public-key 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.
- secret-key or symmetric-key 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
Three of these algorithms - RSASSA-PKCS1-v1_5, RSA-PSS, and ECDSA - are public-key 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
The fourth algorithm - HMAC - is a symmetric-key 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.
The RSASSA-PKCS1-v1_5 algorithm is specified in RFC 3447.
The RSA-PSS algorithm is specified in RFC 3447.
It's different from RSASSA-PKCS1-v1_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
The HMAC algorithm calculates and verifies hash-based message authentication codes according to the FIPS 198-1 standard.
One of these algorithms - RSA-OAEP - is a public-key cryptosystem. Public-key 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 public-key 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 fixed-size 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).
The RSA-OAEP public-key encryption system is specified in RFC 3447.
This represents AES in Counter Mode, as specified in NIST SP800-38A.
This represents AES in Cipher Block Chaining Mode, as specified in NIST SP800-38A.
This represents AES in Galois/Counter Mode, as specified in NIST SP800-38D.
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 chosen-ciphertext 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.
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 fixed-size output, usually much shorter than the input. They have a variety of applications in cryptography.
This algorithm is specified in FIPS 180-4, section 6.1. Produces an output 160 bits long.
Note that this algorithm is now considered vulnerable and should not be used.
This algorithm is specified in FIPS 180-4, section 6.2. Produces an output 256 bits long.
This algorithm is specified in FIPS 180-4, section 6.5. Produces an output 384 bits long.
This algorithm is specified in FIPS 180-4, section 6.4. Produces an output 512 bits long.
Key derivation algorithms
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 (Elliptic Curve Diffie-Hellman) is a key-agreement 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 is a key derivation function. It's designed to derive some key material from some high-entropy input, such as the output of an ECDH key agreement operation.
It's not designed to derive keys from relatively low-entropy input such as passwords. For that, use PBKDF2.
HKDF is specified in RFC 5869.
PBKDF2 is also a key derivation function. It's designed to derive some key material from some relatively low-entropy 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 brute-force to discover the key using a dictionary attack.
PBKDF2 is specified in RFC 2898.
Key wrapping algorithms
This algorithm is usable by the
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.
AES-KW is a way to use the AES cipher for key wrapping.
It is specified in RFC 3394.