Algorithmes cryptographiques approuvés par le CSTC pour la protection des renseignements sensibles et pour les applications d'authentification et d'autorisation électroniques au sein du gouvernement du Canada



ITSA-11E | Mars 2011

Objet

L'objet de la présente ALERTE est de fournir aux ministères du gouvernement du Canada (GC) de l'information sur :

  • les algorithmes approuvés pour le chiffrement, l'établissement de clés, les signatures numériques, les fonctions de dérivation de clé, le transport des clés, l'enveloppement des clés et l'intégrité des données;
  • les algorithmes de hachage approuvés et la situation de l'algorithme Secure Hash Algorithm (SHA-1);
  • les protocoles de bourrage approuvés;
  • la génération de nombres aléatoires;
  • les initiatives futures dans le domaine de la cryptographie.

La présente ALERTE remplace l'ITSA-11D publiée en juillet 2008.

Transition de la cryptographie à 80 bits à la cryptographie à 112 bits

Dans les alertes ITSA-11C et ITSA-11D précédentes, on annonçait que la robustesse cryptographique de 80 bits allait être graduellement abandonnée avant la fin de 2010 pour être remplacée par une cryptographie d'au moins 112 bits. Or, le CSTC estime que l'environnement de menace en ce qui concerne l'information PROTÉGÉ A et PROTÉGÉ B ne justifie par une migration immédiate et obligatoire vers la cryptographie à 112 bits.

L'emploi autorisé de la cryptographie à 80 bits pour la protection de renseignements PROTÉGÉ A et PROTÉGÉ B est prolongé de 3 ans jusqu'à la fin de 2013. Toutefois, il est fortement recommandé de faire appel à une robustesse de sécurité minimale de 112 bits. Il est également recommandé que les nouvelles mises en œuvre n'utilisent pas d'algorithmes à 80 bits.

Les ministères du GC qui utilisent la cryptographie à 80 bits doivent accepter certains risques qui augmenteront au fil du temps. Cette acceptation des risques comprend l'utilisation de l'algorithme Triple DES à deux clés. Les risques augmentent en raison des progrès réalisés dans la puissance de calcul et d'une probabilité accrue que des faiblesses seront décelées au cours de recherches cryptanalytiques. C'est à l'utilisateur ou à son organisation que revient la responsabilité de déterminer le niveau de risque tolérable pour une application et les données connexes.

Prière de se reporter à l'appendice B de la publication spéciale 800-131A [i] du NIST pour les stratégies visant à atténuer les risques présentés par la cryptographie à 80 bits.

Le tableau 1 donne une comparaison des différents niveaux de robustesse des algorithmes mentionnés dans la présente alerte.

Tableau 1 : Comparaison de la robustesse des algorithmes mentionnés dans l'ITSA-11E

Bits de sécurité Algorithme à clé symétrique Algorithme de hachage Cryptographie à corps fini et à factorisation des nombres entiers Cryptographie à courbe elliptique
80 80-bit CAST5 SHA-1 1024 160
100 Triple DES à 2 clés [ii]      
112 Triple DES à 3 clés SHA-224 2048 224
128 AES-128
128-bit CAST5 		SHA-256 3072 256
192 AES-192 SHA-384 7680 384
256 AES-256 SHA-512 15360 512

Contexte

Les algorithmes cryptographiques et les paramètres connexes décrits ci-après s'appliquent aux services de confidentialité, d'intégrité et d'authentification mis en œuvre pour protéger les renseignements désignés PROTÉGÉ du GC et aux applications d'autorisation et d'authentification électroniques (AAE).

Pour assurer un degré convenable de sécurité cryptographique, il faut tenir compte d'autres facteurs en sus de l'utilisation d'algorithmes approuvés. Les versions d'algorithmes cryptographiques doivent être validées en vertu du Cryptographic Algorithm Validation Program (CAVP) afin d'assurer qu'elles respectent la norme précisée. Il est possible d'obtenir un niveau d'assurance additionnel pour le produit dans lequel est mis en œuvre l'algorithme au moyen d'une évaluation selon la norme FIPS 140-2 (ou la norme FIPS 140-3 subséquente) en vertu du Programme de validation des modules cryptographiques (PVMC) et des Critères communs. Il faut également tenir compte d'autres aspects de la sécurité, notamment l'initialisation (seeding) de générateurs de nombres aléatoires, l'environnement d'application et les menaces particulières pesant contre les applications. Pour plus de détails, prière de communiquer ave le CSTC.

