Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B information - ITSP.40.111

Overview

This document identifies and describes recommended cryptographic algorithms and appropriate methods of use that organizations can implement to protect sensitive information. For Government of Canada (GC) departments and agencies, the guidance in this document applies to UNCLASSIFIED, PROTECTED A, and PROTECTED B information.

Your organization’s ability to protect sensitive data and information is fundamental to the delivery of programs and services. Cryptography provides security mechanisms which can be used to protect the authenticity, confidentiality, and integrity of information.

Data authenticity, confidentiality, integrity, stakeholder authentication and accountability, and non-repudiation are all benefits of properly configured cryptography. Several algorithms may be required to satisfy these security requirements, and each algorithm should be selected and implemented to ensure these requirements are met.

1 Introduction

Organizations rely on Information Technology (IT) systems to achieve business objectives. These interconnected systems can be the targets of serious threats and cyberattacks that jeopardize the availability, authenticity, confidentiality, and integrity of the information assets. Compromised networks, systems, or information can have adverse effects on business activities and may result in data breaches and financial loss.

This document aids technology practitioners in choosing and appropriately using cryptographic algorithms. When used with valid domain parameters and specific key lengths, the cryptographic algorithms listed in this document are recommended cryptographic mechanisms for protecting the authenticity, confidentiality, and integrity of sensitive UNCLASSIFIED, PROTECTED A, and PROTECTED B information to the medium injury level, as defined in the Cyber Centre’s IT Security Risk Management: A Lifecycle Approach (ITSG-33)^{Footnote 1}. For requirements on the use of Cyber Centre approved cryptography to protect PROTECTED C and Classified information, contact the Cyber Centre by email at contact@cyber.gc.ca.

This document complements the Treasury Board of Canada Secretariat (TBS) Guideline on Defining Authentication Requirements^{Footnote 2}. Organizations are responsible for determining their security objectives and requirements as part of their risk management framework.

1.1 Practitioner notes

In this document we make recommendations for cryptographic algorithms and parameters. We also list algorithms that should be “phased out” of use. New applications should not use these algorithms. Where these algorithms are used in existing applications, they should be replaced with algorithms that we recommend in this document. For certain algorithms we specify a date by which these algorithms should have been replaced. In other instances, these algorithms should be replaced as soon as possible.

Unless otherwise specified, when an algorithm requires a primitive, it should be chosen from those recommended in this document. For example, a hash function from Sections 6.2 or 6.3 should be used when using the Keyed-Hash Message Authentication Code (HMAC) from Section 8.1. Unless otherwise specified, when an algorithm requires a parameter, it should be chosen from those recommended in the given reference for the algorithm.

1.2 Policy drivers

The need to address and counter cyber threats and vulnerabilities currently threatening networks is a crucial step in securing networks, data, and assets. GC departments must ensure IT security policies and procedures are implemented in accordance with the TBS Policy on Government Security^{Footnote 3}.

1.3 Relationship to the IT risk management process

The Cyber Centre’s IT Security Risk Management: A Lifecycle Approach (ITSG-33)^{Footnote 1} guidelines suggest a set of activities at two levels within an organization: the departmental level and the information system level.

Long description - IT Security risk management process

This figure describes the high-level departmental IT security risk management process and associated activities, as well as the information system security risk management activities. It also highlights how the IT security risk management activities at both levels act together in a continuous cycle to efficiently maintain and improve the security posture of departmental information systems.

At the departmental level, the IT security risk management activities conducted by the departmental security authorities (e.g. CSO, ITSC) include:

• Define departmental IT security needs and security controls
• Deploy security controls
• Monitor and assess performance of security controls - maintain authorization
• Identify security control updates

The key deliverables of the deploy security controls activity are departmental control profiles and departmental IT threat assessment reports. These deliverables are key inputs into the security risk management activities at the information system level.

At the information system level, the IT security risk management activities conducted by IT project managers, security practitioners and developers include:

• Define IT security needs and security controls
• Design and develop or acquire information system with security
• Integrate, test, and install information system with security
• Operate, monitor, and maintain information systems with security
• Securely dispose of IT assets at retirement

