[Cfrg] Proposed Informational Note: Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API

Harry Halpin <hhalpin@w3.org> Thu, 20 November 2014 15:38 UTC

Return-Path: <hhalpin@w3.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20E21A1A70 for <cfrg@ietfa.amsl.com>; Thu, 20 Nov 2014 07:38:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.338
X-Spam-Level:
X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_PROFIT1=3.858, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTDYRWPWB4Bg for <cfrg@ietfa.amsl.com>; Thu, 20 Nov 2014 07:38:30 -0800 (PST)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3426F1A1A6B for <cfrg@irtf.org>; Thu, 20 Nov 2014 07:38:22 -0800 (PST)
Received: from men75-11-88-175-104-179.fbx.proxad.net ([88.175.104.179] helo=[192.168.1.48]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <hhalpin@w3.org>) id 1XrToK-0005ZI-K2 for cfrg@irtf.org; Thu, 20 Nov 2014 10:38:21 -0500
Message-ID: <546E0AE5.3040601@w3.org>
Date: Thu, 20 Nov 2014 16:38:13 +0100
From: Harry Halpin <hhalpin@w3.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/hMakmj8-_VGrG3-GIBCqjkFaYgc
Subject: [Cfrg] Proposed Informational Note: Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Nov 2014 15:38:43 -0000

Everyone,

As the W3C Web Cryptography API gets ready to move to Candidate
Recommendation, we wanted to address the concerns brought up by Rich
Salz and others for better security guidelines for developers, given
that the API exposes a variety of algorithms. I've taken Graham Steel's
excellent write-up, which is in a large part based on Smart et al.'s
magisterial ENISA report,  and have turned it into a draft CFRG note.

We'd like to see the security guidelines below discussed here, and if
there's no objections after discussion, move this onwards. W3C commits
to maintaining this note as much as possible.

Links to draft:

TXT:
http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-00.txt
HTML:
http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-00.html

cheers,
    harry

----

Crypto Forum Research Group                               H. Halpin, Ed.
Internet-Draft                                                   W3C/MIT
Intended status: Informational                                  G. Steel
Expires: May 23, 2016                                  Cryptosense/INRIA
                                                       November 20, 2015


    Security Guidelines for Cryptographic Algorithms in the W3C Web
                            Cryptography API
                draft-irtf-cfrg-webcrypto-algorithms-00

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 23, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Halpin & Steel            Expires May 23, 2016                  [Page 1]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Document Conventions . . . . . . . . . . . . . . . . . . . . .  5
   4.  Conformance Criteria . . . . . . . . . . . . . . . . . . . . .  5
   5.  Algorithm Review . . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  RSAES-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . . . .  5
     5.2.  RSA-OAEP . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.3.  RSASSA-PKCS1-v1_5  . . . . . . . . . . . . . . . . . . . .  6
     5.4.  RSA-PSS  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.5.  ECDSA  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.6.  ECDH . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.7.  AES-CBC, AES-CFB, AES-CTR  . . . . . . . . . . . . . . . .  6
     5.8.  AES-GCM  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.9.  AES-CMAC . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.10. AES-KW . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.11. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.12. DH . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.13. SHA1 . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.14. SHA-256, SHA-384, SHA-512  . . . . . . . . . . . . . . . .  9
     5.15. HKDF-CTR . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.16. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.17. CONCAT . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14




















Halpin & Steel            Expires May 23, 2016                  [Page 2]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


1.  Introduction

   Cryptography is a small but important part of security, and choosing
   the right cryptographic algorithm is a small but 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 [W3CWebCryptoLC].
   This analysis may also be useful in analyzing the properties of
   protocols given in the algorithms used by the IETF JSON Web
   Algorithms [JWA].

   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 [W3CWebCryptoLC].  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 [enisa13].  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.






Halpin & Steel            Expires May 23, 2016                  [Page 3]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


