Chapitre 10 FAQ de sci.crypt Pas de chapitre suivant Retour à la case départ

Huile de serpent: logiciels de chiffrement à éviter

© 1996-1998
Matt Curtin <cmcurtin@interhack.net>
10 Avril 1998

Table des matières

Administrativia

Distribution

La distribution de ce document est illimitée. Nous nous adressons à des gens qui ne sont pas experts en cryptographie ou en sécurité mais qui doivent décider quellle sorte de cryptographie ils vont utiliser pour leur organisation ou pour eux.

La FAQ huile de serpent est publiée tous les mois sur sci.crypt, alt.security, comp.security, comp.answers, et comp.infosystems.
Elle est disponible en PostScript et en format PDF (idéal pour les impressions) via le web à
http://www.interhack.net/people/cmcurtin/snake-oil-faq.ps
http://www.interhack.net/people/cmcurtin/snake-oil-faq.pdf
et en HTML à
http://www.interhack.net/people/cmcurtin/snake-oil-faq.html

Déclaration de principe

Les employeurs de tous les auteurs n'ont sans aucun doute aucune responsabilité dans ce qui suit.
Nous ne parlons que pour nous-mêmes.

Ceci est une compilation des habitudes des vendeurs d'huile de serpent. Ce ne doit pas être la seule méthode d'évaluation d'un produit de sécurité, car il peut exister des exceptions à toute règle. De temps en temps, un vendeur réputé produira quelque chose qui sera réellement bon, mais fera sa promotion avec des techniques de marketing complètement tordues. Mais si vous voyez quelque chose qui présente plusieurs signes caractéristiques, vous avez probablement affaire à de l'huile de serpent.

Nous avons fait tout notre possible pour produire un document précis et utile, mais les renseignements donnés ici sont sans aucune garantie. Ceci est un travail continu; un retour est grandement apprécié. Si vous trouvez des erreurs ou souhaitez apporter votre pierre à l'édifice, contactez s'il vous plait Matt Curtin <cmcurtin@interhack.net>

Histoire du document

Comme le nombre de produits de cryptographie augmentait, celui de produits inefficaces ou bogués s'est accru aussi. Après discussion sur ce sujet sur la liste cypherpunks, Robert Rothenburg <wlkngowl@unix.asb.com> a écrit le premier jet de la FAQ huile de serpent. Matt Curtin a pris le premier texte et l'a amené à son état actuel avec l'aide des participants qui sont énumérés (et aussi probablement de quelques autres dont les noms ont été oubliés par inadvertance. Nous nous en excusons par avance, si tel est le cas).

Participants

Les personnes suivantes ont participé à cette FAQ.
Jeremey Barrett <jeremey@forequest.com>
Steven M. Bellovin <smb@research.att.com>
Matt Blaze <mab@research.att.com>
Bo Dvmstedt <bo.domstedt@protego.se>
Gary Ellison <gary.ellison@eng.sun.com>
<fifersl@ibm.net>
<geeman@best.com>
Larry Kilgallen <KILGALLEN@Eisner.DECUS.Org>
Dutra Lacerda <dutra.lacerda@mail.telepac.pt>
Felix Lee <flee@teleport.com>
Colin Plumb <colin@nyx.net>
Jim Ray <jmr@shopmiami.com>
Terry Ritter <ritter@io.com>
Robert Rothenburg <wlkngowl@unix.asb.com>
Adam Shostack <adam@homeport.org>
Rick Smith <smith@sctc.com>
Randall Williams <ac387@yfn.ysu.edu>

Introduction

La bonne cryptographie est un outil excellent et nécessaire pour quasiment tout le monde. On trouve beaucoup de bons produits cryptographiques, commerciaux, "shareware" ou gratuits. Toutefois, il existe aussi des produits cryptographiques extrêmement mauvais, qui non seulement ne parviennent pas à assurer la sécurité, mais contribuent aussi à de nombreuses idées fausses sur la cryptographie et la sécurité.

