NIST)  Quantum Computing Will Break Many Public-Key Cryptographic Algorithms/Schemes ◦ Key Agreement (E.G

Total Page:16

File Type:pdf, Size:1020Kb

NIST)  Quantum Computing Will Break Many Public-Key Cryptographic Algorithms/Schemes ◦ Key Agreement (E.G Post Quantum Cryptography Team Presenter: Lily Chen National Institute of Standards and Technology (NIST) Quantum computing will break many public-key cryptographic algorithms/schemes ◦ Key agreement (e.g. DH and MQV) ◦ Digital signatures (e.g. RSA and DSA) ◦ Encryption (e.g. RSA) These algorithms have been used to protect Internet protocols (e.g. IPsec) and applications (e.g.TLS) NIST is studying “quantum-safe” replacements This talk will focus on practical aspects ◦ For security, see Yi-Kai Liu’s talk later today ◦ Key establishment: ephemeral Diffie-Hellman ◦ Authentication: signature or pre-shared key Key establishment through RSA, DHE, or DH Client Server ◦ RSA – Client encrypts pre- master secret using server’s Client RSA public key Hello Server Hello Certificate* ◦ DHE – Ephemeral Diffie- ServerKeyExchange* Hellman CertificateRequest* ◦ DH – Client generates an ServerHelloDone ephemeral DH public value. Certificate* ClientKeyExchange* Pre-master secret is generated CertificateVerify* using server static public key {ChangeCipherSpec} Finished Server authentication {ChangeCipherSpec} ◦ RSA – implicit (by key Finished confirmation) ◦ DHE - signature Application data Application Data ◦ DH – implicit (by key confirmation) IKE ◦ A replacement of ephemeral Diffie-Hellman key agreement should have a fast key pair generation scheme ◦ If signatures are used for authentication, both signing and verifying need to be equally efficient TLS ◦ RSA - encryption replacement needs to have a fast encryption ◦ DHE – fast key pair generation and efficient signature verification ◦ DH – fast key pair generation Which are most important in practice? ◦ Public and private key sizes ◦ Key pair generation time ◦ Ciphertext size ◦ Encryption/Decryption speed ◦ Signature size ◦ Signature generation/verification time Not a lot of benchmarks in this area Lattice-based ◦ NTRU Encryption and NTRU Signature ◦ (Ring-based) Learning with Errors Code-based ◦ McEliece encryption and CFS signatures Multivariate ◦ HFE, psFlash , Quartz (a variant of HFE), Many more…. ◦ hash-based signatures ◦ isogeny-based schemes ◦ etc... All have their pros and cons Algorithm KeyGen Decrypt Encrypt Public Private Ciphertext Time* Key* Time Time Time Key Key Size Size Scaling Scaling (RSA (RSA (RSA Size (bits) (((bits)(bits) sign=1) sign=1) sign=1) (bits) NTRUEncrypt 10 0.1 0.1 ~3000 ~4000 ~3000 k2 k McEliece 5 1 0.02 651264 1098256 1660 k2 k2 QuasiQuasi----CyclicCyclic 5 1 0.02 4801 9602 9602 k2 k McEliece RSA 50 1 0.02 1024 1024 1024 k6 k3 DHDHDH 0.5 0.5 0.5 1024 160 1024 k4 k3 ECC 0.1 0.1 0.1 320 160 320 k2 k • Disclaimer – these are rough estimates for comparison purposes only, not benchmarks. Numbers are for 80 bits of security. * Time and key scaling ignore log k factors Algorithm KeyGen Sign Verify Limited Public Private Key Signature Time* Key *** Time Time Time Lifetime Key Size Size Size (bits) Scaling Scaling (RSA (((RSA(RSA (RSA ??? sign=1) sign=1) sign=1) WinternitzWinternitz----MerkleMerkle 200 1 0.2 220 368 15200 17024 k2 k2 signatures 10000 1 0.2 230 368 22304 18624 500000 2 0.2 240 368 29344 20224 GLP ssignaturesignatures 0.01 0.5 0.02 11800 1620 8950 k2 k (lattice(lattice----based)based) CFS signature 5 2000 0.02 9437184 ~15000000 144 exp(o(k)) exp(o(k)) (code based) Psflash signature 50 1 0.1 576992 44400 296 k3 k3 (multivariate) Quartz signature 100 2 0.05 126000 11500 80 k3 k3 (((multivariate)(multivariate) RSA 50 1 0.02 1024 1024 1024 k6 k3 DSA 0.5 0.5 0.5 1024 160 320 k4 k3 ECDSA 0.1 0.1 0.1 320 160 320 k2 k • Disclaimer – these are rough estimates for comparison purposes only, not benchmarks. Numbers are for 80 bits of security. * Time and key scaling ignore log k factors For the most of the potential PQC replacements, the times needed for encryption, decryption, signing, verification are acceptable Some key sizes are significantly larger than RSA and DL families with the current required security strength ◦ If the public keys do not need to be exchanged, it may not be a problem ◦ But long certificates have been considered as an implementation pitfall for TLS handshake Some ciphertext size and signature size are not quite plausible ◦ It may become a show stopper for the bandwidth/space limited environment Key pair generation time for the encryption schemes is not bad at all ◦ One-time encryption can be used to replace ephemeral DH for “perfect forward secrecy” No easy “drop-in” replacements ◦ Many factors need to be considered We need more time to study Would be nice to have more benchmarks We would like more input Questions? Comments? [email protected] NIST PQC Team: Lily Chen, Stephen Jorden, Yi-Kai Liu, Dustin Moody, Rene Peralta, Ray Perlner, Daniel Smith.
Recommended publications
  • Etsi Gr Qsc 001 V1.1.1 (2016-07)
    ETSI GR QSC 001 V1.1.1 (2016-07) GROUP REPORT Quantum-Safe Cryptography (QSC); Quantum-safe algorithmic framework 2 ETSI GR QSC 001 V1.1.1 (2016-07) Reference DGR/QSC-001 Keywords algorithm, authentication, confidentiality, security ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 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.
    [Show full text]
  • Circuit-Extension Handshakes for Tor Achieving Forward Secrecy in a Quantum World
    Proceedings on Privacy Enhancing Technologies ; 2016 (4):219–236 John M. Schanck*, William Whyte, and Zhenfei Zhang Circuit-extension handshakes for Tor achieving forward secrecy in a quantum world Abstract: We propose a circuit extension handshake for 2. Anonymity: Some one-way authenticated key ex- Tor that is forward secure against adversaries who gain change protocols, such as ntor [13], guarantee that quantum computing capabilities after session negotia- the unauthenticated peer does not reveal their iden- tion. In doing so, we refine the notion of an authen- tity just by participating in the protocol. Such pro- ticated and confidential channel establishment (ACCE) tocols are deemed one-way anonymous. protocol and define pre-quantum, transitional, and post- 3. Forward Secrecy: A protocol provides forward quantum ACCE security. These new definitions reflect secrecy if the compromise of a party’s long-term the types of adversaries that a protocol might be de- key material does not affect the secrecy of session signed to resist. We prove that, with some small mod- keys negotiated prior to the compromise. Forward ifications, the currently deployed Tor circuit extension secrecy is typically achieved by mixing long-term handshake, ntor, provides pre-quantum ACCE security. key material with ephemeral keys that are discarded We then prove that our new protocol, when instantiated as soon as the session has been established. with a post-quantum key encapsulation mechanism, Forward secret protocols are a particularly effective tool achieves the stronger notion of transitional ACCE se- for resisting mass surveillance as they resist a broad curity. Finally, we instantiate our protocol with NTRU- class of harvest-then-decrypt attacks.
    [Show full text]
  • Public Key Cryptography And
    PublicPublic KeyKey CryptographyCryptography andand RSARSA Raj Jain Washington University in Saint Louis Saint Louis, MO 63130 [email protected] Audio/Video recordings of this lecture are available at: http://www.cse.wustl.edu/~jain/cse571-11/ Washington University in St. Louis CSE571S ©2011 Raj Jain 9-1 OverviewOverview 1. Public Key Encryption 2. Symmetric vs. Public-Key 3. RSA Public Key Encryption 4. RSA Key Construction 5. Optimizing Private Key Operations 6. RSA Security These slides are based partly on Lawrie Brown’s slides supplied with William Stallings’s book “Cryptography and Network Security: Principles and Practice,” 5th Ed, 2011. Washington University in St. Louis CSE571S ©2011 Raj Jain 9-2 PublicPublic KeyKey EncryptionEncryption Invented in 1975 by Diffie and Hellman at Stanford Encrypted_Message = Encrypt(Key1, Message) Message = Decrypt(Key2, Encrypted_Message) Key1 Key2 Text Ciphertext Text Keys are interchangeable: Key2 Key1 Text Ciphertext Text One key is made public while the other is kept private Sender knows only public key of the receiver Asymmetric Washington University in St. Louis CSE571S ©2011 Raj Jain 9-3 PublicPublic KeyKey EncryptionEncryption ExampleExample Rivest, Shamir, and Adleman at MIT RSA: Encrypted_Message = m3 mod 187 Message = Encrypted_Message107 mod 187 Key1 = <3,187>, Key2 = <107,187> Message = 5 Encrypted Message = 53 = 125 Message = 125107 mod 187 = 5 = 125(64+32+8+2+1) mod 187 = {(12564 mod 187)(12532 mod 187)... (1252 mod 187)(125 mod 187)} mod 187 Washington University in
    [Show full text]
  • Ch 13 Digital Signature
    1 CH 13 DIGITAL SIGNATURE Cryptography and Network Security HanJung Mason Yun 2 Index 13.1 Digital Signatures 13.2 Elgamal Digital Signature Scheme 13.3 Schnorr Digital Signature Scheme 13.4 NIST Digital Signature Algorithm 13.6 RSA-PSS Digital Signature Algorithm 3 13.1 Digital Signature - Properties • It must verify the author and the date and time of the signature. • It must authenticate the contents at the time of the signature. • It must be verifiable by third parties, to resolve disputes. • The digital signature function includes authentication. 4 5 6 Attacks and Forgeries • Key-Only attack • Known message attack • Generic chosen message attack • Directed chosen message attack • Adaptive chosen message attack 7 Attacks and Forgeries • Total break • Universal forgery • Selective forgery • Existential forgery 8 Digital Signature Requirements • It must be a bit pattern that depends on the message. • It must use some information unique to the sender to prevent both forgery and denial. • It must be relatively easy to produce the digital signature. • It must be relatively easy to recognize and verify the digital signature. • It must be computationally infeasible to forge a digital signature, either by constructing a new message for an existing digital signature or by constructing a fraudulent digital signature for a given message. • It must be practical to retain a copy of the digital signature in storage. 9 Direct Digital Signature • Digital signature scheme that involves only the communication parties. • It must authenticate the contents at the time of the signature. • It must be verifiable by third parties, to resolve disputes. • Thus, the digital signature function includes the authentication function.
    [Show full text]
  • Presentation
    Side-Channel Analysis of Lattice-based PQC Candidates Prasanna Ravi and Sujoy Sinha Roy [email protected], [email protected] Notice • Talk includes published works from journals, conferences, and IACR ePrint Archive. • Talk includes works of other researchers (cited appropriately) • For easier explanation, we ‘simplify’ concepts • Due to time limit, we do not exhaustively cover all relevant works. • Main focus on LWE/LWR-based PKE/KEM schemes • Timing, Power, and EM side-channels Classification of PQC finalists and alternative candidates Lattice-based Cryptography Public Key Encryption (PKE)/ Digital Signature Key Encapsulation Mechanisms (KEM) Schemes (DSS) LWE/LWR-based NTRU-based LWE, Fiat-Shamir with Aborts NTRU, Hash and Sign (Kyber, SABER, Frodo) (NTRU, NTRUPrime) (Dilithium) (FALCON) This talk Outline • Background: • Learning With Errors (LWE) Problem • LWE/LWR-based PKE framework • Overview of side-channel attacks: • Algorithmic-level • Implementation-level • Overview of masking countermeasures • Conclusions and future works Given two linear equations with unknown x and y 3x + 4y = 26 3 4 x 26 or . = 2x + 3y = 19 2 3 y 19 Find x and y. Solving a system of linear equations System of linear equations with unknown s Gaussian elimination solves s when number of equations m ≥ n Solving a system of linear equations with errors Matrix A Vector b mod q • Search Learning With Errors (LWE) problem: Given (A, b) → computationally infeasible to solve (s, e) • Decisional Learning With Errors (LWE) problem: Given (A, b) →
    [Show full text]
  • Implementation and Performance Evaluation of XTR Over Wireless Network
    Implementation and Performance Evaluation of XTR over Wireless Network By Basem Shihada [email protected] Dept. of Computer Science 200 University Avenue West Waterloo, Ontario, Canada (519) 888-4567 ext. 6238 CS 887 Final Project 19th of April 2002 Implementation and Performance Evaluation of XTR over Wireless Network 1. Abstract Wireless systems require reliable data transmission, large bandwidth and maximum data security. Most current implementations of wireless security algorithms perform lots of operations on the wireless device. This result in a large number of computation overhead, thus reducing the device performance. Furthermore, many current implementations do not provide a fast level of security measures such as client authentication, authorization, data validation and data encryption. XTR is an abbreviation of Efficient and Compact Subgroup Trace Representation (ECSTR). Developed by Arjen Lenstra & Eric Verheul and considered a new public key cryptographic security system that merges high level of security GF(p6) with less number of computation GF(p2). The claim here is that XTR has less communication requirements, and significant computation advantages, which indicate that XTR is suitable for the small computing devices such as, wireless devices, wireless internet, and general wireless applications. The hoping result is a more flexible and powerful secure wireless network that can be easily used for application deployment. This project presents an implementation and performance evaluation to XTR public key cryptographic system over wireless network. The goal of this project is to develop an efficient and portable secure wireless network, which perform a variety of wireless applications in a secure manner. The project literately surveys XTR mathematical and theoretical background as well as system implementation and deployment over wireless network.
    [Show full text]
  • Key Improvements to XTR
    To appear in Advances in Cryptology|Asiacrypt 2000, Lecture Notes in Computer Science 1976, Springer-Verlag 2000, 220-223. Key improvements to XTR Arjen K. Lenstra1, Eric R. Verheul2 1 Citibank, N.A., Technical University Eindhoven, 1 North Gate Road, Mendham, NJ 07945-3104, U.S.A., [email protected] 2 PricewaterhouseCoopers, GRMS Crypto Group, Goudsbloemstraat 14, 5644 KE Eindhoven, The Netherlands, Eric.Verheul@[nl.pwcglobal.com, pobox.com] Abstract. This paper describes improved methods for XTR key rep- resentation and parameter generation (cf. [4]). If the ¯eld characteristic is properly chosen, the size of the XTR public key for signature appli- cations can be reduced by a factor of three at the cost of a small one time computation for the recipient of the key. Furthermore, the para- meter set-up for an XTR system can be simpli¯ed because the trace of a proper subgroup generator can, with very high probability, be com- puted directly, thus avoiding the probabilistic approach from [4]. These non-trivial extensions further enhance the practical potential of XTR. 1 Introduction In [1] it was shown that conjugates of elements of a subgroup of GF(p6)¤ of order 2 dividing Á6(p) = p ¡ p + 1 can be represented using 2 log2(p) bits, as opposed to the 6 log2(p) bits that would be required for their traditional representation. In [4] an improved version of the method from [1] was introduced that achieves the same communication advantage at a much lower computational cost. The resulting representation method is referred to as XTR, which stands for E±cient and Compact Subgroup Trace Representation.
    [Show full text]
  • Efficient Encryption on Limited Devices
    Rochester Institute of Technology RIT Scholar Works Theses 2006 Efficient encryption on limited devices Roderic Campbell Follow this and additional works at: https://scholarworks.rit.edu/theses Recommended Citation Campbell, Roderic, "Efficient encryption on limited devices" (2006). Thesis. Rochester Institute of Technology. Accessed from This Master's Project is brought to you for free and open access by RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. Masters Project Proposal: Efficient Encryption on Limited Devices Roderic Campbell Department of Computer Science Rochester Institute of Technology Rochester, NY, USA [email protected] June 24, 2004 ________________________________________ Chair: Prof. Alan Kaminsky Date ________________________________________ Reader: Prof. Hans-Peter Bischof Date ________________________________________ Observer: Prof. Leonid Reznik Date 1 1 Summary As the capstone of my Master’s education, I intend to perform a comparison of Elliptic Curve Cryptography(ECC) and The XTR Public Key System to the well known RSA encryption algorithm. The purpose of such a project is to provide a further understanding of such types of encryption, as well as present an analysis and recommendation for the appropriate technique for given circumstances. This comparison will be done by developing a series of tests on which to run identical tasks using each of the previously mentioned algorithms. Metrics such as running time, maximum and average memory usage will be measured as applicable. There are four main goals of Crypto-systems: Confidentiality, Data Integrity, Authentication and Non-repudiation[5]. This implementation deals only with confidentiality of symmetric key exchange.
    [Show full text]
  • Overview of Post-Quantum Public-Key Cryptosystems for Key Exchange
    Overview of post-quantum public-key cryptosystems for key exchange Annabell Kuldmaa Supervised by Ahto Truu December 15, 2015 Abstract In this report we review four post-quantum cryptosystems: the ring learning with errors key exchange, the supersingular isogeny key exchange, the NTRU and the McEliece cryptosystem. For each protocol, we introduce the underlying math- ematical assumption, give overview of the protocol and present some implementa- tion results. We compare the implementation results on 128-bit security level with elliptic curve Diffie-Hellman and RSA. 1 Introduction The aim of post-quantum cryptography is to introduce cryptosystems which are not known to be broken using quantum computers. Most of today’s public-key cryptosys- tems, including the Diffie-Hellman key exchange protocol, rely on mathematical prob- lems that are hard for classical computers, but can be solved on quantum computers us- ing Shor’s algorithm. In this report we consider replacements for the Diffie-Hellmann key exchange and introduce several quantum-resistant public-key cryptosystems. In Section 2 the ring learning with errors key exchange is presented which was introduced by Peikert in 2014 [1]. We continue in Section 3 with the supersingular isogeny Diffie–Hellman key exchange presented by De Feo, Jao, and Plut in 2011 [2]. In Section 5 we consider the NTRU encryption scheme first described by Hoffstein, Piphe and Silvermain in 1996 [3]. We conclude in Section 6 with the McEliece cryp- tosystem introduced by McEliece in 1978 [4]. As NTRU and the McEliece cryptosys- tem are not originally designed for key exchange, we also briefly explain in Section 4 how we can construct key exchange from any asymmetric encryption scheme.
    [Show full text]
  • Making NTRU As Secure As Worst-Case Problems Over Ideal Lattices
    Making NTRU as Secure as Worst-Case Problems over Ideal Lattices Damien Stehlé1 and Ron Steinfeld2 1 CNRS, Laboratoire LIP (U. Lyon, CNRS, ENS Lyon, INRIA, UCBL), 46 Allée d’Italie, 69364 Lyon Cedex 07, France. [email protected] – http://perso.ens-lyon.fr/damien.stehle 2 Centre for Advanced Computing - Algorithms and Cryptography, Department of Computing, Macquarie University, NSW 2109, Australia [email protected] – http://web.science.mq.edu.au/~rons Abstract. NTRUEncrypt, proposed in 1996 by Hoffstein, Pipher and Sil- verman, is the fastest known lattice-based encryption scheme. Its mod- erate key-sizes, excellent asymptotic performance and conjectured resis- tance to quantum computers could make it a desirable alternative to fac- torisation and discrete-log based encryption schemes. However, since its introduction, doubts have regularly arisen on its security. In the present work, we show how to modify NTRUEncrypt to make it provably secure in the standard model, under the assumed quantum hardness of standard worst-case lattice problems, restricted to a family of lattices related to some cyclotomic fields. Our main contribution is to show that if the se- cret key polynomials are selected by rejection from discrete Gaussians, then the public key, which is their ratio, is statistically indistinguishable from uniform over its domain. The security then follows from the already proven hardness of the R-LWE problem. Keywords. Lattice-based cryptography, NTRU, provable security. 1 Introduction NTRUEncrypt, devised by Hoffstein, Pipher and Silverman, was first presented at the Crypto’96 rump session [14]. Although its description relies on arithmetic n over the polynomial ring Zq[x]=(x − 1) for n prime and q a small integer, it was quickly observed that breaking it could be expressed as a problem over Euclidean lattices [6].
    [Show full text]
  • DRAFT Special Publication 800-56A, Recommendation for Pair-Wise Key
    The attached DRAFT document (provided here for historical purposes) has been superseded by the following publication: Publication Number: NIST Special Publication (SP) 800-56A Revision 2 Title: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography Publication Date: 05/13/2013 • Final Publication: https://doi.org/10.6028/NIST.SP.800-56Ar2 (which links to http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf). • Information on other NIST Computer Security Division publications and programs can be found at: http://csrc.nist.gov/ The following information was posted with the attached DRAFT document: Aug 20, 2012 SP 800-56 A Rev.1 DRAFT Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography (Draft Revision) NIST announces the release of draft revision of Special Publication 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography. SP 800-56A specifies key-establishment schemes based on the discrete logarithm problem over finite fields and elliptic curves, including several variations of Diffie-Hellman and MQV key establishment schemes. The revision is made on the March 2007 version. The main changes are listed in Appendix D. Please submit comments to 56A2012rev-comments @ nist.gov with "Comments on SP 800-56A (Revision)" in the subject line. The comment period closes on October 31, 2012. NIST Special Publication 800-56A Recommendation for Pair-Wise August 2012 Key-Establishment Schemes Using Discrete Logarithm Cryptography (Draft Revision) Elaine Barker, Lily Chen, Miles Smid and Allen Roginsky C O M P U T E R S E C U R I T Y Abstract This Recommendation specifies key-establishment schemes based on the discrete logarithm problem over finite fields and elliptic curves, including several variations of Diffie-Hellman and MQV key establishment schemes.
    [Show full text]
  • Guidelines on Cryptographic Algorithms Usage and Key Management
    EPC342-08 Version 7.0 4 November 2017 [X] Public – [ ] Internal Use – [ ] Confidential – [ ] Strictest Confidence Distribution: Publicly available GUIDELINES ON CRYPTOGRAPHIC ALGORITHMS USAGE AND KEY MANAGEMENT Abstract This document defines guidelines on cryptographic algorithms usage and key management. Document Reference EPC342-08 Issue Version 7.0 Date of Issue 22 November 2017 Reason for Issue Maintenance of document Produced by EPC Authorised by EPC Document History This document was first produced by ECBS as TR 406, with its latest ECBS version published in September 2005. The document has been handed over to the EPC which is responsible for its yearly maintenance. DISCLAIMER: Whilst the European Payments Council (EPC) has used its best endeavours to make sure that all the information, data, documentation (including references) and other material in the present document are accurate and complete, it does not accept liability for any errors or omissions. EPC will not be liable for any claims or losses of any nature arising directly or indirectly from use of the information, data, documentation or other material in the present document. Conseil Européen des Paiements AISBL– Cours Saint-Michel 30A – B 1040 Brussels Tel: +32 2 733 35 33 – Fax: +32 2 736 49 88 Enterprise N° 0873.268.927 – www.epc-cep.eu – [email protected] © 2016 Copyright European Payments Council (EPC) AISBL: Reproduction for non-commercial purposes is authorised, with acknowledgement of the source Table of Content MANAGEMENT SUMMARY ............................................................. 5 1 INTRODUCTION .................................................................... 7 1.1 Scope of the document ...................................................... 7 1.2 Document structure .......................................................... 7 1.3 Recommendations ............................................................ 8 1.4 Implementation best practices .........................................
    [Show full text]