0:00:00.000,0:00:04.010
Je donnerai ici quelques exemples de chiffrements [br]de flux qui sont utilisés en pratique.

0:00:04.010,0:00:07.072
Je vais débuter avec deux vieux exemples [br]qui ne devraient pas

0:00:07.072,0:00:11.017
être utilisés pour de nouveaux systèmes. [br]Néanmoins, ils sont largement

0:00:11.017,0:00:14.164
utilisés, et je veux donc simplement les nommer [br]pour que ces concepts vous soient

0:00:14.164,0:00:19.087
familiers. Le premier chiffrement de flux [br]s'appelle RC4, il a été conçu

0:00:19.087,0:00:23.429
en 1987. Je n'en donnerai qu'une [br]description de haut niveau, et ensuite

0:00:23.429,0:00:27.818
nous parlerons de quelques faiblesses de RC4. [br]Donc RC4 prend

0:00:27.818,0:00:32.702
une semence de taille variable; [br]j'utiliserai un exemple où cette semence

0:00:32.702,0:00:36.980
est de 128 bits, ce qui serait utilisé [br]comme clé pour le chiffrement de flux.

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

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

0:00:46.382,0:00:51.197
cette expansion, il exécute une boucle [br]très simple où chaque itération de

0:00:51.197,0:00:55.898
boucle produit un octet. Essentiellement, [br]on peut donc faire marcher le générateur

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

0:01:00.653,0:01:05.205
plutôt populaire. Il est utilisé [br]couramment dans le protocole HTTPS.

0:01:05.205,0:01:11.888
Par exemple, Google utilise RC4 pour son [br]HTTPS. Il est aussi utilisé dans WEP, comme

0:01:11.888,0:01:15.686
nous avons dit dans le dernier segment. [br]Mais dans WEP, il est utilisé incorrectement

0:01:15.686,0:01:18.861
sans la moindre sécurité. [br]Au fil des ans, on a trouvé

0:01:18.861,0:01:23.886
quelques vulnérabilités dans RC4 et on [br]recommande donc que les nouveaux projets

0:01:23.886,0:01:28.793
n'utilisent pas RC4 mais un générateur [br]pseudo-aléatoire moderne, ce dont nous

0:01:28.793,0:01:34.059
discuterons vers la fin du segment. [br]Mentionnons juste deux vulnérabilités.

0:01:34.059,0:01:39.561
La première est un peu bizare. Si on [br]regarde le second octet

0:01:39.561,0:01:44.630
de la sortie de RC4. Il s'avère que le second [br]octet est légèrement biaisé. Si RC4 était

0:01:44.630,0:01:49.780
complètement aléatoire, la probabilité [br]que le second octet soit égale à zéro

0:01:49.780,0:01:54.744
serait exactement de 1/256: il y a 256 [br]bytes possibles, donc la probabilité

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

0:01:59.646,0:02:04.486
de 2/256. Ce qui veut dire que si tu [br]utilises l'output de RC4 pour encrypter un

0:02:04.486,0:02:09.574
message, le second octet n'est [br]probablement pas encrypté: ce sera

0:02:09.574,0:02:14.575
donc XOR-é avec zéro pour le double de la probabilité qui[br]est attendu. ////

0:02:14.575,0:02:19.436
Donc 2 sur 256, plutôt que 1 sur 156. Et en passant, [br]je dois mentionné qu'il

0:02:19.436,0: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

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

0:02:27.818,0:02:32.800
les premiers 256 octets devrait être ignoré et

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

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

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

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

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

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

0:03:03.948,0: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

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

0:03:13.718,0:03:18.634
RC4. Néanmoins, c'est quelquechose qui peut être utilisé[br]pour prévoir le générateur

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

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

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

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

0:03:36.313,0:03:41.078
si on utilise des clés qui sont étroitement reliées une à l'autre [br]alors c'est possible

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

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

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