]>
Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API
W3C/MIT
harry@w3c.org
http://www.ibiblio.org/hhalpin/
Cryptosense/INRIA
Graham.Steel@inria.fr
http://www.lsv.ens-cachan.fr/~steel/
Internet Research Task Force
Internet-Draft
This overview document provides information on the current state of algorithms made available by the W3C Web Cryptography API, including whether protocols have security proofs or known weaknesses.
While cryptography is a small part of security, choosing the right cryptographic algorithm is an important part of deploying cryptography. Many developers find it difficult to follow the current state of cryptanalytic research regarding particular algorithms. This document gives a concise overview of known weaknesses and the state of security proofs in standard developer-facing APIs such as the W3C Web Cryptography API . This analysis may also be useful in analyzing the properties of protocols given in the algorithms used by the IETF JSON Web Algorithms .
This overview provides no substitute for a detailed analysis of a particular protocol: when deploying cryptographic algorithms in Web and Internet applications, developers should strictly follow the instructions given by the cryptographic protocol and avoid creating new protocols. Developers should also be aware of the intended threat models of the cryptographic protocols they are implementing and note that some aspects of deploying a protocol in the context of an internet application, such as the use of Javascript and the Web, may change some of its security properties. For example, Javascript code is always ultimately controlled by the origin, thus making end-to-end encryption without a trusted origin of the code impossible. Questions about and proposals to improve the Web Security Model should be sent to the W3C Web Security Interest Group at "public-web-security@w3.org"
In this review, we limit ourselves to peer-reviewed results on the algorithms which have been included in the latest public draft of the W3C Crypto API . Where appropriate we also comment on the status of the algorithm in other standards. Note that this represents a point-in-time snapshot of the state of the art in cryptanalysis and provable security results, which is a complex area subject to (sometimes rapid) change. There is at least one annual publication, the ENISA Algorithms, Key Size and Parameters Report, whose aim is to track these developments . That document discusses a much larger set of algorithms in much greater depth that we do here.
Please discuss this draft on the mailing list "cfrg@ietf.org". Note that draft, while attempting to gather consensus of the cryptographic literature, may not be complete and there may be disagreement, so that readers should view the archives of the CFRG mailing list to be aware of debates and ongoing analysis.
This following table summarizes the results. The marks for legacy and future applications are the same as in the 2013 ENISA report , except for those algorithms (PBKDF2 and AES-KW) which are not covered by the report where the marks represent interpretation of the available literature.
Algorithm/Mode
OK Legacy
OK Future
Note
RSAES-PKCS1-v1_5 YES NO
RSA-OAEP YES YES
RSASSA-PKCS1-v1_5 YES NO No public security proof
RSA-PSS YES YES
ECDSA YES YES Controversy
ECDH YES YES Controvery
AES-CBC YES YES NB not CCA secure
AES-CFB YES YES NB not CCA secure
AES-CTR YES YES NB not CCA secure
AES-GCM YES YES
AES-CMAC YES YES
AES-KW YES NO No public security proof
HMAC YES YES
DHYES YES Only using strong parameters
SHA-1 YES NO Known weaknesses (see text)
SHA-256 YES YES
SHA-384YES YES
SHA-512YES YES
CONCATYES YES
HKDF-CTRYES YES
PBKDF2YES NO Known weaknesses (see text))
The Algorithm/Mode is the title by the W3C Web Cryptography API . Whether or not the protocol is considered secure for legacy use or for future protocols is given next, followed by notes regarding its security properties (such as security proofs).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in .
In this review, we overview the following algorithms listed in the table. They are all currently given in the W3C Web Cryptography API, although RSAES-PKCS1-v1_5 (present in an earlier version of the Web Cryptography API .) was withdrawn from the W3C Web Cryptography API . This analysis originates in work done by Graham Steel . If algorithms are added, we will attempt to add them to this analysis in due course.
This encryption scheme has been known to be vulnerable to a chosen ciphertext attack (CCA) since 1998 . The attack has recently been improved to require a median of less than 15,000 chosen ciphertexts on the standard oracle . Instances of the attack in widely-deployed real-world systems continue to be found .
Since version 2.0 (September 1998), the RSA PKCS#11 standard contains the text: "RSAES-PKCS1-v1_5 is included only for compatibility with existing applications, and is not recommended for new applications" .
TLS up to version 1.2. supports RSAES-PKCS1-v1_5, but using specific countermeasures that 1) substitute a message with a random value in the event of a padding error and 2) require the client to display knowledge of the plaintext before proceeding with the protocol. These countermeasures are not trivially transposable to other applications.
The RSAES-PKCS1-v1_5 scheme was removed from the draft during the Last Call review period of the W3C Web Cryptography API. Despite this, it is still to be found in the Trusted Platform Module (TPM) standard, PKCS#11, Java JCE/JCA, MS-CAPI all support it. TPM 1.2 did not support it, favouring OAEP (below), but it may be included in TPM 2.0 (see section 14.2.1, Level 00 Revision 01.07).
Has a security proof of preservation of indistinguishability under chosen ciphertext attacks (IND-CCA, the standard desirable notion of security for an encryption scheme) . Indeed, the proof has been formalised in the Coq proof assistant . These proofs assume that a well-known implementation pitfall leading to an efficient attack is avoided.
Using OAEP implies using a hash function. A recent report recommends using SHA-1 inside OAEP for legacy applications only and using SHA-2/3 for future applications .
There are no publicly known attacks on this scheme. However, there are also no security proofs and no advantages compared to other RSA-based schemes such as PSS (below) .
An RSA Laboratories memo by Burt Kaliski, dated February 26 2003, states "'While the traditional and widely deployed PKCS#1 v1.5 signature scheme is still appropriate to use, RSA Laboratories encourages a gradual transition to RSA-PSS as new applications are developed" .
Has a security proof due to Bellare and Rogaway in the random oracle model.
ECDSA schemes have some provable security results but only in weak models .
ECDH has provable security results but is subject to attacks due to groups not being well-specified. Like other plain DH modes it offers no authenticity, this must be taken care of separately.
There are known cryptanalytic attacks on AES that are not currently believed to pose a practical threat . The following results assume that AES is a secure block cipher. Keyed MACS are necessary for use with any AES block cipher in a mode that is not AES-GCM.
AES-CBC mode is not CCA secure. It is secure against chosen plaintext attacks (CPA-secure) if the IV is random, but it is not enough if the IV is a possibly non-random nonce .
It does not tolerate a padding oracle - indeed, in practice, padding oracle attacks are common and the padding mode suggested in the current draft is exactly that which gives rise to most of these attacks.
AES-CFB is not CCA secure. It is CPA-secure if the IV is random, but not if the IV is a nonce .
AES-CTR is not CCA secure. It is CPA-secure but not CCA-secure .
For a summary of the properties of these modes and the dangers of using ciphers with only CPA-security, the following excerpt from Rogaway's review is apposite:
"I am unable to think of any cryptographic design problem where, absent major legacy considerations, any of CBC, CFB, or OFB would represent the mode of choice. I regard CTR as easily the "best" choice among the set of the confidentiality modes (meaning the set of schemes aiming only for message privacy, as classically understood). It has unsurpassed performance characteristics and provable-security guarantees that are at least as good as any of the "basic four" modes with respect to classical notions of privacy. The simplicity, efficiency, and obvious correctness of CTR make it a mandatory member in any modern portfolio of SemCPA-secure schemes. The only substantial criticisms of CTR center on its ease of misuse. First, it is imperative that the counter-values that are enciphered are never reused. What is more, these values are 'exposed' to the user of CTR, offering ample opportunity to disregard the instructions. Second, the mode offers absolutely no authenticity, nonmalleability, or chosen-ciphertext-attack (CCA) security. Users of a symmetric scheme who implicitly assume such properties of their confidentiality-providing mode are, with CTR, almost certain to get caught in their error."
GCM mode has a security proof - the security notion is AEAD (Authenticated Encyrption with Associated Data), which (loosely speaking) means that the encryption part is CCA-secure and the message and associated data are unforgeable. There are some cryptanalytic results on certain instantiations of the scheme, those these are not currently thought to pose a practical threat .
Standardised by NIST, GCM is gaining traction in standards such as IPsec, MACSec, P1619.1, and TLS .
AES-CMAC has good security proofs (i.e. it has well studied proofs with reasonable bounds under standard assumptions) .
AES-KW has received various criticisms, for example being inconsistent in its notions of security (requiring IND-CCA from a deterministic mode) and restrictions on the size of the input data. Although it has no public security proof, it has no known attacks either . There are alternative standards with security proofs and less restrictions such as SIV mode (RFC 5297), but SIV is not currently supported by the WebCrypto API.
HMAC has well-studied security proofs, even if the underlying hash function is not (weak) collision resistant .
The security of Diffie-Hellman key agreement maps closely to the difficulty of the Diffie-Hellman problem. There are known attacks on weak parameters for Diffie-Hellman key agreement . Like other plain DH modes it offers no authenticity, this must be taken care of separately.
A procedure is known to obtain SHA-1 collisions in less than 2^62 operations (since SHA-1 has a fixed 160 bit output, the theoretical lower bound is 2^80). A talk by Marc Stevens outlines a procedure requiring 2^60 operations . Speculation about when practical collisions will be seen ranges from 2018-21 .
Preimage calculation attacks on reduced round SHA-1 currently require 2^146.2 steps on 44 round SHA-1 and 2^150.6 steps on 48 round (full SHA-1 has 80 rounds) and Simon Knellwolf, who worked on these latest attacks, notes that given the current rate of progress, efficient preimage attacks will be seen in 2020 .
Finally, some authors consider even the theoretical lower bound on collision attacks (2^80) to be too low a security parameter for future applications .
There are collision and preimage attacks reported on reduced-round versions of the SHA-2 family, but currently no practical attacks .
Security models for password-based key derivation functions are still in a state of flux . However, we note that HKDF has security proofs .
PBKDF2 has known weaknesses and @@ minimum iterations should be used.
CONCAT (which refers to the key derivation function defined in Section 5.8.1 of NIST SP 800-56A) does not appear to have any independent analysis, but is simple and receives approval in the ENISA report .
This informational overview lists some well-known security considerations for algorithms in the W3C Web Cryptographic API. We expect these algorithms to be used in particular applications with a wide variety of differing threat models for various attacks. Thus, the attacks in-scope and out-of-scope depend on the particular protocol, as well as the attacks a protocol is susceptible to and those which it protects against. This note documents per algorithm known attacks that are generic to an algorithm, but does not deal with the particular level.
This memo includes no request to IANA. For the algorithms inspected in this review, the central authority governing their identifiers is the W3C Web Cryptography Working API . Note that the W3C Web Cryptography API does map a subset of these algorithm identifiers (with additional parameters for the ciphersuites) to the IANA registry of JOSE identifiers for algorithms .
JSON Web Algorithms (JWA)
Michael.Jones@microsoft.com
Web Cryptography API
sleevi@google.com
Michael.Jones@microsoft.com
Web Cryptography API
sleevi@google.com
watsonm@netflix.com
OASIS PKCS 11
susan.gleeson@oracle.com chris@wmpp.com
Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)
This memo describes SIV (Synthetic Initialization Vector) a block cipher mode of operation. SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted. It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector. Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption. This memo provides information for the Internet community.
Key words for use in RFCs to Indicate Requirement Levels
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.