Pourquoi "huile de serpent"? Le terme, utilisé dans de nombreux domaines, dénote quelque chose qui est vendu sans considération de sa qualité ou de sa faculté à accomplir la mission présentée par le vendeur. Ce terme était appliqué à l'origine aux élixirs vendus par des médecins ambulants. Ces vendeurs prétendaient que leur élixir pouvait soigner n'importe quoi. Lorsqu'on écoute les arguments de certains vendeurs de crypto, le mot "huile de serpent" est étonnamment adapté.

Superficiellement, il est difficile de distinguer de l'huile de serpent de la Vraie Crypto: tous les outils de chiffrement produisent une sortie illisible. Le but de ce document est de présenter quelques "points noirs" qui devraient vous aider à détecter l'huile de serpent.

Pour diverses raisons, ce document ne mentionne pas de produits ou d'algorithmes spécifiques comme étant "bons" ou "mauvais".

Concepts de base

Quelques principes de base sont exposés ici, dans le but de rendre cette FAQ plus complète. La FAQ de cryptographie [3] est une introduction plus générale et il est bon de la lire elle aussi.

Lors de l'évaluation d'un produit, essayez de bien cerner vos besoins. Pour les produits de sécurité, que cherchez-vous à protéger?
Voulez-vous un archiveur de données, un plug-in pour le courrier, ou quelque chose qui chiffre les communications en ligne? Avez-vous besoin de chiffrer un disque entier ou juste quelques fichiers?

Et quel niveau de sécurité est suffisant? Les données doivent-elles rester illisibles par les "espions" pendant cinq minutes, un an ou un siècle? L'espion est-il la petite soeur de quelqu'un, une entreprise, ou un gouvernement?

Cryptographie symétrique et asymétrique

A la base, il y a deux types de cryptosystèmes: symétriques (ou conventionnels ou à clé secrète) et asymétrique (à clé publique).

Avec un chiffre symétrique, l'émetteur ET le récepteur doivent avoir la même clé. Cette clé est utilisée par l'émetteur pour chiffrer les données, et par le récepteur pour déchiffrer. Le problème ici est de partager la clé entre l'émetteur et le récepteur.

Les chiffres asymétriques sont beaucoup plus souples du côté de la gestion de clé. Chaque utilisateur a une paire de clés: une clé publique et une clé privée. Les messages chiffrés avec une clé ne peuvent être déchiffrés qu'avec l'autre clé. La clé publique peut être diffusée largement alors que la clé privée est tenue secrète.

Donc si Alice veut envoyer un secret à Bob, elle récupère simplement la clé publique de Bob, la vérifie, chiffre son message avec, et l'envoie à Bob. Quand Bob reçoit le message, il le déchiffre avec sa clé privée.

La vérification des clés publiques est une étape importante. Si Alice ne vérifie pas que la clé appartient réellement à Bob, elle court le risque d'utiliser une clé dont la clé privée associée est entre les mains de l'ennemi.

Les chiffres asymétriques sont beaucoupl plus lents que les symétriques. De plus, les clés sont généralement beaucoup plus grosses. Voir la FAQ de cryptographie [3] pour plus de détails sur ces sujets.

Secret et intégrité: que veut-on protéger?

Pour beaucoup d'utilisateurs de cryptographie sur ordinateurs, préserver le contenu d'un message est aussi important que préserver son secret. Les dommages causés par une modification peuvent être pire que ceux causés par la divulgation. Par exemple, découvrir qu'un hacker a lu le contenu d'un ordre de virement est dérangeant, mais c'est un désastre s'il a modifié la destination en direction de son propre compte.

Le chiffrement en lui-même ne protège pas un message contre la falsification. En fait, il existe plusieurs techniques pour changer le contenu d'un message chiffré sans découvrir la clé. Si l'intégrité des messages est importante, ne comptez pas uniquement sur le secret pour les protéger. Vérifiez comment le vendeur protège les messages contre des modifications non détectées.

Tailles de clés

