One document matched: draft-irtf-cfrg-webcrypto-algorithms-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- see also the xml2rfc FAQ: <http://www1.xml.resource.org/xml2rfcFAQ.html> -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC.5297 PUBLIC ""
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5297.xml">
<!ENTITY RFC.2119 PUBLIC ""
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<!-- PROCESSING INSTRUCTIONS -->
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>
<?rfc tocdepth="4"?>
<!--
This .xml file intended to be processed by xml2rfc
http://xml2rfc.ietf.org/
source filename: draft-yournamehere-i-d-template-00.xml
-->
<!-- note that there are various ipr types that can be used in the <rfc> tag
see RFC3979 and RFC3978
be aware that your mileage will vary and you should read the fine print therein
-->
<rfc category="info" ipr="trust200902" docName="draft-irtf-cfrg-webcrypto-algorithms-00" >
<front>
<title abbrev="W3C WebCrypto Security Considerations">Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API</title>
<!-- put your john hancock info here -->
<author initials="H." surname="Halpin" fullname="Harry Halpin" role="editor">
<organization>W3C/MIT</organization>
<address>
<email>harry@w3c.org</email>
<uri>http://www.ibiblio.org/hhalpin/</uri>
</address>
</author>
<author initials="G." surname="Steel" fullname="Graham Steel" >
<organization>Cryptosense/INRIA</organization>
<address>
<email>Graham.Steel@inria.fr</email>
<uri>http://www.lsv.ens-cachan.fr/~steel/</uri>
</address>
</author>
<date day="20" month="November" year="2015"/>
<area>Internet Research Task Force</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sctn-intro">
<t>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 <xref target="W3CWebCryptoLC" />. This analysis may also be useful in analyzing the properties of protocols given in the algorithms used by the IETF JSON Web Algorithms <xref target="JWA" />.</t>
<t>
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"</t>
<t>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 <xref target="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 <xref target="enisa13" />. That document discusses a much larger set of algorithms in much greater depth that we do here. </t>
<t>
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.
</t>
</section>
<section anchor="sctn-overview" title="Overview">
<t>This following table summarizes the results. The marks for legacy and future applications are the same as in the 2013 ENISA report <xref target="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.</t>
<texttable anchor="table_example" title="Algorithm Summary Table">
<ttcol align="center">Algorithm/Mode</ttcol>
<ttcol align="center">OK Legacy</ttcol>
<ttcol align="center">OK Future</ttcol>
<ttcol align="center">Note</ttcol>
<c>RSAES-PKCS1-v1_5</c><c> YES </c><c> NO </c><c> </c>
<c>RSA-OAEP</c><c> YES </c><c> YES </c><c> </c>
<c>RSASSA-PKCS1-v1_5 </c><c> YES </c><c> NO </c><c> No public security proof </c>
<c>RSA-PSS</c><c> YES </c><c> YES </c><c> </c>
<c>ECDSA</c><c> YES </c><c> YES </c><c>Controversy</c>
<c>ECDH</c><c> YES </c><c> YES </c><c>Controvery</c>
<c>AES-CBC</c><c> YES </c><c> YES </c><c> NB not CCA secure</c>
<c>AES-CFB</c><c> YES </c><c> YES </c><c> NB not CCA secure </c>
<c>AES-CTR</c><c> YES </c><c> YES </c><c> NB not CCA secure</c>
<c>AES-GCM</c><c> YES </c><c> YES </c><c> </c>
<c>AES-CMAC</c><c> YES </c><c> YES </c><c></c>
<c>AES-KW</c><c> YES </c><c> NO </c><c> No public security proof</c>
<c>HMAC</c><c> YES </c><c> YES </c><c> </c>
<c>DH</c><c>YES </c><c> YES </c><c>Only using strong parameters</c>
<c>SHA-1</c><c> YES </c><c> NO </c><c> Known weaknesses (see text)</c>
<c>SHA-256</c><c> YES </c><c> YES </c><c> </c>
<c>SHA-384</c><c>YES </c><c> YES </c><c> </c>
<c>SHA-512</c><c>YES </c><c> YES </c><c> </c>
<c>CONCAT</c><c>YES </c><c> YES </c><c> </c>
<c>HKDF-CTR</c><c>YES </c><c> YES </c><c> </c>
<c>PBKDF2</c><c>YES </c><c> NO </c><c> Known weaknesses (see text))</c>
<postamble>The Algorithm/Mode is the title by the W3C Web Cryptography API <xref target="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).</postamble>
</texttable>
</section> <!-- overview -->
<section anchor="sctn-conformance" title="Conformance Criteria">
<t> <!-- don't hack this paragraph - it's gotta be here, and it's
gotta be exactly like this until
further notice, ie until RFC2119 is superseded. see the latter for
gory details. -->
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 <xref target="RFC2119" />.
</t>
</section> <!-- sctn-conformance -->
<section anchor="algorithms" title="Algorithm Review">
<t>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 <xref target="W3CWebCryptoLC" />.) was withdrawn from the W3C Web Cryptography API <xref target="W3CWebCryptoCR" />. This analysis originates in work done by Graham Steel <xref target="SteelChoice" />. If algorithms are added, we will attempt to add them to this analysis in due course. </t>
</section>
<section anchor="RSAES-PKCS1-v1_5" title="RSAES-PKCS1-v1_5">
<t>This encryption scheme has been known to be vulnerable to a chosen ciphertext attack (CCA) since 1998 <xref target="bleichenbacher98" />. The attack has recently been improved to require a median of less than 15,000 chosen ciphertexts on the standard oracle <xref target="bardou12padding" />. Instances of the attack in widely-deployed real-world systems continue to be found <xref target="jager12bleichenbacher" />.</t>
<t>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" <xref target="PKCS11" />.</t>
<t>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.</t>
<t>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).</t>
</section>
<section anchor="RSA-OAEP" title="RSA-OAEP">
<t>Has a security proof of preservation of indistinguishability under chosen ciphertext attacks (IND-CCA, the standard desirable notion of security for an encryption scheme) <xref target="fujisaki04OAEP" />. Indeed, the proof has been formalised in the Coq proof assistant <xref target="barthe2009POPL" />. These proofs assume that a well-known implementation pitfall leading to an efficient attack <xref target="manger01" /> is avoided.</t>
<t>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 <xref target="enisa13" />.</t>
</section>
<section anchor="RSASSA-PKCS1-v1_5" title="RSASSA-PKCS1-v1_5">
<t>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) <xref target="enisa13" />.</t>
<t>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" <xref target="email" />.</t>
</section>
<section anchor="RSA-PSS" title="RSA-PSS">
<t>Has a security proof due to Bellare and Rogaway <xref target="bellare96eurocrypt" /> in the random oracle model.</t>
</section>
<section anchor="ECDSA" title="ECDSA">
<t>ECDSA schemes have some provable security results but only in weak models <xref target="enisa13" />. <!--Further it may be possible to maliciously choose an elliptic curve for ECDSA despite the standard validation scheme <xref target="vaudenay03PKC" />.--></t>
</section>
<section anchor="ECDH" title="ECDH">
<t>ECDH has provable security results <xref target="boneh01crypto" /> 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.</t>
</section>
<section anchor="AES" title="AES-CBC, AES-CFB, AES-CTR">
<t>There are known cryptanalytic attacks on AES that are not currently believed to pose a practical threat <xref target="kaminsky10" />. 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.</t>
<t>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 <xref target="rogaway11evaluation" />.</t>
<t>It does not tolerate a padding oracle <xref target="vaudenay02" /> - indeed, in practice, padding oracle attacks are common <xref target="paterson04padding" /><xref target="mitchell05cbc" /><xref target="rizzo10USENIX" /> and the padding mode suggested in the current draft is exactly that which gives rise to most of these attacks.</t>
<t>AES-CFB is not CCA secure. It is CPA-secure if the IV is random, but not if the IV is a nonce <xref target="rogaway11evaluation" />.</t>
<t>AES-CTR is not CCA secure. It is CPA-secure but not CCA-secure <xref target="rogaway11evaluation" />.</t>
<t>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 <xref target="rogaway11evaluation" /> is apposite:</t>
<t>"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."</t>
</section>
<section anchor="AES-GCM" title="AES-GCM">
<t>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 <xref target="enisa13" />.</t>
<t>Standardised by NIST, GCM is gaining traction in standards such as IPsec, MACSec, P1619.1, and TLS <xref target="rogaway11evaluation" />.</t>
</section>
<section anchor="AES-CMAC" title="AES-CMAC">
<t>AES-CMAC has good security proofs (i.e. it has well studied proofs with reasonable bounds under standard assumptions) <xref target="rogaway11evaluation" />.</t></section>
<section anchor="AES-KW" title="AES-KW">
<t>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 <xref target="rogaway06deterministic" />. There are alternative standards with security proofs and less restrictions such as SIV mode (RFC 5297)<xref target="RFC5297" />, but SIV is not currently supported by the WebCrypto API.</t></section>
<section anchor="HMAC" title="HMAC">
<t>HMAC has well-studied security proofs, even if the underlying hash function is not (weak) collision resistant <xref target="bellare06HMAC" />.</t></section>
<section anchor="DH" title="DH">
<t>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 <xref target="weakdh" />. Like other plain DH modes it offers no authenticity, this must be taken care of separately.</t></section>
<section anchor="SHA1" title="SHA1">
<t>A procedure is known to obtain SHA-1 collisions in less than 2^62 operations <xref target="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 <xref target="stevens" />. Speculation about when practical collisions will be seen ranges from 2018-21 <xref target="schneier" />.</t>
<t>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 <xref target="knellwolf12" />.</t>
<t>Finally, some authors consider even the theoretical lower bound on collision attacks (2^80) to be too low a security parameter for future applications <xref target="enisa13" />.</t></section>
<section anchor="SHA2" title="SHA-256, SHA-384, SHA-512">
<t>There are collision and preimage attacks reported on reduced-round versions of the SHA-2 family, but currently no practical attacks <xref target="enisa13" />.</t></section>
<section anchor="HKDF-CTR" title="HKDF-CTR">
<t>Security models for password-based key derivation functions are still in a state of flux <xref target="wen12framework" />. However, we note that HKDF has security proofs <xref target="krawczyk10HKDF" />.</t></section>
<section anchor="PBKDF2" title="PBKDF2">
<t>PBKDF2 has known weaknesses <xref target="yao05kdf" /> and @@ minimum iterations should be used.</t>
</section>
<section anchor="CONCAT" title="CONCAT">
<t>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 <xref target="enisa13" />.</t></section>
<section anchor="sctn-sec-cons" title="Security Considerations">
<t>
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.
</t>
</section> <!-- sctn-sec-cons -->
<section anchor="sec-iana-consid" title="IANA Considerations">
<t>
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 <xref target="W3CWebCryptoCR" />. 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 <xref target="JWA" />.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="JWA" target="http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/"><front><title>JSON Web Algorithms (JWA)</title><author initials="M." surname="Jones" fullname="Mike Jones"><organization>
</organization><address><email>Michael.Jones@microsoft.com</email></address></author><date day="24" month="October" year="2014"/></front><seriesInfo name="IETF" value="Internet Draft"/></reference>
<reference anchor="W3CWebCryptoLC" target="http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/"><front><title>Web Cryptography API</title><author initials="R." surname="Sleevi" fullname="Ryan Sleevi"><organization>
</organization><address><email>sleevi@google.com</email></address></author><author initials="M." surname="Watson" fullname="Mark Watson"><organization>
</organization><address><email>Michael.Jones@microsoft.com</email></address></author><date day="25" month="March" year="2014"/></front><seriesInfo name="W3C Last Call Working Draft" value=""/></reference>
<reference anchor="W3CWebCryptoCR" target="http://www.w3.org/TR/WebCryptoAPI"><front><title>Web Cryptography API</title><author initials="R." surname="Sleevi" fullname="Ryan Sleevi"><organization>
</organization><address><email>sleevi@google.com</email></address></author><author initials="M." surname="Watson" fullname="Mark Watson"><organization>
</organization><address><email>watsonm@netflix.com</email></address></author><date day="27" month="November" year="2014"/></front><seriesInfo name="W3C Candidate Recommendation" value=""/></reference>
<reference anchor="PKCS11" target="https://www.oasis-open.org/committees/download.php/54455/pkcs11-base-v2.40-wd11.pdf"><front><title>OASIS PKCS 11</title><author initials="S." surname="Gleeson" fullname="Susan Gleeson"><organization>
</organization><address><email>susan.gleeson@oracle.com</email></address></author><author initials="C." surname="Zimman" fullname="Chris Zimman"><organization> </organization><address><email>chris@wmpp.com</email></address></author><date day="3" month="November" year="2014"/></front><seriesInfo name="OASIS Working Draft" value="draft"/></reference>
<reference anchor='RFC5297'>
<front>
<title>Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)</title>
<author initials='D.' surname='Harkins' fullname='D. Harkins'>
<organization /></author>
<date year='2008' month='October' />
<abstract>
<t>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.</t></abstract></front>
<seriesInfo name='RFC' value='5297' />
<format type='TXT' octets='50374' target='http://www.rfc-editor.org/rfc/rfc5297.txt' />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner' />
<date year='1997' month='March' />
<!--<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>-->
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
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:
<list>
<t>
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.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
</references>
<!-- -=-=-=-=-=-=-=-=-= Informative References =-=-=-=-=-=-=-=-= -->
<references title="Informative References">
<reference anchor="knellwolf12" target="http://www.iacr.org/cryptodb/data/paper.php?pubkey=24323"><front><title>New Preimage Attacks against Reduced SHA-1</title><author fullname="Simon Knellwolf" initials="S." surname="Knellwolf" /><author fullname="Dmitry Khovratovich" initials="D." surname="Khovratovich" /><date year="2012" /></front>
<seriesInfo name="In Advances in Cryptology - CRYPTO 2012, volume 7417 of Lecture Notes in Computer Science, pages 367-383. Springer Berlin Heidelberg, 2012." value=""/>
</reference>
<reference anchor="rogaway06deterministic" target="https://eprint.iacr.org/2006/221.pdf"><front><title>Deterministic authenticated-encryption: a provable-security treatment of the key-wrap problem</title><author fullname="P. Rogaway" initials="P." surname="Rogaway" /><author fullname="T. Shrimpton" initials="T." surname="Shrimpton" /><date year="2006" /></front>
<seriesInfo name="In Advances in Cryptology (EUROCRYPT ’06), volume 4004 of LNCS, pages 373–390, 2006." value=""/>
</reference>
<reference anchor="schneier" target="https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html">
<front>
<title>
When Will We See Collisions for SHA-1?
</title>
<author initials="B" surname="Schneier" fullname="Bruce Schneier">
<organization />
</author>
<date year="2012" />
</front>
<seriesInfo name="Accessed:" value="11-Nov-2014" />
</reference>
<reference anchor="SteelChoice" target="http://cryptosense.com/choice-of-algorithms-in-the-w3c-crypto-api/">
<front>
<title>
Choice of Algorithms in the W3C Crypto API
</title>
<author initials="G" surname="Steel" fullname="Graham Steel">
<organization />
</author>
<date year="2014" />
</front>
<seriesInfo name="Accessed:" value="20-Nov-2014" />
</reference>
<reference anchor="stevens"
target="http://2012.sharcs.org/slides/stevens.pdf">
<front>
<title>
Cryptanalysis of MD5 and SHA-1
</title>
<author initials="M" surname="Stevens" fullname="Marc Stevens">
<organization />
</author>
<date year="2012" />
</front>
<seriesInfo name="Accessed:" value="11-Nov-2014" />
</reference>
<reference anchor="email"
target="https://web.archive.org/web/20130523004555/http://www.rsa.com/rsalabs/node.asp?id=2005">
<front>
<title>
Raising the Standard for RSA Signatures: RSA-PSS
</title>
<author initials="B" surname="Kaliski" fullname="Burt Kaliski">
<organization />
</author>
<date year="2003" />
</front>
<seriesInfo name="Accessed:" value="11-Nov-2014" />
</reference>
<reference anchor="yao05kdf"><front><title>Design and analysis of password-based key derivation functions</title><author fullname="Frances F. Yao" initials="F. F." surname="Yao" /><author fullname="Yiqun Lisa Yin" initials="Y. L." surname="Yin" /><date year="2005" /></front>
<seriesInfo name="In Alfred Menezes, editor, CT-RSA, volume 3376 of Lecture Notes in Computer Science, pages 245–261. Springer, 2005" value="" />
</reference>
<reference anchor="krawczyk10HKDF"><front><title>Cryptographic extraction and key derivation: the HKDF scheme</title><author fullname="Hugo Krawczyk" initials="H." surname="Krawczyk" /><date year="2010" /></front>
<seriesInfo name="In Tal Rabin, editor, CRYPTO, volume 6223 of Lecture Notes in Computer Science, pages 631–648. Springer, 2010. " value=""/>
</reference>
<reference anchor="wen12framework"><front><title>A framework for security analysis of key derivation functions</title><author fullname="Chuah Chai Wen" initials="C. C." surname="Wen" /><author fullname="Ed Dawson" initials="E." surname="Dawson" /><author fullname="Juan Manuel Gonzalez Nieto" initials="J. M. G." surname="Nieto" /><author fullname="Leonie Simpson" initials="L." surname="Simpson" /><date year="2012" /></front>
<seriesInfo name="In Mark Dermot Ryan, Ben Smyth, and Guilin Wang, editors, ISPEC, volume 7232 of Lecture Notes in Computer Science, pages 199–216. Springer, 2012" value=""/>
</reference>
<reference anchor="wang2005" target="http://dx.doi.org/10.1007/11535218_2"><front><title>Finding collisions in the full SHA-1</title><author fullname="Xiaoyun Wang" initials="X." surname="Wang" /><author fullname="Yiqun Lisa Yin" initials="Y. L." surname="Yin" /><author fullname="Hongbo Yu" initials="H." surname="Yu" /><date year="2005" /><keyword>SHA-0</keyword><keyword> SHA-1</keyword><keyword> collision search attacks</keyword><keyword> hash functions</keyword></front>
<seriesInfo name="In Proceedings of the 25th Annual International Conference on Advances in Cryptology, CRYPTO’05, pages 17–36, Berlin, Heidelberg, 2005. Springer-Verlag" value="" />
</reference>
<reference anchor="weakdh" target="http://weakdh.org"><front><title>Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice</title><author fullname="David Adrian" initials="D." surname="Adrian" /><author fullname="Karthik Bhargavan" initials="K." surname="Bhargavan" /><author fullname="et al." initials="et" surname="al." /><date year="2015" /><keyword>DH</keyword></front> <seriesInfo name="In Proceedings of the 22nd ACM Conference on Computer and Communications Security (CCS ’15), Denver, CO, October 2015" value="" />
</reference>
<reference anchor="fujisaki04OAEP" target="http://dx.doi.org/10.1007/s00145-002-0204-y"><front><title>RSA-OAEP is secure under the RSA assumption</title><author fullname="Eiichiro Fujisaki" initials="E." surname="Fujisaki" /><author fullname="Tatsuaki Okamoto" initials="T." surname="Okamoto" /><author fullname="David Pointcheval" initials="D." surname="Pointcheval" /><author fullname="Jacques Stern" initials="J." surname="Stern" /><date year="2004" /></front>
<seriesInfo name="Journal. Cryptol., 17(2):81–104, March 2004" value="" />
</reference>
<reference anchor="bellare06HMAC"><front><title>New proofs for MAC and HMAC: security without collision-resistance</title><author fullname="Mihir Bellare" initials="M." surname="Bellare" /><date year="2006" /></front>
<seriesInfo name="In Cynthia Dwork, editor, CRYPTO, volume 4117 of Lecture Notes in Computer Science, pages 602–619. Springer, 2006" value=""/>
</reference>
<reference anchor="rogaway11evaluation"><front><title>Evaluation of some blockcipher modes of operation</title><author fullname="Philip Rogaway" initials="P." surname="Rogaway" /><date year="2011" /></front>
<seriesInfo name="Technical report, University of California, Davis, February 2011. Evaluation carried out for the Cryptography Research and Evaluation Committees (CRYPTREC) for the Government of Japan." value=""/>
</reference>
<reference anchor="enisa13"><front><title>Algorithms, key sizes and parameters report: 2013 recommendations</title><author fullname="Nigel P. Smart" initials="N. P." surname="Smart" /><author fullname="Vincent Rijmen" initials="V." surname="Rijmen" /><author fullname="Bogdan Warinschi" initials="B." surname="Warinschi" /><author fullname="Gaven Watson" initials="G." surname="Watson" /><date year="2013" /></front>
<seriesInfo name="Technical report, October 2013. ENISA Report. Version 1.0. " value="" />
</reference>
<reference anchor="mitchell05cbc"><front><title>Error oracle attacks on CBC mode: is there a future for CBC mode encryption?</title><author fullname="Chris J. Mitchell" initials="C. J." surname="Mitchell" /><date year="2005" /></front>
<seriesInfo name="In J. et al. Zhou, editor, ISC 2005, volume 3650 in Lecture Notes in Computer Science, pages 244–258, 2005." value=""/>
</reference>
<reference anchor="rizzo10USENIX" target="http://portal.acm.org/citation.cfm?id=1925004.1925008"><front><title>Practical padding oracle attacks</title><author fullname="Juliano Rizzo" initials="J." surname="Rizzo" /><author fullname="Thai Duong" initials="T." surname="Duong" /><date year="2010" /></front>
<seriesInfo name="WOOT’10, pages 1–8, Berkeley, CA, USA, 2010. USENIX Association" value=""/>
</reference>
<reference anchor="vaudenay03PKC" target="http://dx.doi.org/10.1007/3-540-36288-6_23"><front><title>The security of DSA and ECDSA</title><author fullname="Serge Vaudenay" initials="S." surname="Vaudenay" /><date year="2002" /></front>
<seriesInfo name="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" value=""/>
</reference>
<reference anchor="boneh01crypto" target="http://dx.doi.org/10.1007/3-540-44647-8_12"><front><title>On the unpredictability of bits of the elliptic curve diffie-hellman scheme</title><author fullname="Dan Boneh" initials="D." surname="Boneh" /><author fullname="Igor Shparlinski" initials="I." surname="Shparlinski" /><date year="2001" /></front>
<seriesInfo name="In Joe Kilian, editor, Advances in Cryptology - CRYPTO 2001, volume 2139 of Lecture Notes in Computer Science, pages 201–212. Springer Berlin Heidelberg, 2001." value=""/>
</reference>
<reference anchor="vaudenay02"><front><title>Security flaws induced by CBC padding - applications to SSL, IPSEC, WTLS ...</title><author fullname="Serge Vaudenay" initials="S." surname="Vaudenay" /><date year="2002" /></front>
<seriesInfo name="In Lars R. Knudsen, editor, EUROCRYPT, volume 2332 of Lecture Notes in Computer Science, pages 534–546. Springer, 2002." value=""/>
</reference>
<reference anchor="paterson04padding"><front><title>Padding oracle attacks on the ISO CBC mode encryption standard</title><author fullname="K.G. Paterson" initials="K." surname="Paterson" /><author fullname="A. Yau" initials="A." surname="Yau" /><date year="2004" /></front>
<seriesInfo name="In T. Okamoto, editor, RSA ’04 Cryptography Track, number 2964 in LNCS, pages 305–323. Springer, 2004." value=""/>
</reference>
<reference anchor="kaminsky10"><front><title>An overview of cryptanalysis research for the advanced encryption standard</title><author fullname="Alan Kaminsky" initials="A." surname="Kaminsky" /><author fullname="Michael Kurdziel" initials="M." surname="Kurdziel" /><author fullname="Stanislaw Radziszowski" initials="S." surname="Radziszowski" /><date year="2010" /></front>
<seriesInfo name="In Military Communications Conference, 2010 - MILCOM 2010." value="" />
</reference>
<reference anchor="barthe2009POPL" target="http://dx.doi.org/10.1145/1480881.1480894"><front><title>Formal certification of code-based cryptographic proofs</title><author fullname="Gilles Barthe" initials="G." surname="Barthe" /><author fullname="Benjamin Gregoire" initials="B." surname="Gregoire" /><author fullname="Santiago Zanella-Beguelin" initials="S." surname="Zanella-Beguelin" /><date year="2009" /></front>
<seriesInfo name="In 36th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, POPL 2009, pages 90–101. ACM, 2009." value=""/>
</reference>
<reference anchor="manger01"><front><title>A chosen ciphertext attack on rsa optimal asymmetric encryption padding (OAEP) as standardized in PKCS #1 v2.0</title><author fullname="James Manger" initials="J." surname="Manger" /><date year="2001" /></front>
<seriesInfo name="In Joe Kilian, editor, Advances in Cryptology CRYPTO 2001, volume 2139 of Lecture Notes in Computer Science, pages 230–238. Springer Berlin / Heidelberg, 2001" value=""/>
</reference>
<reference anchor="bellare96eurocrypt" target="http://dl.acm.org/citation.cfm?id=1754495.1754541"><front><title>The exact security of digital signatures-how to sign with rsa and rabin</title><author fullname="Mihir Bellare" initials="M." surname="Bellare" /><author fullname="Phillip Rogaway" initials="P." surname="Rogaway" /><date year="1996" /></front>
<seriesInfo name="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." value="" />
</reference>
<reference anchor="bardou12padding"><front><title>Efficient padding oracle attacks on cryptographic hardware</title><author fullname="Romain Bardou" initials="R." surname="Bardou" /><author fullname="Riccardo Focardi" initials="R." surname="Focardi" /><author fullname="Yusuke Kawamoto" initials="Y." surname="Kawamoto" /><author fullname="Lorenzo Simionato" initials="L." surname="Simionato" /><author fullname="Graham Steel" initials="G." surname="Steel" /><author fullname="Joe-Kai-Tsay" initials="" surname="Joe-Kai-Tsay" /><date year="2012" /></front>
<seriesInfo name="In Advances in Cryptology: Proceedings of CRYPTO ’12, volume 7417 of LNCS, pages 608–625. Springer, 2012." value=""/>
</reference>
<reference anchor="bleichenbacher98"><front><title>Chosen ciphertext attacks against protocols based on the RSA encryption standard</title><author fullname="D. Bleichenbacher" initials="D." surname="Bleichenbacher" /><date year="1998" /></front>
<seriesInfo name="In Advances in Cryptology: Proceedings of CRYPTO ’98, volume 1462 of Lecture Notes in Computer Science,pages 1–12, 1998." value=""/>
</reference>
<reference anchor="jager12bleichenbacher" target="http://dx.doi.org/10.1007/978-3-642-33167-1_43"><front><title>Bleichenbacher's attack strikes again: breaking PKCS#1 v1.5 in XML encryption</title><author fullname="Tibor Jager" initials="T." surname="Jager" /><author fullname="Sebastian Schinzel" initials="S." surname="Schinzel" /><author fullname="Juraj Somorovsky" initials="J." surname="Somorovsky" /><date year="2012" /></front>
<seriesInfo name="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." value=""/>
</reference>
</references>
<section anchor="acknowledgments" title="Acknowledgments">
<t>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 <xref target="SteelChoice" />, and Harry Halpin from W3C/MIT agreed to edit and keep the document up to date.</t>
</section> <!-- acknowledgments -->
<!-- begin using change log with -01 revision
<section title="Change Log">
<t>
<list>
<t>
Changes from -01 to -02:
<list style="numbers">
<t>
[ document changes here].
</t>
</list>
</t>
<t>
Changes from -00 to -01:
<list style="numbers">
<t>
[ document changes here].
</t>
</list>
</t>
</list>
</t>
</section>
-->
</back>
</rfc>
<!-- PLEASE DO NOT DELETE!!! The below is used by XEmacs XML major-mode -->
<!--
Local Variables:
mode: xml
indent-tabs-mode:nil
sgml-omittag:t
sgml-shorttag:t
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-indent-data:t
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
<!-- PLEASE DO NOT DELETE!!! The above is used by XEmacs XML major-mode -->
<!-- <reference anchor="ForceHTTPS"
target="https://crypto.stanford.edu/forcehttps/">
<front>
<title>
ForceHTTPS:
Protecting High-Security Web Sites from Network
Attacks
</title>
<author initials="C" surname="Jackson" fullname="Collin Jackson">
<organization />
</author>
<author initials="A" surname="Barth" fullname="Adam Barth">
<organization />
</author>
<date month="April" year="2008" />
</front>
<seriesInfo name="In Proceedings of
the 17th International World Wide Web Conference (WWW2008)" value="" />
</reference> -->
| PAFTECH AB 2003-2026 | 2026-04-24 02:54:29 |