Note that the force of these words is modified by the requirement
level of the document in which they are used.
New Preimage Attacks against Reduced SHA-1
Deterministic authenticated-encryption: a provable-security treatment of the key-wrap problem
When Will We See Collisions for SHA-1?
Choice of Algorithms in the W3C Crypto API
Cryptanalysis of MD5 and SHA-1
Raising the Standard for RSA Signatures: RSA-PSS
Design and analysis of password-based key derivation functions
Cryptographic extraction and key derivation: the HKDF scheme
A framework for security analysis of key derivation functions
Finding collisions in the full SHA-1SHA-0 SHA-1 collision search attacks hash functions
Imperfect Forward Secrecy: How Diffie-Hellman Fails in PracticeDH
RSA-OAEP is secure under the RSA assumption
New proofs for MAC and HMAC: security without collision-resistance
Evaluation of some blockcipher modes of operation
Algorithms, key sizes and parameters report: 2013 recommendations
Error oracle attacks on CBC mode: is there a future for CBC mode encryption?
Practical padding oracle attacks
The security of DSA and ECDSA
On the unpredictability of bits of the elliptic curve diffie-hellman scheme
Security flaws induced by CBC padding - applications to SSL, IPSEC, WTLS ...
Padding oracle attacks on the ISO CBC mode encryption standard
An overview of cryptanalysis research for the advanced encryption standard
Formal certification of code-based cryptographic proofs
A chosen ciphertext attack on rsa optimal asymmetric encryption padding (OAEP) as standardized in PKCS #1 v2.0
The exact security of digital signatures-how to sign with rsa and rabin
Efficient padding oracle attacks on cryptographic hardware
Chosen ciphertext attacks against protocols based on the RSA encryption standard
Bleichenbacher's attack strikes again: breaking PKCS#1 v1.5 in XML encryption
Special thanks to Ryan Sleevi and Mark Watson for their work on the Web Cryptography API, as well as Rich Salz for bringing up the issue of algorithm-specific security considerations. Thanks to Kelsey Cairns for helping with the formal analysis. Graham Steel authored the original version of this report , and Harry Halpin from W3C/MIT agreed to edit and keep the document up to date.