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