La protection de l'information classifiée du GC dépasse les limites du présent document. Prière de se reporter à l'ITSB-40A du CSTC pour plus de détails sur la protection de l'information classifiée à l'aide des algorithmes cryptographiques Suite B.

Au moment de sélectionner un algorithme, il est important de considérer la période de temps pendant laquelle l'information doit être protégée. Un algorithme ne devrait être utilisé que s'il est acceptable pour toute la durée de la période de protection. À titre d'exemple, si des renseignements PROTÉGÉ B sont chiffrés en 2011 et qu'ils doivent demeurer sécurisés pendant 5 ans, l'algorithme CAST5 à 80 bits ne devrait pas être utilisé étant donné qu'il n'est pas approuvé au-delà de l'année 2013.

On entend par « cryptopériode » le laps de temps pendant lequel l'utilisation d'une clé particulière est autorisée.

Algorithmes de chiffrement

Le CSTC approuve l'utilisation des algorithmes de chiffrement suivants pour le chiffrement des renseignements désignés PROTÉGÉ avec les limites données plus bas :

  • AES (128, 192, 256 bits);
  • Triple DES (2 clés, 3 clés)
  • CAST5 (80, 128 bits)

Les algorithmes de chiffrement peuvent être utilisés avec l'un ou l'autre des modes opératoires donnés plus bas. La clé de chiffrement peut être établie à l'aide d'un des algorithmes présentés dans la rubrique Algorithmes d'établissement de clé plus bas.

  1. AES. La norme FIPS-197 2001 (Advanced Encryption Standard) du NIST donne la spécification de l'algorithme AES.

    La cryptopériode ne doit pas dépasser 7 jours.

  2. Triple DES. La norme ANSI X9.52-1998 (Triple Data Encryption Algorithm – Modes of Operation) et la publication spéciale 800-67 2004 du NIST (Recommendation for the Triple Data Encryption Algorythm [TDEA] Block Cipher) précisent les méthodes acceptables de mise en œuvre de l'algorithme Triple DES.

    La cryptopériode ne doit pas dépasser 7 jours.

    NOTA: L'option à trois clés offre la meilleure protection et est donc l'option de premier choix. L'option à deux clés est également acceptable à l'heure actuelle pour les renseignements PROTÉGÉ A et PROTÉGÉ B à condition que la clé utilisée pour le chiffrement final ait également servi au chiffrement initial. L'option à une seule clé, qui équivaut au DES, n'est pas approuvée par le CSTC pour protéger les renseignements désignés PROTÉGÉ du GC.

    L'utilisation de l'option à deux clés n'est pas acceptable pour les renseignements PROTÉGÉ C. L'utilisation de l'option à deux clés pour les renseignements PROTÉGÉ A et PROTÉGÉ B sera abandonnée d'ici la fin de 2015. L'option Triple DES à deux clés restreint à 2 20 blocs la taille des blocs de données pouvant être chiffrés au moyen de la même clé.

    L'utilisation de Triple DES à trois clés sera abandonnée d'ici la fin de 2025 pour les renseignements PROTÉGÉ C, et d'ici la fin de 2030 pour les renseignements PROTÉGÉ de tous les niveaux.

  3. CAST5. [iii] Les modes opératoires acceptables pour le CAST5 sont identiques à ceux précisés pour l'AES.

    La version à 128 bits du CAST5 est actuellement valide pour les renseignements PROTÉGÉ de tous les niveaux. Pour les renseignements PROTÉGÉ C, la version à 80 bits devrait avoir été abandonnée à la fin de 2005. Elle devra l'être d'ici la fin de 2013 pour les renseignements PROTÉGÉ A et PROTÉGÉ B.

Pour la version à 80 bits, la cryptopériode ne doit pas dépasser 24 heures. Elle ne doit pas dépasser 7 jours pour la version à 128 bits.

Modes opératoires

Les modes opératoires de chiffrement approuvés sont définis dans les publications spéciales 800-38A, 800-38B, 800-38C et 800-38D du NIST.