2.  Overview

   This following table summarizes the results.  The marks for legacy
   and future applications are the same as in the 2013 ENISA report
   [enisa13], 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    |    OK    |           Note          |
   |                   |  Legacy  |  Future  |                         |
   +-------------------+----------+----------+-------------------------+
   |  RSAES-PKCS1-v1_5 |    YES   |    NO    |                         |
   |      RSA-OAEP     |    YES   |    YES   |                         |
   | RSASSA-PKCS1-v1_5 |    YES   |    NO    |    No security proof    |
   |      RSA-PSS      |    YES   |    YES   |                         |
   |       ECDSA       |    YES   |    NO    |  Weak provable security |
   |                   |          |          |         results         |
   |        ECDH       |    YES   |    YES   |                         |
   |      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   |                         |
   |         DH        |    YES   |    YES   |                         |
   |       SHA-1       |    YES   |    NO    |  Known weaknesses (see  |
   |                   |          |          |          text)          |
   |      SHA-256      |    YES   |    YES   |                         |
   |      SHA-384      |    YES   |    YES   |                         |
   |      SHA-512      |    YES   |    YES   |                         |
   |       CONCAT      |    YES   |    YES   |                         |
   |      HKDF-CTR     |    YES   |    YES   |                         |
   |       PBKDF2      |    YES   |    NO    |  Known weaknesses (see  |
   |                   |          |          |          text))         |
   +-------------------+----------+----------+-------------------------+

      The Algorithm/Mode is the title by the W3C Web Cryptography API
    [W3CWebCryptoCR].  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).

                     Table 1: Algorithm Summary Table






Halpin & Steel            Expires May 23, 2016                  [Page 4]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


3.  Document Conventions


4.  Conformance Criteria

   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 [RFC2119].


5.  Algorithm Review

   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 [W3CWebCryptoLC].) was withdrawn from the W3C Web
   Cryptography API [W3CWebCryptoCR].  This analysis originates in work
   done by Graham Steel [SteelChoice].  If algorithms are added, we will
   attempt to add them to this analysis in due course.

5.1.  RSAES-PKCS1-v1_5

   This encryption scheme has been known to be vulnerable to a chosen
   ciphertext attack (CCA) since 1998 [bleichenbacher98].  The attack
   has recently been improved to require a median of less than 15,000
   chosen ciphertexts on the standard oracle [bardou12padding].
   Instances of the attack in widely-deployed real-world systems
   continue to be found [jager12bleichenbacher].

   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"
   [PKCS11].

   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.  Finally, note also that as of version 1.3, RSAES-
   PKCS1-v1_5 will be dropped from the TLS standard.

   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).



Halpin & Steel            Expires May 23, 2016                  [Page 5]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


5.2.  RSA-OAEP

   Has a security proof of preservation of indistinguishability under
   chosen ciphertext attacks (IND-CCA, the standard desirable notion of
   security for an encryption scheme) [fujisaki04OAEP].  Indeed, the
   proof has been formalised in the Coq proof assistant
   [barthe2009POPL].  These proofs assume that a well-known
   implementation pitfall leading to an efficient attack [manger01] 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 [enisa13].

5.3.  RSASSA-PKCS1-v1_5

   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) [enisa13].

   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" [email].

5.4.  RSA-PSS

   Has a security proof due to Bellare and Rogaway [bellare96eurocrypt]
   in the random oracle model.

5.5.  ECDSA

   ECDSA schemes have some provable security results but only in weak
   models [enisa13].  Further it may be possible to maliciously choose
   an elliptic curve for ECDSA despite the standard validation scheme
   [vaudenay03PKC].

5.6.  ECDH

   ECDH has provable security results [boneh01crypto].  Like other plain
   DH modes it offers no authenticity, this must be taken care of
   separately.

5.7.  AES-CBC, AES-CFB, AES-CTR

   There are known cryptanalytic attacks on AES that are not currently
   believed to pose a practical threat [kaminsky10].  The following



Halpin & Steel            Expires May 23, 2016                  [Page 6]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


   results assume that AES is a secure block cipher.

   AES-CBC mode is not CCA secure.  It is secure against chosen
   plaintext attacks (CPA-secure) if the IV is random, but not if the IV
   is a nonce [rogaway11evaluation].

   It does not tolerate a padding oracle [vaudenay02] - indeed, in
   practice, padding oracle attacks are common
   [paterson04padding][mitchell05cbc][rizzo10USENIX] 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 [rogaway11evaluation].

   AES-CTR is not CCA secure.  It is CPA-secure but not CCA-secure
   [rogaway11evaluation].

   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 [rogaway11evaluation] 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."

5.8.  AES-GCM

   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



Halpin & Steel            Expires May 23, 2016                  [Page 7]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


   cryptanalytic results on certain instantiations of the scheme, those
   these are not currently thought to pose a practical threat [enisa13].

   Standardised by NIST, GCM is gaining traction in standards such as
   IPsec, MACSec, P1619.1, and TLS [rogaway11evaluation].

