Which hashing algorithm is recommended for the protection of sensitive unclassified information select one?

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.

An 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 and 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.

For further information, please contact us:
Cyber Centre Contact Centre

613-949-7048 or 1-833-CYBER-88

Table of contents

• 1 Introduction
  • 1.1 Practitioner notes
  • 1.2 Policy drivers
  • 1.3 Relationship to the IT risk management process
• 2 Encryption algorithms
  • 2.1 Advanced encryption standard algorithm
  • 2.2 Triple data encryption algorithm
  • 2.3 CAST5
• 3 Encryption algorithm modes of operation
  • 3.1 Protecting the confidentiality of information
  • 3.2 Protecting the confidentiality and authenticity of information
• 4 Key establishment schemes
  • 4.1 Rivest-shamir-adleman (RSA)
  • 4.2 Finite Field Cryptography (FFC) Diffie-Hellman (DH) and Menezes-Qu-Vanstone (MQV)
  • 4.3 Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH)and Menezes-Qu-Vanstone (ECC-MQV)
• 5 Digital signature schemes
  • 5.1 RSA
  • 5.2 Digital Signature Algorithm (DSA)
  • 5.3 Stateful hash-based signature schemes
• 6 Secure hash algorithms (SHAs)
  • 6.1 SHA-1
  • 6.2 SHA-2
  • 6.3 SHA-3
• 7 Message Authentication Codes (MAC)
  • 7.1 Keyed-Hash Message Authentication Code (HMAC)
  • 7.2 Cipher-based Message Authentication Code (CMAC)
  • 7.3 Galois/Counter Mode Message Authentication Code (GMAC)
• 8 Key Derivation Functions (KDF)
  • 8.1 One-step KDF
  • 8.2 Two-step KDF
  • 8.3 Key derivation using pseudorandom functions
  • 8.4 Internet Key Exchange version 2 (IKEv2) KDF
  • 8.5 Transport Layer Security version 1.2 (TLS 1.2) KDF
  • 8.6 Secure Shell (SSH) KDF
  • 8.7 Secure Real-time Transport Protocol (SRTP) KDF
  • 8.8 Trusted Platform Module (TPM) KDF
  • 8.9 Password-Based Key Derivation Function (PBKDF)
• 9 Key wrap modes of operation
  • 9.1 AES Key Wrap (KW)
  • 9.2 AES Key Wrap with Padding (KWP)
  • 9.3 Triple Data Encryption Algorithm Key Wrap (TKW)
• 10 Deterministic Random Bit Generators (DRBGs)
• 11 Commercial technologies assurance programs
• 12 Preparing for post quantum cryptography
• 13 Summary
  • 13.1 Contacts and assistance
• 14 Supporting Content
  • 14.1 List of abbreviations
  • 14.2 Glossary
  • 14.3 References

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 this document are recommended cryptographic mechanisms for protecting the confidentiality and integrity of sensitive UNCLASSIFIED, PROTECTED A, and PROTECTED B information to the medium injury level, as defined in the Cyber Centre’s ITSG-33 IT security risk management: A lifecycle approach Footnote 1. For requirements on the use of Cyber Centre approved cryptography to protect PROTECTED C and Classified information, refer to the Cyber Centre’s ITSD-01A: IT Security Directive for the Application of Communications Security using CSE-Approved Solutions Footnote 2.

This document complements the Treasury Board of Canada Secretariat (TBS) Guideline on Defining Authentication Requirements Footnote 3. 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 7.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 4.

1.3 Relationship to the IT risk management process

The Cyber Centre’s ITSG-33 IT security risk management: A lifecycle approach Footnote 1 guidelines suggest a set of activities at two levels within an organization: the departmental level and the information system level.

Figure 1: IT Security risk management process

Figure 1 depicts the IT security risk management process that is suggested in ITSG-33 Annex 1 and 2. The figure shows that IT security risk management activities are orchestrated at two distinct levels: the organizational level and the information system level.

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

• Define organizational IT security needs and security controls
• Deploy security controls
• Monitor and Assess performance of security controls - maintain
• Identify security control updates

Figure 1 depicts the IT security risk management process that is suggested in ITSG-33 Annex 1 and 2. The figure shows that IT security risk management activities are orchestrated at two distinct levels: the organizational level and the information system level.

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

• Define organizational IT security needs and security controls
• Deploy security controls
• Monitor & Assess performance of security controls - maintain
• Identify security control updates

The key deliverables of the deploy security controls activity are organizational control profiles and organizational 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
• Dispose of IT assets securely at retirement

Information from the operations and maintenance activities provide feedback into the monitor and assess activity at the organizational 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 of 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; and,
• 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 of ITSG-33.

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 be phased out by 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) Publication 197: Advanced Encryption Standard Footnote 5 with key lengths of 128, 192, and 256 bits.

