2. General Requirements (Exigences générales)
2. General Requirements (Exigences générales)
Aujourd'hui, une exigence d'aléa couramment rencontrée est de choisir un mot de passe utilisateur, généralement une simple chaîne de caractères. Évidemment, un mot de passe qui peut être deviné ne fournit pas de sécurité. Pour les mots de passe réutilisables, il est souhaitable que les utilisateurs puissent se souvenir du mot de passe. Cela peut rendre conseillé d'utiliser des chaînes de caractères prononçables ou des phrases composées de mots ordinaires. Mais cela n'affecte que le format de l'information du mot de passe, pas l'exigence que le mot de passe soit très difficile à deviner.
De nombreuses autres exigences proviennent du domaine cryptographique. Les techniques cryptographiques peuvent être utilisées pour fournir une variété de services, incluant la confidentialité et l'authentification. Ces services sont basés sur des quantités, traditionnellement appelées "clés", qui sont inconnues et non devinables par un adversaire.
Il existe même des utilisations du protocole TCP/IP pour l'aléa dans le choix des numéros de séquence initiaux [RFC1948].
De manière générale, les exemples ci-dessus illustrent également deux types différents de quantités aléatoires qui peuvent être souhaitées. Dans le cas des mots de passe utilisables par l'homme, la seule caractéristique importante est qu'ils soient non devinables. Il n'est pas important qu'ils puissent être composés de caractères ASCII, de sorte que le bit supérieur de chaque octet soit zéro, par exemple. D'autre part, pour les clés de longueur fixe et similaires, on veut normalement des quantités qui semblent être véritablement aléatoires, c'est-à-dire des quantités dont les bits passeront les tests statistiques d'aléa.
Dans certains cas, comme l'utilisation du chiffrement symétrique avec les masques jetables ou un algorithme comme l'US Advanced Encryption Standard [AES], les parties qui souhaitent communiquer confidentiellement et/ou avec authentification doivent toutes connaître la même clé secrète. Dans d'autres cas, où des techniques cryptographiques asymétriques ou "à clé publique" sont utilisées, les clés viennent par paires. Une clé de la paire est privée et doit être gardée secrète par une partie; l'autre est publique et peut être publiée au monde. Il est infaisable sur le plan calculatoire de déterminer la clé privée à partir de la clé publique, et la connaissance de la clé publique n'est d'aucune aide à un adversaire [ASYMMETRIC]. Voir les références générales [SCHNEIER, FERGUSON, KAUFMAN].
La fréquence et le volume de l'exigence de quantités aléatoires diffèrent grandement pour différents systèmes cryptographiques. Avec RSA pur, des quantités aléatoires sont requises seulement lorsqu'une nouvelle paire de clés est générée; par la suite, un nombre quelconque de messages peut être signé sans besoin supplémentaire d'aléa. L'algorithme de signature numérique à clé publique conçu par le US National Institute of Standards and Technology (NIST) nécessite de bons nombres aléatoires pour chaque signature [DSS]. Et chiffrer avec un masque jetable (en principe la technique de chiffrement la plus forte possible) nécessite un aléa d'un volume égal à tous les messages à traiter. Voir les références générales [SCHNEIER, FERGUSON, KAUFMAN].
Dans la plupart de ces cas, un adversaire peut essayer de déterminer la clé "secrète" par essai et erreur. Cela est possible tant que la clé est suffisamment plus petite que le message pour que la clé correcte puisse être identifiée de manière unique. La probabilité qu'un adversaire réussisse cela doit être rendue acceptablement faible, selon l'application particulière. La taille de l'espace que l'adversaire doit parcourir est liée à la quantité "d'information" de clé présente, au sens de la théorie de l'information [SHANNON]. Cela dépend du nombre de valeurs secrètes différentes possibles et de la probabilité de chaque valeur, comme suit:
-----
\
Bits d'information = \ - p * log ( p )
/ i 2 i
/
-----
où i compte de 1 au nombre de valeurs secrètes possibles et p indice i est la probabilité de la valeur numérotée i. (Parce que p indice i est inférieur à un, le log sera négatif, donc chaque terme dans la somme sera non négatif.)
S'il y a 2^n valeurs différentes de probabilité égale, alors n bits d'information sont présents et un adversaire devrait essayer, en moyenne, la moitié des valeurs, soit 2^(n-1), avant de deviner la quantité secrète. Si la probabilité de différentes valeurs est inégale, alors il y a moins d'information présente, et moins de tentatives seront, en moyenne, requises par un adversaire. En particulier, toutes les valeurs qu'un adversaire peut savoir être impossibles ou de faible probabilité peuvent être initialement ignorées par l'adversaire, qui parcourra d'abord les valeurs les plus probables.
Par exemple, considérons un système cryptographique qui utilise des clés de 128 bits. Si ces clés sont dérivées en utilisant un générateur de nombres pseudo-aléatoires fixe qui est amorcé avec une graine de 8 bits, alors un adversaire n'a besoin de parcourir que 256 clés (en exécutant le générateur de nombres pseudo-aléatoires avec chaque graine possible), et non 2^128 clés comme cela peut sembler être le cas à première vue. Seulement 8 bits "d'information" sont dans ces clés de 128 bits.
Bien que l'analyse ci-dessus soit correcte en moyenne, elle peut être trompeuse dans certains cas pour l'analyse cryptographique où ce qui est vraiment important est le facteur de travail pour un adversaire. Par exemple, supposons qu'il y ait un générateur de nombres pseudo-aléatoires générant des clés de 128 bits, comme dans le paragraphe précédent, mais qu'il génère zéro la moitié du temps et une sélection aléatoire parmi les 2^128 - 1 valeurs restantes le reste du temps. L'équation de Shannon ci-dessus indique qu'il y a 64 bits d'information dans l'une de ces valeurs de clé, mais un adversaire, simplement en essayant la valeur zéro, peut briser la sécurité de la moitié des utilisations, bien qu'une moitié aléatoire. Ainsi, pour des fins cryptographiques, il est également utile de regarder d'autres mesures, telles que l'entropie minimale, définie comme
Entropie minimale = - log ( maximum ( p ) )
i
où i est comme ci-dessus. En utilisant cette équation, nous obtenons 1 bit d'entropie minimale pour notre nouvelle distribution hypothétique, par opposition à 64 bits d'entropie de Shannon classique.
Un spectre continu d'entropies, parfois appelé entropie de Renyi, a été défini, spécifié par le paramètre r. Ici r = 1 est l'entropie de Shannon et r = infini est l'entropie minimale. Lorsque r = zéro, c'est juste log (n), où n est le nombre de probabilités non nulles. L'entropie de Renyi est une fonction non croissante de r, donc l'entropie minimale est toujours la mesure la plus conservatrice d'entropie et généralement la meilleure à utiliser pour l'évaluation cryptographique [LUBY].
L'aléa testé statistiquement au sens traditionnel N'EST PAS la même chose que l'imprévisibilité requise pour une utilisation de sécurité.
Par exemple, l'utilisation d'une séquence constante largement disponible, telle que la table aléatoire des CRC Standard Mathematical Tables, est très faible contre un adversaire. Un adversaire qui l'apprend ou la devine peut facilement briser toute sécurité, future et passée, basée sur la séquence [CRC]. Comme autre exemple, utiliser AES avec une clé constante pour chiffrer des entiers successifs tels que 1, 2, 3, ... produira une sortie qui a également d'excellentes propriétés statistiques d'aléa mais est prévisible. D'autre part, prendre des lancers successifs d'un dé à six faces et encoder les valeurs résultantes en ASCII produirait une sortie statistiquement médiocre avec une composante imprévisible substantielle. Donc notez que passer ou échouer des tests statistiques ne révèle pas si quelque chose est imprévisible ou prévisible.