Information from the operations and maintenance activities provide feed back into the monitor and assess activity at the departmental level. The IT security performance feedback supports the maintain authorization activity under the monitor and assess.

Departmental-level activities are integrated into the organization’s security program to plan, manage, assess, and improve the management of IT security-related risks faced by the organization. Cryptographic algorithms should be considered during the define, deploy, and monitor and assess activities. These activities are described in detail in Annex 1 - Departmental IT security risk management activities (ITSG-33)^{Footnote 1}.

Information system level activities are integrated into an information system lifecycle to ensure:

• IT security needs of supported business activities are met
• appropriate security controls are implemented and operating as intended
• continued performance of the implemented security controls is assessed, reported back, and acted upon to address any issues.

Cryptographic algorithms should be considered during all information system level activities. These activities are described in detail in Annex 2 - Information system security risk management activities (ITSG-33)^{Footnote 1}.

2 Encryption algorithms

The following section outlines the encryption algorithms that we recommend for protecting the confidentiality of UNCLASSIFIED, PROTECTED A, and PROTECTED B information. We also specify encryption algorithms that were recommended in a previous version of this document but should have been phased out by the end of 2023.

2.1 Advanced encryption standard algorithm

We recommend the Advanced Encryption Standard (AES) algorithm as specified in National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS) Information Processing Standards Publication 197: Advanced Encryption Standard^{Footnote 4} with key lengths of 128, 192, and 256 bits.

2.2 Triple data encryption algorithm

The use of 3-key Triple Data Encryption Algorithm (TDEA) should have been phased out by the end of 2023.

We no longer recommend the use of the TDEA specified in NIST SP 800-67 Revision 2: Recommendation for the Triple Data Encryption Algorithm Block Cipher^{Footnote 5}. Legacy applications still using the 3-key option of TDEA should note the important restriction that one key bundle should not be used to encrypt more than 2²⁰ 64-bit data blocks.

2.3 CAST5

The use of CAST5 should have been phased out by the end of 2023.

We no longer recommend the CAST5 algorithm specified in Request for Comments (RFC) 2144: The CAST-128 Encryption Algorithm^{Footnote 6}.

3 Encryption algorithm modes of operation

The following section outlines the encryption algorithm modes of operation that we recommend for use with the AES algorithm, as specified in Section 2.1.

3.1 Protecting the confidentiality of information

We recommend the following block cipher modes of operation for protecting the confidentiality of UNCLASSIFIED, PROTECTED A, and PROTECTED B information, as specified in NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation: Methods and Techniques^{Footnote 7}:

•  Electronic Codebook (ECB) – ECB mode is only suitable for situations where a single block of data is being encrypted or as specified in derived algorithms such as key wrapping (see Section 10). It should not be used for bulk data encryption
• Cipher Feedback (CFB)
• Output Feedback (OFB)
• Counter (CTR)
• Cipher Block Chaining (CBC) - When using CBC mode with a plaintext input of bit length greater than or equal to the block size, a padding method must be used as described in Appendix A of SP800-38A^{Footnote 7}. Protocols typically specify particular padding methods that may be used. If no padding method is specified, we recommend the following modes from NIST Addendum to SP 800-38A: Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode^{Footnote 8}:
  • CBC-CS1
  • CBC-CS2
  • CBC-CS3

Note several important requirements from SP800-38A^{Footnote 7}:

• the CBC and CFB modes require unpredictable Initialization Vectors (IVs)
• for OFB mode, the IV must be a nonce that is unique to each execution of the encryption operation. It does not need to be unpredictable
• the CTR mode requires a unique counter block for each block of plaintext ever encrypted under a given key, across all messages

For protecting data on storage devices, we recommend XTS-AES mode as specified in NIST SP 800-38E: Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices^{Footnote 9}.

3.2 Protecting the confidentiality and authenticity of information

We recommend the following modes of operation for protecting the confidentiality and authenticity of UNCLASSIFIED, PROTECTED A, and PROTECTED B information:

• Counter with Cipher Block Chaining Message Authentication Code (CCM) as specified in NIST SP 800–38C: Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality^{Footnote 10}
• Galois/Counter Mode (GCM) as specified in NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode^{Footnote 11}