2.2 Triple data encryption algorithm

The use of 3-key TDEA should be phased out by the end of 2023.

We no longer recommend the 3-key option of the Triple Data Encryption Algorithm (TDEA) as specified in NIST Special Publication (SP) 800-67 Revision 2: Recommendation for the Triple Data Encryption Algorithm Block Cipher Footnote 6. Note the important restriction that one key bundle should not be used to encrypt more than 220 64-bit data blocks Footnote 6.

2.3 CAST5

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

We no longer recommend the CAST5 algorithm as specified in Request for Comments (RFC) 2144 The CAST-128 Encryption Algorithm Footnote 7.

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 8:

• 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 9). It should not be used for bulk data encryption;
• Cipher Feedback (CFB);
• Output Feedback (OFB);
• Counter (CTR); and
• 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. Protocols typically specify particular padding methods that may be used. If no padding method is specified, we recommend the following modes from the Addendum to NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode Footnote 9:
  • CBC-CS1;
  • CBC-CS2; and
  • CBC-CS3.

Note several important requirements from NIST SP 800 38A: Recommendation for Block Cipher Modes of Operation – Methods and Techniques Footnote 8:

• 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 counterblock 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 10.

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 11; and
• Galois/Counter Mode (GCM) as specified in NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode Footnote 12.

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 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 13 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 (FFC) Diffie-Hellman (DH) 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 14. 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 (ECC CDH)and Menezes-Qu-Vanstone (ECC-MQV)

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 NIST SP 800-56A Revision 3: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography Footnote 14 with an elliptic curve from Table 24 and a field size of at least 224 bits.

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

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.

5.1 RSA

We recommend the RSA digital signature scheme as specified in NIST FIPS 186-4: Digital Signature Standard Footnote 15 and RSA PKCS #1 v2.2: RSA Cryptography 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)

We 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.

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

5.3 Elliptic Curve Digital Signature Algorithm (ECDSA)

We recommend the Elliptic Curve Digital Signature Algorithm (ECDSA) as specified in NIST FIPS 186-4: Digital Signature Standard Footnote 15 with an elliptic curve from Appendix D of NIST FIPS 186-4: Digital Signature Standard Footnote 15 and a field size of at least 224 bits.

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

5.4 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 quantum-resistant signature scheme must be implemented in the near future, before other general-purpose quantum-resistant signature schemes are standardized (see Section 12);
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:

• Leighton-Micali Signature (LMS);
• Hierarchical Signature System (HSS);
• eXtended Merkle Signature Scheme (XMSS); and
• Multi-tree eXtended Merkle Signature Scheme (XMSSMT).

6 Secure hash algorithms (SHAs)

The following section outlines the Secure Hash Algorithms (SHAs) 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: 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.

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 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.

7.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.

7.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.

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

7.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 12. GMAC is only recommended for use with the AES algorithm as specified in Section 2.1.

8 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.

8.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 22.

8.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 22. Note that the Transport Layer Security version 1.3 (TLS 1.3) protocol uses this KDF.

8.3 Key derivation using pseudorandom functions

We recommend the KDFs using Pseudorandom Functions (PRFs) as specified in NIST SP 800-108: Recommendation for Key Derivation Using Pseudorandom Functions Footnote 23.

8.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 24.

8.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 24.

8.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 24.

8.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 24.

8.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 24.

8.9 Password-Based Key Derivation Function (PBKDF)

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 25 for protecting data on storage devices.

9 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.

9.1 AES Key Wrap (KW)

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 26.

9.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 26.

9.3 Triple Data Encryption Algorithm Key Wrap (TKW)

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 26, which was previously approved with a key length of 168 bits.

TKW with a key length of 168 bits should be phased out by the end of 2023.

10 Deterministic Random Bit Generators (DRBGs)

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

• Hash_DRBG;
• HMAC_DRBG; and
• CTR_DRBG.

11 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 28;
2. Cryptographic modules should be tested and validated under the Cryptographic Module Validation Program (CMVP) for compliance to FIPS 140-3: Security Requirements for Cryptographic Modules Footnote 29; and
3. Information technology security products should be evaluated and certified to meet the Common Criteria standard Footnote 30 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 31 to ensure that only the Cyber Centre recommended algorithms are used.

12 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 quantum-resistant public-key cryptographic algorithms. The process is still underway, but all candidate algorithms are significantly different from current public key cryptosystems and the transition will require major software and hardware changes to current IT systems.

NIST is expecting to finalize standards by 2024. We will update the guidance in this document to address the quantum threat once standards are available. 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.4.

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

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

13 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.

13.1 Contacts and assistance

For more detailed information on Cryptographic Algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B information, please contact:

 Telephone: 613-949-7048 or 1‑833‑CYBER‑88
 E-mail: 

14 Supporting content

14.3 References