Même si un chiffre est sûr contre des attaques analytiques, il peut être vulnérable contre des attaques par force brute si la clé est trop courte. Dans une attaque par force brute, l'attaquant essaie simplement toutes les clés possibles jusqu'à ce qu'il trouve la bonne. Le temps que ça va prendre dépend de la taille de la clé et de la puissance de calcul disponible. Donc en essayant de sécuriser des données, vous devez prendre en considération le temps pendant lequel elles doivent rester sûres et la puissance de calcul disponible pour l'attaquant.

[1] et [2] présentent quelques lignes directrices pour le choix d'une taille de clé appropriée. Par exemple, la table 1 montre le coût de casser des algorithmes symétriques, comme indiqué dans [2]. Le même rapport recommande fortement l'utilisation de clés symétriques de 90 bits ou plus.

Avec l'explosion de la puissance de calcul sur les dernières décades, des cryptosystèmes qui étaient considérés comme sûrs à une époque sont maintenant vulnérables à une attaque par force brute. RSA Laboratories a sponsorisé une série de défis, connus sous le nom de "1997 Secret Key Challenge" [5] (défi des clés secrètes 1997). Jusqu'à présent, nous avons vu tomber face aux attaques par force brute RC5 à 56 bits et le cheval de bataille de l'industrie, le DES. Avec 56 bits, les clés utilisées dans le DES sont simplement trop petites pour résister à un attaquant. Il est intéressant de noter que les deux groupes qui ont cassé des messages chiffrés en DES l'ont fait avec quasiment aucun financement.

Table 1: Temps et coût de la récupération de clés

Type d'attaquant Budget Outil Temps et coût par clé de 40 bits récupérée Longueur minimale pour une protection efficace fin 1995
Hacker de passage Minuscule ordinateur récupéré 1 semaine 45 bits
400 $ FPGA 5 heures (0,08 $) 50 bits
Petite entreprise 10.000 $ FPGA 12 minutes (0,08 $) 55 bits
Service moyen 300.000 $ FPGA 24 secondes (0,08 $)
ASIC 5 ms 60 bits
Grosse entreprise 10.000.000 $ FPGA 0,7 s
ASIC 5 ms (0,001 $) 70 bits
Services de renseignements 300.000.000 $ ASIC 0.0002 s (0,001 $) 75 bits

Comme mentionné plus haut, les chiffres asymétriques nécessitent des clés bien plus longues pour produire le même niveau de sécurité que les chiffres symétriques. La comparaison des longueurs de clés entre algorithmes est douteuse car des algorithmes différents ont des caractéristiques différentes. La connaissance de la longueur de la clé est inutile si vous ne connaissez pas le type d'algorithme utilisé.

