Chiffrement de flux dans la vrai vie (20 min)

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