5.9.  AES-CMAC

   AES-CMAC has good security proofs (i.e. it has well studied proofs
   with reasonable bounds under standard assumptions)
   [rogaway11evaluation].

5.10.  AES-KW

   AES-KW has received various criticisms, for example being
   inconsistent in its notions of security (requiring IND-CCA from a
   deterministic mode), but though it has no public security proof, it
   has no known attacks either [rogaway06deterministic].  There are
   alternative standards with security proofs such as SIV mode (RFC
   5297)[RFC5297].

5.11.  HMAC

   HMAC has well-studied security proofs, even if the underlying hash
   function is not (weak) collision resistant [bellare06HMAC].

5.12.  DH

   The security of Diffie-Hellman key agreement maps closely to the
   difficulty of the Diffie-Hellman problem.  More than 35 years after
   publication of the DH protocol and despite progress on the discrete
   log problem, there are no publicly known attacks.  Like other plain
   DH modes it offers no authenticity, this must be taken care of
   separately.

5.13.  SHA1

   A procedure is known to obtain SHA-1 collisions in less than 2^62
   operations [wang2005] (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 [stevens].  Speculation about
   when practical collisions will be seen ranges from 2018-21
   [schneier].

   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



Halpin & Steel            Expires May 23, 2016                  [Page 8]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


   preimage attacks will be seen in 2020 [knellwolf12].

   Finally, some authors consider even the theoretical lower bound on
   collision attacks (2^80) to be too low a security parameter for
   future applications [enisa13].

5.14.  SHA-256, SHA-384, SHA-512

   There are collision and preimage attacks reported on reduced-round
   versions of the SHA-2 family, but currently no practical attacks
   [enisa13].

5.15.  HKDF-CTR

   Security models for password-based key derivation functions are still
   in a state of flux [wen12framework].  However, we note that HKDF has
   security proofs [krawczyk10HKDF].

5.16.  PBKDF2

   PBKDF2 has known weaknesses [yao05kdf].

5.17.  CONCAT

   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 [enisa13].


6.  Security Considerations

   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.


7.  IANA Considerations

   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 [W3CWebCryptoCR].  Note that the



Halpin & Steel            Expires May 23, 2016                  [Page 9]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


   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 [JWA].


8.  References

8.1.  Normative References

   [JWA]      Jones, M., "JSON Web Algorithms (JWA)", IETF Internet
              Draft, October 2014,
              <http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/>.

   [PKCS11]   Gleeson, S. and C. Zimman, "OASIS PKCS 11", OASIS Working
              Draft draft, November 2014, <https://www.oasis-open.org/
              committees/download.php/54455/pkcs11-base-v2.40-wd11.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5297]  Harkins, D., "Synthetic Initialization Vector (SIV)
              Authenticated Encryption Using the Advanced Encryption
              Standard (AES)", RFC 5297, October 2008.

   [W3CWebCryptoCR]
              Sleevi, R. and M. Watson, "Web Cryptography API", W3C
              Candidate Recommendation , November 2014,
              <http://www.w3.org/TR/WebCryptoAPI>.

   [W3CWebCryptoLC]
              Sleevi, R. and M. Watson, "Web Cryptography API", W3C Last
              Call Working Draft , March 2014,
              <http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/>.

8.2.  Informative References

   [SteelChoice]
              Steel, G., "Choice of Algorithms in the W3C Crypto API",
              Accessed: 20-Nov-2014, <http://cryptosense.com/
              choice-of-algorithms-in-the-w3c-crypto-api/>.

   [bardou12padding]
              Bardou, R., Focardi, R., Kawamoto, Y., Simionato, L.,
              Steel, G., and Joe-Kai-Tsay, "Efficient padding oracle
              attacks on cryptographic hardware", In Advances in
              Cryptology: Proceedings of CRYPTO '12, volume 7417 of
              LNCS, pages 608-625. Springer, 2012. , 2012.