Pour vous donner une idée de ce qui est raisonnable, la table 2, tirée de [1], compare les clés symétriques contre un type de clés asymétriques: celles qui sont basées sur le problème de factorisation ou le problème du logarithme discret. (les algorithmes basés sur le problème du logarithme discret dans l'espace des courbes elliptiques sont plus résistants à la force brute et peuvent utiliser des clés plus petites. En fait, elles n'ont pas besoin d'être beaucoup plus grosses que les clés symétriques, d'après ce que nous savons jusqu'à présent)

Table 2: Longueurs de clés ayant une résistance similaire face aux attaques par force brute

Clés symétriques Clés publiques
56 bits 384 bits
64 bits 512 bits
80 bits 768 bits
112 bits 1792 bits
128 bits 2304 bits

Clés et mots de passe

Une clé n'est pas la même chose qu'un mot de passe ou qu'une phrase de passe. Pour résister à une attaque, toutes les clés possibles doivent être équiprobables. Si certaines clés sont plus probables que d'autres, alors un attaquant peut se servir de cette information pour réduire la quantité de travail nécessaire pour casser le chiffre.

Le point essentiel est que la clé doit être aléatoire. Toutefois, une phrase sera facile à mémoriser, mais possède sensiblement moins d'entropie que sa longueur laisse croire. Par exemple, une phrase de 20 lettres en anglais, plutôt que d'avoir 20 x 8 = 160 bits d'entropie, n'en a environ que 20 x 2 = 40.

Donc la plupart des logiciels cryptographiques doivent convertir la phrase en clé via un processus appelé hachage ou initialisation de la clé [NdT: on dit aussi broyage de clé]. Evitez les cryptosystèmes qui sautent cette phase et utilisent directement un mot de passe comme clé.

Evitez tout ce qui ne vous permet pas de générer vos propres clés (par exemple, le vendeur vous envoie les clés par courrier, ou vos clés sont incluses dans la copie du logiciel que vous achetez).

Environnement

D'autres facteurs qui peuvent influencer la sécurité relative d'un produit sont liés à son environnement. Par exemple, dans un produit de chiffrement logiciel, est-ce que le texte clair est écrit sur disque (peut-être dans des fichiers temporaires)? Que se passe-t-il sur les systèmes d'exploitations qui peuvent swapper un processus de la mémoire vers le disque? Quand quelque chose est chiffré, est-ce que le texte clair correspondant est détruit? La destruction est-elle une suppression classique du nom du répertoire, ou bien les données sont-elles écrasées? Si c'est écrasé, est-ce bien écrasé? Ce niveau de sécurité a-t-il un sens pour vous? Stockez-vous vos clés sur une machine multi utilisateurs? Si oui la probabilité que vos clés soient lues illégalement est beaucoup plus élevée. Il est important de prendre de telles choses en considération quand vous essayez de décider du niveau de sécurité de ce que vous allez mettre en oeuvre.

Signes d'huile de sepent

"Faites-nous confiance, nous savons ce que nous faisons"

Peut-être le plus gros signe de tous, que le message "Faites-nous confiance, nous savons ce que nous faisons" soit prononcé directement ou sous-entendu dans les propos du vendeur. Si le vendeur n'est pas sûr de la sécurité de son système après avoir décrit exactement comment il fonctionne, il est certainement sans intérêt. Qu'ils le disent ou non, des gens intelligents le sentiront. Les mauvais garçons qui en veulent à vos secrets (spécialement si vous êtes une cible tentante, comme une grosse entreprise, une banque, etc.) ne sont pas stupides. Ils sentiront où sont les failles. Si le vendeur ne vous dit pas exactement et clairement ce qui est à l'intérieur, vous pouvez être sûr qu'ils cachent quelque chose, et que le seul qui en souffrira finalement c'est vous, le client.

Technojargon

Si la description du vendeur est un mélange confus, il se pourrait fort que ça soit le cas, même à un expert dans le domaine. Un signe de technojargon est une description qui emploie des termes nouveaux ou déposés sans expliquer réellement comment marche le système. Le technojargon est un bon moyen de troubler un client potentiel et de masquer le manque d'expertise du vendeur.

Considérez ceci: si le discours marketing n'est pas clair, pourquoi s'attendre à ce que les instructions d'utilisation soient meilleures? Même le meilleur produit peut être inutile s'il n'est pas mis en oeuvre correctement. Si vous ne comprenez pas ce qu'un vendeur vous dit, vous feriez probablement mieux de trouver quelque chose qui a plus de sens.

Algorithmes secrets

Evitez les logiciels qui utilisent des algorithmes secrets. Ce n'est pas un moyen sûr de protéger des données. Si le vendeur ne croit pas que sa méthode puisse supporter l'analyse, alors vous feriez mieux de ne pas lui faire confiance.

Une excuse commune pour ne pas divulguer l'algorithme est que "les hackers pourraient essayer de casser la sécurité du programme". Bien que ceci puisse être une considération légitime, il faut noter que de tels "hackers" peuvent faire la rétro conception du programme pour voir comment il marche. Ce n'est pas un problème si l'algorithme est solide et le programme bien écrit.

Un algorithme bien connu en qui on a confiance, des notes techniques expliquant la réalisation, le code source disponible sont des signes que le vendeur a confiance dans la sécurité de son produit. Vous pouvez le prendre et le tester vous même. Même si l'algorithme est bon, une mauvaise mise en oeuvre fera perdre tout intérêt au produit cryptographique.
Un verrou que l'attaquant ne peut pas passer même quand il voit ses mécanismes internes est un verrou vraiment solide. La bonne cryptographie est exactement dans ce style.

Notez qu'un vendeur spécialisé en cryptographie peut avoir un algorithme propriétaire qu'ils ne révèleront qu'à condition de signer un accord de confidentialité. Le produit peut être tout à fait satisfaisant si le vendeur est réputé. (mais est-ce qu'un non expert sait si un vendeur est réputé?). En général, il vaut mieux éviter les algorithmes secrets.