4 Key establishment schemes

The following section outlines the key establishment schemes that we recommend for use with cryptographic algorithms for protecting UNCLASSIFIED, PROTECTED A, and PROTECTED B information.

4.1 Rivest-Shamir-Adleman (RSA)

We recommend the Rivest-Shamir-Adleman (RSA)-based key-transport and key-agreement schemes as specified in NIST SP 800-56B Revision 2: Recommendation for Pair-Wise Key-Establishment Schemes Using Integer Factorization Cryptography^{Footnote 12} with an RSA modulus length of at least 2048 bits.

The RSA modulus length should be increased to at least 3072 bits by the end of 2030.

4.2 Finite Field Cryptography Diffie-Hellman and Menezes-Qu-Vanstone (MQV)

We recommend the Finite Field Cryptography (FFC) Diffie-Hellman (DH) and FFC Menezes-Qu-Vanstone (MQV)-based key-agreement schemes with valid domain parameters for the FB or FC FFC parameter-size sets as specified in NIST SP 800-56A Revision 3: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography^{Footnote 13}. The field size (prime modulus parameter) should be at least 2048 bits.

The FFC field size should be increased to at least 3072 bits by the end of 2030.

4.3 Elliptic Curve Cryptography Cofactor Diffie-Hellman and Menezes-Qu-Vanstone

We recommend the Elliptic Curve Cryptography (ECC) Cofactor Diffie-Hellman (ECC CDH) and ECC Menezes-Qu-Vanstone (ECC MQV)-based key-agreement schemes as specified in the NIST SP 800-56A Revision 3: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography^{Footnote 13}. We recommend the following elliptic curves specified in the NIST SP 800-186: Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters^{Footnote 14}:

• Curve P-224
• Curve P-256
• Curve P-384
• Curve P-521

Curve P-224 should be phased out by the end of 2030.

We no longer recommend binary curves specified in Appendix D of NIST FIPS 186-4: Digital Signature Standard^{Footnote 15}.

All binary curves should be phased out by the end of 2030. A list of the curves to be phased out can be found in Section 3.3 of the NIST SP 800-186 Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters^{Footnote 14}.

5 Digital signature schemes

The following section outlines the algorithms that we recommend for digital signature applications providing data integrity and data origin authentication of UNCLASSIFIED, PROTECTED A, and PROTECTED B information. We also specify a digital signature scheme that was recommended in a previous version of this document but should be phased out by the end of 2030.

5.1 Rivest-Shamir-Adleman

We recommend the Rivest-Shamir-Adleman (RSA) Digital Signature Algorithm, using RSASSA-PKCS1-v1.5 or RSASSA-PSS, as specified in NIST FIPS 186-5: Digital Signature Standard^{Footnote 16} with an RSA modulus length of at least 2048 bits.

The RSA modulus length should be increased to at least 3072 bits by the end of 2030.

5.2 Digital Signature Algorithm (DSA)

The use of Digital Signature Algorithm (DSA) should be phased out by the end of 2030.

We no longer recommend the Digital Signature Algorithm (DSA) as specified in NIST FIPS 186-4: Digital Signature Standard^{Footnote 15} with valid domain parameters for a field size of at least 2048 bits.

5.3 Elliptic Curve Digital Signature Algorithm (ECDSA)

We recommend the Elliptic Curve Digital Signature Algorithm (ECDSA) and deterministic ECDSA^{Footnote *} as specified in NIST FIPS 186-5: Digital Signature Standard^{Footnote 16}. We recommend the following elliptic curves specified in NIST SP 800-186: Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters^{Footnote 14}:

• Curve P-224
• Curve P-256
• Curve P-384
• Curve P-521

Curve P-224 should be phased out by the end of 2030.

We no longer recommend binary curves specified in Appendix D of NIST FIPS 186-4: Digital Signature Standard^{Footnote 15}.

All binary curves should be phased out by the end of 2030. A list of the curves to be phased out can be found in Section 3.3 of NIST SP 800-186 Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters^{Footnote 14}.

5.4 Edwards-Curve Digital Signature Algorithm (EdDSA)