Halpin & Steel            Expires May 23, 2016                 [Page 10]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


   [barthe2009POPL]
              Barthe, G., Gregoire, B., and S. Zanella-Beguelin, "Formal
              certification of code-based cryptographic proofs", In 36th
              ACM SIGPLAN-SIGACT Symposium on Principles of Programming
              Languages, POPL 2009, pages 90-101. ACM, 2009. , 2009,
              <http://dx.doi.org/10.1145/1480881.1480894>.

   [bellare06HMAC]
              Bellare, M., "New proofs for MAC and HMAC: security
              without collision-resistance", In Cynthia Dwork, editor,
              CRYPTO, volume 4117 of Lecture Notes in Computer Science,
              pages 602-619. Springer, 2006 , 2006.

   [bellare96eurocrypt]
              Bellare, M. and P. Rogaway, "The exact security of digital
              signatures-how to sign with rsa and rabin", In Proceedings
              of the 15th Annual International Conference on Theory and
              Application of Cryptographic Techniques, EUROCRYPT'96,
              pages 399-416, Berlin, Heidelberg, 1996. Springer-
              Verlag. , 1996,
              <http://dl.acm.org/citation.cfm?id=1754495.1754541>.

   [bleichenbacher98]
              Bleichenbacher, D., "Chosen ciphertext attacks against
              protocols based on the RSA encryption standard", In
              Advances in Cryptology: Proceedings of CRYPTO '98, volume
              1462 of Lecture Notes in Computer Science,pages 1-12,
              1998. , 1998.

   [boneh01crypto]
              Boneh, D. and I. Shparlinski, "On the unpredictability of
              bits of the elliptic curve diffie-hellman scheme", In Joe
              Kilian, editor, Advances in Cryptology - CRYPTO 2001,
              volume 2139 of Lecture Notes in Computer Science, pages
              201-212. Springer Berlin Heidelberg, 2001. , 2001,
              <http://dx.doi.org/10.1007/3-540-44647-8_12>.

   [email]    Kaliski, B., "Raising the Standard for RSA Signatures:
              RSA-PSS", Accessed: 11-Nov-2014, <https://web.archive.org/
              web/20130523004555/http://www.rsa.com/rsalabs/
              node.asp?id=2005>.

   [enisa13]  Smart, N., Rijmen, V., Warinschi, B., and G. Watson,
              "Algorithms, key sizes and parameters report: 2013
              recommendations", Technical report, October 2013. ENISA
              Report. Version 1.0.  , 2013.

   [fujisaki04OAEP]



Halpin & Steel            Expires May 23, 2016                 [Page 11]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


              Fujisaki, E., Okamoto, T., Pointcheval, D., and J. Stern,
              "RSA-OAEP is secure under the RSA assumption", Journal.
              Cryptol., 17(2):81-104, March 2004 , 2004,
              <http://dx.doi.org/10.1007/s00145-002-0204-y>.

   [jager12bleichenbacher]
              Jager, T., Schinzel, S., and J. Somorovsky,
              "Bleichenbacher's attack strikes again: breaking PKCS#1
              v1.5 in XML encryption", In Sara Foresti, Moti Yung, and
              Fabio Martinelli, editors, Computer Security - ESORICS
              2012, volume 7459 of Lecture Notes in Computer Science,
              pages 752-769. Springer Berlin Heidelberg, 2012. , 2012,
              <http://dx.doi.org/10.1007/978-3-642-33167-1_43>.

   [kaminsky10]
              Kaminsky, A., Kurdziel, M., and S. Radziszowski, "An
              overview of cryptanalysis research for the advanced
              encryption standard", In Military Communications
              Conference, 2010 - MILCOM 2010. , 2010.

   [knellwolf12]
              Knellwolf, S. and D. Khovratovich, "New Preimage Attacks
              against Reduced SHA-1", In Advances in Cryptology - CRYPTO
              2012, volume 7417 of Lecture Notes in Computer Science,
              pages 367-383. Springer Berlin Heidelberg, 2012. , 2012,
              <http://www.iacr.org/cryptodb/data/
              paper.php?pubkey=24323>.

   [krawczyk10HKDF]
              Krawczyk, H., "Cryptographic extraction and key
              derivation: the HKDF scheme", In Tal Rabin, editor,
              CRYPTO, volume 6223 of Lecture Notes in Computer Science,
              pages 631-648. Springer, 2010.  , 2010.

   [manger01]
              Manger, J., "A chosen ciphertext attack on rsa optimal
              asymmetric encryption padding (OAEP) as standardized in
              PKCS #1 v2.0", In Joe Kilian, editor, Advances in
              Cryptology CRYPTO 2001, volume 2139 of Lecture Notes in
              Computer Science, pages 230-238. Springer Berlin /
              Heidelberg, 2001 , 2001.

   [mitchell05cbc]
              Mitchell, C., "Error oracle attacks on CBC mode: is there
              a future for CBC mode encryption?", In J. et al. Zhou,
              editor, ISC 2005, volume 3650 in Lecture Notes in Computer
              Science, pages 244-258, 2005. , 2005.