Les modes opératoires assurant la confidentialité pour les algorithmes AES, Triple DES et CAST5 sont le mode de dictionnaire (ECB pour Electronic Codebook), le mode d'enchaînement de blocs de chiffrement (CBC pour Cipher Block Chaining), le mode à rebouclage par le chiffre (CFB pour Cipher Feedback), le mode à rebouclage par la sortie (OFB pour Output Feedback) et le mode compteur (CTR pour Counter). Le mode de code d'authentification de message à base de fonction de chiffrement (CMAC pour Cipher-based Message Authentication Code) offre la confidentialité et l'authentification des données pour les algorithmes AES, Triple DES et CAST5.

Le mode compteur avec enchaînement de blocs de chiffrement – code d'authentification de message (CCM pour Counter with Cipher Block Chaining – Message Authentication Code), le mode compteur Galois (GCM pour Galois/Counter Mode) et le mode GMAC offrent la confidentialité et l'authentification des données pour les algorithmes AES et CAST5 à 128 bits.

Algorithmes d'établissement de clé

Les algorithmes d'établissement de clé créent un secret partagé qui est utilisé avec une fonction de dérivation de clé pour dériver une ou plusieurs clés à partir du secret partagé. Le CSTC autorise l'utilisation des algorithmes suivants pour l'établissement des clés de chiffrement :

  • RSA (Rivest, Shamir, Adleman)
  • autres algorithmes fondés sur l'exponentiation dans un corps fini (p. ex., Diffie-Hellman, MQV)
  • algorithmes à courbe elliptique

Les cryptopériodes doivent être approuvées par le CSTC au cas par cas.

  1. RSA. La publication spéciale 800-56b [iv] du NIST définit l'algorithme RSA. La taille du module doit être d'au moins 1024 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B et de 2048 bits pour les renseignements PROTÉGÉ C. D'ici la fin de 2013, la taille du module sera augmentée à au moins 2048 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B. Elle sera augmentée à au moins 3072 bits d'ici la fin de 2025 pour les renseignements PROTÉGÉ C, et d'ici la fin de 2030 pour tous les niveaux PROTÉGÉ.
  2. Autres algorithmes basés sur l'exponentiation dans un corps fini. La publication spéciale 800-56A [v] du NIST précise les protocoles d'établissement de clé acceptables qui font appel à la cryptographie à base de logarithmes discrets dans un corps fini, notamment les algorithmes Diffie-Hellman et MQV. Les paramètres de domaine pour le corps fini doivent être générés à l'aide d'une méthode précisée dans la publication FIPS 186-3 du NIST et doivent se conformer aux tailles de paramètres acceptables précisées dans la publication spéciale 800-56A. Plus particulièrement, la cardinalité du corps doit être un nombre premier d'une taille d'au moins 1024 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B et 2048 bits pour les renseignements PROTÉGÉ C. D'ici la fin de 2013, la taille du corps devra être d'au moins 2048 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B. D'ici la fin de 2025, elle devra être d'au moins 3072 bits pour les renseignements PROTÉGÉ C. D'ici la fin de 2030, la taille du corps devra être d'au moins 3072 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B.

    Le CSTC doit approuver les protocoles dans lesquels l'algorithme d'établissement de clé est intégré.

  3. Algorithmes à courbe elliptique. La publication spéciale 800-56A du NIST précise également les protocoles d'établissement de clé acceptables qui font appel à la cryptographie à courbe elliptique (ECC pour Elliptic Curve Cryptography), dont les algorithmes Elliptic Curve Diffie-Hellman et ECMQV. Les paramètres du domaine ECC doivent être générés tel qu'il est indiqué dans la norme ANS X9.62, ou sélectionnés à partir des paramètres du domaine à courbe elliptique recommandés dans la publication FIPS 186-3 du NIST. L'ECC doit être mise en œuvre dans un corps fini de l'ordre de q, où q est un nombre premier impair, ou de la forme 2m où m est un nombre premier. Associée aux paramètres du domaine est une longueur de clé, la longueur en bits de l'ordre du point de référence. La longueur de la clé doit être d'au moins 160 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B, et 224 bits pour les renseignements PROTÉGÉ C. D'ici 2013, des longueurs de clé à courbe elliptique d'au moins 224 bits seront utilisées pour les renseignements PROTÉGÉ A et PROTÉGÉ B. Le CSTC recommande fortement l'emploi des courbes données à l'appendice D de la publication FIPS 186-3 (Digital Signature Standard). La publication spéciale 800-56A du NIST donne également de l'orientation sur la longueur maximale en bits du cofacteur h.

