1
00:00:00,000 --> 00:00:04,010
Je donnerai ici quelques exemples de chiffrements 
de flux qui sont utilisés en pratique.

2
00:00:04,010 --> 00:00:07,072
Je vais débuter avec deux vieux exemples 
qui ne devraient pas

3
00:00:07,072 --> 00:00:11,017
être utilisés pour de nouveaux systèmes. 
Néanmoins, ils sont largement

4
00:00:11,017 --> 00:00:14,164
utilisés, et je veux donc simplement les nommer 
pour que ces concepts vous soient

5
00:00:14,164 --> 00:00:19,087
familiers. Le premier chiffrement de flux 
s'appelle RC4, il a été conçu

6
00:00:19,087 --> 00:00:23,429
en 1987. Je n'en donnerai qu'une 
description de haut niveau, et ensuite

7
00:00:23,429 --> 00:00:27,818
nous parlerons de quelques faiblesses de RC4. 
Donc RC4 prend

8
00:00:27,818 --> 00:00:32,702
une semence de taille variable; 
j'utiliserai un exemple où cette semence

9
00:00:32,702 --> 00:00:36,980
est de 128 bits, ce qui serait utilisé 
comme clé pour le chiffrement de flux.

10
00:00:36,980 --> 00:00:41,738
D'abord, il augmente la clé secrète de 
128-bits à 2048 bits qui

11
00:00:41,738 --> 00:00:46,382
seront utilisés comme l'état interne 
pour le générateur. Ensuite, une fois faite

12
00:00:46,382 --> 00:00:51,197
cette expansion, il exécute une boucle 
très simple où chaque itération de

13
00:00:51,197 --> 00:00:55,898
boucle produit un octet. Essentiellement, 
on peut donc faire marcher le générateur

14
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

15
00:01:00,653 --> 00:01:05,205
plutôt populaire. Il est utilisé 
couramment dans le protocole HTTPS.

16
00:01:05,205 --> 00:01:11,888
Par exemple, Google utilise RC4 pour son 
HTTPS. Il est aussi utilisé dans WEP, comme

17
00:01:11,888 --> 00:01:15,686
nous avons dit dans le dernier segment. 
Mais dans WEP, il est utilisé incorrectement

18
00:01:15,686 --> 00:01:18,861
sans la moindre sécurité. 
Au fil des ans, on a trouvé

19
00:01:18,861 --> 00:01:23,886
quelques vulnérabilités dans RC4 et on 
recommande donc que les nouveaux projets

20
00:01:23,886 --> 00:01:28,793
n'utilisent pas RC4 mais un générateur 
pseudo-aléatoire moderne, ce dont nous

21
00:01:28,793 --> 00:01:34,059
discuterons vers la fin du segment. 
Mentionnons juste deux vulnérabilités.

22
00:01:34,059 --> 00:01:39,561
La première est un peu bizare. Si on 
regarde le second octet

23
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

24
00:01:44,630 --> 00:01:49,780
complètement aléatoire, la probabilité 
que le second octet soit égale à zéro

25
00:01:49,780 --> 00:01:54,744
serait exactement de 1/256: il y a 256 
bytes possibles, donc la probabilité

26
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

27
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

28
00:02:04,486 --> 00:02:09,574
message, le second octet n'est 
probablement pas encrypté: ce sera

29
00:02:09,574 --> 00:02:14,575
donc XOR-é avec zéro pour le double de la probabilité qui
est attendu. ////

30
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

31
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

32
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

33
00:02:27,818 --> 00:02:32,800
les premiers 256 octets devrait être ignoré et

34
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

35
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

36
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

37
00:02:48,482 --> 00:02:53,863
il est plus probable d'obtenir la séquence 00. Autrement dit, il est plus

38
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

39
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

40
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

41
00:03:08,556 --> 00:03:13,718
ce biais qui débute après plusieurs giga-octets de donnés produites par

42
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

43
00:03:18,634 --> 00:03:23,120
et définitivement, cela peut être utilisé pour distingué la sortie du générateur

44
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

45
00:03:28,097 --> 00:03:32,414
qu'il ne le devrait. Dans le dernier segment, nous avons abordé

46
00:03:32,414 --> 00:03:36,313
les attaques liées à la clé qui étaient uiltisées pour attaquer WEP qui disait que

47
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

48
00:03:41,078 --> 00:03:45,732
de retrouver la clé racine. Donc ceci complète les vulnérabilités connues sur RC4,

49
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

50
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