-
Je donnerai ici quelques exemples de chiffrements
de flux qui sont utilisés en pratique.
-
Je vais débuter avec deux vieux exemples
qui ne devraient pas
-
être utilisés pour de nouveaux systèmes.
Néanmoins, ils sont largement
-
utilisés, et je veux donc simplement les nommer
pour que ces concepts vous soient
-
familiers. Le premier chiffrement de flux
s'appelle RC4, il a été conçu
-
en 1987. Je n'en donnerai qu'une
description de haut niveau, et ensuite
-
nous parlerons de quelques faiblesses de RC4.
Donc RC4 prend
-
une semence de taille variable;
j'utiliserai un exemple où cette semence
-
est de 128 bits, ce qui serait utilisé
comme clé pour le chiffrement de flux.
-
D'abord, il augmente la clé secrète de
128-bits à 2048 bits qui
-
seront utilisés comme l'état interne
pour le générateur. Ensuite, une fois faite
-
cette expansion, il exécute une boucle
très simple où chaque itération de
-
boucle produit un octet. Essentiellement,
on peut donc faire marcher le générateur
-
aussi longtemps que l'on veut et générer
un octet à la fois. En fait, RC4 est
-
plutôt populaire. Il est utilisé
couramment dans le protocole HTTPS.
-
Par exemple, Google utilise RC4 pour son
HTTPS. Il est aussi utilisé dans WEP, comme
-
nous avons dit dans le dernier segment.
Mais dans WEP, il est utilisé incorrectement
-
sans la moindre sécurité.
Au fil des ans, on a trouvé
-
quelques vulnérabilités dans RC4 et on
recommande donc que les nouveaux projets
-
n'utilisent pas RC4 mais un générateur
pseudo-aléatoire moderne, ce dont nous
-
discuterons vers la fin du segment.
Mentionnons juste deux vulnérabilités.
-
La première est un peu bizare. Si on
regarde le second octet
-
de la sortie de RC4. Il s'avère que le second
octet est légèrement biaisé. Si RC4 était
-
complètement aléatoire, la probabilité
que le second octet soit égale à zéro
-
serait exactement de 1/256: il y a 256
bytes possibles, donc la probabilité
-
qu'il soit zéro devrait être de 1/256.
Or pour RC4, la probabilité est en fait
-
de 2/256. Ce qui veut dire que si tu
utilises l'output de RC4 pour encrypter un
-
message, le second octet n'est
probablement pas encrypté: ce sera
-
donc XOR-é avec zéro pour le double de la probabilité qui
est attendu. ////
-
Donc 2 sur 256, plutôt que 1 sur 156. Et en passant,
je dois mentionné qu'il
-
n'y rien de spécial dans le second octet à encrypté. Il s'avère que le premier et le troisième octet
-
sont également biaisés. Et en fait, c'est maintenant recommandé que pour toute utilisation de RC4
-
les premiers 256 octets devrait être ignoré et
-
commence à utiliser la sortie du générateur juste à partir du 257e octet. La première série
-
d'octets est en fait biaisée. Donc il faut les ignorés. La deuxième attaque qui
-
a été découverte est qu'en fait lorsqu'on observe une très longue sortie de RC4
-
il est plus probable d'obtenir la séquence 00. Autrement dit, il est plus
-
probable d'obtenir sur seize bits deux octet de zéro zéro (0,0) que la normale.
Encore une fois si RC4
-
serait totalement aléatoire la probabilité de retrouver zéro, zéro devrait être exactement 1/256
-
au carré. Il s'avère que RC4 est légèrement biaisé et le biais est 1/256 au cube. C'est
-
ce biais qui débute après plusieurs giga-octets de donnés produites par
-
RC4. Néanmoins, c'est quelquechose qui peut être utilisé
pour prévoir le générateur
-
et définitivement, cela peut être utilisé pour distingué la sortie du générateur
-
d'une séquence réellement aléatoire. Simplement le fait que zéro apparaît plus souvent
-
qu'il ne le devrait. Dans le dernier segment, nous avons abordé
-
les attaques liées à la clé qui étaient uiltisées pour attaquer WEP qui disait que
-
si on utilise des clés qui sont étroitement reliées une à l'autre
alors c'est possible
-
de retrouver la clé racine. Donc ceci complète les vulnérabilités connues sur RC4,
-
conséquemment il est recommandé que les nouveaux systèmes n'utilise pas RC4 mais plutôt un
-
générateur pseudo-aléatoire moderne. Okay, comme deuxième exemple que je veux vous donner est un