We recommend the Edwards-Curve Digital Signature Algorithm (EdDSA) as specified in NIST FIPS 186-5: Digital Signature Standard^{Footnote 16} with the following elliptic curves specified in NIST SP 800-186 Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters^{Footnote 14}:

• Edwards25519
• Edwards448

We do not recommend the prehash version HashEdDSA.

5.5 Stateful hash-based signature schemes

We recommend stateful hash-based signatures be used only in situations where all of the following apply:

1. when a post quantum signature scheme must be implemented in the near future, before other general-purpose post quantum signature schemes are standardized (see Section 13);
2. when the implementation will have a long lifetime and it will not be practical to transition to a new digital signature scheme once the implementation has been deployed;
3. when the slow key generation and signing computations are operationally acceptable; and,
4. when state management can be implemented.

In these situations, we recommend the following hash-based signature schemes as specified in NIST SP 800-208: Recommendation for Stateful Hash-based Signatures Scheme^{Footnote 17}, using one of the hash functions SHA-256, SHA-256/192, SHAKE256/256, SHAKE256/192 specified in Section 2.3 of^{Footnote 17}:

• Leighton-Micali Signature (LMS)
• Hierarchical Signature System (HSS)
• eXtended Merkle Signature Scheme (XMSS)
• Multi-tree eXtended Merkle Signature Scheme (XMSS^MT)

6 Hash functions

The following section outlines the hash functions that we recommend for use with the cryptographic algorithms specified in this publication for protecting UNCLASSIFIED, PROTECTED A, and PROTECTED B information.

6.1 SHA-1

We no longer recommend the use of SHA-1 as specified in NIST FIPS 180-4: Secure Hash Standard^{Footnote 18}, which was previously approved for use with keyed-hash message authentication codes, key derivation functions, and random bit generators.

SHA-1 must not be used with digital signature schemes, or any applications that require collision resistance. SHA-1 should be phased out for use in keyed-hash message authentication codes, key derivation functions, and random bit generators.

6.2 SHA-2

We recommend SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256 as specified in NIST FIPS 180-4: Secure Hash Standard^{Footnote 18} for use with digital signature schemes, keyed-hash message authentication codes, key derivation functions, and random bit generators. The truncated hash function SHA-256/192 specified in ^{Footnote 17} is only recommended for use with the stateful hash-based signature schemes listed in Section 5.5.

SHA-224 should be phased out by the end of 2030.

6.3 SHA-3

We recommend SHA3-224, SHA3-256, SHA3-384, and SHA3-512 as specified in NIST FIPS 202: SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions^{Footnote 19} for use with digital signature schemes, keyed-hash message authentication codes, key derivation functions, and random bit generators.

SHA3-224 should be phased out by the end of 2030.

7 Extendable-Output Functions (XOF)

The following section outlines the Extendable-Output Functions (XOFs) that we recommend for use with select cryptographic algorithms specified in this publication for protecting UNCLASSIFIED, PROTECTED A, and PROTECTED B information.

7.1 SHAKE

We recommend SHAKE128 and SHAKE256 as specified in NIST FIPS 202: SHA-3 Standard: Permutation Based Hash and Extendable-Output Functions^{Footnote 19} for use in the following:

• The digital signature schemes RSA (Section 5.1), ECDSA (Section 5.3) and EdDSA (Section 5.4)
• Stateful hash-based digital signature schemes in Section 5.5
• KMAC in Section 8.4

8 Message Authentication Codes (MAC)

The following sections outline the MAC algorithms that we recommend for data integrity and data origin authentication of UNCLASSIFIED, PROTECTED A, and PROTECTED B information.

8.1 Keyed-Hash Message Authentication Code (HMAC)

We recommend Keyed-Hash Message Authentication Code (HMAC) as specified in NIST FIPS 198-1: The Keyed-Hash Message Authentication Code^{Footnote 20} with a key length of at least 112 bits.

The key length should be increased to at least 128 bits by the end of 2030.

8.2 Cipher-based Message Authentication Code (CMAC)

We recommend Cipher-based Message Authentication Code (CMAC) as specified in NIST SP 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication^{Footnote 21} with a key length of at least 112 bits.