Le CSTC doit approuver les protocoles dans lesquels l'échange de clé est intégré.

Algorithmes de signature numérique

La génération d'une signature numérique nécessite une fonction de hachage cryptographique qui s'exécute sur les données à signer, de même qu'une clé cryptographique et un algorithme de signature pour générer une signature sur les résultats de la fonction de hachage.

Le CSTC approuve l'utilisation des algorithmes suivants pour les applications de signature numérique :

  • RSA (Rivest, Shamir, Adleman)
  • DSA (Digital Signature Algorithm)
  • autres algorithmes fondés sur l'exponentiation dans un corps fini (p. ex., El-Gamal)
  • ECDSA (Elliptic Curve Digital Signature Algorithm)

Les recommandations ci-dessous ne s'appliquent pas aux signatures générées par des autorités de certification (AC). Prière de consulter le CSTC pour la taille recommandée des modules ou des cardinalités pour les AC.

Les cryptopériodes doivent être approuvées par le CSTC.

  1. RSA. Les protocoles de signature sont définis dans la norme ANSI X9.31 – 1998 et dans la RSA PKCS #1 v2.1. Les directives relatives à la mise en œuvre sont données dans la norme FIPS 186-3 (Digital Signature Standard). La taille du module doit être d'au moins 1024 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B et 2048 bits pour les renseignements PROTÉGÉ C. D'ici la fin de 2013, la taille du module sera augmentée à au moins 2048 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B. La taille du module sera augmentée à au moins 3072 bits d'ici la fin de 2025 pour les renseignements PROTÉGÉ C, et d'ici la fin de 2030 pour tous les niveaux PROTÉGÉ.
  2. DSA. Ce protocole de signature est défini dans la norme FIPS 186-3 (Digital Signature Standard). Le module, dont la cardinalité est un nombre premier, doit avoir une taille d'au moins 1024 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B. Pour les renseignements PROTÉGÉ C, la taille du module doit être d'au moins 2048 bits. D'ici la fin de 2013, elle sera augmentée à au moins 2048 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B. La taille du module sera augmentée à au moins 3072 bits d'ici la fin de 2025 pour les renseignements PROTÉGÉ C, et d'ici la fin de 2030 pour tous les niveaux PROTÉGÉ.
  3. Autres algorithmes fondés sur l'exponentiation dans un corps fini (p. ex.,  El-Gamal). La cardinalité du corps doit être un nombre premier et sa taille doit être d'au moins 1024 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B. Pour les renseignements PROTÉGÉ C, un corps d'au moins 2048 bits sera utilisé. D'ici la fin de 2013, la taille du corps sera augmentée à au moins 2048 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B. La taille du module sera augmentée à au moins 3072 bits d'ici la fin de 2025 pour les renseignements PROTÉGÉ C, et d'ici la fin de 2030 pour tous les niveaux PROTÉGÉ.

    Le CSTC doit approuver les protocoles dans lesquels l'algorithme de signature numérique est intégré.

  4. ECDSA. Ce protocole de signature est défini dans la norme ANSI X9.62 –2005. Les directives relatives à sa mise en œuvre sont données dans la norme FIPS 186-3 (Digital Signature Standard). La taille de la courbe elliptique doit être d'au moins 160 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B et d'au moins 224 bits pour les renseignements PROTÉGÉ C. Pour les renseignements PROTÉGÉ A et PROTÉGÉ B, des clés de courbe elliptique d'une longueur minimale de 224 bits  seront utilisées d'ici la fin de 2013. Le CSTC recommande fortement l'utilisation des courbes elliptiques figurant à l'appendice D de la norme FIPS 186-3.

Algorithmes de hachage et situation de l'algorithme SHA-1

Le CSTC autorise l'utilisation des algorithmes SHA-224, SHA-256, SHA-384 et SHA-512 pour les renseignements PROTÉGÉ A, PROTÉGÉ B et PROTÉGÉ C. Ces algorithmes sont définis dans la norme FIPS 180-3 (Secure Hash Standard).