Halpin & Steel            Expires May 23, 2016                 [Page 12]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


   [paterson04padding]
              Paterson, K. and A. Yau, "Padding oracle attacks on the
              ISO CBC mode encryption standard", In T. Okamoto, editor,
              RSA '04 Cryptography Track, number 2964 in LNCS, pages
              305-323. Springer, 2004. , 2004.

   [rizzo10USENIX]
              Rizzo, J. and T. Duong, "Practical padding oracle
              attacks", WOOT'10, pages 1-8, Berkeley, CA, USA, 2010.
              USENIX Association , 2010,
              <http://portal.acm.org/citation.cfm?id=1925004.1925008>.

   [rogaway06deterministic]
              Rogaway, P. and T. Shrimpton, "Deterministic
              authenticated-encryption: a provable-security treatment of
              the key-wrap problem", In Advances in Cryptology
              (EUROCRYPT '06), volume 4004 of LNCS, pages 373-390,
              2006. , 2006, <https://eprint.iacr.org/2006/221.pdf>.

   [rogaway11evaluation]
              Rogaway, P., "Evaluation of some blockcipher modes of
              operation", Technical report, University of California,
              Davis, February 2011. Evaluation carried out for the
              Cryptography Research and Evaluation Committees (CRYPTREC)
              for the Government of Japan. , 2011.

   [schneier]
              Schneier, B., "When Will We See Collisions for SHA-1?",
              Accessed: 11-Nov-2014, <https://www.schneier.com/blog/
              archives/2012/10/when_will_we_se.html>.

   [stevens]  Stevens, M., "Cryptanalysis of MD5 and SHA-1", Accessed:
               11-Nov-2014, <http://2012.sharcs.org/slides/stevens.pdf>.

   [vaudenay02]
              Vaudenay, S., "Security flaws induced by CBC padding -
              applications to SSL, IPSEC, WTLS ...", In Lars R. Knudsen,
              editor, EUROCRYPT, volume 2332 of Lecture Notes in
              Computer Science, pages 534-546. Springer, 2002. , 2002.

   [vaudenay03PKC]
              Vaudenay, S., "The security of DSA and ECDSA", In Yvo G.
              Desmedt, editor, Public Key Cryptography - PKC 2003,
              volume 2567 of Lecture Notes in Computer Science, pages
              309-323. Springer Berlin Heidelberg, 2002 , 2002,
              <http://dx.doi.org/10.1007/3-540-36288-6_23>.

   [wang2005]



Halpin & Steel            Expires May 23, 2016                 [Page 13]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015


              Wang, X., Yin, Y., and H. Yu, "Finding collisions in the
              full SHA-1", In Proceedings of the 25th Annual
              International Conference on Advances in Cryptology,
              CRYPTO'05, pages 17-36, Berlin, Heidelberg, 2005.
              Springer-Verlag , 2005,
              <http://dx.doi.org/10.1007/11535218_2>.

   [wen12framework]
              Wen, C., Dawson, E., Nieto, J., and L. Simpson, "A
              framework for security analysis of key derivation
              functions", In Mark Dermot Ryan, Ben Smyth, and Guilin
              Wang, editors, ISPEC, volume 7232 of Lecture Notes in
              Computer Science, pages 199-216. Springer, 2012 , 2012.

   [yao05kdf]
              Yao, F. and Y. Yin, "Design and analysis of password-based
              key derivation functions", In Alfred Menezes, editor, CT-
              RSA, volume 3376 of Lecture Notes in Computer Science,
              pages 245-261. Springer, 2005 , 2005.


Appendix A.  Acknowledgments

   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 [SteelChoice], and Harry Halpin
   from W3C/MIT agreed to edit and keep the document up to date.


Authors' Addresses

   Harry Halpin (editor)
   W3C/MIT

   Email: harry@w3c.org
   URI:   http://www.ibiblio.org/hhalpin/


   Graham Steel
   Cryptosense/INRIA

   Email: Graham.Steel@inria.fr
   URI:   http://www.lsv.ens-cachan.fr/~steel/






Halpin & Steel            Expires May 23, 2016                 [Page 14]