8.3 Galois/Counter Mode Message Authentication Code (GMAC)

We recommend Galois/Counter Mode Message Authentication Code (GMAC) as specified in NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode^{Footnote 11}. GMAC is only recommended for use with the AES algorithm as specified in Section 2.1.

8.4 KECCAK Message Authentication Code (KMAC)

We recommend KMAC128 and KMAC256 as specified in NIST SP 800-185: SHA3-Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash^{Footnote 22} with a key length of at least 112 bits.

The key length should be increased to at least 128 bits by the end of 2030.

9 Key Derivation Functions (KDF)

The following sections outline the KDF that we recommend for the derivation of cryptographic keys from key-establishment or pre-shared secrets, used for protecting UNCLASSIFIED, PROTECTED A and PROTECTED B information.

9.1 One-Step KDF

We recommend the One-Step Key Derivation Function (KDF) as specified in NIST SP 800-56C Revision 2: Recommendation for Key-Derivation Methods in Key-Establishment Schemes^{Footnote 23}.

9.2 Two-Step KDF

We recommend the Two-Step Extraction-then-Expansion Key Derivation procedure as specified in NIST SP 800-56C Revision 2: Recommendation for Key-Derivation Methods in Key-Establishment Schemes^{Footnote 23}. Note that the HKDF function used in the Transport Layer Security version 1.3 (TLS 1.3) protocol follows this specification.

9.3 Key derivation using pseudorandom functions

We recommend the KDFs using Pseudorandom Functions (PRFs) as specified in NIST SP 800-108 Revision 1: Recommendation for Key Derivation Using Pseudorandom Functions^{Footnote 24}.

9.4 Internet Key Exchange version 2 (IKEv2) KDF

When used in the context of the Internet Key Exchange version 2 (IKEv2) protocol, we recommend the IKEv2 KDF as specified in NIST SP 800-135 Revision 1: Recommendation for Existing Application-Specific Key Derivation Functions^{Footnote 25}.

9.5 Transport Layer Security version 1.2 (TLS 1.2) KDF

When used in the context of the Transport Layer Security version 1.2 (TLS 1.2) protocol, we recommend the TLS 1.2 KDF as specified in NIST SP 800-135 Revision 1: Recommendation for Existing Application-Specific Key Derivation Functions^{Footnote 25}.

9.6 Secure Shell (SSH) KDF

When used in the context of the Secure Shell (SSH) protocol, we recommend the SSH KDF as specified in NIST SP 800-135 Revision 1: Recommendation for Existing Application-Specific Key Derivation Functions^{Footnote 25}.

9.7 Secure Real-time Transport Protocol (SRTP) KDF

When used in the context of the Secure Real-time Transport Protocol (SRTP), we recommend the SRTP KDF as specified in NIST SP 800-135 Revision 1: Recommendation for Existing Application-Specific Key Derivation Functions^{Footnote 25}.

9.8 Trusted Platform Module (TPM) KDF

When used in the context of a Trusted Platform Module (TPM) session, we recommend the TPM KDF as specified in NIST SP 800-135 Revision 1: Recommendation for Existing Application-Specific Key Derivation Functions^{Footnote 25}.

9.9 Password-Based Key Derivation Function (PBKDF)

For protected data on storage devices, we recommend the Password-Based Key Derivation Function (PBKDF) as specified in NIST SP 800-132 Recommendation for Password-Based Key Derivation: Part 1: Storage Applications^{Footnote 26} using a password of at least 12 characters. For more information on passwords and passphrases, see Best Practices for Passphrases and Passwords (ITSAP.30.032)^{Footnote 27}.

10 Key wrap modes of operation

The following sections outline the key wrap modes of operation that we recommend for key wrapping to protect the confidentiality and integrity of cryptographic keys used for protecting UNCLASSIFIED, PROTECTED A and PROTECTED B information. We also specify a key wrap mode of operation that was recommended in a previous version of this document but should have been phased out by the end of 2023.

10.1 AES Key Wrap (KW)

When input is known to always be a multiple of 64-bits, we recommend the AES Key Wrap (KW) mode as specified in NIST SP 800-38F: Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping^{Footnote 28}.

