WEBVTT

00:00:00.000 --> 00:00:04.010
Je donnerai ici quelques exemples de chiffrements 
de flux qui sont utilisés en pratique.

00:00:04.010 --> 00:00:07.072
Je vais débuter avec deux vieux exemples 
qui ne devraient pas

00:00:07.072 --> 00:00:11.017
être utilisés pour de nouveaux systèmes. 
Néanmoins, ils sont largement

00:00:11.017 --> 00:00:14.164
utilisés, et je veux donc simplement les nommer 
pour que ces concepts vous soient

00:00:14.164 --> 00:00:19.087
familiers. Le premier chiffrement de flux 
s'appelle RC4, il a été conçu

00:00:19.087 --> 00:00:23.429
en 1987. Je n'en donnerai qu'une 
description de haut niveau, et ensuite

00:00:23.429 --> 00:00:27.818
nous parlerons de quelques faiblesses de RC4. 
Donc RC4 prend

00:00:27.818 --> 00:00:32.702
une semence de taille variable; 
j'utiliserai un exemple où cette semence

00:00:32.702 --> 00:00:36.980
est de 128 bits, ce qui serait utilisé 
comme clé pour le chiffrement de flux.

00:00:36.980 --> 00:00:41.738
D'abord, il augmente la clé secrète de 
128-bits à 2048 bits qui

00:00:41.738 --> 00:00:46.382
seront utilisés comme l'état interne 
pour le générateur. Ensuite, une fois faite

00:00:46.382 --> 00:00:51.197
cette expansion, il exécute une boucle 
très simple où chaque itération de

00:00:51.197 --> 00:00:55.898
boucle produit un octet. Essentiellement, 
on peut donc faire marcher le générateur

00:00:55.898 --> 00:01:00.653
aussi longtemps que l'on veut et générer 
un octet à la fois. En fait, RC4 est

00:01:00.653 --> 00:01:05.205
plutôt populaire. Il est utilisé 
couramment dans le protocole HTTPS.

00:01:05.205 --> 00:01:11.888
Par exemple, Google utilise RC4 pour son 
HTTPS. Il est aussi utilisé dans WEP, comme

00:01:11.888 --> 00:01:15.686
nous avons dit dans le dernier segment. 
Mais dans WEP, il est utilisé incorrectement

00:01:15.686 --> 00:01:18.861
sans la moindre sécurité. 
Au fil des ans, on a trouvé

00:01:18.861 --> 00:01:23.886
quelques vulnérabilités dans RC4 et on 
recommande donc que les nouveaux projets

00:01:23.886 --> 00:01:28.793
n'utilisent pas RC4 mais un générateur 
pseudo-aléatoire moderne, ce dont nous

00:01:28.793 --> 00:01:34.059
discuterons vers la fin du segment. 
Mentionnons juste deux vulnérabilités.

00:01:34.059 --> 00:01:39.561
La première est un peu bizare. Si on 
regarde le second octet

00:01:39.561 --> 00:01:44.630
de la sortie de RC4. Il s'avère que le second 
octet est légèrement biaisé. Si RC4 était

00:01:44.630 --> 00:01:49.780
complètement aléatoire, la probabilité 
que le second octet soit égale à zéro

00:01:49.780 --> 00:01:54.744
serait exactement de 1/256: il y a 256 
bytes possibles, donc la probabilité

00:01:54.744 --> 00:01:59.646
qu'il soit zéro devrait être de 1/256. 
Or pour RC4, la probabilité est en fait

00:01:59.646 --> 00:02:04.486
de 2/256. Ce qui veut dire que si tu 
utilises l'output de RC4 pour encrypter un

00:02:04.486 --> 00:02:09.574
message, le second octet n'est 
probablement pas encrypté: ce sera

00:02:09.574 --> 00:02:14.575
donc XOR-é avec zéro pour le double de la probabilité qui
est attendu. ////

00:02:14.575 --> 00:02:19.436
Donc 2 sur 256, plutôt que 1 sur 156. Et en passant, 
je dois mentionné qu'il

00:02:19.436 --> 00:02:22.849
n'y rien de spécial dans le second octet à encrypté. Il s'avère que le premier et le troisième octet

00:02:22.849 --> 00:02:27.818
sont également biaisés. Et en fait, c'est maintenant recommandé que pour toute utilisation de RC4

00:02:27.818 --> 00:02:32.800
les premiers 256 octets devrait être ignoré et

00:02:32.800 --> 00:02:37.246
commence à utiliser la sortie du générateur juste à partir du 257e octet. La première série

00:02:37.246 --> 00:02:41.241
d'octets est en fait biaisée. Donc il faut les ignorés. La deuxième attaque qui

00:02:41.241 --> 00:02:48.482
a été découverte est qu'en fait lorsqu'on observe une très longue sortie de RC4

00:02:48.482 --> 00:02:53.863
il est plus probable d'obtenir la séquence 00. Autrement dit, il est plus

00:02:53.863 --> 00:02:58.970
probable d'obtenir sur seize bits deux octet de zéro zéro (0,0) que la normale.
Encore une fois si RC4

00:02:58.970 --> 00:03:03.948
serait totalement aléatoire la probabilité de retrouver zéro, zéro devrait être exactement 1/256

00:03:03.948 --> 00:03:08.556
au carré. Il s'avère que RC4 est légèrement biaisé et le biais est 1/256 au cube. C'est

00:03:08.556 --> 00:03:13.718
ce biais qui débute après plusieurs giga-octets de donnés produites par

00:03:13.718 --> 00:03:18.634
RC4. Néanmoins, c'est quelquechose qui peut être utilisé
pour prévoir le générateur

00:03:18.634 --> 00:03:23.120
et définitivement, cela peut être utilisé pour distingué la sortie du générateur

00:03:23.120 --> 00:03:28.097
d'une séquence réellement aléatoire. Simplement le fait que zéro apparaît plus souvent

00:03:28.097 --> 00:03:32.414
qu'il ne le devrait. Dans le dernier segment, nous avons abordé

00:03:32.414 --> 00:03:36.313
les attaques liées à la clé qui étaient uiltisées pour attaquer WEP qui disait que

00:03:36.313 --> 00:03:41.078
si on utilise des clés qui sont étroitement reliées une à l'autre 
alors c'est possible

00:03:41.078 --> 00:03:45.732
de retrouver la clé racine. Donc ceci complète les vulnérabilités connues sur RC4,

00:03:45.732 --> 00:03:50.217
conséquemment il est recommandé que les nouveaux systèmes n'utilise pas RC4 mais plutôt un

00:03:50.217 --> 00:03:54.421
générateur pseudo-aléatoire moderne. Okay, comme deuxième exemple que je veux vous donner est un