L'utilisation de SHA-1 pour la génération de signature numérique pour les renseignements PROTÉGÉ A et PROTÉGÉ B devrait être abandonnée d'ici 2013. Pour les renseignements PROTÉGÉ C, l'utilisation de l'algorithme SHA-1 pour la génération de la signature numérique aurait dû avoir été abandonnée en 2008.

L'algorithme SHA-1 peut être utilisé pour toutes les autres applications de la fonction de hachage, y compris HMAC, les fonctions de dérivation de clé et la génération de nombres aléatoires.

Quoique l'utilisation de l'algorithme SHA-1 soit autorisée, le CSTC recommande fortement l'emploi de l'algorithme SHA-224 ou d'un algorithme supérieur dans la mesure du possible.

Algorithmes d'intégrité des données

Un code d'authentification de message (MAC pour Message Authentication Code) sert à assurer l'intégrité des données et l'authentification de l'origine des données. Le CSTC autorise l'utilisation des codes d'authentification de message suivants :

  • HMAC (MAC à base de fonction de hachage)
  • CMAC (MAC à base de fonction de chiffrement)
  • GMAC/mode compteur Galois et CCM
  1. HMAC. Le MAC à base de fonction de hachage est défini dans la norme FIPS 198-1 (The Keyed-Hash Message Authentication Code [HMAC]) publiée en 2008. Les clés doivent être d'une longueur d'au moins 80 bits. D'ici la fin de 2013, la longueur des clés augmentera à au moins 112 bits.
  2. CMAC. L'utilisation du MAC à base de fonction de chiffrement avec l'algorithme AES ou Triple DES tel qu'elle est définie dans la publication spéciale 800-38B du NIST est approuvée pour protéger les renseignements PROTÉGÉ de tous les niveaux. L'utilisation de Triple DES à 2 clés sera abandonnée d'ici la fin de 2015. La longueur de l'étiquette doit être d'au moins 90 bits pour les renseignements PROTÉGÉ A et PROTÉGÉ B et 122 bits pour les renseignements PROTÉGÉ C. Pour les renseignements PROTÉGÉ A et PROTÉGÉ B, des étiquettes d'une longueur d'au moins 122 bits seront utilisées d'ici la fin de 2013 [vi].
  3. GMAC/GCM and CCM. Le mode CCM est précisé dans la publication spéciale 800-38C du NIST, et le GMAC/GCM dans la publication spéciale 800-38D. Ces algorithmes peuvent être utilisés pour tous les niveaux PROTÉGÉ.

Fonction de dérivation de clé

Le CSTC approuve l'utilisation des fonctions de dérivation de clé (KDF pour Key Derivation Function) suivantes pour dériver le matériel de chiffrement secret à partir d'un secret partagé. Les KDF suivantes sont définies dans la publication spéciale 800-56A du NIST.

  • Concatenation KDF
  • ASN.1 KDF

La publication spéciale 800-108 du NIST précise les fonctions de dérivation de clé qui utilisent une clé cryptographique pour générer des clés cryptographiques additionnelles.

  • HMAC-based KDF (KDF à base de HMAC)
  • CMAC-based KDF using AES (KDF à base de CMAC utilisant AES)
  • CMAC-based KDF using Triple DES (KDF à base de CMAC utilisant Triple DES)

L'utilisation de Triple DES à 2 clés comme algorithme de chiffrement par blocs dans le KDF à base CMAC sera abandonnée d'ici la fin de 2015.

Enveloppement et transport des clés

On entend par « enveloppement de clé » le chiffrement d'une clé symétrique par une autre clé symétrique avec protection de l'intégrité. Le CSTC approuve l'utilisation des algorithmes suivants pour l'enveloppement des clés :

  • AES
  • Triple DES

Quoiqu'il n'existe aucune norme à l'heure actuelle pour l'enveloppement des clés, il existe une spécification non officielle à l'aide d'AES [vii]. Si Triple DES est l'algorithme choisi, la même technique doit être utilisée.

L'utilisation du Triple DES à 2 clés a pour restriction qu'au plus 220 blocs de données peuvent être chiffrés à l'aide de la même clé. L'algorithme d'enveloppement de clé Triple DES à 2 clés devrait être abandonné d'ici la fin de 2015. L'emploi de Triple DES à 3 clés est l'option de premier choix.