10.2 AES Key Wrap with Padding (KWP)

When input is not a multiple of 64-bits, we recommend the AES Key Wrap with Padding (KWP) mode as specified in NIST SP 800-38F: Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping^{Footnote 28}.

10.3 Triple Data Encryption Algorithm Key Wrap (TKW)

The use of TKW should have been phased out by the end of 2023.

We no longer recommend the Triple Data Encryption Algorithm Key Wrap (TKW) mode as specified in NIST SP 800-38F: Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping^{Footnote 28}, which was previously approved with a key length of 168 bits.

11 Deterministic Random Bit Generators (DRBGs)

We recommend the following Deterministic Random Bit Generators (DRBGs) as specified in NIST SP 800-90A Revision 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators^{Footnote 29} for producing random bits for cryptographic applications that protect UNCLASSIFIED, PROTECTED A, and PROTECTED B information:

• Hash_DRBG
• HMAC_DRBG
• CTR_DRBG

The initial seed for a DRBG should contain entropy assessed to be at least 112 bits. We recommend that additional entropy be periodically added to the DRBG via the reseed function.

The assessed entropy of the initial seed for a DRBG should be increased to at least 128 bits by the end of 2030.

12 Commercial technologies assurance programs

In addition to using the cryptographic algorithms, parameters, and key lengths recommended in this document to ensure a suitable level of cryptographic security, we recommend the following with respect to implementation assurance programs:

1. Cryptographic algorithm implementations should be tested and validated under the Cryptographic Algorithm Validation Program (CAVP)^{Footnote 30}.
2. Cryptographic modules should be tested and validated under the Cryptographic Module Validation Program (CMVP)^{Footnote 31} for compliance to FIPS 140-3: Security Requirements for Cryptographic Modules^{Footnote 32}.
3. Information technology security products should be evaluated and certified to meet the Common Criteria standard^{Footnote 33} by a Certificate Authorizing Scheme that is a member of the international Common Criteria Recognition Arrangement.

Products containing cryptographic modules validated under the CMVP are referenced on CMVP module validation lists and are accompanied by a vendor-supplied, non-proprietary security policy document (see Selecting a CMVP Validated Product). The security policy document specifies the cryptographic security provided by a module and describes its capabilities, protection, and access controls. We recommend using the security policy document to select suitable cryptographic security products and to configure those products in FIPS Approved Mode of Operation as defined in Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program^{Footnote 34} to ensure that only the Cyber Centre recommended algorithms are used.

13 Preparing for post quantum cryptography

Quantum computers threaten to break the public key cryptosystems and weaken the symmetric cryptosystems that we currently use. Although quantum technologies are not yet powerful enough to break the cryptography recommended in this publication, there is significant research in the area. In 2016, NIST initiated a process to solicit, evaluate, and standardize post quantum public-key cryptographic algorithms. In July 2022, NIST announced the initial selections for standardization^{Footnote 35}, and we expect to include these in an update to this document once the standards are published.

NIST is expecting to finalize the first set of standards in 2024. In the meantime, we recommend the following high-level steps:

• Evaluate the sensitivity of your organization’s information and determine its lifespan to identify information that may be at risk (e.g., as part of on-going risk assessment processes)
• Review your IT lifecycle management plan and budget for potentially significant software and hardware updates
• Educate your workforce on the quantum threat
• Consider using Stateful Hash-based Signature schemes if you meet the criteria in Section 5.5.

For more detailed information on how to prepare, see Preparing your organization for the quantum threat to cryptography (ITSAP.00.017)^{Footnote 36}.

Organizations should wait until standards for post-quantum public-key encryption and signature schemes are finalized before using any candidate algorithm to protect information or systems.

14 Summary

Cryptography provides security mechanisms which can be used to protect the authenticity, confidentiality, and integrity of sensitive information. Several algorithms may be required to satisfy security requirements, and each algorithm should be selected and implemented to ensure these requirements are met. This publication provides guidance on the use of the Cyber Centre recommended cryptographic algorithms to protect UNCLASSIFIED, PROTECTED A, and PROTECTED B information.

15 Supporting content

15.3 References