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