ETSI GR QSC 003 V1.1.1 (2017-02)

Quantum Safe Cryptography; Case Studies and Deployment Scenarios

DGR/QSC-003

General Information

• Status: Published
• Publication Date: 06-Feb-2017
• Technical Committee: QSC - Quantum Safe Cryptography
• Current Stage: 12 - Completion
• Due Date: 27-Feb-2017
• Completion Date: 07-Feb-2017

Standards Content (Sample)

GROUP REPORT
Quantum Safe Cryptography;
Case Studies and Deployment Scenarios
Disclaimer
The present document has been produced and approved by the Quantum-Safe Cryptography (QSC) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR QSC 003 V1.1.1 (2017-02)

Reference
DGR/QSC-003
Keywords
algorithm, authentication, confidentiality, security

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2017.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GR QSC 003 V1.1.1 (2017-02)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Abbreviations . 8
4 QSC deployment scenarios . 9
5 Network security protocols . 10
5.1 Introduction . 10
5.2 TLS . 10
5.2.1 TLS cryptography . 10
5.2.2 Drop-in replacement . 11
5.2.3 Hybrid scheme . 11
5.2.4 Re-engineering . 11
5.3 Discussion . 11
5.3.1 Integration into the protocol stack . 11
5.3.2 Handling large key sizes . 12
5.3.3 Is quantum-safe authentication required today? . 13
6 Offline services . 13
6.1 Secure e-mail . 13
6.2 Credentials for offline services . 14
6.3 Discussion . 14
7 Internet of Things . 14
7.1 Introduction . 14
7.2 IoT cryptography . 15
7.3 Discussion . 15
8 Satellite communications . 16
8.1 Requirements . 16
8.2 Constraints . 16
8.3 Discussion . 17
9 Key Distribution Centres . 17
9.1 Introduction . 17
9.2 Examples . 18 ®
9.2.1 Kerberos . 18 ®
9.2.2 ZigBee Trust Centre . 18
9.2.3 Datagram Transport Layer Security (DTLS) . 18
9.3 Discussion . 18
10 Authentication . 19
10.1 Introduction . 19
10.2 Requirements and use cases . 19
10.2.1 Authenticating Internet-based applications . 19
10.2.2 Offline file Authentication . 19
10.2.3 Authenticating broadcast communications . 20
10.3 Symmetric solutions . 20
10.4 Discussion . 20
11 Exotic functionality . 20
11.1 Identity-based encryption (IBE) . 20
11.2 Attribute-based encryption (ABE) and fully homomorphic encryption (FHE) . 21
ETSI
4 ETSI GR QSC 003 V1.1.1 (2017-02)
11.3 Discussion . 22
12 Conclusions . 22
Annex A: Summary table . 24
History . 25