Avancées révolutionnaires

Méfiez-vous des vendeurs qui prétendent avoir inventé "un nouveau type de cryptographie" ou "une avancée révolutionnaire". Les vraies avancées apparaissent d'abord dans les publications consacrées à la recherche, et les professionnels du domaine ne leur font pas confiance avant de les avoir analysées pendant des années, et à ce moment-là elles ne sont plus si neuves.

La force de n'importe quel système de chiffrement doit subir l'épreuve du temps. La cryptographie nouvelle ressemble aux nouveaux médicaments, pas aux nouvelles voitures. D'un certain côté, c'est pire: si une entreprise pharamaceutique produit des drogues mal conçues, des gens vont tomber malades, mais si vous utilisez de la mauvaise crypto, vous ne saurez probablement pas que vos secrets ne sont pas si secrets que ça.

Evitez les logiciels qui prétendent utiliser de "nouvelles tendances" en informatique comme les automates cellulaires, les réseaux de neurones, les algorithmes génétiques, la théorie du chaos, etc. Ce n'est pas parce qu'un logiciel utilise une nouvelle méthode de calcul qu'il devient sûr pour autant (en fait, ces techniques sont au coeur de la recherche cryptographique, et personne n'a encore publié de résultats convaincants).

Evitez aussi soigneusement des versions spécialement modifiées d'algorithmes bien connus. Ca peut affaiblir le chiffre, intentionellement ou non.

Il est important de comprendre la différence entre un nouveau chiffre et un nouveau produit. Développer des chiffres ou des produits cryptographiques sont de bonnes choses. Néanmoins, faire les deux à la fois est stupide. Beaucoup de vendeurs d'huile de serpent se vantent de ça, en dépit du manque de sagesse d'une telle activité.

Experts en sécurité expérimentés, compte-rendus dithyrambiques et autres certificats inutiles

Méfiez-vous de ceux qui prétendent que leurs produits ont été analysés par des "experts en sécurité expérimentés" sans fournir de référence. Cherchez toujours la bibliographie. Les chiffres qu'ils utilisent devraient apparaître dans un bon nombre de références scientifiques. Sinon, ils n'ont manifestement pas été assez bien testés pour prouver ou démolir leur sécurité.

Ne vous fiez pas aux revues dans les journaux, magazines ou émissions de télévision, car en général ils n'ont pas de cryptographes pour analyser le logiciel à leur place. (Les "hackers" célèbres qui connaissent les systèmes téléphoniques ne sont pas nécessairement des experts en cryptographie).

Que le vendeur soit une entreprise bien connue ou que l'algorithme soit breveté ne le rend pas plus sûr.

Incassable

Certains vendeurs prétendront que leur logiciel est "incassable". Ce n'est qu'un argument marketing, et un signe courant d'huile de serpent. Aucun algorithme n'est incassable. Même les meilleurs algorithmes peuvent être attaqués par force brute, bien que ceci puisse être irréalisable si la clé est suffisamment longue.

Certaines sociétés qui prétendent avoir un système incassable ont vraiment de sérieuses raisons de le dire. Malheureusement, ces raisons dépendent généralement d'une définition étroite du mot "casser". Par exemple, les masques jetables (voir le prochain paragraphe) sont techniquement incassables seulement si certaines conditions importantes et difficiles sont remplies. Quand bien même, ils sont vulnérables à des attaques à texte clair connu contre l'intégrité. D'autres systèmes ne sont incassables que si l'on ne vole pas un dispositif de communication (un ordinateur portable par exemple). Vérifiez bien ce que signifie la propriété "incassable" du système et voyez si les parties plus cassables du système fournissent elles aussi une sécurité adéquate.

