idnits 2.17.1 draft-whyte-select-pkc-qsh-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2016-10-04) is 2754 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SECG' is mentioned on line 98, but not defined == Missing Reference: 'SUPEC' is mentioned on line 386, but not defined == Unused Reference: 'BER09' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC4366' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'RFC5990' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC5859' is defined on line 619, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-whyte-qsh-tls13-00 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. M. Schanck 3 Intended Status: Experimental Security Innovation & U. Waterloo 4 Expires: 2017-04-04 W. Whyte 5 Security Innovation 6 Z. Zhang 7 Security Innovation 8 2016-10-04 10 Criteria for selection of public-key cryptographic algorithms 11 for quantum-safe hybrid cryptography 12 draft-whyte-select-pkc-qsh-02.txt 14 Abstract 16 Authenticated key exchange mechanisms instantiated with cryptosystems 17 based on integer factorization, finite field discrete log, or 18 elliptic curve discrete log, are believed to be secure now but are 19 vulnerable to a harvest-then-decrypt attack where an attacker who 20 cannot currently break the mechanism records the traffic anyway, then 21 decrypts it at some point in the future when quantum computers become 22 available. The Quantum-safe Hybrid approach is a modular design, 23 allowing any authenticated key exchange mechanism to be protected 24 against the harvest-then-decrypt attack by exchanging additional 25 secret material protected with an ephemeral key for a quantum-safe 26 public key cryptographic algorithm and including that secret material 27 in the Key Derivation Function (KDF) run at the end of the key 28 exchange. This approach has been proposed in TLS as the Quantum-safe 29 Hybrid handshake mechanism for Transport Layer Security protocol 30 (QSH_TLS). This document provides a guideline to criteria for 31 selecting public key encryption algorithms approved for experimental 32 use in the quantum safe hybrid setting. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html. 47 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 Update from last version: keeping alive till TLS WG review. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Quantum Attacks on Cryptosystems . . . . . . . . . . . . . 4 64 2.1.1. Shor's algorithm . . . . . . . . . . . . . . . . . . . 4 65 2.1.2. Grover's algorithm . . . . . . . . . . . . . . . . . . 5 66 2.2. Harvest-then-decrypt attack . . . . . . . . . . . . . . . 5 67 2.3. Quantum-safe hybrid approach . . . . . . . . . . . . . . . 5 68 2.4. Symmetric algorithm . . . . . . . . . . . . . . . . . . . 6 69 2.5. Random bit generation . . . . . . . . . . . . . . . . . . 6 70 3. Selection Criteria . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1. Similar work . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.2. Mandatory aspects . . . . . . . . . . . . . . . . . . . . 7 73 3.2.1. Security levels . . . . . . . . . . . . . . . . . . . 7 74 3.2.2. Freely available specifications of the algorithm . . . 7 75 3.2.3. Freely available source code for a reference 76 implementation . . . . . . . . . . . . . . . . . . . . 8 77 3.3 Desirable aspects . . . . . . . . . . . . . . . . . . . . . 8 78 3.3.1. SUPERCOP implementation . . . . . . . . . . . . . . . 8 79 3.3.2. Constant-time implementation . . . . . . . . . . . . . 9 80 3.3.3. Standardization . . . . . . . . . . . . . . . . . . . 9 81 3.3.4. Patent and IP related issues . . . . . . . . . . . . . 9 82 4. Recommendations, justifications and considerations . . . . . . 9 83 4.1. Preliminary list of recommendations . . . . . . . . . . . 9 84 4.2. Schemes under consideration . . . . . . . . . . . . . . . 10 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 88 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 90 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 94 1. Introduction 96 Quantum computers pose a significant threat to modern cryptography. 97 The two most widely adopted public key cryptosystems, namely, RSA 98 [PKCS1] and Elliptic Curve Cryptography (ECC) [SECG], will be broken 99 by general purpose quantum computers. RSA is adopted in TLS from 100 Version 1.0 to TLS Version 1.3 [RFC2246], [RFC4346], [RFC5246], 101 [TLS1.3]. ECC is enabled in RFC 4492 [RFC4492] and adopted in TLS 102 version 1.2 [RFC5246] and 1.3 [TLS1.3]. Those two primitives are the 103 only public key cryptography that TLS relies on. 105 Although these algorithms are currently believed to be secure, data 106 encrypted using these algorithms is vulnerable to a "harvest-then- 107 decrypt" attack where an attacker who cannot currently break the 108 mechanism records the traffic anyway, then decrypts it at some point 109 in the future when quantum computers become available. See section 2 110 for a detailed account of those attacks. 112 The Quantum-safe Hybrid approach, which has a concrete proposal as 113 the Quantum-safe Hybrid handshake for Transport Layer Security 114 protocol (QSH_TLS) [QSHTLS], addresses this attack by introducing a 115 quantum-safe public key encapsulation mechanism along with the 116 classical authenticated handshake. QSH_TLS is a modular design that 117 allows in principle for any quantum-safe encryption algorithm to be 118 used in the hybrid approach. 120 Since the IETF has not yet designated a single algorithm for use to 121 provide quantum-safety, and since the quantum-safe algorithm used is 122 intended to enhance security rather than being the only source of 123 security, it is appropriate for there to be multiple algorithms that 124 may be used in a quantum-safe hybrid setting. This provides an 125 opportunity for implementers to compare different quantum-safe 126 algorithms before the choice of a single one becomes vital. However, 127 an algorithm should clearly satisfy some baseline set of criteria 128 before it is approved for use in the quantum-safe hybrid setting, 129 even if those criteria are more relaxed than they would be for 130 selecting a single algorithm to rely on. 132 This document specifies what those criteria are. 134 The remainder of this document is organized as follows. Section 2 135 provides necessary background of the modular design of quantum-safe 136 handshake for TLS. Section 3 specifies selection criteria. Section 137 4 provides a preliminary list of recommended encryption algorithms. 138 Section 5 describes IANA considerations. 140 This is followed by the lists of normative and informative references 141 cited in this document, the authors' contact information, and 143 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 145 statements on intellectual property rights and copyrights. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 Well-known abbreviations and acronyms can be found at RFC Editor 152 Abbreviations List [REAL]. 154 2. Background 156 2.1. Quantum Attacks on Cryptosystems 158 If there exists a general purpose quantum computer, any cryptosystem 159 that is built on top of the mathematical hard problems of integer 160 factorization, finite field discrete logarithm (DL), or elliptic 161 curve discrete logarithm (ECDL) will be vulnerable. This includes 162 RSA, DSA, DH, ECDH, ECDSA and other variants of these ciphers, 163 including variants currently under consideration for standardization 164 by CFRG and all public key cryptosystems used in TLS. A quantum 165 computer may allow a real-time attack on the authentication within a 166 handshake protocol, or may allow an attacker to decrypt previously 167 recorded network traffic. 169 It is not clear when quantum computers will become available. The EU 170 has expressed in their Horizon 2020 project a desire for systems to 171 be "quantum-ready" by 2020 [H2020]. Research groups have 172 optimistically predicted practical and powerful quantum computer 173 could become available by the same date [TPM15], which may be large 174 enough to solve some instances of the elliptic curve discrete log 175 problem that are currently secure. It is, however, clear that data 176 exchanged today may be vulnerable to the harvest-then-decrypt attack 177 described below. 179 2.1.1. Shor's algorithm 181 Many of the hard problems used in public key cryptography can be 182 reduced to the Hidden Subgroup Problem over a finite cyclic group. 183 For an finite cyclic group G and finite set X, a function f : G -> X 184 is said to hide a subgroup H if f(a) = f(b) iff a - b is in H. The 185 Hidden Subgroup Problem (HSP) is to determine the hidden subgroup H 186 given black box access to f. Shor's algorithm [SHOR97] is a 187 probabilistic quantum algorithm that solves the HSP over any finite 188 cyclic group in polynomial time. Among the problems that reduce to 189 the HSP are the integer factorization and discrete logarithm problems 190 that underly RSA, DSA, DH, ECDH, and ECDSA, hence all of these 191 systems are vulnerable to quantum attacks. 193 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 195 2.1.2. Grover's algorithm 197 Grover's algorithm [GROV96] is a probabilistic quantum algorithm that 198 finds the unique input to a black box function that produces a 199 particular output value. Compared with classical algorithms, 200 Grover's algorithm finds the solution with a quadratic boost, i.e., 201 within O(N^(1/2)) evaluations of the function, where N is the size of 202 the function's domain. 204 While an exact cost analysis of Grover's algorithm will depend 205 crucially on architecture dependent parameters that are not currently 206 available, it is a common belief among cryptographers that Grover's 207 algorithm is effective against symmetric primitives [BRA98]. To be 208 conservative we ignore constant factors and simply assume that 209 Grover's algorithm finds preimages quadratically faster than 210 classical brute force search. Likewise, we assume that Grover's 211 algorithm reduces the time required to recover the key of a symmetric 212 cipher by a quadratic factor. As an example, AES-256 provides 256 213 bits of security against classical computers, but is assumed to 214 provide only 128 bits of security against quantum computers. 216 2.2. Harvest-then-decrypt attack 218 The harvest-then-decrypt attack is a straightforward yet effective 219 attack. In such an attack, the attacker stores encrypted data for 220 long periods of time until legal, technological, or cryptanalytic 221 means become available for revealing keys. 223 Under the context of quantum computing, this attack becomes extremely 224 powerful. TLS relies on RSA and ECC, both will be broken when 225 quantum computer becomes available. Hence, any data encrypted now 226 will be vulnerable to this attack. It is likely that it will be some 227 time before breaks become so cheap that all harvested traffic can be 228 decrypted. However, this is little consolation to the people whose 229 traffic is initially targeted for decryption. It seems prudent to 230 provide protection against the harvest-then-decrypt attack natively 231 to secure data exchange protocols as soon as possible. 233 2.3. Quantum-safe hybrid approach 235 The quantum safe hybrid approach defeats the quantum harvest-then- 236 decrypt attack by introducing a second quantum-safe cryptographic 237 primitive running in parallel with existing handshake approaches. 238 This measure assures that when the classical cryptography fails, the 239 attacker still need to break the corresponding quantum-safe 240 encryption algorithm. 242 It is easy to see that this approach is at least as strong as the 244 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 246 stronger primitive of classical cryptography and the quantum-safe 247 cryptography in the pre-quantum world [QSHTOR]. Therefore, it is an 248 ideal approach to migrate into quantum-safe cryptography for TLS as 249 it does not reduce the security guarantees that TLS is already 250 delivering; in the meantime, it allows for trial usage of quantum- 251 safe algorithms and protects data against the aforementioned harvest- 252 the-decrypt attack. 254 2.4. Symmetric algorithm 256 For 128 bit security, implementations of a quantum-safe hybrid 257 approach SHOULD use a symmetric algorithm with a 256-bit key, but MAY 258 use a symmetric algorithm with a 128-bit key for interoperability or 259 performance reasons. 261 2.5. Random bit generation 263 For 128 bit security, implementations of a quantum-safe hybrid 264 approach SHOULD ensure that any Deterministic Random Bit Generator 265 (DRBG) used in key generation or encryption for a quantum-safe 266 primitives is instantiated with at least 256 bits of entropy from a 267 secure random source. 269 3. Selection Criteria 271 The hybrid approach is a modular design, which, in order to support 272 various quantum-safe algorithms, does not recommend any specific 273 quantum-safe encryption algorithm. In this section we give 274 guidelines for selecting encryption algorithms that are suitable for 275 experimental use in the hybrid approach. 277 3.1. Similar work 279 To date, multiple groups have been involved in the work of evaluating 280 quantum-safe encryption algorithms. 282 o The National Security Agency of the United States has 283 announced a plan to migrate to quantum-safe cryptography [NSA15]. 285 o The ETSI Quantum-Safe Cryptography (QSC) Industry 286 Specification Group (ISG) aims to assess and make recommendations 287 for quantum-safe cryptographic primitives and protocols, taking 288 into consideration both the current state of academic cryptology 289 and quantum algorithm research, as well as industrial requirements 290 for real-world deployment [ETSIQ]. 292 o The Secure Architectures of Future Emerging Cryptography 293 (SAFEcrypto) project [SAFEC], supported by H2020 project, focuses 295 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 297 on practical implementation of quantum-safe encryptions 298 algorithms, particularly lattice-based public key cryptography. 300 o The Post-quantum cryptography for long-term security 301 (PQCRYPTO) group, also supported by H2020 project, has made their 302 initial recommendations of long-term secure post-quantum systems 303 [PQCRY]. 305 Note that PQCRYPTO is the only group that has made initial 306 recommendations on quantum-safe cryptography. 308 This document describes criteria for quantum-safe encryption 309 algorithms, with a focus on those algorithms existing today and 310 suitable for transitional use until the quantum era. The intent is 311 ultimately to align with other industry groups while enabling earlier 312 deployment of algorithms that can reasonably be expected to make 313 things better, not worse. 315 3.2. Mandatory aspects 317 Algorithms to be considered by quantum-safe hybrid approach MUST meet 318 the following criteria. 320 3.2.1. Security levels 322 The candidate algorithm MUST provide 128 bit security in the quantum- 323 safe setting. 325 If the candidate algorithm is subject to decryption failures, these 326 MUST happen with a probability of less than 2^-74 (such that 128 327 billion devices (2^7 * 2^30) each initiating 128 billion connections 328 (2^7 * 2^30) will with high probability encounter no decryption 329 failures). Note that an attacker will be able to create invalid 330 messages that do not decrypt correctly, so an implementation will 331 have to correctly handle this failure case even when the chance of a 332 decryption failure is negligible on a valid message (or even when 333 this chance is zero). 335 3.2.2. Freely available specifications of the algorithm 337 The candidate algorithm MUST have a set of publicly accessible 338 documents specifying common techniques and implementation choices. 339 The documents MAY be Internet Drafts. Topics MUST include: 341 o Cryptographic primitives: the building blocks for a secure 342 cryptographic scheme; 344 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 346 o Cryptographic schemes: complete sequences of operations for 347 performing secure cryptographic functions; 349 o Supported parameter choices: specific selections of approved 350 sets of values for cryptographic parameters; 352 o Classical security levels for the proposed parameter sets; 354 o Argument for post-quantum security levels for the proposed 355 parameter sets; 357 o Encoding of cryptographic data items: specifies 358 encoding/decoding of public keys and ciphertexts. 360 In addition, it MAY include relevant information to assist in the 361 development and interoperable implementation, including: 363 o Security considerations; 365 o Open issues. 367 3.2.3. Freely available source code for a reference implementation 369 It is important to have a stable reference implementation available 370 for the candidate algorithm. The code needs to be rigorously tested 371 and reviewable. A poor implementation of a good cryptosystem can be 372 as harmful as a broken cryptosystem. 374 The implementation SHOULD also be open source to allow for public 375 auditing. In particular, any default choice of parameters MUST be 376 justified. 378 3.3 Desirable aspects 380 The following aspects are desirable. Algorithms that meet those 381 criteria are preferred. 383 3.3.1. SUPERCOP implementation 385 System for Unified Performance Evaluation Related to Cryptographic 386 Operations and Primitives (SUPERCOP) [SUPEC] is a toolkit developed 387 by the Virtual Application and Implementation Research (VAMPIRE) Lab 388 for measuring the performance of cryptographic software. The latest 389 release of SUPERCOP measures the performance of hash functions, 390 secret key stream ciphers, public key encryption systems, public key 391 signature systems, and public key secret sharing systems. 393 The candidate algorithm MAY have a reference implementation for 395 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 397 SUPERCOP. Performance of the implementation on SUPERCOP MAY be taken 398 into consideration when selections are made. 400 3.3.2. Constant-time implementation 402 An implementation of a cryptosystem is constant-time means that the 403 time for encryption/decryption functions is constant, regardless of 404 the input and the output of the functions. As an example, the time 405 to decrypt any valid ciphertext should use a same time as decrypting 406 an invalid ciphertext and producing a decryption error. Constant 407 time implementation is important for cryptography as it makes side- 408 channel attacks substantially harder. 410 Algorithms with provable constant time implementations SHOULD be 411 preferred. However, this is not an absolute requirement as the QSH 412 setting uses ephemeral keys and an implementation of QSH SHOULD only 413 decrypt once with any key, so an attacker is unlikely to gain 414 sufficient information from the time of a single decryption to 415 recover the plaintext. 417 3.3.3. Standardization 419 The candidate algorithm MAY be standardized by another standards 420 body, such as ANSI X.9, IEEE, or ETSI. Algorithms that maintain 421 creditability among multiple standards bodies SHOULD be preferred. 423 3.3.4. Patent and IP related issues 425 The candidate algorithm MAY be either non-patented or patented but 426 with FRAND (Free or Reasonable and Non-Discriminatory) licensing 427 statement made and all relevant IETF IP declarations provided. 429 4. Recommendations, justifications and considerations 431 4.1. Preliminary list of recommendations 433 The following list is an (incomplete) list of recommended quantum- 434 safe encryption algorithms and parameters for 128 bits security that 435 MAY be considered in the hybrid approach. 437 o NTRUEncrypt lattice-based encryption scheme with parameter 438 sets ees443ep1, ees587ep1, and ees743ep1 as defined in [EESS1]; 440 o Specification: [EESS1] provides a concrete specification of 441 NTRUEncrypt with parameter set ees443ep1, ees587ep1, and 442 ees743ep1, including primitives, syntax, reference to classical 443 security analysis in [HOF15], quantum security analysis, and 444 encode/decode mechanisms 446 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 448 o Open-sourced reference implementation: Available from 449 [NTRU-GIT] 451 o SUPERCOP implementation: Available for related parameter 452 sets, not yet available for the recommended parameter sets 454 o Constant-time implementation: Not yet available 456 o Standardization: The recommended parameter sets have not 457 been published in a standard, but the encryption scheme and 458 other parameter sets have been standardized in IEEE 1363.1 and 459 ANSI X9.98. 461 o Patent and IP Issues: NTRUEncrypt is subject to patents 462 held by Security Innovation. Security Innovation has provided 463 IPR Declaration 2588 to IETF. 465 4.2. Schemes under consideration 467 The following schemes are under consideration. They are well known 468 quantum safe encryption algorithms in the literature. However, due 469 to the lack of specifications, implementation of those schemes are 470 non-trivial. For this reason we list those schemes as "under 471 consideration". They will be promoted to the recommendation list 472 once detailed specifications are provided. 474 o Learning with error lattice-based encryption scheme [REG05], 475 with parameter set form [LIN11]; 477 o NTRUEncrypt lattice-based encryption scheme instantiated with 478 learning with error problem [STE11]; 480 o McEliece code-based encryption scheme [MCELI] with parameter 481 set for McBits [MCBIT]; 483 o McEliece code-based encryption scheme with Quasi-cyclic 484 Moderate Density Parity-Check (MDPC) codes [MDPC]. 486 5. IANA Considerations 488 This document does not establish any new IANA registries, nor does it 489 add any entries to existing registries. 491 6. References 493 6.1. Normative References 494 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 496 [BER09] Bernstein, D., "Cost analysis of hash collisions: Will 497 quantum computers make SHARCS obsolete?", SHARCS'09. 498 500 [BRA98] Brassard, G., Hoyer, P., and Tapp, A., "Quantum 501 cryptanalysis of hash and claw-free functions", LATIN'98: 502 Theoretical Informatics. 504 [EESS1] Consortium for Efficient Embedded Security, "Efficient 505 Embedded Security Standard #1: Implementation Aspects of 506 NTRUEncrypt", March 2015. 507 510 [ETSIQ] ETSI White Paper No. 8, "Quantum Safe Cryptography and 511 Security: An introduction, benefits, enablers and 512 challenges", June 2015. 514 [GROV96] Grover, L., "A fast quantum mechanical algorithm for 515 database search", STOC 1996. 517 [H2020] Lange, T., "PQCRYPTO project in the EU", April, 2015. 518 520 [HOF15] Hoffstein, J., Pipher, J., Schanck, J., Silverman, J., 521 Whyte, W., and Zhang, Z., "Choosing Parameters for 522 NTRUEncrypt", 2015. 524 [LIN11] Lindner, R., and Peikert, C., "Better Key Sizes (and 525 Attacks) for LWE-Based Encryption", 2011. 527 [MCBIT] Bernstein, D., Chou, T., and Schwabe, P., "McBits: Fast 528 Constant-Time Code- Based Cryptography", 2013. 530 [MCELI] McEliece, R., "A Public-Key Cryptosystem Based On 531 Algebraic Coding Theory", 1978. 533 [MDPC] Misoczki, R., Tillich, J., Sendrier, N., and Barreto, P., 534 "MDPC-McEliece: New McEliece variants from Moderate 535 Density Parity-Check codes", 2013. 537 [NSA15] NSA, "NSA Suite B Cryptography", Aug 19, 2015. 538 540 [NTRU-GIT] https://github.com/NTRUOpenSourceProject/NTRUEncrypt 542 [PKCS1] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 543 1.5", PKCS 1, November 1993 545 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 547 [PQCRY] PQCRYPTO, "Initial recommendations of long-term secure 548 post-quantum systems". 549 551 [QSHTLS] Schanck, J., Whyte, W., and Zhang, Z., "Quantum-Safe 552 Hybrid (QSH) Ciphersuite for Transport Layer Security 553 (TLS) version 1.3", draft-whyte-qsh-tls13-00, July 2015. 555 [QSHTOR] Schanck, J., Whyte, W., and Zhang, Z., "A quantum-safe 556 circuit-extension handshake for Tor", March 2015. 557 559 [REAL] "RFC Editor Abbreviations List", September 2013, 560 . 563 [REG05] Regev, O., "On lattices, learning with errors, random 564 linear codes, and cryptography", 2005. 566 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 567 Requirement Levels", RFC 2119, March 1997. 569 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 570 RFC 2246, January 1999. 572 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 573 IANA Considerations Section in RFCs", RFC 2434, October 574 1998. 576 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 577 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 579 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 580 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 581 for Transport Layer Security (TLS)", RFC 4492, May 2006. 583 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 584 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 586 [SAFEC] Secure Architectures of Future Emerging Cryptography 587 (SAFEcrypto). 589 [SHOR97] Shor, P., "Polynomial-time algorithms for prime 590 factorization and discrete logarithm problems", SIAM J. 591 Computing 26 (1997), 1484-1509. 592 594 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 596 [STE11] Stehle, D., and Steinfield, R., "Making NTRUEncrypt and 597 NTRUSign as secure as worst-case problems over ideal 598 lattices", 2011. 600 [TLS1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol 601 Version 1.3", draft-ietf-tls-tls13-05, March 2015. 603 [TPM15] Morgan, T., "Google Sees Long, Expensive Road Ahead For 604 Quantum Computing", July 2015. 605 608 6.2. Informative References 610 [RFC4366] Blake-Wilson, S., Nysrom, M., Hopwood, D., Mikkelsen, J., 611 and T. Wright, "Transport Layer Security (TLS) 612 Extensions", RFC 4366, April 2006. 614 [RFC5990] Randall, J., Kaliski, B., Brainard, J. and Turner S., "Use 615 of the RSA-KEM Key Transport Algorithm in the 616 Cryptographic Message Syntax (CMS)", RFC 5990, September 617 2010. 619 [RFC5859] Krawczyk, H., Eronen, P., "HMAC-based Extract-and-Expand 620 Key Derivation Function (HKDF)", RFC 5859, May 2010. 622 Authors' Addresses 624 John M. Schanck 625 Security Innovation, US 626 and 627 University of Waterloo, Canada 628 jschanck@securityinnovation.com 630 William Whyte 631 Security Innovation, US 632 wwhyte@securityinnovation.com 634 Zhenfei Zhang 635 Security Innovation, US 636 zzhang@securityinnovation.com 638 INTERNET DRAFT PKC Selecting Criteria for QSH-TLS 2016-10-04 640 Copyright Notice 642 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 643 2: Copyright (c) 2015 IETF Trust and the persons identified as the 644 document authors. All rights reserved. 646 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(ii), 647 paragraph 3: This document is subject to BCP 78 and the IETF Trust's 648 Legal Provisions Relating to IETF Documents 649 (http://trustee.ietf.org/license-info) in effect on the date of 650 publication of this document. Please review these documents 651 carefully, as they describe your rights and restrictions with respect 652 to this document.