ETSI
5 ETSI GR QSC 003 V1.1.1 (2017-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Quantum-Safe Cryptography
(QSC).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI GR QSC 003 V1.1.1 (2017-02)
1 Scope
The present document examines a number of real-world uses cases for the deployment of quantum-safe cryptography
(QSC). Specifically, it examines some typical applications where cryptographic primitives are deployed today and
discusses some points for consideration by developers, highlighting features that may need change to accommodate
quantum-safe cryptography. The main focus of the document is on options for upgrading public-key primitives for key
establishment and authentication, although several alternative, non-public-key options are also discussed.
The present document gives an overview of different technology areas; identify where the security and cryptography
currently resides; and indicate how things may have to evolve to support quantum-safe cryptographic primitives.
Clauses five and six discuss network security protocols, using TLS and S/MIME as typical examples. These are
contrasted in clauses seven and eight by an examination of security options for IoT and Satellite use cases, which have
very different requirements and constraints than traditional internet-type services. Some alternatives to public key
protocols are reviewed in clause nine. Authentication requirements are discussed in clause ten and some
forward-looking examples providing advanced functionality are examined in clause eleven.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI: "Quantum safe cryptography and security," ETSI White Paper No. 8, 2015.
[i.2] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2", 2008.
[i.3] Draft RCF draft-ietf-tls-tls13-09: "The Transport Layer Security (TLS) protocol version 1.3",
5 October 2015.
[i.4] C. Peikert: "Lattice Cryptography for the Internet" IACR ePrint 2014/070, 2014.
[i.5] J. W. Bos, C. Costello, M. Naehrig and D. Stebila: "Post-quantum key exchange for the TLS
protocol from the ring learning with errors problem" IACR ePrint Archive 2014/599, 2014.
[i.6] V. Singh: "A Practical Key Exchange for the Internet using Lattice Cryptography" IACR ePrint
2015/138, 2015.
[i.7] E. Alkim, L. Ducas, T. Pöppelmann and P. Schwabe: "Post-quantum key exchange - a new hope"
IACR ePrint 2015/1092, 2015.
[i.8] Draft IETF draft-whyte-qsh-tls13-01: "Quantum-safe hybrid (QSH) ciphersuite for Transport
Layer Security (TLS) version 1.3 (draft RFC)", 20 September 2015.
[i.9] O. Garcia-Morchon, R. Rietman, L. Tolhuizen, J.-L. Torre-Arce, S. Bhattacharya and M.
Bodlaender: "Efficient quantum-resistant trust Infrastructure based on HIMMO", IACR ePrint
2016/410, 2016.
ETSI
7 ETSI GR QSC 003 V1.1.1 (2017-02)
[i.10] D. McGrew: "Living with post quantum security", NIST workshop on cubersecurity in a post
quantum world, 2015.
[i.11] Z. Zheng, W. White and J. Schanck: "A quantum-safe circuit-extension handshake for Tor" in
NIST Workshop on Cybersecurity in a Post-Quantum World, 2015.
[i.12] ETSI GR QSC 001 (V1.1.1): "Quantum-Safe Cryptography (QSC); Quantum-safe algorithmic
framework".
[i.13] IETF RFC 5751: "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2", 2010.
[i.14] D. McGrew, P. Kampanakis , S. Fluhrer, S.-L. Gazdag , D. Butin and J. Buchmann: "State
Management for Hash-Based Signatures" IACR ePrint, vol. 2016/357, 2016.
[i.15] Philips: "Philips Hue".
NOTE: Available at www.meethue.com.
[i.16] O. Garcia-Morchon: "Security for Pervasive Healthcare" PhD Thesis, RWTH University, 2011. ®
[i.17] ZigBee Alliance.
NOTE: Available at www.zigbee.org.
[i.18] IETF RFC 7228: "Terminology for Constrained-Node Networks", 2014.
[i.19] A. Waller, A. Byrne, R. Griffin, S. La Porta, B. Ammar and D. Lund: "Case Study Specification
and Requirements" 2015.
NOTE: Available at http://www.safecrypto.eu/.
[i.20] A. Menezes, P. van Oorschot and S. Vanstone: "Chapter 13: Key Management Techniques,
Handbook of Applied Cryptography".
NOTE: Available at http://cacr.uwaterloo.ca/hac/. ®
[i.21] Kerberos Consortium.
NOTE: Available at www.kerberos.org.
[i.22] IETF RFC 1510: "The Kerberos Network Authentication Service (V5)", 1993.
[i.23] IETF RFC 7252: "The Constrained Application Protocol (CoAP)", 2014.
[i.24] IETF RFC 4279: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", 2005.
[i.25] O. Garcia-Morchon: "DTLS-HIMMO: Achieving DTLS certificate security with symmetric key
overhead" in 20th European Symposium on Research in Computer Security (ESORICS), 2015.
[i.26] R. Blom: "Non-public key distribution" in CRYPTO 82, New York, 1983.
[i.27] T. Matsumoto and H. Imai: "On the key predistribution system - A practical solution to the key
distribution problem" in CRYPTO 87.
[i.28] C. Blundo, A. De Santis, A. Herzberg, S. Kutten, U. Vaccaro and M. Yung: "Perfectly-secure key
distribution for dynamic conferences" in CRYPTO 92, 1992.
[i.29] W. Zhang, M. Tran, S. Zhu and G. Cao: "A Random PerturbationBased Pairwise Key
Establishment Scheme for Sensor Networks" in ACM MobiHoc, 2007.
[i.30] M. Albrecht, C. Gentry, S. Halev and J. Katz: "Attacking cryptographic schemes based on
"perturbation polynomials" in 16th ACM conference on Computer and communications security
(CCS '09), 2009.
[i.31] O. Garcia-Morchon, R. Rietman, L. Tolhuizen, J.-L. Torre-Arce, S. Moon, D. Gomez-Perez,
J. Gutierrez and B. Schoenmakers: "Attacks and parameter choices in HIMMO" IACR ePrint
2016/152, 2016.
ETSI
8 ETSI GR QSC 003 V1.1.1 (2017-02)
[i.32] TUD: "Practical hash based signatures", 2016.
NOTE: Available at www.pqsignatures.org.
[i.33] IEEE 1609.2-2013™: "Wireless Access in Vehicular Environments", 2013.
[i.34] NIST: "The keyed-hash Meassage Authentication Code (HMAC)" FIPS-198-1, 2008.
[i.35] ISO/IEC 9797 parts 1 and 2: "Message Authentication Codes (MACs)", 1999.
[i.36] L. Ducas, V. Lyubashevsky and T. Prest: "Efficient identity-based encryption over NTRU
lattices," IACR ePrint 2014/794, 2014.
[i.37] D. Apon, X. Fan and F.-H. Liu: "Fully secure lattice-based IBE as compact as PKE" IACR ePrint
2016/125, 2016.
[i.38] S. Agrawal, D. Boneh and X. Boyen: "Lattice basis delegation in fixed dimension and shorter
ciphertext hierarchical IBE" in EUROCRYPT 2010 Volume 6110 of the series Lecture Notes in
Computer Science pp 553-, 2010.
[i.39] D. Cash, D. Hofheinz, E. Kiltz and C. Peikert: "Bonsai Trees, or How To Delegate a Lattice Basis"
Journal of Cryptology October 2012, vol. 25, no. 4, pp. 601-609, 2012.
[i.40] KLU: "HEAT project".
NOTE: Available at https://heat-project.eu/.
[i.41] K. Xagawa: "Improved (hierarchical) inner-product encryption from lattices" IACR ePrint
2015/249, 2015.
[i.42] S. Argawal, D. Freeman and V. Vaikuntanathan: "Functional encryption for inner product
predicates from learning with errors" IACR ePrint 200/410, 2011.
[i.43] C. Gentry, A. Sahai and B. Waters: "Homomorphic encryption from learning with errors:
Conceptually-simpler, asymptotically-faster, attribute-based" IACT ePrint 2013/340, 2013.
[i.44] Z. Barkerski, C. Gentry and V. Vaikuntanathan: "(Leveled) fully homomorphic encryption without
bootstrapping" IACR ePrint 2011/277, 2011.
[i.45] NIST: "Report on Post Quantum cryptography" NISTER 8105, 2016.
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
6LoWPAN Ipv6 over Low power Wireless Personal Area Networks
ABE Attribute-based Encryption
AES Advanced Encryption Standard
CoAP Constrained Application Protocol
COTS Commercial Off The Shelf
DH Diffie-Hellman
DSA Digital Signature Algorithm
DTLS Datagram Transport Layer Security
ECDH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
FHE Fully Homomorphic Encryption
HEAT Homomorphic Encryption Applications and Technology
HFE Hidden Field Equations
HIBE Hierarchical Identity-Based Encryption
HIMMO Hiding Information Mixing Modular Operations
HTTP Hypertext Transfer Protocol
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
ETSI
9 ETSI GR QSC 003 V1.1.1 (2017-02)
IKE Internet Key Exchange
IoT Internet of Things
IPsec Internet Protocol Security
KDC Key Distribution Centre
KMS Key Management Server
KTC Key Translation Centre
LoRA™ Low Power Wide Area Network for IoT
LTE™ Long Term Evolution
MAC Message Authentication Codes
MIT Massachusetts Institute of Technology
oneM2M Standards for machine to machine
PKC Public Key Cryptography
PKI Public Key Infrastructure
PSK Pre-shared key
QSC Quantum-Safe Cryptography
QSH Quantum Safe Hybrid
RFC Request For Comments
RSA Rivest Shamir Adleman
S/MIME Secure/Multipurpose Internet Mail Extensions
SHA Secure Hash Algorithm
SMTP Simple Mail Transfer Protocol
TCP Transmission Control Protocol
TLS Transport Layer Security
UDP User Datagram Protocol
V2X Vehicle to everything
VoIP Voice over Internet Protocol
VPN Virtual Private Network
W3C Worldwide Web Consortium
4 QSC deployment scenarios
Cryptography is already widely-used and is rapidly becoming ubiquitous, appearing in everything from internet and
mobile applications to emerging technologies such as the Internet of Things (IoT). Over the past 20 to 30 years,
information storage has transitioned from a paper-based society, where physical copies of sensitive documents were
once locked in filing cabinets and safes, to one where sensitive documents are now stored electronically. Although not
obviously visible, this migration continues to occur. More information is now stored on databases within cloud
environments, completely off-site to where the data originated. This poses an interesting problem for the future: how to
keep sensitive data from unauthorised access both while being transferred over a network and while stored
electronically.
Furthermore, quantum computers are no longer the thought experiments they once were not very long ago. There are
many approaches to quantum computation, including super-conducting qubits, ion traps, nuclear magnetic resonance,
quantum annealing and others. As of this date, small quantum computers exist in laboratories, although they are
sufficiently under-powered to solve complex cryptographic problems in reasonable periods of time.
While these small quantum computers pose no threat to information security at present, it is already possible to observe
their efficiency in solving certain classes of mathematical problems. This is why there is an increased priority by
industry and governments on quantum computer research. This priority is evidenced by the propensity for increased
investment in recent years. This is also why there is an increased priority on investments in quantum safe cryptography.
The wide range of applications being built today is accompanied by a diversity of security, efficiency and policy
requirements and a variety of different computing platforms ranging from highly constrained devices to high end
computing; so it seems unlikely that there would be a single one-size fits all solution for quantum resistance. The
document presents some real-world use cases of where cryptography is deployed today and investigates how things may
need change to migrate to quantum-safe cryptography.
The present document gives an overview of different technology areas, identify where the security and cryptography
currently resides, and indicate how things might have to evolve or change to support quantum-safe cryptographic
primitives. More detailed analysis of these examples may appear as separate ISG documents.
ETSI
10 ETSI GR QSC 003 V1.1.1 (2017-02)
NOTE: The present document is a survey and should not be treated as an official ETSI endorsement of any
products or standards mentioned below. Nor is it the intention of the document to prescribe how protocols
defined and maintained by any other standards bodies should evolve. The intention is simply to discuss
the consequences of using certain primitives in some typical example use-cases.
5 Network security protocols
5.1 Introduction
An over-simplified but stereotypical model for public key-based communications is the following. Two parties wish to
establish a secure and authenticated communications link across a network. One or both parties obtain signed
certificates from a trusted Public Key Infrastructure (PKI) containing the identity and public key of the other party with
whom they wish to communicate. After verifying the validity of the certificate and the counterpart's identity, a
public-key based handshake protocol is used to establish a secret session key known only to the two parties, and this
session key is typically input to a block cipher to encrypt the subsequent communications between the pair.
Most current public-key-based communications are designed to be secure against classical adversaries. This means that
the handshake mechanism allows two authenticated parties to agree on a secret session key that is secure against
attackers with traditional computing resources. It is widely accepted that most currently-deployed public-key based
communications will become vulnerable to a future attacker with access to large-scale quantum computers. For this
reason, a growing body of research is being focused on developing quantum-safe public-key based handshake protocols.
Protocols such as Internet Protocol Security (IPsec), Internet Key Exchange (IKE), Transport Layer Security (TLS)
protocol, Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP) and others are ubiquitous
internet or application level protocols used to secure a host of modern communications applications including web
browsing, e-mails, Virtual Private Networks (VPNs), Voice over Internet Protocol (VoIP), instant messaging, etc.
chapter 4 of the ETSI whitepaper [i.1] gives an overview of the sorts of changes that would need to be considered to
incorporate quantum-safe primitives into common network protocols such as these.
Most of these protocols are defined and maintained by the Internet Engineering Task Force (IETF), Worldwide Web
Consortium (W3C) or similar groups and it is not in the remit of ETSI ISG QSC to decide how these protocols should
evolve. However, given the ubiquitous nature of these protocols, it is necessary to have some understanding of the
compatibility of any ETSI recommended primitives with the wider commercial infrastructure.
Clauses 5.2 to 5.3.3 focus on TLS as an important example of a real-world use case. They look at some specific
proposals in the literature for ways to upgrade TLS to be quantum secure. The TLS [i.2] and [i.3] protocol suite
provides a cryptographic layer through which network application protocols such as Hypertext Transfer Protocol Secure
(HTTPS) (used for web browsing), SMTP (e-mail) and VoIP (voice) can be securely tunnelled. TLS is widely used to
underpin the security of many of the other technology areas discussed in the remainder of the present document.
5.2 TLS
5.2.1 TLS cryptography
TLS version 1.2, defined in [i.2] and its intended upgrade, still in draft at [i.3], make wide use of public-key
cryptography supported by PKI to provide key establishment and authentication services. These are currently based on
the well-known factoring or discrete logarithm primitives Rivest Shamir Adelman (RSA), Diffie-Hellman (DH), Digital
Signature Algorithm (DSA), Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm
(ECDSA) and it is precisely these primitives that need to be upgraded to be quantum-safe. Since TLS is so widely used,
it is here that the best and most modern primitives to provide secure and efficient quantum-safe replacements for the
current Public Key Cryptographic (PKC) protocols will need to be deployed.
TLS also makes use of symmetric cryptography e.g. the block cipher Advanced Encryption Standard (AES) for data
encryption and the Secure Hash Algorithm (SHA) for digital signatures and certificate verification. Since these
primitives may be regarded as already quantum-safe, or easily upgraded to be quantum-safe by increasing key or block
sizes, they will not be discussed further here and the focus will instead be on the public-key primitives.
ETSI
11 ETSI GR QSC 003 V1.1.1 (2017-02)
There have been three main approaches suggested so far for possible migration paths for upgrading TLS to incorporate
quantum-safe primitives.
NOTE: The large amount of work required to define new cipher suites or upgrade any other infrastructure
required to support quantum safe primitives is not discussed here.
5.2.2 Drop-in replacement
The most straightforward proposal is to replace some or all of the current public-key primitives with like-for-like
quantum-safe drop-in replacements, assuming that suitable alternatives with similar security levels and efficiency
properties are available. A promising example of this approach is the Ring Learning With Errors proposal [i.4]. An
early proof of concept demonstration [i.5] integrated a version of this scheme into OpenSSL and compared this against
standard TLS using elliptic curve cryptography. The authors reported that that their preliminary constant run-time
implementation looked practical, producing a typical reduction of 1.2x in throughput for serving HTTPS connections.
More recent implementations [i.6] and [i.7] report greatly increased throughputs of 8x-20x over [i.5] and halve the
communications overhead, for the same 128-bit security level. These papers all include security, soundness and
implementation analysis for the schemes presented.
5.2.3 Hybrid scheme
A second proposal is to introduce hybrid schemes which derive an encryption key from some combination of the
outputs from a well-studied and trusted classical key agreement scheme and a separate and perhaps novel quantum-safe
key agreement scheme. This might be a viewed as an interim step in the migration to using purely quantum-safe
cryptography, or as a way of providing extra functionality or security. One such example for TLS is Quantum Safe
Hybrid (QSH) [i.8] which proposes combining a standard classical TLS handshake with an NTRUEncrypt key
transport. An initial implementation for TLS 1.2 reports a similar reduction in throughput of just 1.2x for the 128-bit
security level.
NOTE: These figures are based on an implementation in WolfSSL using NTRUEncrypt parameter set eess439ep1
for 128 bits of classical security. In this case, typical timings give ECDHE-ECDSA-AES256-SHA384
with QSH taking 9,31 ms compared with 7,48 ms for the original classical TLS 1.2 ECDHE-ECDSA-
AES256-SHA384 exchange.
Another example of a hybrid architecture is presented in [i.9].
5.2.4 Re-engineering
A more radical approach would be to re-engineer the infrastructure of the internet and use a systems engineering
approach to mitigate performance issues and allow larger key sizes to be handled. One such proposal for TLS is [i.10]
which envisions using session resumption techniques to minimize the transmission and storage of large public keys
between peers on a network, together with using symmetric keys supplied by trusted servers to secure individual
sessions. Clearly it would be major undertaking to migrate for the entire Internet to a new architecture such as this but
this approach might be more suitable for smaller networks.
5.3 Discussion
5.3.1 Integration into the protocol stack
This first example already serves to highlight some important points for developers considering how to deploy quantum
safe cryptography.
A considerable amount of work will be required to integrate quantum-safe cryptography into real-world systems.
Hybrid key exchanges are not always allowed by network protocols or they may not fit into the bandwidth currently
allocated for handshakes [i.11] and even the apparently straightforward "drop in replacement" approach would require
new cipher suites and other infrastructure to be defined.
ETSI
12 ETSI GR QSC 003 V1.1.1 (2017-02)
Quantum-safe primitives with very large public keys initially seem unsuitable for widespread deployment using the
"drop in" approach as there are often restrictions on packet size, handshake size or other bandwidth issues. In
clause 4.3.3 of the ETSI whitepaper introducing quantum-safe cryptography [i.1] TLS record fragment size was raised
as a possible technical concern. This concern was also raised in the TLS 1.2 specification [i.2], where it was
recommended that protocol implementations should fragment and reassemble the handshake protocol messages
correctly. The specification further noted that the method of fragmentation and reassembly is an implementation detail,
i.e. how this is done would be left up to the implementer, but may have an impact on its performance and
interoperability. Going forward proper fragmentation and re-assembly of handshake messages will be crucial in
ensuring the eventual migration to quantum-safe security.
TLS packet fragmentation works over TCP which is a synchronized connection oriented protocol. That is, TCP presents
data as a stream to TLS. Likewise TLS presents data as a stream to applications (e.g. HTTP).The situation is drastically
different with UDP since this is a packet oriented protocol. Applications over UDP (e.g. IKE or DTLS) need to supply
their own fragmentation layer.
The available computational resources of emerging technologies is an important consideration: it is very different to
perform cryptographic mathematics on a server-class machine than an embedded processor in a smartphone, heart-rate
monitor or other resource-constrained device; see clause 7.5 for more discussion. The network architecture and the
impact of any latency introduced by the processing of post quantum crypto primitives on the timeout requirements are
other factors to be considered. Although the TLS protocol itself does not specify any timeout constraints, the
computational cost of key pair generation, shared secret derivation, encryption/decryption, and/or signature generation
and validation may affect the underlying protocol.
In cases where a cryptographic operation requires more time to complete than the configured connection timeout at the
transport or application layer, the connection will close before the handshake is completed. Generating and transporting
large public keys may become an important issue in low data-rate or low quality networks.
5.3.2 Handling large key sizes
Suppose a developer wanted to set up a "high security" TLS 1.2 network based on quantum safe primitives with very
large parameters, such as a code-based key transport scheme and a hash-based signatures (see ETSI GR QSC 001 [i.12]
for options here and information on parameter sizes).
The handshake component of TLS is the only one that is affected by the replacement of the classic public-key
primitives with quantum-safe equivalents. It is responsible for algorithm negotiation, peer authentication, and
symmetric key establishment. The entire handshake is completed in two message sequence round-trips, comprising four
messages between the client and server [i.2]. In the case of classic cryptographic algorithms, handshake messages are
typically always smaller than the maximum record size, and therefore do not require fragmentation. In the case of code-
based key transport scheme and a hash-based signature these messages would dramatically increase in size. This may
require message fragmentation by the Record Layer component, to accommodate messages larger than the maximum
specified record size.
There are three Handshake component messages that are directly impacted by the quantum-safe primitives, due to the
increased public key, signature and ciphertext sizes:
• Certificate message is sent by the server, and optionally the client. This message typically carries the entire
certificate chain starting with the end entity certificate, followed by zero or more intermediate certificates, and
optionally ending with the root certificate.
• ServerKeyExchange message is sent by the server. This message contains the server's public key-establishment
key, along with the signature of that key.
• ClientKeyExchange message is sent by the client. In the case of key agreement, this message carries client's
public key-agreement keys. In the case of key transport, it carries the client-generated pre-master secret
encrypted with the server's public encryption key.
Authentication: Although the private signing key may be very large, it has no impact on the TLS protocol because it is
not transmitted, in whole or in part, during the handshake. The root public key size also does not produce any impact
the TLS protocol, as its size is comparable to the current classic primitives' public key sizes. Signature size, on the other
hand, will significantly increase the size of the certificates and the size of the signed digest in the key establishment
messages. This means that the Certificate and ServerKeyExchange messages will grow in size, and this may require
message fragmentation.
ETSI
13 ETSI GR QSC 003 V1.1.1 (2017-02)
Key agreement: Fragmentation may also be a practical issue for code-based key agreement. On the client side, a
generated pre-master secret will be encrypted with public key before it is sent to the server in the ClientKeyExchange
message. If the message exceeds the record size limit if 16 kilo-octets it will be fragmented. Code-based keys are not
only very large but they take a relatively long time to generate. In practice, hello messages larger than 1 kilo-octet will
like to increase the connection error to an unacceptable level. This suggests that further investigation may be needed to
understand fragmentation limits of the various implementations of TLS.
Forward security: High security TLS networks may also require forward secrecy, which is not typically an inherent
characteristic of key transport schemes [i.12]. Cipher suites that do not provide forward secrecy are considered insecure
and many have been disabled by commercial web browsers. (This may not be a problem if the network is isolated from
the public Internet and uses bespoke software.) However it may sometimes be possible to add forward security in the
following way: Generate a public-private key pair on the server side and send the signed public key to the client. After
verifying the signature, send to the server the pre-master secret encrypted with server's public key. This behaviour can
be specified in the ciphersuite description and is permitted by TLS. Note however that the generation of an ephemeral
key pair will introduce some latency which in some cases trigger could time-outs.
5.3.3 Is quantum-safe authentication required today?
A common model for distinguishing between two types of quantum threat is to classify potential adversaries as either
passive or active attackers. A passive attacker is capable of recording current network traffic and will break out the
secret session key when quantum computers becomes available at some point in the future, while an active attacker is
assumed to have access to a quantum computer and can therefore break the authentication and forge a certificate today.
The communication is compromised even though the session key may itself be derived via a quantum-safe channel.
Although confidentiality and authentication are equally important in providing secure communications, under this
model quantum-safe confidentiality is seen as a matter that needs to be addressed today, while quantum-safe
authentication is not strictly needed until the day quantum computers arrive. Hence under this view there are two steps
to achieve quantum safety: protecting current public key-based handshakes against passive attackers, and adding
quantum-safe authentication, possibly at a later date. Both of the first two proposals [i.5] and [i.8] are content to retain
using current (non quantum-safe) digital signatures such as RSA or ECDSA to provide authentication for TLS.
See clause 10 for more discussion on quantum safe authentication.
6 Offline services
6.1 Secure e-mail
While much of the public discussion so far with regards to the need for quantum safe cryptography has focused on
interactive communications such as TLS or other network protocols, there has been rather less emphasis on off-line
applications like secure e-mail, based for example on S/MIME [i.13]. Here it the receiver is not assumed to be on-line at
the time of sending a message and so two-way, interactive key establishment protocols are not appropriate.
S/MIME is often used by governments and enterprises to ensure the security of e-mail communications which may
contain details of strategic plans, health records, human resources information, military planning, or similar information
which requires long term security.
The main difference that secure e-mail has over interactive protocols like TLS is the reliance on the fact that the
receiving party already has a certificate, and hence, a public key in place to use for key establishment to achieve
one-pass protocol. Protocols such as S/MIME use public key encryption or static key exchange for key establishment,
with the static public key contained in a certificate to provide its authenticity. Key transport schemes, such as McEliece
(see ETSI GR QSC 001 [i.12] for a survey of key transport options) are usually considered most appropriate to be used
in offline scenarios and fit very well with the assumed functionality of typical secure e-mail applications. One practical
drawback of many simple key transport schemes, is the loss of perfect forward secrecy, however it is often possible to
overcome this in practical scenarios if the public keys are not too large and they can be generated efficiently. Other
possibilities to consider are identity-based schemes, see clause 11.1.
ETSI
14 ETSI GR QSC 003 V1.1.1 (2017-02)
6.2 Credentials for offline services
For many offline applications authentication via general-purpose signature algorithms such as lattice signatures or
similar constructions for will be appropriate.
Hash-based signatures need to be used carefully to ensure that the consumption of state is monitored closely [i.14]; this
implies a need for updating end-entity certificates on a periodic basis. One such model for updating credentials is
already commonly used in the context of time-based expiration schemes for certificates, however things are much more
challenging in applications where fixed hardware tokens like smart cards are used for credential storage. Pol
...