Souvent, des commerciaux moins expérimentés vont vous dire "Bien sûr, ce n'est pas incassable si vous faites telle et telle chose". Le point crucial est que la nature exacte du "tel et tel" variera d'un produit à l'autre. Prenez celui qui correspond le mieux à vos besoins opérationnels sans sacrifier votre besoin de sécurité.

Masques jetables (ou "clés aléatoires une fois")

Un vendeur peut prétendre utiliser un masque jetable, que l'on peut prouver incassable. Techniquement, tous les décryptements de la sortie d'un masque jetable sont équiprobables. Par exemple,

598v *$_+~ xCtMB0

a autant de chance de se déchiffrer comme :

la réponse est oui
la réponse est non
vous avez perdu !!

Les vendeurs d'huile de serpent vont essayer de s'appuyer sur la force connue du masque jetable. Mais il est important de comprendre que toute variation dans la réalisation signifie que ce n'est pas un masque jetable et qu'on est loin de la sécurité d'un masque jetable.

Un masque jetable marche avec un masque de bits aléatoires connus à la fois de l'émetteur et du récepteur, mais absolument de personne d'autre. A l'origine, avant l'apparition des ordinateurs, on utilisait des bandes [?] de papier. Il faut envoyer le masque au destinataire de façon sûre, par exemple dans une valise verrouillée menottée au porteur.

Pour chiffrer un message de N bits, les N prochains bits du masque servent de clé. Une fois ces bits utilisés, ils sont détruits et ne peuvent jamais resservir.

Il ne faut pas générer les bits du masque à l'aide d'un algorithme ou d'un chiffre. Ils doivent être vraiment aléatoires, provenant de matériel spécialisé, de mesure de radioactivité, etc. Certains vendeurs d'huile de serpent vont essayer d'esquiver ce sujet en parlant des fonctions qu'ils appliquent sur le flux de bits, ou de ce qu'ils font entre le flux de bits et le texte chiffré, etc. Mais ça ne change toujours rien au fait que quelque chose qui n'utilise pas une source véritablement aléatoire n'est pas un masque jetable. Le point important dans un masque jetable est la source de bits, pas ce qu'on en fait.

Les masques jetables sont sérieusement vulnérables si jamais on réutilise un masque. Par exemple, le projet VENONA [4] de la NSA a réussi sans aide d'ordinateurs à décrypter une série de messages du KGB chiffrés avec de mauvais masques. Il ne faut pas beaucoup de travail pour casser un masque réutilisé.