Le transport de clé est requis lorsqu'une partie détermine la clé. Le CSTC approuve l'utilisation de RSA pour le transport de clé tel qu'il est défini dans la publication spéciale 800-56b du NIST. La taille du module doit être d'au moins 1024 bits pour l'information PROTÉGÉ A et PROTÉGÉ B, et 2048 bits pour l'information PROTÉGÉ C. D'ici la fin de 2013, la taille du module sera augmentée à au moins 2048 bits pour l'information PROTÉGÉ A et PROTÉGÉ B.

Protocoles de bourrage

Certains des algorithmes d'établissement de clé et de signature numérique énumérés plus haut ne peuvent être utilisés si aucun protocole de bourrage n'est défini.

Le CSTC autorise l'utilisation des protocoles de bourrage RSA suivants pour l'établissement de clé :

  1. de la RSA PKCS #1 v2.1, le protocole de bourrage appelé RSAES-OAEP.

Le CSTC autorise l'utilisation des protocoles de bourrage RSA suivants pour la signature numérique :

  1. le protocole de bourrage défini dans la norme ANSI X9.31;
  2. de la RSA PKCS #1 v2.1, le protocole de bourrage appelé RSAES-PSS.

L'utilisation d'un protocole de bourrage quelconque avec l'algorithme SHA-1 sera abandonnée d'ici la fin de 2013.

Génération de bits aléatoires

Un générateur de bits aléatoires approuvé par le CSTC (parfois appelé « générateur de nombres aléatoires ») a deux composantes : une source d'entropie et un générateur déterministe de bits aléatoires (DRBG pour deterministic random bit generator). La source d'entropie sert à initialiser le DRBG en lui fournissant une graine ou germe (seed) pour qu'il produise la sortie pseudo-aléatoire.

Le CSTC autorise l'utilisation des DRBG suivants pour la production de bits aléatoires, avec les restrictions décrites plus bas :

  • Hash_DRBG
  • HMAC_DRBG
  • CTR_DRBG
  • Dual_EC_DRBG

Il est préférable de réinitialiser le DRBG (en lui fournissant de nouvelles graines) le plus souvent possible. Le nombre maximal de sorties faites par une version entre réinitialisations doit être approuvé par le CSTC.

Lorsque la sortie d'un des DRBG ci-dessus est convertie en nombres aléatoires, l'une des méthodes décrites dans la publication spéciale 800-90 du NIST [viii] doit être utilisée.

Toutes les versions des algorithmes suivants doivent se conformer à la publication spéciale 800-90 du NIST.

  1. L'utilisation de Hash_DRBG est approuvée avec l'un des algorithmes de hachage approuvés plus haut.
  2. L'utilisation de HMAC_DRBG est approuvée avec l'un des algorithmes de hachage approuvés plus haut. Le HMAC_DRBG est également précisé dans l'appendice D de la publication ANS X9.62:2005.
  3. L'utilisation de CTR_DRBG est approuvée avec l'algorithme Triple DES utilisé avec 3 clés indépendantes ou avec l'algorithme AES.
  4. L'utilisation de Dual_EC_DRBG est approuvée avec les courbes elliptiques définies sur un corps premier P-224, P-256, P-384 ou P-512 du NIST, et les paramètres connexes.

Le CSTC approuve également l'utilisation de DRBG patrimoniaux qui seront abandonnés d'ici la fin de 2015. L'appendice 3 de la FIPS 186-2 (Digital Signature Standard) précise l'utilisation de SHA-1 et de DES pour générer des bits aléatoires. Il est recommandé d'utiliser la FIPS 186-3 dans laquelle ces méthodes ont été mises à jour pour utiliser SHA-224 et les versions ultérieures.

Aide et renseignements

Services à la clientèle de la Sécurité des TI
Centre de la sécurité des télécommunications Canada
C.P. 9703, Terminus
Ottawa (Ontario) K1G 3Z4
Téléphone: 613-991-7654
Courriel : itsclientservices@cse-cst.gc.ca

Signature de Toni Moffa

Toni Moffa
La chef adjointe de la Sécurité des TI