La vraie limitation à l'utilisation pratique des masques jetables est la génération et la distribution des clés vraiment aléatoires. Il faut distribuer au moins un bit de clé par bit de données transmis. Les masques jetables sont inadaptés à la cryptographie à usage général. Ils ne sont utilisables que sur des canaux de communications à bande passante très faible où les deux partis peuvent échanger les clés par une méthode différente des données. (on prétend qu'un lien entre Washington et Moscou était chiffré avec masque jetable)
[NdT: il s'agirait du fameux téléphone rouge, qui était en fait un téléscripteur]

De plus, si les masques sont fournis par le vendeur, vous ne pouvez pas vérifier la qualité des masques. Comment savez-vous que le vendeur ne donne pas les mêmes bits à tout le monde? Ne garde pas une copie pour lui? Ou ne vend pas une copie à vos rivaux?

Certains vendeurs essaient aussi de brouiller des clés de sessions aléatoires ou des vecteurs d'initialisation avec des masques jetables.

L'algorithme ou le produit X n'est pas sûr

Soyons méfiants envers quiconque prétend que les algorithmes ou produits concurrents ne sont pas sûrs sans fournir de preuves formelles.
Certaines attaques sont purement théoriques ou irréalisables, ne sont applicables que dans des circonstances très précises ou requièrent une puissance de calcul énorme pendant des années, et il est facile de troubler le profane en les mentionnant.

Recouvrement de clés

S'il y a un système de recouvrement ou de dépôt de clés, le contrôlez-vous ou est-ce quelqu'un d'autre qui garde une copie de la clé? Un tiers peut-il récupérer votre clé sans trop d'effort? Souvenez-vous que vous n'avez aucune assurance contre quelqu'un qui a votre clé.

Si le vendeur prétend qu'il peut récupérer les clés perdues sans utiliser de système de dépôt de clé, évitez-le. La sécurité est manifestement imparfaite.

Exportable des Etats-Unis

Si le logiciel est fait aux Etats-Unis, peut-il être exporté? La cryptographie forte est considérée comme une munition dangereuse par les Etats-Unis et il faut une autorisation du US Bureau of Export Administration, dépendant du US Department of Commerce. Diverses agences gouvernementales conseillent le Bureau of Export Administration lors de l'évaluation de telles requêtes. (Les Etats-Unis ne sont pas les seuls à faire cela; d'autres pays ont des restrictions d'exportation de la cryptographie forte similaires). Si le logiciel est autorisé à l'exportation, il y a des chance que l'algorithme soit faible ou cassable.

Si le vendeur n'est pas au courant des restrictions d'exportation, évitez son logiciel. Par exemple, s'il prétend que l'IDEA est exportable alors que la plupart des vendeurs (et le gouvernement américain !) ne s'engagent pas, alors ce vendeur n'a probablement pas les connaissances suffisantes pour vous fournir de la bonne cryptographie.

A cause des restrictions d'exportation, certains des produits de crypto décents ont deux versions: Etats-Unis seulement et exportable. La version exportable sera bridée, probablement en utilisant une clé plus courte, ce qui la rend facile à casser.

Il n'y a aucune restriction sur l'importation de produits de crypto aux Etats-Unis, donc un vendeur non américain peut proposer légalement une seule version sûre de son produit dans le monde entier.

Un cryptosystème peut ne pas être exportable alors qu'il est disponible à l'extérieur des Etst-Unis: parfois un utilitaire est exporté illégalement et publié sur un site étranger.

"Qualité militaire"

Certains vendeurs prétendent que leur système est de "qualité militaire". Ceci n'a aucun sens car il n'existe aucun standard qui définisse la "qualité militaire" mis à part ce qui est réellement utilisé par diverses forces armées. Comme ces organisations ne révèlent pas la crypto qu'elles utilisent, il est impossible de confirmer ou d'infirmer que quelque chose est de "qualité militaire".
[NdT: je me permets de mettre un bémol à ce paragraphe. Il est exact que le standard réservait le DES au chiffrement de données non confidentielles. Les militaires américains (et alliés) utilisent donc autre chose. En revanche, le standard russe correspondant, le GOST 28147-89 ne limite pas le niveau de classification des données qui peuvent être chiffrées. Il aurait été utilisé pour des données militaires en Union Soviétique. A ma connaissance, il est utilisé par la banque fédérale russe, et les boîtes S "recommandées" (?) par les renseignements soviétiques ont même été publiées. Personne ne peut évidemment être sûr que ces boîtes ont été ou sont toujours employées, mais des cryptanalystes occidentaux ont examiné ces boîtes et elles semblent de bonne qualité.
Bref, on peut monter un système "de niveau militaire" autour du GOST. Reste à trouver ou à construire de bonnes boîtes S !]

Malheureusement, certains bons produits de crypto utilisent aussi ce terme. Méfiez-vous quand il apparaît à côté d'autres indicateurs d'huile de serpent, par exemple "notre système de chiffrement de qualité militaire est exportable des Etats-Unis".

Autres considérations

Evitez les vendeurs qui ne semblent pas comprendre tout ce qui est décrit dans le paragraphe "Concepts de base" ci-dessus.

Evitez tout ce qui permet à quelqu'un qui a une copie de votre logiciel d'accéder des fichiers, des données, etc., sans avoir un genre de clé ou de mot de passe.

Méfiez-vous des produits qui sont conçus pour une tâche spécifique, comme l'archivage de données, et où le chiffrement est une caractéristique supplémentaire. Il vaut mieux utiliser un utilitaire de chiffrement qu'un outil conçu pour autre chose dans lequel on a ajouté le chiffrement après coup.

Aucun produit n'est sûr s'il n'est pas utilisé correctement. Vous pouvez être le maillon faible de la chaîne si vous utilisez mal un produit. Ne croyez pas le produit blindé, et ne faites pas confiance à un produit qui prétend l'être.

L'interface n'est pas tout: la facilité d'utilisation est importante, mais méfiez-vous de tout ce qui insiste trop sur l'utilisation sans considération sérieuse sur la robustesse cryptographique.

Glossaire

algorithmes
Une procédure ou une formule mathématique. Les algorithmes cryptographiques convertissent un texte clair (ou libellé) en texte chiffré (ou cryptogramme).
Chiffre
Synonyme d'algorithme cryptographique.
cryptanalyse
"Casser" ou trouver la solution d'un cryptosystème.
EAR
Export Administration Regulations. [Règles Administratives d'Exportation] Ce sont les règles qui régissent l'exportation de logiciel cryptographique hors des Etats-Unis.
Dépôt de clé
Un tiers capable de décrypter les messages envoyés par une personne à une autre. Bien que ce terme soit souvent utilisé en rapport avec la proposition "Clipper" du gouvernement américain, il n'est pas limité à une fonction imposée par le gouvernement pour pouvoir décrypter toute information chiffrée à volonté. Certaines entreprises souhaitent que leurs employés utilisent des systèmes à dépôt de clé dans l'exercice de leurs fonctions, de façon que l'information soit toujours accessible si l'employé est incapable de la déverrouiller lui-même, (s'il est incapable de se souvenir de son mot de passe, s'il quitte soudainement la société, s'il se fait écraser par un bus, etc.)
Ou bien quelqu'un peut souhaiter que son épouse ou son avocat puisse lire les données chiffrées, etc. auquel cas il peut utiliser un cryptosystème à dépôt de clé.
vecteur d'initialisation
Un des problèmes avec le chiffrement de fichiers dans des formats spécifiques (par exemple, d'un traitement de texte, du courrier électronique, etc.) est que les premiers octets du message sont hautement prévisibles. On pourrait se servir de ça pour casser le message plus facilement que par force brute. Dans les chiffres où un bloc de données influence le cryptogramme du suivant (comme le mode CBC), un bloc de données aléatoire est chiffré et est utilisé comme premier bloc du message chiffré, ce qui rend le texte chiffré beaucoup moins prévisible. Ce bloc aléatoire s'appelle le vecteur d'initialisation. Le processus de déchiffrement supprime le premier bloc, ce qui redonne le texte clair.
ITAR
International Traffic in Arms Regulations. [Règlement sur le commerce international d'armes] Ces règles, définies par le Département d'Etat américain définissent quelles munitions peuvent être exportées (ou non) des Etats-Unis. Jusqu'à une date récente, elles régissaient aussi l'exportation de la cryptographie. Ce point est maintenant entre les mains du Bureau of Export Administration, dépendant du US Department of Commerce.
clé
Un bout de données qui entré dans un algorithme avec un texte chiffré, fournit un texte clair (ou qui fournit le texte chiffré à partir du texte clair)
Clé de session aléatoire
C'est une clé temporaire générée spécialement pour un message. Typiquement, dans un système à clé publique, on chiffre le message à envoyer avec un algorithme symétrique et une clé générée spécialement pour ce message.
[NdT: je me permets de réécrire la suite qui contenait un énorme contre sens]
On envoie en plus du cryptogramme la clé de session chiffrée avec la clé publique du destinataire. Quand il reçoit le message, le système déchiffre la clé de session avec la clé privée puis déchiffre le texte avec la clé "symétrique".
[NdT: fin du délire]
On fait souvent cela à cause de la différence énorme de vitesse entre les chiffres symétriques et asymétriques.
[NdT: tel que c'était formulé, on avait l'impression que le texte chiffré avec l'algorithme symétrique était surchiffré avec le système à clé publique, ce qui ferait plutôt perdre du temps !]

Index

Références

Chapitre 10 FAQ de sci.crypt Pas de chapitre suivant Retour à la case départ
Michel Arboi
Last modified: Sun Jan 19 13:04:11 CET 2003