Cryptographie TP

Bruce Schneier
Cryptographie appliquée
Deuxième édition
Protocoles, algorithmes
et codes cource en C
Traduction de Laurent Viennot

Table des matières
P ré fa ce xiii
Comment lire ce livre ........................................................................................... xiv
R em erciem ents....................................................................................................... xvii
À p ro p o s de l’ au teu r x ix
1 P rin cip e s d e base 1

1.1 Terminologie ................................................................................................ 1
1.2 Steganographie............................................................................................. 9
1.3 Substitution et transposition....................................................................... 10
1.4 Ou exclusif s i m p l e ..................................................................................... 14
1.5 Masque j e t a b l e ................. 15
1.6 Algorithmes inform atiques.......................................................................... 18
1.7 Grands nom bres............................................................................................. 18
1 Protocoles cryptographiques 21
2 B riqu es élém en taires 23

2.1 Introduction aux p r o t o c o le s ...................................................................... 23
2.2 Communications à l’aide d ’un cryptosystèmeà clef s e crè te................... 30
2.3 Fonctions à sens unique ............................................................................ 31
2.4 Fonctions de hachage à sens u n iqu e.......................................................... 32
2.5 Communications à l’aide d ’un cryptosystèmeà clef p u b liq u e............... 33
2.6 Signatures num ériques................................................................................ 37
2.7 Signatures numériques avec chiffrement................................................ 44
2.8 Générateurs aléatoires et pseudo-aléatoires............................................. 47
3 P r o to c o le s élém en taires 51
3.1 Échange de clefs ......................................................................................... 51
3.2 Authentification............................................................................................ 56
3.3 Authentification et échange de c le fs ......................................................... 61
3.4 Analyse formelle des protocoles d ’authentification et d ’échange de clefs 70
3.5 Cryptographie à clef publique à clefs multiples....................................... 74
3.6 Secret m orcelé............................................................................................... 75
3.7 Secret r é p a r t i............................................................................................... 77
TABLE DES MATIÈRES
3.8 Protection cryptographique de bases dedonnées.................................... 80
4 P r o to c o le s in term édiaires 81
4.1 Services de datation ................................................................................ 81
4.2 Canal su b lim in a l......................................................................................... 85
4.3 Signatures numériques incontestables....................................................... 87
4.4 Signatures numériques à vérificateurd é d ié ............................................... 88
4.5 Signatures par procuration......................................................................... 89
4.6 Signatures collectives................................................................................... 90
4.7 Signatures numériques « Fail-Stop »..... ..................................................... 91
4.8 Calcul avec données chiffrées...................................................................... 92
4.9 Mise en gage ............................................................................................... 92
4.10 Jouer à pile ou f a c e ...................................................................................... 95
4.11 Poker à l’a v e u g le ......................................................................................... 99
4.12 Accumulateurs à sens unique ................................................................... 102
4.13 Divulgation tout ou rien de s e c r e t s .......................................................... 103
4.14 Dépôt de c le f s ............................................................................................... 103
5 P r o to c o le s avancés 109
5.1 Preuves à divulgation nulle ...................................................................... 109
5.2 Identification par preuve à divulgation n u lle .......................................... 117
5.3 Signatures en aveugle ................................................................................ 120
5.4 Cryptographie à clef publique à based ’identification . . . . . . . . . 123
5.5 Transfert in con scien t.................................................................................. 124
5.6 Signatures in conscien tes............................................................................ 126
5.7 Signature simultanée de co n tr a t................................................................ 127
5.8 Courrier électronique certifié...................................................................... 131
5.9 Echange simultané de s e c r e t s ................................................................... 132
6 P r o to c o le s ésotériq u es 135
6.1 Elections sûres ............................................................................................ 135
6.2 Calcul réparti s û r ......................................................................................... 144
6.3 Diffusion de messages anonymes . 148
6.4 Argent électronique . . . . . . . 150
II Techniques cryptographiques 161
7 L on g u eu r des clefs 163

7.1 Longueur des clefs secrètes......................................... ............ 163
7.2 Longueur des clefs publiques...................................................................... 170
7.3 Comparaison de la longueur des clefssecrètes et des clefs publiques . 178
7.4 Attaques des anniversaires contre unefonction de hachage à sens unique 178
7.5 Quelle doit être la longueur de clef? ..................................................... 179
7.6 Avertissement............................................................................................... 180
TABLE DES MATIÈRES vii
8 G e stio n des clefs 181

8.1 Génération de c l e f s ......................................................................................... 182
8.2 Espaces des clefs non linéaires...................................................................... 188
8.3 Transfert de c l e f s ............................................................................................ 188
8.4 Vérification de clefs ...................................................................................... 190
8.5 Utilisation des c le fs ......................................................................................... 192
8.6 Mise à jour des c l e f s ...................................................................................... 193
87 Stockage des c le f s ............................................................................................ 193
8.8 Duplicata des c l e f s ......................................................................................... 194
8.9 Clefs co m p ro m ise s......................................................................................... 195
8.10 Longévité des c l e f s ......................................................................................... 196
8.11 Destruction des c l e f s ...................................................................................... 197
8.12 Gestion des clefs pour la cryptographie à clef p u b liq u e .......................... 198
9 T y p e s et m o d e s d ’a lgorith m es 201
9.1 Carnet de codage électronique.................................................................... 202
9.2 Bloc rejoué ................................................................................................... 203
9.3 Mode de chiffrement avec chaînage de b l o c s ........................................... 205
9.4 Algorithmes de chiffrement en c o n t in u .................................................... 209
9.5 Chiffrement autosynchrone en c o n t i n u ....................................................... 211
9.6 Chiffrement à rétroaction ............................................................................. 212
9.7 Chiffrement synchrone en co n tin u ................................................................ 214
9.8 Mode de rétroaction de s o r t i e ................................................ 216
9.9 Mode « compteur » ......................................................................................... 219
9.10 Autres m o d e s .................................................................................................. 220
9.11 Choix d’un mode opératoire de chiffrement.................................. 222
9.12 Intercalation..................................................................................................... 223
9.13 Chiffrement par blocs vs chiffrement en co n tin u ....................................... 225
10 U tilisa tion des a lgorith m es 227

10.1 Choix d’un a lgorith m e................................................................................... 228
10.2 La cryptographie à clef publique vs la cryptographie à clef secrète . . 230
10.3 Chiffrement des canaux de com m unication................................................ 230
10.4 Chiffrement des données à des fins de stockage ...................................... 235
10.5 Chiffrement matériel vs chiffrement logiciel ............................................. 237
10.6 Compression, codage et chiffrem ent............................................................. 240
10.7 Détection du chiffrem ent............................................................................... 241
10.8 Cacher du texte chiffré dans du texte c h iffré ............................................. 242
10.9 Destruction d’in fo rm a tio n ............................................................................ 243
III Algorithmes cryptographiques 245
11 R u d im en ts m ath ém a tiqu es 247

11.1 Théorie de l’in form a tion ............................................................................... 247
11.2 Théorie de la com p lex ité............................................................................... 251
11.3 Théorie des n o m b r e s ..................................................................................... 256
11.4 Factorisation .................................................................................................. 271
TABLE DES MATIÈRES
11.5 Génération de nombres premiers ............................................................ 274

11.6 Logarithmes discrets dans un corps fini . . . 278
12 Le D E S 281
12.1 H istoriqu e...................................................................................................... 281
12.2 Description du DES....................................................................................... 286
12.3 Niveau de sécurité du D E S • 296
12.4 Cryptanalyse différentielle et linéaire ............ . . . 302
12.5 Les critères réels de conception . . . . . . . . 311
12.6 Variantes du DES ........................ 312
12.7 A quel point le DES est-il sûr de nos j o u r s ? . . 318
13 A u tres a lgorith m es d e ch iffrem en t par b lo cs 321

13.1 L ucifer . - 321
13.2 M a d r y g a ........ ................................................................. 322
13.3 N e w D E S ..................................................................................................... 325
13.4 F E A L ............................................................................................................ 325
13.5 R E D O C ......................................................................................................... 331
13.6 L O K I ............................................................................................................ 332
13.7 K hufu et K hafre ........................................................................................ 335
13.8 R C 2 ............................................................................................................... 337
13.9 I D E A ............................................................................................................ 338
13.10 M M B ............................... ............................................................. 345
13.11 C A - 1 . 1 ......................................................................................................... 346
13.12 S k i p j a c k ..................................................................................................... 347
14 E n co re d ’au tres algorith m es de ch iffrem ent par b lo c s 351

14.1 G O S T ........................................................................................................... 351
14.2 C A S T ............................................................................................................ 354
14.3 B l o w f is h ..................................................................................................... 355
14.4 S A F E R ....................................... ................................................................ 359
14.5 3 - W A Y ................................ .................................................................. 361
14.6 C R A B ........................................................................................................... 362
14.7 SX A L 8 et M B A L ..................................................................................... 364
14.8 R C 5 .............................................................................................................. 364
14.9 Autres algorithmes dechiffrementpar blocs . . 366
14.10 Théorie des algorithmes dechiffrement par blocs . 366
14.11 Utilisation de fonction dehachageà sens unique...................................... 372
14.12 Choisir un algorithme de chiffrement par blocs . 375
15 C o m b in a iso n d ’ algorith m es de ch iffrem ent par b lo cs 377

15.1 Surchiffrement double ..................................................................... 377
15.2 Surchiffrement t r i p l e ............................................ 379
15.3 Doublement de la longueur deb l o c ........................................................... 384
15.4 Autres schémas de surchiffrement . 384
15.5 Troncature de clef (dans C D M F ) . 387
15.6 Blanchim ent.................................................................................................. 387
15.7 Mise en cascade de plusieursalgorithm es................................................. 388
TABLE DES MATIÈRES IX
15.8 Combiner plusieurs algorithmes de chiffrement par b l o c s ................... 389
16 G én érateu rs de su ites aléa toires et ch iffrem ent en con tin u 391

16.1 Générateurs pseudo-aléatoires de suites................................................... 391
16.2 Registres à décalage à rétroaction lin é a ir e ............................................. 395
16.3 Conception et analyse d’algorithmes de chiffrement en continu . . . . 402
16.4 Chiffrement en continu à base de R D R L ................................................ 403
16.5 A 5 ................................................................................................................ 412
16.6 H ugues X P D / K P D ................................................................................ 413
16.7 N a n o t e q ................................................................................................... 413
16.8 R a m b u t a n ................................................................................................ 414
16.9 Générateurs a d d i t if s ................................................................................ 414
16.10 G ifford ................................................................................................... 416
16.11 A lgorithm e M ...................................................................................... 417
16.12 P K Z IP ...................................................................................................... 417
17 A u tre s algorith m es d e ch iffrem en t e n con tin u et générateurs

d e suites v raim en t aléatoires 419
17.1 R C 4 ............................................................................................................. 419
17.2 S E A L .......................................................................................................... 420
17.3 W A K E ....................................................................................................... 423
17.4 Registres à décalage à rétroaction avec r e t e n u e .................................. 424
17.5 Chiffrement en continu à base de R D R R .............................................. 427
17.6 Registres à décalage à rétroaction non linéaire..................................... 433
17.7 Autres algorithmes de chiffrement en c o n t i n u ..................................... 435
17.8 Approche par la théorie des systèm es.................................................... 436
17.9 Approche par la théorie de la com plexité.............................................. 437
17.10 Autres approches à la conception d ’algorithmes de chiffrement en conti
nu ................................................................................................................. 439
17.11 Chiffrement en continu en cascade ........................................................ 441
17.12 Choisir un algorithme de chiffrement en con tin u .................................. 442
17.13 Génération de plusieurs flux à partir d’un seul générateur pseudo
aléatoire de suites........................................................................................ 442
17.14 Générateurs de suites vraiment aléatoires ........................................... 444
18 F on ction s d e hachage à sens u n iqu e 453

18.1 Introduction................................................................................................ 453
18.2 Snefru ................................................................................................... 455
18.3 N -H a s h ...................................................................................................... 457
18.4 M D 4 ............................................................................................................. 458
18.5 M D 5 ............................................................................................................ 460
18.6 M D 2 ............................................................................................................ 465
18.7 Algorithme sûr de hachage SHA .......................................................... 465
18.8 R I P E - M D ................................................................................................ 469
18.9 H A V A L ...................................................................................................... 469
18.10 Autres fonctions de hachage à sens u n iq u e ........................................... 470
18.11 Utilisation d ’algorithmes de chiffrement par b l o c s .............................. 471
18.12 Utilisation d ’algorithmes à clef p u b liq u e .............................................. 479
X TABLE DES MATIÈRES
18.13 Choix d’une fonction de hachage à sensu n i q u e .................................... 479

18.14 Codes d ’authentification de m essages..................................................... 479
19 A lg o rith m e s à c le f p u b liq u e 485

19.1 Introduction................................................................................................ 485
19.2 Algorithmes à em pilem ent........................................................................ 486
19.3 R S A ............................................................................................................. 491
19.4 P ohlig - H ellman ................................................................................. 499
19.5 R a b i n .......................................................................................................... 500
19.6 E l G a m a l ................................................................................................... 501
19.7 M c E liece ................................................. 504
19.8 Cryptosystèmes à courbes elliptiqu es..................................................... 505
19.9 L U C ............................................................................................................. 506
19.10 Automates fin is .......................................................................................... 507
20 A lg o rith m e s d e sign atu re n u m ériqu e à c le f p u b liq u e 509

20.1 Algorithme de signature numérique D SA ............ 509
20.2 Variantes de D SA .................................................................................... 520
20.3 Algorithme de signature numérique G O S T . 522
20.4 Schémas de signature numérique à basede logarithmes discrets . . 523
20.5 O ng Schnork S h a m ir . . 525
20.6 E S I G N ...................................................................................................... 526
20.7 Automates cellulaires................................................................................. 527
20.8 Les autres algorithmes à clef publique ................................................ 527
21 Schém as d ’ id en tifica tion 531

21.1 F eige - F iat - S hamir .............................................................................. 531
21.2 G uillou - Q u i s q u a t e r ........................................................................... 536
21.3 Sc h n o r r .................................................................................................... 538
21.4 Convertir un schéma d ’identification en un schéma de signature numé
rique .............................................................................................................. 540
22 A lg o rith m e s d ’éch an ge d e clefs 541

22.1 D iffie - H ellman .................................................................................... 541
22.2 Protocole point à p o in t............................................................................. 544
22.3 Protocole à trois passes de Sh a m i r ....................................................... 544
22.4 C O M S E T .................................................................................................... 545
22.5 Échange de clefs chiffré............................................................................. 546
22.6 Négociation de clef fortifiée .................................................................... 550
22.7 Distribution de clef de conférence et diffusion de s e c r e t..................... 551
23 A lg o rith m e s sp éciau x p o u r p r o to c o le s 555

23.1 Cryptographie à clef publique à clefs multiples.................................... 555
23.2 Algorithmes de partage de s e c r e t .......................................................... 556
23.3 Canal s u b lim in a l....................................................................................... 560
23.4 Signatures numériques incontestables.................................................... 565
23.5 Signatures numériques à vérificateur d é d ié ........................................... 567
23.6 Calcul avec données chiffrées.................................................................... 569
TABLE DES MATIÈRES xi
23.7 Pile ou face équitable................................................................................. 570

23.8 Accumulateurs à sens unique ................................................................. 572
23.9 Divulgation tout ou rien de s e c r e t s ........................................................ 572
23.10 Cryptosystèmes équitables et à sûreté intégrée . . . . 575
23.11 Preuves à divulgation nulle .................................................................... 577
23.12 Signatures en aveugle................................................................................. 579
23.13 Transfert in con scien t................................................................................. 579
23.14 Calcul réparti s û r ....................................................................................... 580
23.15 Chiffrement prob a b iliste.......................................................................... 582
23.16 Cryptographie quantique.......................................................................... 584
IV Le monde réel 587

24 E x em p les d e réa lisation 589
24.1 Protocole IBM de gestion de clefs secrètes........................................... 589
24.2 M I T R E N E T .............................................................................................. 590
24.3 RNIS .......................................................................................................... 591
24.4 S T U - I I I ....................................................................................................... 593
24.5 K e r b e r o s .................................................................................................... 594
24.6 K r y p t o K n i g h t ....................................................................................... 600
24.7 SESAME .................................................................................................... 600
24.8 Architecture cryptographique commune d’I B M .................................. 601
24.9 Environnement d’authentification I S O .................................................. 602
24.10 « Privacy-Enhanced Mail » ( P E M ) .......................................................... 606
24.11 « Message Security Protocol » (M SP ) .................................................... 612
24.12 « Pretty G ood Privacy » (P G P ) ........................................................... 613
24.13 Cartes à p u c e .............................................................................................. 615
24.14 « Public-Key Cryptography Stan
dards » (P K C S) ........................................................................................ 616
24.15 Système de paiement électronique u n iv e r s e l........................................ 618
24.16 C l i p p e r ....................................................................................................... 620
24.17 C a p s t o n e .................................................................................................... 622
24.18 Modèle 3600 du dispositif de sécurité du téléphone d ’A T & T . . . . 623
25 P o litiq u e 625
25.1 « National Security Agency » ( N S A ) ...................................................... 625
25.2 « National Computer Security Center » (N C SC ).................................... 627
25.3 « National Institute of Standards and Technology »( N I S T ) .............. 628
25.4 R SA D ata Se c u r it y , In c ....................................................................... 632
25.5 « Public Key Partners » ( P K P ) ............................................................... 632
25.6 « International Association for Cryptologie Research »(IACR) . . . 634
25.7 « R A C E Integrity Primitives Evaluation » (R IP E ) . . . . . 634
25.8 « Conditional Access for Europe » ( C A F E ) .......................................... 635
25.9 « ISO/IEC 9979 » ......................................................................................... 636
25.10 Groupes industriels, de défense des libertés civiles, et professionnelles 637
25.11 S c i .c r y p t ................................................................................................... 638
25.12 C y p h e r p u n k s .......................................................................................... 638
xii TABLE DES MATIÈRES
25.13 Brevets......................................................................................................... 639

25.14 Réglementation américaine à l’exportation .................................. 639
25.15 Importation et exportation decryptographie............................... 647
25.16 L é g a lit é ...................................................................................................... 648
P o stfa ce de M a tt B la ze 651
V Code source 655

D E S .......................................................................................................................... 657
L O K I 9 1 ................................................................................................................. 675
I D E A ....................................................................................................................... 685
G O S T ....................................................................................................................... N701
B l o w f i s h ................................................................................................................ 711
3-W a y ....................................................................................................................... 721
R C 5 .......................................................................................................................... 727
A 5 ............................................................................................................................. 729
S E A L ....................................................................................................................... 735
L ex iq u e anglais—français 741
B ib lio g ra p h ie 747
In d ex 827
Préface
Il existe deux types de cryptographie dans le monde: la cryptographie qui empêche

votre petite sœur de lire vos fichiers, et la cryptographie qui empêche les principaux
gouvernements de lire vos fichiers. Ce livre traite de la deuxième.
Je prends une lettre, l’enferme dans un coffre et cache ce coffre quelque part dans New
York... si je vous demande ensuite de lire la lettre, il n’est pas question de sécurité:
c’est de l’obscurité. Autre exemple : je prends une lettre, l’enferme dans un coffre et
vous donne le coffre avec ses spécifications de conception et une centaine d’autres
coffres identiques avec leurs combinaisons, de telle manière que vous et les meilleurs
perceurs de coffres-forts puissiez étudier le mécanisme de verrouillage... si vous ne
pouvez toujours pas ouvrir le coffre contenant la lettre, il est alors question de sécurité.
Pendant de nombreuses années, ce type de cryptographie était le domaine exclusif des
militaires. La « National Security Agency » américaine et ses contreparties en ex-Union
soviétique, au Royaume-Uni, en France, en Israël, et partout ailleurs, ont dépensé des
milliards de dollars au jeu très sérieux de la protection de leurs propres communications,
tout en essayant de casser toutes celles des autres. Le particulier, avec nettement moins
d ’expertise et de budget, était impuissant à protéger sa propre vie privée vis-à-vis de
ces gouvernements.
Durant ces vingt dernières années, il y a eu une explosion de recherche académique
publique en cryptographie. Alors que la cryptographie classique est utilisée depuis
longtemps par des citoyens ordinaires, la cryptographie par ordinateur était le domaine
réservé des militaires depuis la Seconde Guerre mondiale. De nos jours, la cryptographie
à la pointe de l’art est pratiquée en dehors de la protection des murs des agences
militaires. Le profane peut maintenant employer des techniques cryptographiques qui
le protègent contre les adversaires les plus puissants — à un niveau de sécurité qui
pourrait même le protéger des agences militaires pour plusieurs années à venir.
Est-ce que l’individu moyen a besoin de ce type de sécurité? Je l’affirme. Il peut prépa
rer une campagne politique, il peut discuter de ses impôts, ou avoir une liaison illicite.
Il peut concevoir un nouveau produit, discuter d’une stratégie de commercialisation,
ou préparer une prise de pouvoir commerciale agressive. Il peut vivre dans un pays
qui ne respecte pas le droit à la vie privée de ses citoyens. Il peut faire quelque chose
qu’il estime ne pas être illégal mais qui l’est. Peu importe les raisons, ses données et
ses communications sont personnelles, privées et ce n’est l’affaire de personne d’autre
à part lui.
Ce livre est publié en des temps troubles. L’administration C l i n t o n a adopté le pro
gramme « Escrowed Encryption Standard» (qui repose sur la puce CLlPPERet la carte
F o r t e z z a ) et le projet de loi « Digital Telephony ». Ces deux initiatives tendent à
xiv Préface
donner au gouvernement la possibilité de mener des surveillances électroniques.

Cela repose sur la dangeureuse hypothèse orwelienne que le gouvernement a le droit
d ’écouter les communications privées, et qu’il y a anguille sous roche si un citoyen tente
de dissimuler un secret au gouvernement. Les lois ont toujours permis de mener une
éventuelle surveillance avec l’autorisation des tribunaux. Mais c ’est la première fois
que chacun est contreint de participer activement pour rendre sa surveillance possible.
Ces initiatives ne sont pas seulement des propositions gouvernementales concernant
un domaine obscur, elles sont une tentative préventive et unilatérale d’usurper des
pouvoirs qui relevaient de chacun.
C l ip p e r et la loi « Digital Telephony » ne protègent pas la vie privée : elles obligent
les individus à avoir confiance inconditionnellement dans le Gouvernement quant au
respect de leur vie privée. Elle émet l’hypothèse que le Gouvernement fait partie des
bons et que tous les citoyens font partie des méchants. Les mêmes autorités légales qui
ont placé des écoutes illégales sur les lignes téléphoniques de Martin Luther King Jr.
peuvent facilement espionner un téléphone protégé par une puce C l ip p e r . Durant ces
cinq dernières années, les autorités de police locales ont été poursuivies pénalement ou
civilement dans de nombreuses juridictions — y compris le Maiyland, le Connecticut, le
Vermont, la Géorgie, le Missouri et le Nevada — pour avoir placé des écoutes illégales.
C ’est une mauvaise idée de déployer une technologie qui pourrait un jour aider un état
policier.
On peut en tirer la leçon qu’il est insuffisant de se protéger avec des lois, il faut se
protéger avec les Mathématiques. Le chiffrement est trop important pour être laissé au
gouvernement.
Ce livre vous donne les moyens de préserver votre vie privée ; les appareils de chiffrement
peuvent être déclarés illégaux, mais l’information ne le sera jamais.
Comment lire ce livre

J’ai écrit Applied Cryptography comme un ouvrage de référence exhaustif sur la cryp
tographie moderne. J’ai privilégié la lisibiüté du texte sans pour autant sacrifier l’exac
titude et la précision. Ce livre ne se veut pas un traité mathématique. Bien que je
n’aie pas donné délibérément de fausses informations, j ’ai été cavalier avec la théo
rie. Pour ceux qui sont intéressés par le côté formel, il y a de nombreuses références
bibliographiques de la littérature académique.
Le premier chapitre introduit la cryptographie, définit de nombreux termes et présente
brièvement la cryptographie avant l’ère informatique.
Les chapitres 2 à 6 (première partie) présentent les protocoles cryptographiques. Les
protocoles vont du plus simple (envoyer un message chiffré d ’une personne à l’autre) au
plus complexe (jouer à pile ou face par téléphone) et à l’ésotérique (l’échange d ’argent
électronique sûr et anonyme). Certains de ces protocoles sont évidents, d’autres sont
presque ahurissants. La cryptographie permet de résoudre de nombreux problèmes que
la plupart des gens n’ont jamais réalisé qu’il soit possible de les résoudre.
Les chapitres 7 à 10 (deuxième partie) présentent les techniques cryptographiques.
Les quatre chapitres de cette partie sont tous importants même pour l’utilisation la
plus élémentaire de la cryptographie. Les chapitres 7 et 8 traitent des clefs : quelle
doit être la longueur d’une clef pour qu’elle soit sûre, comment engendrer les clefs,
comment stocker les clefs, comment détruire les clefs, etc. La gestion des clefs est la
Préface xv
partie la plus difficile de la cryptographie, et est souvent le tendon d’Achille de systèmes

cryptographiques qui seraient sinon très sûrs. Le chapitre 9 présente différents moyens
d’utiliser les algorithmes cryptographiques, et le chapitre 10 donne les tenants et les
aboutissements des algorithmes : comment choisir, réaliser, et utiliser des algorithmes.
Les chapitres 11 à 23 (troisième partie) fournissent une liste d ’algorithmes, le livre dé
crit finalement les algorithmes. Le chapitre 11 donne des fondements mathématiques.
Ce chapitre n’est obligatoire que si vous êtes intéressé par les algorithmes à clef pu
blique. Si vous voulez seulement réaliser le DES (ou quelque chose de similaire), vous
pouvez passer ce chapitre. Le chapitre 12 décrit le D E S : l’algorithme, son histoire,
sa sécurité, et quelques variantes. Le chapitre 13, 14 et 15 décrivent d’autres algo
rithmes à clef secrète. Si vous voulez quelque chose de plus sûr que le DES, lisez la
section sur ID E A ou sur le DES triple. Si vous voulez prendre connaissance de plu
sieurs algorithmes, dont certains pourraient être plus sûrs que le DES, lisez les trois
chapitres. Les algorithmes 16 et 17 traitent des algorithmes de chiffrement en continu.
Le chapitre 18 concerne les fonctions de hachage à sens unique: M D5 et SHA sont
les plus communes bien que j ’en décrive beaucoup d ’autres. Le chapitres 19 décrit les
algorithmes à clef publique, le chapitre 20 concerne les algorithmes de signature nu
mérique à clef publique. Les algorithmes importants sont R SA , D SA , F ia t - S h a m ir
et D if f ie H e l l m a n respectivement. Le chapitre 23 contient des algorithmes à clef
publique et des protocoles plus ésotériques ; les mathématiques peuvent se compliquer :
attachez votre ceinture.
Les chapitres 24 et 25 (quatrième partie) se tournent vers le monde réel de la cryp
tographie. Le chapitre 24 décrit quelques réalisations concrètes de ces algorithmes et
de ces protocoles, tandis que chapitre 25 aborde le contexte politique qui entoure la
cryptographie. Ceux-ci n’ont aucunement la prétention d’être exhaustifs.
Enfin, ce livre contient les codes sources de dix des algorithmes de la troisième partie.
Je n’ai pas pu inclure autant de codes que je l’aurait souhaité pour des raisons de
limitation en place, et sans quoi les codes sources cryptographiques n’auraient pas pu
être exportés. (Aussi surprenant que cela puisse paraître, le Département d’Etat amé
ricain a autorisé l’exportation de la première édition ce livre avec les codes sources qu’il
contenait, mais a refusé l’exportation d’une disquette de codes sources contenant exac
tement les mêmes codes sources. Allez savoir.) Un jeu de disquettes inclus bien plus de
codes sources que je ne pouvais en donner dans ce livre ; cela constitue probablement la
plus grande bibliothèque de codes sources cryptographiques hors des institutions mili
taires. Je ne peux envoyer des disquettes de codes sources qu’aux citoyens américains
ou canadiens vivant aux Etats-Unis ou au Canada, mais cela devrait heureusement
changer un jour.
S’il y avait une critique à faire de ce livre, c’est que sa nature encyclopédique le rend
moins lisible. C ’est vrai, mais je voulais offrir une seule référence pour ceux qui pour
raient rencontrer un algorithme dans la littérature académique ou dans un produit. À
ceux qui s’intéressent plus à un cours d’introduction, je présente mes excuses. Beaucoup
est fait dans ce domaine. C ’est la première fois que tant de choses ont été rassemblées
sous un même chapeau. Même ainsi, il y a de nombreuses choses que le manque de
place m’a obligé à laisser de côté. J’ai essayé de couvrir les sujets que je trouvais soit
importants, d ’intérêt pratique, ou intéressants. Quand je n’ai pu traiter un sujet en
profondeur, j ’ai donné les références des publications qui le font.
J’ai fait la chasse aux erreurs du mieux que j ’ai pu, mais de l’avis général c ’est quasi
xvi Préface
impossible de n’en laisser aucune. La seconde édition contient sûrement moins d’erreurs
que la première. Je tiens à votre disposition une liste des errata qui est périodiquement
postée au group USENET s c i . c r y p t . Si quelqu’un trouve une erreur, s’il vous plaît,
avertissez-moi. Pour chaque erreur, la première personne qui me la signale recevra une
copie gratuite de la disquette1.
1. N ote du traducteur : cette offre n ’est valable que pou r l’édition am éricaine de l’ouvrage.
Préface xvii
Remerciements
La liste des gens qui ont contribué à la réalisation de ce livre semble infinie mais ils
méritent tous d ’être mentionnés. Je tiens à remercier Don A l v a r e z , R oss A n d e r s s o n ,
Dave B a l e n s o n , Karl B a r r u s , Steve B e l l o v i n , Dan B e r n s t e i n , Eli B i h a m , Joan
B o y a r , Karen C o o p e r , W hit D if f ie , Joan F e i g e n b a u m , Phil K a r n , Neal K o b l i t z ,
Xuejia L a i , Tom L e r a n t h , Mike M a r k o w i t z , Ralph M e r k l e , Bill P a t t o n , Peter
P e a r s o n , Charles P f l e e g e r , Ken P iz z i n i , Bart P r e n e e l , Mark R io r d a n , Joachim
S c h u r m a n , et Marc S c h w a r t z pour avoir lu et corrigé tout ou partie du ma
nuscrit de la première édition; Marc VÀUCLAIR pour avoir traduit la première édi
tion en français ; Abe A b r a h a m , Ross A n d e r s o n , Dave B a n i s a r , Steve B e l l o v i n ,
Edi B i h a m , Matt B is h o p , Matt B l a z e , Gary C a r t e r , Jan C o m e n is c h , Claude
C r é p a u , Joan D a e m e n , Jorge D a v i l a , Ed D a w s o n , Whit D if f ie , Cari E l l is o n ,
Joan F e i g e n b a u m , Niels F e r g u s o n , Matt F r a n k l i n , Rosario G e n n a r o , Dieter
G ollm ' a n n , Mark G o r e s k y , Richard G r a v e m a n , Stuart H a b e r , Jingman H e , bob
H o g u e , Kenneth I v e r s e n , Markus J a k o b s s o n , Burt K a l i s k i , Phil K a r n , John
K e l s e y , John K e n n e d y , Lars K n u d s e n , Paul K o c h e r , John L a d w i g , Xuejia L a i ,
Arjen L e n s t r a , Paul L e y l a n d , Mike M a r k o w i t z , Jim M a s s e y , Bruce M c N a i r ,
William H u g h M u r r a y , Roger N e e d h a m , Clif N e u m a n , Kaisa N y b e r g , Luke
O ’ C o n n o r , Peter P e a r s o n , René P e r a l t a , Bart P r e n e e l , Yisrael R a d a i , Matt
R o b s h a w , Michael R o e , Phil R o g a w a y , Avi R u b i n , Paul R u b i n , Selwyn R u s s e l l ,
Kazue S a k o , Mahmoud S a l m a s i z a d e h , Markus S t a d l e r , Dmitry T i t o v , Jimmy
U p t o n , Marc V a u c l a i r , Serge V a u d e n a y , Gideon Y u v a l , Glen Z o r n , et plusieurs
employé anonymes du gouvernement américain pour avoir lu et édité plusieurs parties
de la seconde édition ; Lawrie B r o w n , Leisa C o n d i e , Joan D a e m e n , Peter G u t m a n n ,
Alan I n s l e y , Chris J o h n s t o n , John K e l s e y , Xuejia L a i , Bill L e i n i n g e r , Mark
M a r k o w i t z , Richard O u t e r b r i d g e , Peter P e a r s o n , Ken P iz z i n i , Colin P l u m b ,
Steph R a v a n o n a , R S A D a t a S e c u r i t y , I n c ., Michael R o e , Michael W o o d , et
Phil Z i m m e r m a n n pour m’avoir fourni des codes sources ; Paul M a c N e r l a n d pour
avoir réalisé les figures de la première édition; Karen C o o p e r pour son travail de
secrétaire de rédaction pour la seconde édition ; Beth F r i e d m a n pour avoir revu et
corrigé la seconde édition ; Carol K e n n e d y pour avoir fait l’index de la seconde édi
tion; les lecteurs de s c i .c r y p t et de la liste de courrier électronique Cypherpunks
pour avoir commenté des idées, avoir répondu à des questions et avoir corrigé des er
reurs dans la première édition ; Randy S e u s s pour avoir fourni un accès à l’iNTERNET ;
Jeff D u n t e m a n n et Jon E r ic k s o n pour m ’avoir aidé à commencer ; la famille I n s l e y
pour avoir donné l’impulsion, les encouragements, le soutien, les conversations, l’amitié
et les dîners ; et A T & T B e l l L a b s pour m ’avoir licencié et pour avoir rendu tout cela
possible. Ces personnes m’ont aidé à créer un livre bien meilleur que ce que j ’aurais pu
faire tout seul.
Bruce S c h n e ie r
Oak Park, 111.
schneier@couterpane.coin
A propos de l’auteur
Bruce S c h n e ie r est le président de C o u n t e r p a n e S y s t e m s , une entreprise de conseil

en cryptographie et sécurité en informatique, située à Oak Park dans l’Illinois aux
États-Unis. Bruce S c h n e ie r est aussi l’auteur de E-Mail Security (J o h n W il e y &
F il s , 1995) et Protect Your Macintosh (P e a c h p i t P r e s s , 1994) ; et a écrit des dou
zaines douzaines d ’articles dans les principales revues. Il est l’un des éditeurs associé
de Dr. Dobb’s Journal où il gère la colonne « Algorithms Alley », il est aussi éditeur
associé de Computer and Communication Security Reviews. Bruce S c h n e ie r officie
dans le conseil de direction de VInternational Association for Cryptologie Research,
il est membre du conseil consultatif du Electronic Privacy Information Center, et il
fait parti du comité de programme du New Security Paradigms Workshop. En plus de
tout cela, il trouve du temps pour donner de fréquents exposés sur la cryptographie,
la sécurité en informatique, et la confidentialité.
Chapitre 1
Principes de base
1.1 Terminologie
Expéditeur et destinataire
Supposons qu’un expéditeur veut envoyer un message à un destinataire. Cet expéditeur
veut envoyer le message de manière sûre: il veut s’assurer qu’aucune oreille indiscrète
ne puisse s’informer du message.
Messages et chiffrement
Un message est appelé te x te en clair. Le processus de transformation d ’un message de
telle manière à le rendre incompréhensible est appelé chiffrem ent (ou en cry p tion ).
Le résultat de ce processus de chiffrement est appelé te x te chiffré (ou encore c r y p to
gram m e). Le processus de reconstruction du texte en clair à partir du texte chiffré est
appelé déch iffrem en t (ou d é cry p ta g e ). Ces différents processus sont illustrés par la
figure 1.1.
FlG. 1.1 — Chiffrement et déchiffrement
L’art et la science de garder le secret de messages est appelé cry p to g ra p h ie pratiquée

par des cry p to g ra p h e s. Les cry p ta n a lystes pratiquent la cry p ta n a lyse qui est l’art
de décrypter des messages chiffrés. La branche des mathématiques qui traite de la cryp
tographie et de la cryptanalyse s’appelle la cr y p to lo g ie et ses pratiquants sont appelés
cryp tologu es. De nos jours, presque tous les cryptologues sont des mathématiciens
théoriciens par la force des choses.
Le texte en clair est noté A L Ce peut être une suite de bits, un fichier de texte, un
enregistrement de voix numérisé, ou une image vidéo numérique. Du point de vue de
2 Chapitre 1 Principes de base
l’ordinateur, A i n’est rien d’autre que de l’information binaire1. Le texte en clair peut
être transmis ou stocké. Dans tous les cas, A i est le message à chiffrer.
Le texte chiffré est noté C. C ’est aussi de l’information binaire, parfois de la même
taille que A i, parfois plus grand2. La fonction de chiffrement, notée E , transforme A i
en C. Ce qui en notation mathématique s’écrit :
E ( M ) = C.
La fonction inverse, notée D, de déchiffrement transforme C en A i :
D{C) = A i.
Comme le but de toutes ces opérations n’est rien d’autre que de retrouver le message
en clair à partir de la version chiffrée de ce même message, l’identité suivante doit être
vérifiée :
D ( E ( M ) ) = A i.
Authentification, intégrité, non désaveu

En plus de la confidentialité, on attend souvent de la cryptographie d’accomplir d ’autres
tâches:
1. A u th e n tifica tio n . Le destinataire d ’un message doit pouvoir s’assurer de son

origine. Un intrus ne doit pas être capable de se faire passer pour quelqu’un
d ’autre.
2. In tég rité. Le destinataire d ’un message doit pouvoir vérifier que celui-ci n’a
pas été modifié en chemin. Un intrus doit être incapable de faire passer un faux
message pour un légitime.
3. N o n désaveu. Un expéditeur ne doit pas pouvoir, par la suite, nier à tort avoir
envoyé un message.
Ce sont des exigences vitales en matière d ’interactions sociales par ordinateur; elles
sont l’analogue des rencontres face à face. Quelqu’un est-il celui qu’il prétend être? La
pièce d’identité, le permis de conduire, le diplôme de médecin, ou le passeport d’une
personne sont-ils valides? Ce sont les questions auxquelles l’authentification, l’intégrité,
et le non désaveu répondent.
Algorithmes cryptographiques
Un a lgorith m e cry p to g ra p h iq u e est une fonction mathématique utilisée pour le
chiffrement et le déchiffrement3.
1. A partir du chapitre suivant, ce livre ne traite que de cryptographie appliquée à de l’inform ation
binaire.
2. En com binant com pression et chiffrement, C peut être plus petit que A 4. Toutefois, en général,
le chiffrement à lui seul ne fait pas l’opération de com pression.
3. Généralement, un algorithm e cryptographique com prend deux fonctions: une pour chiffrer et
l’autre pou r déchiffrer.
1.1 Terminologie 3
Si la sécurité d’un algorithme est basée sur le fait que celui-ci est tenu secret, on parlera
alors d ’algorithme restreint. De tels algorithmes ne présentent plus qu’un intérêt
historique car de nos jours ils sont inadéquats pour les besoins actuels de sécurité.
Un groupe d ’utilisateurs important ou variable ne peut utiliser de tels algorithmes
car chaque fois qu’un membre quitte le groupe, tous les autres doivent se mettre à
utiliser un autre algorithme. Si quelqu’un révèle accidentellement le secret, tout le
mende doit changer d’algorithme. Encore plus accablant, les algorithmes restreints
ne permettent aucun contrôle de qualité et aucune standardisation. Chaque groupe
d’utilisateurs doit avoir son propre algorithme. Un tel groupe ne peut pas utiliser de
produits tout faits, matériels ou logiciels, vendus dans le commerce; un espion peut
acheter le même produit et apprendre l’algorithme. Ils leur faut écrire leur propres
algorithmes et les programmer eux même. S’il n’y a pas de bon cryptographe dans le
groupe, ils ne sauront pas s’ils ont un algorithme sûr.
Malgré cela, les algorithmes restreints sont très populaires pour les applications à bas
niveau de sécurité. Les utilisateurs ne réalisent pas, ou bien ne se soucient pas des
problèmes de sécurité inhérents à leur système.
La cryptographie moderne résoud ce problème avec une clef, notée k. Cette clef peut
prendre une des valeurs parmi un grand nombre de valeurs possibles. L ’ensemble des
valeurs possibles d ’une clef est appelé esp ace d es clefs. Les opérations de chiffrement
et de déchiffrement utilisent toutes les deux cette clef (i.e., elles dépendent de la clef
et ceci est dénoté par l’indice k), aussi les fonctions s’écrivent de la manière suivante:
E k{ M ) = C
D k(C) = M .
Ces fonctions vérifient la propriété suivante (voir la figure 1.2): :
D k(Ek( M ) ) = M .
FlG. 1.2 - Chiffrement et déchiffrement avec une clef
Certains algorithme utilisent des clefs différentes pour le chiffrement et le déchiffre-

ment(voir la figure 1.3). Dans ce cas, la clef de chiffrement, notée ki, est différente de
la clef de déchiffrement, notée k,2 - Les relations suivantes décrivent un tel cryptosys
tème:
E kl( M ) = C
D k2(C) - M
D k2(Ekl( M ) ) = M .
Avec ces algorihtmes, toute la sécurité réside dans la (ou les) clef(s), et non dans
les détails de l’algorithme. Ceci implique que l’algorithme peut être publié et anlysé.
Clef de Clef de
chiffrement déchiffrement
Texte en clair
Texte en clair
1 Texte chiffré original
.
Chiffrement Déchiffrement
F ig. 1.3 - Chiffrement et déchiffrement avec deux clefs
On peut fabriquer en masse un produit utilisant cet algorithme. Peu importe qu’une
espionne connaisse votre algorihtme; si elle ignore votre clef, elle ne pourra pas lire vos
messages.
Un cryptosystème est composé d ’un algorithme, et de tous les textes en clairs, textes
chiffrés, et clefs possibles.
Algorithmes à clef secrète

Il y a deux types principaux d ’algorithmes à base de clefs : à clef secrète ou à clef pu
blique. Les algorith m es à c le f secrète sont des algorithmes où la clef de chiffrement
peut être calculée à partir de la clef de déchiffrement ou vice versa. Dans la plupart
des cas, la clef de chiffrement et la clef de déchiffrement sont identiques. Pour de tels
algorithmes, l’émetteur et le destinataire doivent se mettre d ’accord sur une clef à
utiliser avant d’échanger des messages. Cette clef doit être gardée secrète. La sécurité
d ’un algorithme à clef secrète repose sur la clef : si celle-ci est dévoilée, alors n’importe
qui peut chiffrer ou déchiffrer des messages dans ce cryptosystème.
Le chiffrement et le déchiffrement dans un algorithme à clef secrète sont notés :
E k{ M ) = C
D k(C) = M .
Les algorithmes à clef secrète peuvent être classés en deux catégories. Certains opèrent
sur le message en clair un bit à la fois. Ceux-ci sont appelés algorith m es de chif
frem ent en continu. D ’autres opèrent sur le message en clair par groupes de bits.
Ces groupes de bits sont appelés b lo cs, et les algorithmes correspondants sont appelés
a lgorith m es d e ch iffrem en t par b lo cs. Pour des algorithmes réalisés sur ordina
teur, la taille typique des blocs est de 64 bits — ce qui est assez grand pour interdire
l’analyse et assez petit pour être pratique4.
Algorithmes à clef publique

Les algorith m es à c le f p u b liq u e sont différents. Ils sont conçus de telle manière
que la clef de chiffrement soit différente de la clef de déchiffrement. De plus, la clef de
déchiffrement ne peut pas être calculée (du moins en un temps raisonnable) à partir
de la clef de chiffrement. De tels algorithmes sont appelés « à clef publique » parce que
la clef de chiffrement peut être rendue publique : n ’importe qui peut utiliser la clef de
4. Autrefois, avant l’utilisation de l’ou til inform atique, les algorithm es manipulaient généralement le
texte en clair caractère par caractère. Vous pouvez considérer de tels algorithm es com m e un chiffrement
en continu d ’ un caractère à la fois.
1.1 Terminologie 5
chiffrement pour chiffrer un message mais seul celui qui possède la clef de déchiffrement
peut déchiffrer le message chiffré résultant. Dans de tels systèmes, la clef de chiffrement
est appelée c le f p u b liq u e et la clef de déchiffrement est appelée c le f privée. La clef
privée est aussi parfois appelée c le f secrète mais pour éviter toute confusion avec les
algorithmes à clef secrète, ce terme ne sera pas utilisé ici.
Le chiffrement en utilisant la clef publique k est noté :
E k( M ) = C .
Bien que les clefs publique et privée soient différentes, le déchiffrement avec la clef
privée correspondante est noté :
D k(C) = M .
Parfois, les messages seront chiffrés avec la clef privée et déchiffrés avec la clef publique ;
une telle technique est utilisée pour les signatures numériques (voir § 2.6). Malgré le
risque de confusion possible, ces opérations seront notées :
E k{ M ) = C
D k(C) = M .
Cryptanalyse
Le but principal de la cryptographie est de préserver le texte en clair de l’indiscré
tion des espions (aussi appelés adversaires, attaquants, intercepteurs, intrus, oppo
sants, oreilles indiscrètes, cryptanalystes, décrypteurs, ou tout simplement ennemis).
On suppose que les espions ont plein accès aux communications entre l’expéditeur et
le destinataire.
La cryptanalyse est la science de la reconstitution du texte en clair sans connaître
la clef. Une cryptanalyse réussie peut fournir soit le texte en clair, soit la clef. La
cryptanalyse peut également mettre en évidence les faiblesses d’un cryptosystème qui
peuvent éventuellement faciliter les attaques contre celui-ci5.
Une tentative de cryptanalyse est appelée attaque. Un des axiomes fondamentaux
de la cryptographie, énnoncé pour la première fois par l’hollandais A. Kerckhoffs au
dixneuvième siècle, est que l’ennemi possède tous les détails de l’algorithme et qu’il ne
lui manque que la clef spécifique utilisée pour le chiffrement [795]6. Bien que cela ne
soit pas toujours le cas dans le monde réel de la cryptanalyse, c ’est toujours vrai dans
le monde académique de la cryptanalyse, et c ’est de toute façon une bonne assertion
dans le monde réel de la cryptanalyse. Si l’on ne sait pas casser un algorithme même
en sachant comment il fonctionne, on ne sait certainement pas le casser sans cette
connaissance.
Il y a quatre types génériques d’attaques cryptanalytiques. Il va de soi que chacune
d’entre elles repose sur l’hypothèse que le cryptanalyste dispose de la connaissance
complète de l’algorithme de chiffrement :
1. L ’a ttaq u e à te x te ch iffré seu lem en t. Le cryptanalyste dispose du texte chif
fré de plusieurs messages, tous ayant été chiffrés avec le même algorithme. La
5. La perte d ’ une clef par des moyens autres que la cryptanalyse est appelée com prom ission.
6. Bien sûr, on peut supposer que la C IA n ’ a pas l’habitude de com m uniquer au M ossad quoique
ce soit au sujet de ses algorithm es. Bien que le M ossad le découvre de toute façon...
tâche du cryptanalyste est de retrouver le texte en clair du plus grand nombre

de messages possible ou mieux encore de trouver la ou les clefs qui ont été utili
sées pour chiffrer les messages ce qui permettrait de déchiffrer d’autres messages
chiffrés avec ces mêmes clefs.
Données: Ci = E k ( M i ) , C 2 = E k ( M 2),...,C i = E k ( M t ).
Requis: Soit A i i , M 2, - . , M i , soit k, soit un algorithme permettant de déduire
M i+ 1à partir de Ci+i = E k { M i + 1 ).
2. L ’a tta q u e à te x te en cla ir con n u . Le cryptanalyste a non seulement accès aux

textes chiffrés de plusieurs messages mais aussi aux textes en clair correspondants.
La tâche est de retrouver la ou les clef(s) utilisées pour chiffrer ces messages ou
un algorithme qui permet de déchiffrer n’importe quel nouveau message chiffré
avec la même clef.
D o n n é e s: M k,C i = E k { M i ) , M 2,C2 = E k ( M 2) , . . . , M t ,Ct — E k { M r).
R eq u is : Soit k, soit un algorithme permettant de déduire A f,+ i à partir de

C i+ i = Ek{M.r+ 1).
3. L ’a ttaq u e à te x te en cla ir c h o is i7. Non seulement le cryptanalyste a accès

aux textes chiffrés et aux textes en clair mais de plus il peut choisir les textes en
clair à chiffrer. Cette attaque est plus efficace que l’attaque à texte en clair connu
car le cryptanalyste peut choisir des textes en clair spécifiques qui donneront plus
d ’informations sur la clef. La tâche consiste à retrouver la ou les clefs utilisées
pour chiffrer ces messages ou un algorithme qiii permette de déchiffrer n’importe
quel nouveau message chiffré avec la même clef.
D o n n é e s: M i , C i = E k ( M \ ) , M 2,C2 = E k ( M 2) , . . . , M i , C t = E k ( M %), où le
cryptanalyste choisit A 4 i , A 4 2,...,A 4 i.
R e q u is : Soit k , soit un algorithme permettant de déduire JAt+i à partir de
f'ï+l --
4. L ’attaq u e à te x te en clair ch oisi a d a p ta tiv e 8. C ’est un cas particulier de

l’attaque à texte en clair choisi. Non seulement le cryptanalyste peut choisir les
textes en clair mais il peut également adapter ses choix en fonction des textes
chiffrés précédents. Dans une attaque à texte en clair choisi, le cryptanalyste est
juste autorisé à choisir un grand bloc de texte en clair au départ tandis que dans
une attaque à texte en clair adaptative, il choisit un bloc initial plus petit et
ensuite il peut choisir un autre bloc en fonction du résultat pour le premier et
ainsi de suite.
Il y a au moins trois autres types d’attaques cryptanalytiques.
1. L ’ atta qu e à te x te ch iffré choisi. Le cryptanalyste peut choisir différents textes

chiffrés à déchiffrer. Les textes déchiffrés lui sont alors fournis. Par exemple, le
cryptanalyste a un dispositif qui ne peut être désassemblé et qui fait du déchif
frement automatique, sa tâche est de retrouver la clef.
7. Parfois appelée « attaque à texte en clair choisi statique » par opp osition à la m éthode décrite
au point suivant.
8. Parfois appelée « attaque à texte en clair choisi dynamique ».
1.1 Terminologie 7
D o n n é e s: C i,A li = £>a..(Ci),C2,A12 = D k (C 2) , —, C i , M t = D k (C i).
R e q u is : k.
Ce type d’ attaque est principalement applicable aux cryptosystèmes à clef pu
blique et sera illustrée dans le paragraphe 19.3. Une attaque à texte chiffré choisi
fonctionne parfois pour les cryptosystèmes à clef secrète9.
2. L ’a ttaq u e à c le f ch oisie. Cela n’est pas une attaque où le cryptanalyste peut

choisir la clef; il est seulement au courant de quelques relations entre différentes
clefs. C ’est étrange et obscur. Ce n’est pas très pratique. Nous y reviendrons au
paragraphe 12.4.
Les attaques à texte en clair connu et les attaques à texte en clair choisi sont plus
courantes que vous ne pourriez l’imaginer. Il arrive qu’un cryptanalyste dispose du
texte en clair d ’un message ou qu’il soudoie quelqu’un pour chiffrer un message choisi.
Parfois, vous n’avez même pas besoin de soudoyer quelqu’un : si vous donnez un mes
sage à un ambassadeur, il y a de fortes chances pour que ce message soit chiffré et
envoyé à son pays d ’origine pour évaluation. Beaucoup de messages ont des en-têtes
et des conclusions qui peuvent être connues ou devinées par le cryptanalyste. Le code
source chiffré est particulièrement vulnérable à cause de l’apparition fréquente des mots
clefs: # d efin e, s tr u c t, e ls e , return. Le code exécutable chiffré souffre de la même
vulnérabilité : dans ce cas ce sont les fonctions, les structures de boucles, etc. qui sont
en cause. Il est connu que des attaques à texte en clair connu (et même à texte en
clair choisi) ont été menées avec succès durant la Seconde Guerre mondiale. Le livre de
David K a h n [468, 469, 470] donne quelques exemples historiques de ce type d’attaques.
Et n’oubliez pas l’axiome de Kerckhoffs: ne comptez pas sur un cryptosystème dont
la résistence réside dans le fait que l’ennemi ne sait pas comment fonctionne votre
algorithme. Vous vous trompez si vous croyez qu’il vaut mieux garder secret les détails
de votre algorithme plutôt que de laisser la communauté scientifique l’analyser. De
plus, il serait naïf de penser que personne ne désassemblera votre code exécutable pour
reconstruire votre algorithme10. Les meilleurs algorithmes dont nous disposions sont
ceux qui ont étés rendus publics et attaqués par les meilleurs cryptographes au monde,
et qui ne sont toujours pas cassés11.
Les cryptanalystes n’ont pas toujours accès à l’algorithme — c ’était le cas quand les
Etats-Unis ont cassé le code diplomatique japonais, P U R P L E , pendant la Seconde
Guerre mondiale [795] mais la plupart du temps ils y ont accès. Si l’algorithme
est utilisé dans un programme commercial de sécurité, c ’est seulement une question
de temps et d ’argent pour désassembler le programme et retrouver l’algorithme. Si
l’algorithme est utilisé dans un système militaire de communication, c’est aussi une
question de temps et d ’argent pour acheter (ou voler) l’équipement et reconstruire
l’algorithme. Il y a beaucoup de cas historiques où les cryptanalystes ne connaissaient
pas l’algorithme ; parfois ils l’ont cassé, parfois ils ont échoué. Dans tous les cas il est
irréaliste de compter sur la confidentialité de l’algorithme.
9. Une attaque â texte en clair choisi menée de front avec une attaque â texte chiffré choisi est
parfois appelée a tta q u e à te x te choisi.
10. C eci est arrivé en 1994 avec l’algorithm e R C 4 voir la section 17.1
11. La « N ational Security A gen cy » garde ses algorithm es secrets, mais les meilleurs cryptographes
travaillent dans ses murs. D e plus, ils s’échangent leurs algorithm es les uns les autres, s’ appuyant sur
leurs pairs pour déceler toute faiblesse dans leurs travaux.
Ceux qui clament avoir un système inviolable seulement parce qu’ils ne peuvent pas
eux-mêmes le casser sont soit des génies, soit des fous. Malheureusement, il y en a plus
de la seconde espèce de par le monde. Attention à ceux qui vantent les vertus de leur
algorithme mais qui refusent de le rendre public : avoir confiance en leur algorithme est
comme faire confiance à un remède de charlatan.
Pour différencier les bons algorithmes des mauvais, les bons cryptographes acceptent
le regard critique de leurs pairs.
Sécurité des cryptosystèmes

Les différents algorithmes ont des niveaux de sécurité divers, plus ou moins difficiles à
casser. Si le coût nécessaire pour casser un algorithme dépasse la valeur de l’information
chiffrée, alors cet algorithme est probablement sûr. Si le temps nécessaire pour casser
un algorithme est plus long que le temps durant lequel l’information chifrée doit rester
secrète, alors cet algorithme est probablement sûr. S’il faut plus d’information pour
casser l’algorithme qu’il n’en a été chiffré avec la même clef, alors votre algorithme est
probablement sûr.
Je dis « probablement » car il est toujours possible qu’une nouvelle avancée soit faite
en cryptanlyse. D ’un autre côté, une information perd de sa valeur avec le temps. Il est
important que la valeur d’une information reste toujours inférieure au coût nécessaire
pour briser la protection qui l’entoure.
Lars Knudsen a classé ces différentes manières de casser un algorithme. Les voici par
ordre décroissant de sévérité:
1. C assage co m p le t. Un cryptanalyste trouve la clef k telle que Dk(C) = Ai.
2. O b te n tio n g lob a le. Un cryptanalyste trouve un algorithme de remplacement

A équivalent à Dy.(C) sans connaître k.
3. O b te n tio n locale. Un cryptanalyste trouve le texte en clair d ’un message chiffré

qu’il a intercepté.
4. O b te n tio n d ’ in fo rm a tio n Un cryptanalyste glane quelque information à pro

pos du texte en clair ou de la clef. Cette information pourrait être certains bits
de la clef, un renseignement sur la forme du texte en clair, et ainsi de suite.
Un algorithme est in con d ition n ellem en t sûr si — peu importe la quantité de texte
chiffré dont le cryptanalyste dispose — il n’y a pas d ’information suffisante pour re
trouver le texte en clair. De fait, seul le masque jetable (voir § 1.5) est invulnérable
étant donné des ressources infinies. Tous les autres cryptosystèmes sont vulnérables à
une attaque à texte chiffré seulement, simplement en essayant toutes les clefs possible
une par une et en regardant si le texte en clair résultant a un sens. Ceci s’appelle une
attaque exh a u stive (voir la section 7.1).
La cryptographie se préoccupe plus particulièrement de cryptosystèmes invulnérables
par calcul. Un algorithme est considéré in vu ln érable par ca lcu l (ou parfois qualifié
de fort), s’il ne peut pas être cassé avec les ressources disponibles actuellement et dans
le futur. Ce qui constitue ces « ressources disponibles » est ouvert à l’interprétation.
1.2 Steganographie 9
On peut mesurer la compiexité(voir la section 7.1) d ’une attaque de l’une ou l’autre

des manières suivantes:
1. C o m p le x ité en in form a tion . La quantité d’information nécessaire en entrée
pour l’algorithme.
2. C o m p le x ité en tem ps. Le temps nécessaire pour achever l’attaque. Ceci est
aussi appellé effort.
3. C o m p le x ité en esp a ce. La quantité de mémoire nécessaire à l’attaque.

Comme règle de base, la complexité d ’une attaque est prise comme le minimum de ces
trois facteurs. Pour certaines attaques, il faut jongler entre les trois complexités: une
attaque peut être plus rapide au prix de besoins en mémoire plus importants.
Les complexités sont exprimées en un ordre de grandeur. Si un algorithme a, par
exemple, un effort de 2128, alors il faut 2128 opérations pour le casser12.
Peu importe, si vous faites l’hypothèse que vous aurez suffisamment de puissance de
calcul pour faire un million d ’opérations par seconde et que vous mettiez un million
de processeurs en parallèle à la tâche, cela prendra encore 1019 années pour retrouver
la clef pour l’exemple donné plus haut. Cela correspond à un milliard de fois l’âge de
l’univers.
Tandis que la complexité d’une attaque est constante (c’est-à-dire, jusqu’à ce qu’un
cryptanalyste trouve une meilleure attaque), la puissance de calcul est tout sauf
constante. Durant ce dernier demi-siècle, il y a eu des progrès phénoménaux en puis
sance de calcul et il n’y pas de raison de penser que cela s’arrêtera si tôt. Nombre
d ’attaques cryptanalytiques sont très bien adaptées aux machines parallèles : la tâche
peut être morcelée en milliards de petites tâches et aucun des processeurs ne doit in-
teragir avec les autres. Annoncer qu’un algorithme est sûr simplement parce qu’on ne
peut pas le casser avec la technologie d’aujourd’hui est hasardeux. Les bons cryptosys
tèmes sont conçus pour être invulnérables même avec les puissances de calcul prévues
d ’ici à de nombreuses années dans le futur.
Terminologie historique
Historiquement, on appelle c o d e un cryptosystème qui sert au niveau des unités linguis
tiques : mots, locutions, phrases, etc. Par exemple, le mot « SOEUR » peut être le texte
chiffré pour la phrase entière : « TOURNER À GAUCHE DE 90 DEGRÉS » ; le mot
« NONNES » peut être le texte chiffré de « TOURNER À DROITE DE 90 DEGRÉS * ;
et les mots « TR A LA LA » peuvent être le texte chiffré pour « OBUSIER » . Les codes
de ce type ne sont pas décrits dans ce livre, ils sont présentés dans [795, 796]. Les codes
sont utiles dans certaines circonstances seulement. Les chiffres sont utiles en toute cir
constance. S’il n’y a pas d ’entrée pour le mot « TROPPO » dans le carnet de codage,
il ne peut pas être « codé ». On peut tout chiffrer à l’aide d’un chiffre.
1.2 Steganographie
La stegan ograph ie sert à cacher des messages secrets dans d’autres messages, de
sorte que l’existence même du secret est dissimulée. Généralement, l’expéditeur écrit
12. Ces opérations peuvent être com plexes et coûteuses en tem ps de calcul.
un message innoffensif et dissimule un message secret dans la même feuille de papier.

Parmi les astuces historiques, on note les encres invisibles, de minuscules trous d’épingle
dans des caractères sélectionnés, d ’infimes changements dans l’écriture manuelle des
caractères, des marques au crayon sur un texte tapé à la machine, etc.
Plus récemment, on peut cacher des messages secrets dans les images graphiques.
Remplacez le dernier bit significatif de chaque point de l’image par celui d’un message;
l’image graphique ne changera pas de manière appréciable— la plupart des standards
graphiques étant spécifiés pour plus de variations de couleurs que l’œil humain ne peut
en saisir— et le destinataire peut récupérer le message. On peut stocker de cette façon
un message de 64 kilo-octets dans une image 1024 par 1024 à nivaux de gris. Il existe
dans le domaine public différentes applications pour faire cela.
Les fo n ctio n s m im étiq u es de Peter Wayner permettent de détourner des messages.
Elles modifient un message de sorte que son profil statistique ressemble à quelque chose
d’autre: une des rubriques classique du New York Times, une pièce de Shakespeare,
ou un groupe de nouvelles sur Internet [1586, 1587]. Cette sorte de stéganographie
ne trompera pas une personne mais elle peut tromper de gros ordinateurs passant au
crible l’Internet à la recherche de messages intéressants.
1.3 Substitution et transposition

Avant l’avènement des ordinateurs, la cryptographie traitait des cryptosystèmes basés
sur les lettres (ou caractères). Les différents algorithmes cryptographiques remplaçaient
des caractères par d’autres ou transposaient les caractères. Les meilleurs systèmes
faisaient les deux opérations plusieurs fois.
C ’est plus complexe de nos jours, mais la philosophie est restée essentiellement la même.
La différence majeure est que les algorithmes actuels manipulent les bits au lieu des
caractères. Ce n’est finalement qu’un changement de taille d ’alphabet : on passe de 26
éléments à 2 éléments. La plupart des bons algorithmes de cryptographie combinent
toujours des substitutions avec des transpositions.
Chiffre à substitution
Un chiffre à su b stitu tio n est un chiffre dans lequel chaque caractère du texte en
clair est remplacé par un autre caractère dans le texte chiffré. Le destinataire applique
la substitution inverse au texte chiffré pour recouvrer le texte en clair.
En cryptographie classique, il y a quatre types de base de substitution :
- Un ch iffre à su b stitu tio n sim ple est un chiffre dans lequel chaque caractère du
texte en clair est remplacé par un caractère correspondant dans le texte chiffré.
Les cryptogrammes publiés dans les journaux sont des exemples de chiffres à
substitution simple.
- Un ch iffre à su b stitu tio n h o m o p h o n iq u e (ou chiffre à su b stitu tion sim ple

à rep résen ta tion m u ltip le) est comme un chiffre à substitution simple, sauf
qu’à un caractère du texte en clair on fait correspondre plusieurs caractères dans
le texte chiffré. Par exemple, « A » peut correspondre à 5, 13, 25 ou 56, « B »
peut correspondre à 7, 19, 31 ou 42 ; etc.
1.3 Substitution et transposition 11
- Un ch iffre à su b stitu tio n sim ple par p oly g ra m m es est un chiffre pour lequel
les caractères sont chiffrés par blocs. Par exemple, « ABA » peut être chiffré par
« RTQ » tandis que « ABB » est chiffré par « SLL ».
- Un ch iffre à su b stitu tio n p o ly a lp h a b é tiq u e est composé à partir de plusieurs

chiffres à substitution simple. Par exemple, il peut y avoir 5 chiffres à substitution
simple utilisés ; celui qui est utilisé dépend de la position du caractère à chiffrer
dans le texte en clair.
Le fameux ch iffre d e Jules C ésar, dans lequel chaque caractère du texte en clair est
remplacé par celui qui se trouve trois places plus loin dans l’alphabet modulo 26 (A est
remplacé par D, B est remplacé par E..., W est remplacé par Z, X est remplacé par A, Y
est remplacé par B, Z est remplacé par C) est un chiffre à substitution simple.
R O T I3 est un programme de chiffrement fréquemment utilisé sur les systèmes UNIX.
Dans ce chiffre, A est remplacé par N , B est remplacé par O , etc. Chaque lettre est
décalée de 13 places. .
Chiffrer un fichier deux fois avec R O T 13 redonne le fichier original :
M = R O T 1 3 (R O T 1 3 (A f)).
R O T I3 n’est pas destiné à la sécurité. Il est souvent utilisé dans les messages de cour
rier électronique pour cacher du texte pouvant être offensant, pour éviter de dévoiler
trop tôt la solution d ’un casse-tête, etc.
Ce type de chiffres peut être facilement cassé car le chiffre ne cache pas les fréquences
sous-jacentes des différents caractères du texte en clair. En langue anglaise, il ne faut
pas plus de 25 caractères du texte chiffré avant qu’un bon cryptanalyste ne puisse
reconstruire le texte en clair [1439]. Un algorithme général pour casser ce genre de
chiffre est décrit dans [581, 589, 1602, 85, 1481, 1246, 880]. Une bonne réalisation sur
ordinateur est donnée dans [700].
Les chiffres à substitution à représentation multiple furent utilisés dès 1401 par le
Duché de Mantoue en Italie [795]. Ils sont biens plus difficiles à casser que les chiffres
à substitution simple, mais toutefois ils ne cachent pas suffisamment les propriétés
statistiques de la langue du texte en clair. Ces chiffres sont trivialement cassés par
une attaque à texte en clair connu. Une attaque à texte chiffré seulement est plus
difficile mais elle ne prend que quelques secondes par ordinateur. Les détails sont donnés
dans [1272].
Les chiffres à substitution simple par polygrammes sont des chiffres dans lesquels les
lettres sont chiffrées par groupe. Le procédé PLAYFAIR, inventé en 1854, était utilisé
par les Britanniques pendant la Première Guerre mondiale [795]. Il chiffre les lettres
par paires. La cryptanalyse de ce procédé est présentée dans [589, 1481, 880]. Le chiffre
de H ill est encore un autre exemple de chiffre à substitution simple par polygrammes
[734]. Les codes de Huffman sont parfois utilisés pour chiffrer, c ’est un chiffre à substi
tution simple par polygrammes qui est peu sûr.
Les chiffres à substitution polyalphabétique ont été inventés par Léon BATTISTA en
1568 [795]. Ils furent utilisés par les Nordistes durant la guerre de Sécession. Bien qu’ils
puissent être facilement cassés [820, 579, 589, 795] (plus particulièrement avec l’aide
d’ordinateurs), nombre de produits commerciaux de sécurité informatique utilisent ce
type de chiffre [1392, 1397, 1506]. La méthode pour casser le système de chiffrement
à substitution polyalphabétique, utilisé par le traitement de texte WordPerfect, est
décrite dans [145, 146J. Le chiffre de V i g e n Èr e et le chiffre de B e a u f o r t sont des

exemples historiques de chiffres à substitution polyalphabétique.
Les chiffres à substitution polyalphabétique utilisent plusieurs clefs monoalphabétiques.
Chaque clef est utilisée à tour de rôle pour chiffrer une lettre du texte en clair (la
première clef pour le premier caractère, la deuxième clef pour le deuxième, et ainsi de
suite). Lorsque toutes les clefs ont été utilisées, on les réutilise en recommençant à la
première. S’il y a ainsi 20 clefs monoalphabétiques, tous les 20 caractères on utilise la
même clef. Le nombre de clefs utilisées donne la p é rio d e du chiffre. En cryptographie
classique, les chiffres avec des périodes longues étaient considérablement plus difficiles à
casser que ceux avec des périodes courtes. Grâce aux ordinateurs, il est facile de casser
même ceux avec des périodes très longues.
Un autre type de chiffre est celui où l’on utilise un autre texte pour chiffrer le texte en
clair. Bien que ce chiffre ait une période égale à la longueur du texte en clair, il peut
aussi être cassé facilement [578, 795].
Chiffre à transposition
Un chiffre à tra n sp o sitio n est un chiffre dans lequel les caractères du texte en clair
demeurent inchangés mais dont les positions respectives sont modifiées. Pour appliquer
la tra n sp o sitio n sim ple en colon n es, on écrit le texte en clair horizontalement sur
un morceau de papier quadrillé de largeur fixe et l’on relève le texte chiffré verticalement
(voir la figure 1.4). Pour déchiffrer le texte chiffré, il suffit d ’écrire verticalement celui-ci
sur un morceau de papier quadrillé de la même largeur et de lire horizontalement le
texte en clair.
Texte en clair
l ’a s s a s s in est le d o cteu r M a t r ix , r e g a r d e z d e r r iè r e l ’h o r l o g e
LASSASSIN
ESTLEDOCT
EURMATRIX
REGARDEZD
ERRIERELH
0RL0GE
Texte chiffré :
LEERE OASUE RRSTR GRLSL M AIOA EAREG SDTDR ESORE EICIZ LN TXD H
F i g . 1.4 - Transposition simple en colonnes
La cryptanalyse de ces chiffres est présentée dans [589, 1481]. Comme les lettres du
texte chiffré sont les mêmes que celles du texte en clair, une analyse statistique de la
fréquence des lettres montre que chaque lettre se comporte à peu près comme dans la
langue d ’origine du texte. Cela donne un indice imprtant au cryptanalyste qui peut
essayer différentes techniques pour retrouver l’ordre correct des lettres. Appliquer une
deuxième transposition au texte chiffré augmente grandement la sécurité. Il y a des
chiffres à transposition encore plus compliqués mais les ordinateurs permettent de les
1.3 Substitution et transposition 13
casser pratiquement tous.

Le procédé allemand A D F G V X , utilisé pendant la Première Guerre mondiale, est un
chiffre à transposition (plus un chiffre à substitution simple). C ’était un algorithme très
compliqué pour l’époque mais il a été cassé par Georges P a i n VIN, un cryptanalyste
français [468].
Bien que de nombreux cryptosystèmes modernes utilisent la transposition, c ’est contrai
gnant parce que la transposition nécessite beaucoup de mémoire et parfois elle impose
que les messages à chiffrer aient une longueur multiple d ’une certaine valeur. La sub
stitution est beaucoup plus utilisée.
Machines à tambours
Dans les années 20, de nombreux dispositifs mécaniques ont été inventés pour automa
tiser le chiffrement. Ils utilisaient une (ou plusieurs) pièce mécanique appelée ta m b ou r
(ou r o to r) qui était conçue de manière à effectuer une opération de substitution.
Une m achines à ta m b o u rs (ou m achines à rotors) a un clavier et un ensemble de
rotors, et réalise une version du chiffre de VlGENÈRE. Chaque rotor est une permutation
arbitraire de l’alphabet, a 26 positions et effectue une substitution simple. Par exemple,
un rotor pouvait être conçu pour substituer « F » à « A » , « U » à « B », « L » à « C »,
etc. Les picots de sortie d ’un rotor entraînent ceux du rotor suivant.
Par exemple, dans une machine à quatre rotors, le premier rotor pouvait substituer
« F » à « A », le deuxième « Y » à « F », le troisième « E » à « Y », et le quatrième « C »
à « E »; « C » étant la sortie dans le texte chiffré. Puis certains rotors se décalent et la
substitution est différente la fois suivante.
C’est la combinaison de tous ces rotors et des engrenages les entraînant qui rendent
cette machine sûre.Comme tous les rotors bougent, et à des vitesses différentes, la pé
riode d’une machine à n rotors est 26” . Certaines machines peuvent avoir des nombres
de positions différents sur chaque rotor, ce qui complique encore plus la tâche du cryp
tanalyste.
La machine à rotors la plus connue est la machine E n i g m a , utilisée par les Allemands
pendant la Seconde Guerre mondiale. L’idée de base est due à Arthur S c h e r b iu s
et Arvid Gerhard D a m m en Europe. Elle a été brevetée aux Etats-Unis par Arthur
S c h e r b iu s [1388]. Les Allemands avaient considérablement étoffé le concept de base
pour leur effort de guerre.
Il y avait un tableau qui permutait légèrement le texte en clair, et un rotor supplémen
taire qui obligeait chaque rotor à opérer deux fois sur chaque lettre. Aussi compliquée
qu’elle fut, la machine ENIGMA a été « cassée » durant la Seconde Guerre mondiale.
Une équipe de cryptographes polonais a cassé une version simplifiée de la machine
E n ig m a , une équipe britannique, dont Alan T u r in g faisait partie, a cassé la vraie
machine E n i g m a . Pour plus d ’informations concernant les machines à rotors et la fa
çon dont elles peuvent être cassées voyez [795, 93, 451, 496, 449, 880, 1326, 1589, 691].
Deux comptes rendus fascinants relatant comment la machine E n i g m a a été cassée
sont donnés dans [737, 797],
Lectures recommandées
Ce n’est pas un livre sur la cryptographie classique, aussi ne vais-je pas m’étendre
plus avant sur ce sujet. Deux excellents livres présentant la cryptologie d’avant l’ère
H Chapitre 1 Principes de base
informatique sont [589, 1481]; la cryptanalyse des machines à chiffrer se trouve dans
[451]. Dorothy D e n n in g présente nombre de ces chiffres dans [462], et [880] donne une
analyse relativement mathématique de ces mêmes chiffres. Un autre texte plus ancien
sur la cryptographie, qui traite des sujets analogues, est [106]. Un article qui donne
un bon aperçu du sujet est [580]. Les livres historiques de David K a h n sont aussi
excellents [795, 796, 797).
1.4 Ou exclusif simple

X O R est l’opération ou exclusif, notée « ' » en C ou © en Mathématiques. C’est une
opration classique sur les bits:
00 0 = 0
001 = 1
1©0=1
101 = 0
Remarquez les propriétés suivantes:
a© a= 0
a © b© b = a
L’algorithme du ou exclusif simple est vraiment embarrassant; ce n’est rien d ’autre

qu’un chiffre de V iG e n Èr e . Il est inclus ici car il est très souvent utilisé dans des logiciels
commerciaux, du moins dans le monde M S -D O S et le monde M a c i n t o s h [1506, 1392].
Si un logiciel de sécurité clame qu’il utilise un algorithme de chiffrement « propriétaire »
— et qui est nettement plus rapide que le DES — il y a de fortes chances qu’il s’agisse
d ’une variante de ceci :
/* Usage: crypto key input_file output_file */
void mainfint argc, char *argv[])
FILE *fi, *fo;

int *cp;
int c;
if (cp = argv[l] ) {
if ((fi = fopen(argv[2] ,"rb")) != NULL) -[
if ((fo = fopen(argv[3],"wb")) != NULL) {
while ((c = getc(fi)) != EOF) {
if (!*cp) cp = argv[l];
c '= *(cp++);
putc(c,fo);
>
fclose(fo);
>
1.5 Masque jetable 15
fc lo s e (fi);
>
>
>
C ’est un algorithme à clef secrète. Le texte en clair est combiné à la clef par une
opération « ou exclusif » pour produire le texte chiffré. Comme l’application du ou
exclusif deux fois avec la même valeur redonne la valeur initiale, le chiffrement et le
déchiffrement utilisent exactement le même programme (© dénote l’opération logique
ou exclusif) :
M ® K = C
C®K = M
Il n’y a pas de vraie sécurité ici. Ce type de chiffre est trivial à casser, même sans
ordinateur [589, 1481]. Cela ne prendra que quelques minutes avec un ordinateur.
Faisons l’hypothèse que le texte est en langue anglaise. De plus, supposons que la clef
a une petite longueur arbitraire. Voici comment le casser :
1. Découvrir la longueur de la clef par un procédé appelé c o m p ta g e d e coïn

cid en ces [579]. Comparer le texte chiffré à lui-même mais décalé d ’un certain
nombre d’octets : compter le nombre d’octets identiques. Si les deux segments
de texte mis face à face ont été codés avec la même clef, quelque chose comme
plus de 6 % des octets seront égaux. S’ils ont été codés avec une clef différente
alors moins de 0,4 % des octets seront égaux (avec comme hypothèse une clef
quelconque et un texte en clair composé de caractères A SC II ; d’autres textes
en clair donneront des pourcentages différents). Le plus petit déplacement qui
indique une coïncidence élevée est la longueur de la clef recherchée.
2. Décaler le texte chiffré de cette longueur et appliquer le ou exclusif entre le texte

chiffré et le texte ainsi décalé. Cette opération élimine la clef et vous laisse avec le
résultat du ou exclusif du texte en clair avec lui-même décalé. Comme l’anglais
a environ un bit d ’information utile par octet (voir § 11.1), il y a suffisamment
de redondance pour choisir le déchiffrement correct.
Malgré cela, la liste des marchands de logiciels qui prétendent que cet algorithme est
« presque aussi sûr que l’algorithme DES » continue de s’allonger [1392]. C ’est cet
algorithme (avec une clef de 160 bits) que la NSA a finalement permis à l’industrie
américaine du téléphone cellulaire numérique d’utiliser pour assurer la confidentialité
des communications. Un ou exclusif simple empêchera peut-être votre sœur de lire vos
fichiers mais cela n’arrêtera pas un cryptographe plus de quelques minutes.
1.5 Masque jetable

Croyez-le ou non, il existe un cryptosystème parfait. Il s’appelle tech n iqu e du
masque je t a b le (« one-time pad » ) 13 et a été inventé en 1917 par le major Joseph
13. Note du traducteur : le term e « masque jeta b le » com m e traduction du vocable anglo-saxon
« one-tim e pad » a été em prunté à [240].
M a u b o r g n e et Gilbert V e r n a m d’A T & T [795]14. Dans sa forme classique, le masque

jetable n’est rien d’autre qu’une très longue suite non répétitive et aléatoire de lettres,
écrite sur des pages reliées ensemble pour former un bloc. L’émetteur utilise chaque
lettre du masque à son tour pour chiffrer exactement un caractère du texte en clair.
L ’algorithme de chiffrement est simple : on ajoute le rang de la lettre à chiffrer au rang
de la lettre correspondante du masque, le résultat modulo 26 donne le rang de la lettre
du texte chiffré. Le destinataire dispose d ’un bloc identique et utilise le masque de la
même manière pour déchiffrer les lettres du message chiffré une à une.
Chaque lettre du masque est utilisée une seule fois, pour un seul message. L ’émetteur
chiffre le message et détruit les pages correspondantes du bloc. Le destinataire a un
masque identique et utilise tour à tour chaque lettre du masque pour déchiffrer chaque
lettre du message chiffré. If détruit ensuite les mêmes pages du bloc. A chaque nouveau
message on utilise de nouvelles pages et donc une nouvelle clef. Par exemple, si le
message est :
MASQUEJET ABLE
et que le morceau de masque utilisé est :
TBFRGFARFMIKL
alors le texte chiffré est :
GCYIBKKWZNKWQ
puisque l’on a:
M + T mod 26 = G
A + B mod 26 = C
S + F mod 26 = Y
etc.
En émettant l’hypothèse que l’adversaire n’a pas accès au bloc qui contient le masque
jetable, ce système est parfaitement sûr. Un texte chiffré donné peut correspondre à
n’importe quel texte en clair de même longueur.
Comme tout masque est également probable (rappelez-vous que le masque est une suite
aléatoire), un adversaire n’a pas d ’information pour baser sa cryptanalyse. Le morceau
de masque aurait tout aussi bien pu être :
RXDCXFHVQBYRX
qui donnerait le texte en clair :
OEUFDECAILLES
ou encore :
RTFDAPUVHMGNX
qui donnerait le texte en clair :
OISEAUPARADIS
14. En fait, un masque jetable est un cas particulier d ’un schém a à seuil (voir § 3.7).
1.5 Masque jetable 17
Ce point vaut la peine d’être répété : comme tout texte en clair est équiprobable, il n’y
a aucun moyen pour le cryptanalyste de déterminer quel est le bon texte en clair. Le
« ou exclusif » d ’une clef aléatoire avec un texte en clair non aléatoire produit un texte
chiffré complètement aléatoire, peu importe la puissance de calcul.
Le point faible, et il est de taille, est que les lettres du masque doivent être engendrées
aléatoirement. Toute attaque contre la technique du masque jetable se fera contre la
méthode utilisée pour engendrer le masque. On ne peut pas envisager l’utilisation d’un
générateur pseudo-aléatoire ; ceux-ci possèdent toujours des propriétés non aléatoires.
Si vous utilisez un générateur vraiment aléatoire — c ’est beaucoup moins facile qu’il
n’y paraît (voir § 17.14) — cette technique est sûre.
L’autre point important est que vous ne pouvez jamais utiliser à nouveau le même
morceau du masque. Même avec un masque de plusieurs gigaoctets, un cryptanalyste
qui possède des textes chiffrés avec des séquences de masque se recouvrant peut re
construire le texte en clair. Il compare chaque paire de textes chiffrés en décalant l’un
par rapport à l’autre et compte le nombre de lettres identiques en même position.
Quand les textes sont alignés, la proportion de lettres identiques augmente d’un coup
— le pourcentage exact dépend de la langue utilisée dans le texte en clair. Ensuite la
cryptanalyse est facile. Il s’agit d ’un index de coïncidences mais avec deux « périodes »
seulement à comparer [905].
L’idée du masque jetable peut être facilement étendue au chiffrement de données bi
naires. On utilise un masque composé de bits au lieu de caractères. Au lieu d ’addition
ner le texte en clair et le masque, on utilise le ou exclusif. Pour déchiffrer, on applique
le ou exclusif avec le même masque jetable. On ne change rien d ’autre et on a un
niveau de sécurité parfait.
Tout cela à l’air mirobolant, mais il y a quand même quelques problèmes. La longueur
du masque est égale à la longueur du message à transmettre. C ’est acceptable pour
quelques messages courts mais pas pour une ligne de transmission à 1,544 mégabit par
seconde. Malgré tout, vous pouvez enregistrer 650 mégaoctets de bits aléatoires sur
un CD-ROM mais il y a des problèmes. Premièrement, vous avez besoin d ’exactement
deux copies des bits aléatoires alors que les CD-ROMs sont économiquement intéres
sants en grande quantité seulement. Deuxièment, vous devez pouvoir détruire les bits
aléatoires déjà utilisés. Un CD-ROM ne peut-être effacé autrement qu’en le détrui
sant physiquement. Les cassettes numériques sont bien mieux adaptées à ce genre de
besoins.
Même si vous résolvez les problèmes de la distribution du masque et de sa sauvegarde,
vous devez encore vous assurer que l’expéditeur et le destinataire soient parfaitement
synchronisés. Si le destinataire est décalé ne serait-ce que d ’un bit (ou si quelques
bits sont perdus pendant la transmission), le message déchiffré n’aura aucun sens. Si
quelques bits sont faussés durant la transmission (aucun bit n ’est ajouté ou retiré, ils
sont seulement modifiés), seul ces bits-là seront mal déchiffrés. D’autre part, un masque
jetable ne permet aucune authentification.
Les masques jetables ont encore leur utilité aujourd’hui, principalement pour des ca
naux de communications ultra-secrets et à faible débit. Le « téléphone rouge » entre les
Etats-Unis et l’ex-Union soviétique était15, paraît-il, chiffré à l’aide de la technique du
masque jetable. Nombre de messages d ’espions soviétiques étaient chiffrés par masque
jetable. De tels messages sont encore secrets même aujourd’hui et le resteront à tout ja
15. L’est-il encore?

mais. Peu importe combien de temps les super-ordinateurs consacreront à essayer de les
casser, peu importe le nombre de personnes qui essaieront encore d’ici à un demi-siècle
avec des machines et des techniques inimaginables, ils resteront secrets. Même quand
les extraterrestres venant d’Andromède atterriront avec leurs gigantesques engins spa
tiaux et leur puissance de calcul inimaginable, ils ne seront pas capables de déchiffrer
les messages des espions soviétiques chiffrés à l’aide de la technique du masque jetable
(à moins qu’il puissent aussi voyager dans le temps et récupérer les masques utilisés).
1.6 Algorithmes informatiques

Il y a de nombreux algorithmes cryptographiques. Les trois plus courants sont :
- DES (standard de chiffrement de données) « Data Encryption Standard » : l’al

gorithme de chiffrement informatique le plus populaire. Le DES est un standard
américain et même international, du Gouvernement américain et il a l’aval de
l’armée américaine pour le chiffrement de données de nature sensible mais non
secrète. C ’est un algorithme à clef secrète : la même clef sert au chiffrement et au
déchiffrement.
- R SA (d’après le nom de ses concepteurs : R i v e s t , S h a m ir et A d l e m a n ) : l’al

gorithme à clef publique le plus populaire. Il peut aussi bien être utilisé pour le
chiffrement que pour la signature numérique.
- D SA (algorithme de signature numérique) « Digital Signature Algorithm » : un

autre algorithme à clef publique. Il fait partie du standard de signature numé
rique DSS ou « Digital Signature Standard ». Il ne peut pas être utilisé pour le
chiffrement mais seulement pour la signature numérique.
C ’est de ce genre de choses qu’il est question dans ce livre.
1.7 Grands nombres

Tout au long de cet ouvrage, j ’utilise des grands nombres pour décrire différents points
en cryptographie. Il est aisé de perdre de vue l’ordre de grandeur de ces grands nombres.
Le tableau 1.1 montre les équivalents des grands nombres manipulés en cryptographie
par rapport à des grands nombres en physique.
Ces nombres sont des estimations d’ordre de grandeur. Us ont été puisés dans différentes
sources. La plupart des nombres venant de l’astrophysique sont expliqués dans l ’article
de Freeman D y s o n : « Time Without End: Physics and Biology in an Open Universe »
dans Reviews of Modem Physics, volume 52, numéro 3, juillet 1979, pages 447 à 460.
Les nombres indiqués pour les accidents de la circulation ont été calculés à partir des
statistiques collectées par le ministère des Transports américain : 163 morts par million
de personnes en 1993 et une longévité moyenne de 69,7 années.
1.7 Grands nombres 19
Tab. 1.1 - Grands nombres
Equivalent physique Nombre

Probabilité de mourir foudroyé (par jour) 1 chance sur 9 milliards (2 ’ ’ )
Probabilité de gagner le gros Lot à la loterie américaine 1 chance sur 4000000 (222)
Probabilité de gagner le gros lot à la loterie américaine
et de mourir foudroyé le même jour 1 chance sur 261
Probabilité de se noyer
(aux Etats-Unis et par an) 1 chance sur 59000 (216)
Probabilité d ’être tué dans un accident d ’automobile
(aux Etats-Unis en 1993) 1 chance sur 6100 (213)
Probabilité d ’être tué dans un accident d ’automobile
(aux Etats-Unis et sur une vie) 1 chance sur 88 (27)
Temps d ’ici à la prochaine glaciation 14000 ans (214)
Temps d’ici à ce que le soleil explose en nova 109 (230) années
Age de la terre 109 (230) années
Age de l’univers 1010 (234) années
Nombre d ’atomes constituant la terre 10E1 (2170)
Nombre d ’atomes constituant le soleil 1067 (2190)
Nombre d ’atomes constituant la galaxie 1067 (2223)
Nombre d’atomes constituant l’univers
(sans tenir com pte de la matière sombre) 1077 (226E)
Volume de l’univers 1084 (2280) cm3
Si l’univers est ferm é:

Durée de vie de l’univers 1011 (237) années
1018 (261) secondes
Si l’univers est ouvert :

Temps d ’ici à ce que les étoiles peu massives
se refroidissent 1014 (247) années
Temps d ’ici à ce que les planètes quittent leur étoile 101E (2eo) années
Temps d’ici à ce que les étoiles quittent leur galaxie 1019 (264) années
Temps d’ici à ce que les orbites disparaissent
par radiation gravitationnelle 102n (267) années
Temps d ’ici à ce que les trous noirs s’évaporent
complètement par le processus de H aw king 1064 (2213) années
Temps d’ici à ce que toute la matière soit liquide à 0 K 1065 (2216) années
1 r i2 6 e
Temps d’ici à ce que toute la matière se transforme en fer 10 années
Temps d ’ici à ce que toute la matière soit absorbée
1 j
par des trous noirs 10 années
Première partie
Protocoles cryptographiques
Chapitre 2
Briques élémentaires
2.1 Introduction aux protocoles

Le but de la cryptographie est de résoudre des problèmes1. La cryptographie résoud
des problèmes qui ont à voir avec la confidentialité, l’authentification, l’intégrité, et
les gens méfiants ou malhonnêtes. Vous pouvez apprendre tout sur les algorithmes et
les techniques, mais ceux-ci ne sont intéressants que s’ils sont mis à contribution pour
résoudre des problèmes. C’est pourquoi nous allons d’abord regarder les protocoles de
plus près.
Un p r o to c o le est une série d ’étapes, impliquant deux ou plusieurs participants, conçu
pour accomplir une tâche. Cette définition est importante. Il y est question d ’une
« série d’étapes », c ’est-à-dire qu’un protocole est une suite ordonnée d ’étapes et qu’il
a un début et une fin. Chaque étape doit être exécutée à son tour et aucune autre
étape ne peut être exécutée avant que la précédente ne soit finie. L ’expression « deux
ou plusieurs participants » indique qu’il faut au moins deux personnes pour accomplir
un protocole ; une personne isolée ne peut accomplir un protocole. Il est vrai qu’une
personne seule peut réaliser une série d ’étapes pour accomplir une tâche (par exemple,
cuire un gâteau), mais ce n’est pas un protocole. En dernier lieu, l’expression « conçu
pour accomplir une tâche » indique qu’un protocole doit faire quelque chose. Ce qui
ressemble à un protocole mais qui n’accomplit pas une tâche n’est pas un protocole
mais bien une perte de temps.
Les protocoles ont d ’autres caractéristiques :
chaque participant d’un protocole doit connaître le protocole et toutes les étapes
à suivre d’avance ;
- chaque participant impliqué dans un protocole doit être d’accord pour adhérer
au protocole ;
- le protocole doit être non ambigu : chaque étape doit être bien définie et il ne
doit pas y avoir de possibilité de mésentente ;
- un protocole doit être complet: il doit y avoir une action spécifique à chaque
situation possible.
1. D e fait, c ’est le but d e l’ inform atique tou t cou rt — ce que beaucoup de gens tendent à oublier.
24 Chapitre 2 Briques élémentaires
Les protocoles dans ce livre sont organisés en une série d’étapes. L ’exécution d ’un
protocole parcourt linéairement ces étapes, sauf s’il y a des instructions de branchement
indiquant qu’il faut poursuivre à partir d’une autre étape. Chaque étape comprend des
calculs effectués par l’un des participants, et/ou des messages envoyés d ’un participant
à un autre.
Un p r o t o c o le cry p to g ra p h iq u e est un protocole qui utilise la cryptographie. Les
participants peuvent être des amis qui ont implicitement confiance les uns en les autres
ou ils peuvent être des ennemis qui ne se font pas confiance du tout. Un protocole
cryptographique utilise certains algorithmes cryptographiques, mais en général le but
d’un protocole va au-delà de la simple confidentialité. Les participants d’un protocole
peuvent vouloir partager partiellement un secret pour calculer une valeur, engendrer
une suite aléatoire, convaincre l’autre interlocuteur de son identité, ou signer simul
tanément un contrat. Tout l’intêret d’utiliser la cryptographie dans un protocole est
d ’empêcher ou de détecter l’espionnage ou la tricherie. Si vous n ’avez jamais vu de tels
protocols auparavant, cela va changer radicalement votre idée de ce que des participants
mutuellement méfiants peuvent accomplir sur un réseau informatique. En général, on
peut formuler cela ainsi:
- Il doit être impossible de faire ou d ’apprendre plus que ce qui est prévu dans le
protocole.
C ’est beaucoup plus difficile qu’il n’y parraît. De nombreux protocoles sont exami
nés dans les prochains chapitres. Dans certains, un des participant peut tromper les
autres. Dans d ’autres, un espion peut altérer le protocol ou apprendre des informations
secrètes. Certains protocoles échouent faute de précision dans la définition des régies.
D ’autres échouent parce que leurs auteurs ont manqué de méticulosité dans leur ana
lyse. Comme pour un algorithme, il est bien plus difficile de prouver qu’un protocle est
sûr que le contraire.
But des protocoles

Dans la vie de tous les jours, il y a des protocoles informels pour quasiment tout : com
mander des marchandises par téléphone, jouer au poker, voter aux élections. Personne
ne pense vraiment à ces protocoles ; ils ont évolué au cours du temps, tout le monde
sait comment les utiliser et ils marchent.
De nos jours, les interactions humaines se font de plus en plus à travers des réseaux
informatiques et non face à face. Les ordinateurs ont besoin de protocoles pour faire
ce que les gens font sans y penser. Si vous déménagez vers un autre pays et que vous
y trouvez un bureau de vote complètement différent de ce que vous avez l’habitude
d’utiliser, vous vous adapterez facilement. Les ordinateurs ne sont pas aussi flexibles.
Nombre de protocoles « face à face » requièrent la présence des gens pour assurer
l’impartialité et la sécurité. Enverriez-vous une liasse de billets à un étranger pour qu’il
vous achète des marchandises? Joueriez-vous au poker avec quelqu’un si vous ne pouvez
pas le voir mélanger les cartes et les distribuer? Enverriez-vous au Gouvernement votre
vote par courrier sans quelque assurance que votre anonymat soit préservé?
Il est naïf de croire que les utilisateurs d’un réseau informatique sont honnêtes. Il est
naïf de croire que les gestionnaires du réseau sont honnêtes. Il est même naïf de croire
que les concepteurs du réseau étaient honnêtes. La plupart le sont mais les quelques
2.1 Introduction aux protocoles 25
autres peuvent faire beaucoup de dégâts. En formalisant les protocoles, nous pouvons
examiner comment des participants malhonnêtes peuvent essayer de tricher et ainsi
développer des protocoles qui excluent les tricheurs.
Non seulement les protocoles formalisent les comportements mais de plus il permettent
d’abstraire le processus d’accomplissement d’une tâche des mécanismes par lesquels
cette tâche est accomplie. Un protocole de communication entre deux ordinateurs est
le même, que ce soient des P C d ’IBM , des V A X de D i g i t a l o u encore des téléco
pieurs. Nous pouvons examiner les protocoles sans nous noyer dans les détails de leur
réalisation concrète. Une fois que nous sommes convaincus de tenir un bon protocole,
nous pouvons le réaliser avec n’importe quoi tel que des ordinateurs, des téléphones ou
même des gaufriers intelligents.
Les acteurs
Pour illustrer les protocoles, j ’ai engagé des acteurs (voir le tableau 2.1)2. Alice et
Bernard sont les acteurs principaux. Ils accompliront tous les protocoles généraux à
deux participants. Par convention, Alice commencera tous les protocoles. Bernard ré
pondra. Si le protocole requiert l’intervention d ’un troisième ou quatrième participant,
Christine et David seront appelés à la rescousse. Les autres acteurs joueront des rôles
spécifiques qui seront détaillés plus tard.
T a b . 2.1 - Liste des acteurs et de leur rôle
Alice participante de tous les protocoles

Bernard participant de tous les protocoles
Christine participante des protocoles à trois ou quatre participants
David participant des protocoles à quatre participants
Estelle espionne
Martin attaquant malveillant actif
Ivan arbitre intègre
Gatien gardien : il surveillera Alice et Bernard dans certains protocoles
Patricia plaideuse
Victor vérificateur (contrôleur)
Protocoles arbitrés
Un arbitre est un tiers, personne de confiance et désintéressée qui veille au bon dérou
lement du protocole (voir la figure 2.1a). L ’arbitre est dit « désintéressé » parce qu’il
n’a pas d’intérêt dans l’accomplissement du protocole et qu’il n’a aucune allégeance
envers les autres participants. L ’arbitre est dit de « confiance » parce que tous les par
ticipants au protocole acceptent que ce qu’il dit est vrai, que ce qu’il fait est correct
2. Note du traducteur : dans la littérature anglo-saxonne, les prénom s des acteurs : A lice, B ob , Carol,
Dave, Eve, Mallet, Trent, W arden, P eggy et V ictor correspondent respectivem ent à Alice, Bernard,
Christine, David, Estelle, M artin, Ivan, G atien, P atricia et V ictor dans cette édition française. Le
choix de Bernard plutôt que B ob n ’est pas traditionnel mais cela ne change rien à la com préhension
de l’ouvrage car ces prénom s peuvent être quelconques pour autant qu ’ ils com m encent par la bonne
lettre.
et que sa part du protocole sera complète. Les arbitres aident au bon accomplissement
de protocoles entre participants méfiants.
F ig. 2.1 - Types de protocoles
Dans le monde réel, les hommes de loi jouent souvent le rôle d’arbitre. Par exemple,
Alice vend une voiture à Bernard, un inconnu. Bernard veut payer par chèque mais
Alice n’a aucun moyen de savoir si le chèque est un chèque en bois. Alice veut s’assurer
de la solvabilité du chèque avant de céder les papiers du véhicule (titre de propriété
inclus) à Bernard. Bernard, qui n’a pas plus confiance en Alice qu’elle en lui, ne veut
pas donner le chèque avant d ’avoir reçu les papiers.
Un homme de loi qui a la confiance d ’Alice et de Bernardentre alors en scène. Grâce à
l’aide de celui-ci, Alice et Bernard peuvent se mettre d ’accord sur le protocole suivant,
qui garantit que ni l’un ni l’autre ne pourra tricher :
1° Alice donne les papiers et les clefs à l ’homme de loi.
2° Bernard donne le chèque à Alice.
3° Alice dépose le chèque à sa banque.

4° après un certain laps de temps nécessaire à la vérification et à l ’encaissement

du chèque, l’homme de loi donne les papiers et les clefs à Bernard. Si le chèque
n’est pas encaissé après le laps de temps donné, Alice en informe l ’homme de
loi et lui fournit la preuve de ce qu’elle avance; alors l’homme de loi rend les
papiers et les clefs à Alice.
Dans ce protocole, Alice fait confiance à l’homme de loi pour qu’il ne donne les papiers
et les clefs que si le chèque est solvable (et donc encaissé) et pour qu’il lui rende ceux-
ci dans le cas contraire. Bernard fait confiance à l’homme de loi pour qu’il garde les
papiers et les clefs jusqu’à ce que le chèque soit encaissé. Pour l’homme de loi, peu
importe si le chèque est solvable ou non. Il fera sa part du protocole dans tous les cas
puisqu’il sera payé de toute façon.
Dans cet exemple, l’homme de loi joue le rôle d’un agent de dépôt. Les hommes de loi
agissent comme arbitres pour les testaments et parfois pour la négociation de contrats.
Les Bourses agissent comme arbitres entre les acheteurs et les vendeurs.
Les banques agissent aussi comme arbitres. Bernard peut acheter la voiture d ’Alice à
l’aide d’un chèque certifié :
1° Bernard fait un chèque et le donne à sa banque.

2° Après avoir retiré du compte de Bernard le montant nécessaire pour couvrir le
chèque et après l’avoir placé sur un compte bloqué, la banque certifie le chèque
et le rend à Bernard.
3° Alice donne les papiers et les clefs à Bernard et Bernard donne le chèque certifié
à Alice.
4° Alice dépose le chèque à sa banque.
Ce protocole est effectif parce qu’Alice a confiance en la certification réalisée par la

banque. Alice pense que la banque garde bien son argent et qu’elle ne s’en sert pas
pour des investissements douteux.
Un notaire est aussi un arbitre. Quand Bernard reçoit un acte notarié d ’Alice, il est
convaincu qu’Alice a bien signé ce document de sa propre main et volontairement. Le
notaire peut, si nécessaire, attester du fait en justice.
Le concept d’arbitre est aussi vieux que notre société. Il y a toujours eu des gens —
souverains, prêtres, etc. qui avaient l’autorité et le devoir d ’agir honnêtement. Les
arbitres ont un rôle et une position sociale particulière dans notre société. Tromper
le public leur ferait perdre ce statut : des hommes de loi qui utiliseraient des dépôts
fiduciaires à des fins malhonnêtes s’exposeraient à la radiation de leur ordre. Cette
image de confiance ne correspond pas toujours à la réalité mais nous montre l’idéal.
Cet idéal peut être adapté au monde de l’informatique mais il y a quand même quelques
difficultés lorsque les ordinateurs arbitrent :
- Il est plus aisé de trouver et d’avoir confiance en un tiers si on sait qui il est et si
on peut le rencontrer. Deux participants se méfiant l’un de l’autre ont de fortes
chances d’être méfiants vis-à-vis d’un arbitre sans visage quelque part dans un
réseau.
- Le réseau informatique doit assumer le coût de l’arbitrage. Nous connaissons les

honoraires des notaires. Qui est prêt à en payer le coût dans un réseau informa
tique?
- Il y a un délai inhérent au protocole d’arbitrage.
- L’arbitre doit s’occuper de chaque transaction; il est un goulot d ’étranglement

potentiels dans toute réalisation à grande échelle de protocoles. Augmenter le
nombre d ’arbitres peut aider à faire face à ce problème mais alors le coût de la
réalisation augmente aussi.
- Comme tout le monde sur le réseau doit faire confiance à l’arbitre, il devient le
point sensible du réseau et la cible privilégiée de ceux qui veulent corrompre le
réseau.
Malgré tout, les arbitres ont encore un rôle à jouer. Dans les protocoles, le rôle de
l’arbitre sera tenu par Ivan.
Protocoles avec juge-arbitre

L’arbitrage coûte cher, aussi les protocoles arbitrés peuvent être divisés en deux sous-
p r o to c o le s : un sous-protocole non arbitré qui est exécuté chaque fois que le protocole
est utilisé, et un autre sous-protocole arbitré auquel on ne fait appel que s’il y a un
litige entre les participants. Dans ce cas particulier, on ne parlera pas d’arbitre mais
de ju g e -a r b itr e (voir la figure 2.1b).
Un juge-arbitre est aussi un tiers désintéressé et digne de confiance. Contrairement à
un arbitre, il n ’est pas impliqué dans chaque protocole. Le juge-arbitre n’est appelé
que pour déterminer si une transaction a été effectuée honnêtement.
Les juges sont des juges-arbitres professionnels. Contrairement au notaire, les juges
n’interviennent que lorsqu’il y a contestation. Alice et Bernard peuvent conclure un
contrat sans l’intervention d’un juge. Un juge ne verra jamais ce contrat sauf si l’une
des parties porte l’affaire devant les tribunaux.
Le protocole de signature de contrat peut être formalisé de la façon suivante :
Sous-protocole non arbitré (exécuté à chaque fois)
1° Alice et Bernard négocient les termes du contrat.

2° Alice signe le contrat.
3° Bernard signe le contrat.
Sous-protocole avec juge-arbitre (exécuté uniquement en cas de contestation) :
1° Alice et Bernard comparaissent devant un juge.

2° Alice présente sa défense.
3° Bernard présente sa défense.
4° Le juge tranche.
La différence entre un arbitre et un juge-arbitre (du moins pour les besoins de cet
ouvrage) est que le juge-arbitre n’est pas toujours nécessaire. S’il y a contestation, un
juge est appelé pour trancher. S’il n’y a pas contestation, un juge n’est pas nécessaire.
Il existe des protocoles informatiques avec juges-arbitres. Ces protocoles reposent sur
l’hypothèse que les participants sont honnêtes mais si quelqu’un triche, les données
collectées pendant l’exécution du protocole permettront à un tiers désintéressé de dé
terminer s’il y a eu tricherie. Dans un bon protocole avec juge-arbitre, ce dernier peut
également indiquer l’identité de celui qui a triché. Au lieu d’empêcher la tricherie, les
protocoles avec juge-arbitre détectent la tricherie. Le caractère inévitable de la détec
tion agit comme une mesure préventive et décourage la fraude.
Protocoles à discipline intrinsèque

Un p r o to c o le à disciplin e in trin sèqu e est le meilleur type de protocole. Le protocole
lui-même garantit l’intégrité de la transaction (voir la figure 2.1c). Il ne faut pas d’ar
bitre pour utiliser le protocole. Il ne faut pas de juges-arbitres pour régler les conflits.
Le protocole est construit de telle façon que les contestations soient impossibles. Si l’ un
des participants essaie de tricher, l’autre participant le détecte immédiatement et le
protocole est interrompu. Quels que soient les espoirs du tricheur, ils seront déçus.
Dans le meilleur des mondes, tout protocole devrait être à discipline intrinsèque.
Malheureusement, il n’existe pas un tel protocole pour chaque type de transaction
possible.
Attaques de protocoles
Les attaques dirigées contre les protocoles peuvent viser soit les algorithmes cryptogra
phiques utilisés par les protocoles, soit les techniques cryptographiques utilisées pour
réaliser les algorithmes, ou encore le protocole lui-même. Comme ce paragraphe ne
traite que les protocoles, nous allons supposer que les algorithmes et les techniques
sont sûres et ne regarder que les attaques contre le protocole lui-même.
II y a plusieurs façons d ’attaquer un protocole. Quelqu’un qui n ’est pas impliqué dans
le protocole peut espionner tout ou partie de celui-ci. C ’est ce que l’on appelle une
attaque passive parce que l’attaquant ne modifie pas le protocole. Tout ce qu’il peut
faire c’est observer le protocole et ainsi essayer de collecter de l’information. Ce type
d’attaque correspond à une attaque à texte chiffré seulement, telle celle que décrite dans
le paragraphe 1.1. Les attaques passives sont difficiles à détecter, aussi les protocoles
essayent de s’en prémunir plutôt que de les détecter. Dans de telles attaques le rôle de
l’espion sera joué par Estelle.
Un attaquant peut aussi essayer d ’altérer le protocole pour le tourner à son avantage. Il
peut prétendre être quelqu’un d’autre, intercaler de nouveaux messages, supprimer des
messages, remplacer un message par un autre, envoyer un vieux message, détruire le
canal de communication ou encore modifier l’information enregistrée par un ordinateur.
On parlera alors d’a ttaq u es actives car elles requièrent une attitude active de la part
de l’attaquant. La manière dont sont menées ces attaques dépendent du réseau.
Les attaquants passifs ne sont intéressés que par l’information qu’ils peuvent glaner
concernant les participants au protocole. Ils collectionnent les messages qui circulent
entre les différents participants et en essayant de les cryptanalyser. Les attaques ac
tives peuvent au contraire avoir bien d’autres objectifs. L’attaquant peut vouloir soit
obtenir de l’information, soit dégrader les performances du système, soit corrompre de
l’information existante, soit encore avoir accès à des ressources non autorisées.
Les attaques actives sont bien plus sérieuses, plus particulièrement dans les protocoles
où les participants n’ont pas confiance entre eux. L’attaquant n’est pas forcément un
étranger. Il peut être un utilisateur légitime du système. Il peut être l’administrateur
du système. Il peut même y avoir plusieurs attaquants actifs, travaillant ensemble,
chacun étant un utilisateur légitime. Le rôle de l’attaquant malicieux actif sera joué
par Martin.
Il se peut que l’attaquant soit un des participants au protocole. Ilpeut mentir pendant
le protocole ou même ne pas du tout suivre les règles. Ce type d’attaquantest appelé
tricheur. Les trich eu rs passifs respectent le protocole mais ils essaient d’obtenir
plus d ’informations que le protocole ne leur permet normalement. Les tricheu rs actifs
altèrent le protocole en cours en essayant de tricher.
Il est très difficile de garantir la sécurité du système si la plupart des participants
sont des tricheurs actifs mais, parfois, il est possible pour les participants légitimes de
détecter qu’il y a tricherie active. De toute façon, les protocoles doivent se prémunir
de manière fiable contre la tricherie passive.
2.2 Communications à l’aide

d’un cryptosystème à clef secrète
Comment deux parties peuvent-elles communiquer de manière sûre? Ils chiffrent leur
communication bien sûr. Le protocole complet est plus compliqué que cela. Voyons
comment Alice peut envoyer un message chiffré à Bernard :
1° Alice et Bernard choisissent un cryptosystème.
2° Alice et Bernard choisissent une clef.
3° Alice chiffre son texte en clair à l ’aide de l ’algorithme choisi et avec la clef
sélectionnée. Cette étape produit un texte chiffré.
4° Alice envoie le texte chiffré à Bernard.
5° Bernard déchiffre le texte chiffré avec le même algorithme et la même clef, et

finalement lit le message.
Que peut apprendre Estelle un espion qui se place entre Alice et Bernard, en écoutant
le protocole? Si tout ce qu’elle peut entendre est la transmission de l’étape 4, elle peut
essayer de cryptanalyser le texte chiffré. Cette attaque passive est une attaque à texte
chiffré seulement. Il existe des algorithmes qui sont résistants (pour autant que l’on
sache) peu importe la puissance de calcul dont Estelle dispose pour s’y attaquer.
Toutefois, Estelle n’est pas stupide. Elle sait que si elle peut écouter les étapes 1 et
2 du protocole, elle aura ce qu’il lui faut. Elle connaîtra alors l’algorithme et la clef;
elle en saura autant que Bernard. Quand le message est transmis à l’étape 4, tout ce
qu’elle a à faire est de le déchiffrer pour elle-même.
Un bon cryptosystème est un système où la sécurité est inhérente à la connaissance
de la clef et non pas à celle de l’algorithme. C ’est pourquoi la gestion des clefs est un
problème si important en cryptographie. Avec un algorithme à clef secrète, Alice et
Bernard peuvent réaliser l’étape 1 en public mais ils doivent réaliser l’étape 2 en secret.
La clef doit rester secrète avant, pendant et après le protocole, sinon, le message ne
serait plus confidentiel3.
3. La cryptographie à clef publique résout ce problèm e d ’ une autre manière qui sera décrite dans
le paragraphe 2.5.
2.3 Fonctions à sens unique 31
Martin, un attaquant actif, peut faire d ’autres choses. Il peut essayer de casser le canal
de communication de l’étape 4, s’assurant ainsi qu’Alice ne peut pas transmettre du
tout son message à Bernard. Martin peut aussi intercepter les messages d’Alice et les
remplacer par d’autres de son cru. Si de plus Martin connaît la clef (en interceptant la
communication de l’étape 2 par exemple), il peut chiffrer ses propres messages et les
envoyer à Bernard en lieu et place des messages interceptés. Bernard n’aurait aucun
moyen de détecter que ces messages ne viennent pas d ’Alice. Si Martin ne connaissait
pas la clef, les messages qu’il enverrait en remplacement seraient du charabia lorsqu’ils
seraient déchiffrés par Bernard. Bernard, pensant que le message vient d’Alice, croirait
que le réseau, ou Alice, ont de sérieux problèmes.
Quant à Alice, que peut-elle faire pour fausser le protocole? Elle peut donner une copie
de la clef à Estelle. A l’aide de celle-ci, Estelle peut lire tout ce que Bernard dit. Elle
peut reproduire ses propos dans le New York Times. Bien que cela soit grave, la faute
n’est pas imputable au protocole. Il n’y a rien dans le protocole qui puisse empêcher
Alice de donner une copie du texte en clair à Estelle. Bien sûr, Bernard peut faire
tout ce qu’Alice peut faire. Ce protocole présume qu’Alice et Bernard se font confiance
mutuellement.
En résumé, un cryptosystème à clef secrète a les problèmes suivants :
- Les clefs doivent être distribuées secrètement. Elles ont autant de valeur que
tous les messages chiffrés avec elles car connaître les clefs donne accès à tous les
messages. Pour des cryptosystèmes utilisés à l’échelle de la planète, la distribution
des clefs peut être une tâche décourageante. Souvent, des messagers apportent
les clefs à leur destination (de la main à la main).
- Si la clef est compromise (volée, devinée, extorquée, achetée, etc.) alors Estelle
peut déchiffrer tous les messages chiffrés à l’aide de cette clef. Elle peut alors
se faire passer pour l’un des participants et insuffler ses propres messages pour
tromper l’autre participant.
- Si une clef différente est utilisée pour chaque paire d’utilisateurs d’un réseau, le
nombre total de clefs croît très vite par rapport au nombre d ’utilisateurs. Par
exemple, 10 utilisateurs ont besoin de 45 clefs différentes pour pouvoir mener
n’importe quelle conversation deux à deux ; 100 utilisateurs ont besoin de 4950
clefs différentes. Ce problème peut être minimisé en gardant un petit nombre
d’utilisateurs mais cela n’est pas toujours possible.
2.3 Fonctions à sens unique

La notion de fo n ctio n s à sens u n iqu e est fondamentale pour la cryptographie à clef
publique. Bien qu’elles ne constituent pas un protocole en elles-mêmes, les fonctions
à sens unique sont des éléments de base de la plupart des protocoles décrits dans ce
livre.
Une fonction à sens unique est une fonction relativement aisée à calculer mais considé
rablement plus difficile à inverser. En d’autres termes, étant donné un x, il est facile de
calculer f(x), mais étant donné f(x) il est difficile de calculer x. Dans ce contexte, « dif
ficile » veut dire qu’il faudrait des millions d ’années pour calculer la fonction inverse
même si tous les ordinateurs du monde s’attelaient à la tâche.
Casser une assiète est un bon exemple de fonction à sens unique. Il est facile de cas
ser l’assiète en mille morceaux. Toutefois, il est très difficile de recoller les morceaux
ensembles pour reconstruire l’assiète.
Cela a l’air correct mais on ne peut pas en démontrer la véracité. D ’un point de
vue strictement mathématique, il n’y a pas de preuve que des fonctions à sens unique
existent ni même d ’indice qu’elles peuvent être définies [233, 532, 603, 662]. Cependant,
de nombreuses fonctions ont l’air d’être à sens unique: nous pouvons facilement les
calculer et, à ce jour, nous ne connaissons pas de moyen simple pour les inverser. Par
exemple, x2 dans un corps fini est facile à calculer mais le calcul de \fx est nettement
plus difficile. Par la suite, je prétendrai que des fonctions à sens unique existent. Nous
en reparlerons dans le paragraphe 11.2.
Mais à quoi peuvent bien servir des fonctions à sens unique? On ne peut pas les
utiliser telles quelles pour le chiffrement. Un message chiffré à l’aide d’une fonction à
sens unique n’est pas d ’une grande utilité: personne ne peut le déchiffrer4. Pour la
cryptographie à clef publique, nous avons besoin de ce que l’on appelle une fon ctio n
à sens u n iqu e à b rè ch e s e c r è te 5.
Une fo n ctio n à sens unique à brèch e secrète est un type spécial de fonction à sens
unique. Il est facile de la calculer dans un sens et difficile de le faire dans l’autre sens.
Mais pour celui qui connaît le secret, il est aisé de calculer la fonction dans l’autre sens.
En d ’autres termes, il est facile de calculer f (x) étant donné x et difficile de calculer x
étant donné f{x). Toutefois, il existe une information secrète, y, telle qu’étant donné
f(x) et y, il est facile de calculer x.
Une montre est un bon exemple de fonction à sens unique à brèche secrète. Il est facile
de démonter une montre en ses centaines de pièces. Il est très difficile de remettre
les pièces ensemble pour reconstruire une montre qui fonctionne. Toutefois, grâce à
l’information secrète que constitue le plan de montage de la montre, il est bien plus
facile de reconstruire la montre.
2.4 Fonctions de hachage à sens unique

Une fo n c tio n d e h achage à sens u n ique porte de nombreux noms: fonction de
compression, fonction de contraction, digest, empreinte digitale, code correcteur
cryptographique, code de vérification d ’intégrité, code de détection de manipulation6.
Peu importe comment on les appelle, de telles fonctions sont fondamentales pour la
cryptographie moderne. Ces fonctions interviennent comme éléments de base dans de
nombreux protocoles.
Des fonctions de hachage ont été utilisées en informatique depuis longtemps. Une fonc
tion de hachage est une fonction, mathématique ou autre, qui convertit une chaîne de
caractères de longueur quelconque en une chaîne de caractères de taille fixe (souvent
de taille inférieure, cette chaîne est appelée em p rein te). Un exemple de fonction de
hachage simple est une fonction qui à partir d’une chaîne de caractères calculerait un
4. E xercice : écrivez un message sur une assiette, cassez l’ assiette en mille m orceaux, et donnez
ensuite les morceaux à un ami. Demandez-lui de lire le message. Constatez à quel point votre ami est
impressionné par cette fonction à sens unique.
5. Il existe des applications cryptographiques des fonctions à sens unique tou t court (voir § 3.2).
6. N ote du traducteur : les fonctions de hachages sont parfois appelées « fonctions à adressage
dispersé ».
2.5 Communications à l’aide d’un cryptosystème à clef publique 33
octet qui serait le résultat du ou exclusif de tous les caractères de la chaîne donnée.
Le but de l’opération est de déterminer une empreinte digitale de la chaîne de caractères
d’entrée. Cette empreinte permettrait de déterminer si une autre chaîne a des chances
d’être identique à celle pour laquelle l’empreinte a été calculée. Comme les fonctions
de hachage ont la caractéristique de faire correspondre plusieurs valeurs d ’entrée dif
férentes à une même valeur de sortie, on ne peut pas s’en servir pour déterminer avec
certitude si deux chaînes sont égales mais on peut l’utiliser pour avoir une garantie
raisonnable d ’égalité.
Une fonction de hachage à sens unique est une fonction de hachage qui est aussi une
fonction à sens unique ; il est aisé de calculer l’empreinte à partir de la chaîne d ’entrée
mais il est difficile d’engendrer des chaînes qui ont une certaine empreinte. La fonction
de hachage du paragraphe précédent n’est pas à sens unique : étant donné un octet, il
est trivial d’engendrer une chaîne dont le « ou exclusif » de ses caractères donne cet
octet-là. Vous ne pourriez pas faire cela pour des fonctions de hachage à sens unique.
Avec une bonne fonction de hachage à sens unique, il est aussi difficile de produire
deux chaînes ayant la même empreinte.
La fonction de hachage est publique; il n’y a pas de secret dans l’opération. Une fonction
de hachage est sûre parce qu’elle est à sens unique. La sortie ne dépend pas de l’entrée
de manière observable. Tout changement d ’un bit quelconque à l’entrée entraîne le
changement, en moyenne, de la moitié des bits du résultat. Etant donné une empreinte
il est irréalisable par calcul de trouver une chaîne ayant cette empreinte.
Pensez à cela comme un moyen d ’associer une empreinte à des fichiers. Si vous vou
lez vérifier que quelqu’un possède un fichier donné (que vous avez aussi) sans qu’il
vous l’envoie, vous lui demandez alors l’empreinte du fichier. S’il vous envoie la bonne
empreinte, alors il est très probable que la personne a le fichier en question. C ’est
particulièrement adapté aux transactions financières où l’on ne veut pas qu’un retrait
de cent francs devienne un retrait de mille francs. Normalement, vous utiliseriez une
fonction de hachage à sens unique sans clef de telle manière que n’importe qui puisse
calculer l’empreinte. Si vous voulez que seul votre correspondant soit capable de la
calculer, alors lisez le paragraphe suivant.
Code d’Authentifîcation de Messages

Un C o d e d ’ A u tïie n tifica tio n d e M essages (C A M ) est une fonctions de hachage à
sens unique qui fonctionne de plus avec une clef secrète (voir § 18.14). L’empreinte dé
pend à la fois de l’entrée et de la clef. Tout se passe en théorie comme avec une fonction
de hachage sauf qu’il faut avoir la clef pour calculer l’empreinte. On peut construire un
CAM à partir d’une fonction de hachage ou d ’un algorithme de chiffrement par bloc.
Il existe aussi des fonctions spécialement conçues pour faire un C A M .
2.5 Communications à l’aide

d’un cryptosystème à clef publique
On peut comparer un algorithme à clef secrète à un coffre-fort. La clef est la com
binaison du coffre. Celui qui connaît la combinaison peut ouvrir le coffre, mettre un
document à l’intérieur et le refermer. Quelqu’un d’autre, qui possède aussi la combi
naison, peut ouvrir le coffre et prendre le document. Toute personne qui ne connaît
pas la clef n’a pas d’autre ressort que d ’apprendre l’art de percer les coffres-forts.
En 1976, Whitfîeld D i f f i e et Martin H e l l m a n ont changé ce paradigme de la cryp
tographie à tout jamais [494]7. Ils ont décrit la cry p to g ra p h ie à c le f publique. Au
lieu d ’une clef, il y a deux clefs différentes : une publique et une privée. De plus, il est
difficile de calculer la clef privée à partir de la clef publique. Toute personne peut à
l’aide de la clef publique chiffrer un message mais elle ne peut pas le déchiffrer. Seule la
personne en possession de la clef privée peut déchiffrer le message. C ’est comme si quel
qu’un avait changé le coffre-fort de la cryptographie en une boîte aux lettres. Mettre
une lettre dans la boîte revient à chiffrer avec la clef publique, tout le monde peut le
faire. Il suffit de la glisser dans la fente. Sortir le courrier de la boîte revient à déchiffrer
avec la clef privée. C ’est difficile en général, il faut un chalumeau. Cependant, celui
qui détient le secret (la clef physique de la boîte aux lettres) peut facilement retirer le
courrier de la boîte.
Mathématiquement, le procédé est basé sur une fonction à sens unique à brèche secrète
décrite ci-dessus. Le chiffrement est la direction facile La clef publique constitue les
instructions pour le chiffrement : tout le monde peut chiffrer un message. Le déchif
frement est la direction difficile. C ’est suffisamment difficile pour que des gens avec
des ordinateurs C r a y et des milliers (ou même des millions) d’années à leur disposi
tion ne puissent pas déchiffrer les messages sans connaître le secret. Le secret, ou la
brèche secrète, est la clef privée. Avec ce secret, le déchiffrement est aussi facile que le
chiffrement.
Voici comment Alice peut envoyer un message à Bernard en utilisant la cryptographie
à clef publique :
1° Alice et Bernard choisissent un cryptosystème à clef publique.
2° Bernard envoie à Alice sa clef publique.
3° Alice chiffre son message en utilisant la clef publique de Bernard et lui envoie
le résultat.
4° Bernard déchiffre le message d’Alice en utilisant sa clef privée.
Remarquez comment la cryptographie à clef publique résout le problème la distribution

des clefs de la cryptographie à clef secrète. Avant, Alice et Bernard devaient se mettre
d’accord sur une clef en secret. Alice pouvait en choisir une au hasard mais elle devait
toutefois la faire parvenir à Bernard. Elle pouvait la lui avoir donnée par le passé mais
cela imposait de se rencontrer auparavant. Elle pouvait la lui envoyer par courrier
recommandé mais cela prend du temps. La cryptographie à clef publique rend la chose
facile. Sans aucun arrangement au préalable, Alice peut envoyer un message confideiitiel
à Bernard. Estelle, qui écoute tout l’échange, dispose de la clef publique de Bernard
et du message chiffré avec cette clef, mais elle ne peut ni retrouver la clef privée de
Bernard ni le contenu du texte en clair du message.
Plus généralement, un groupe d ’utilisateurs en réseau s’accordent pour utiliser un cryp
tosystème à clef publique. Chaque utilisateur a sa ou ses clefs publiques et privées.
Toutes les clefs publiques sont disponibles dans une base de données quelque part.
7. La N SA prétend avoir eu connaissance du con cept dès 1966, mais ne l’a jam ais prouvé.
2.5 Communications à l’aide d’un cryptosystème à clef publique 35
Ainsi le protocole est plus simple :
1° Alice obtient la clef publique de Bernard par la base de données.

2° Alice chiffre son message en utilisant la clef publique de Bernard et lui envoie
le résultat.
Dans le premier protocole, Bernard devait envoyer sa clef publique à Alice avant qu’elle
ne puisse lui envoyer un message. Le second protocole est plus proche du courrier
traditionnel. Bernard n’est pas concerné par le protocole tant qu’il ne lit pas son
courrier.
Cryptosystèmes hybrides
Les premiers algorithmes à clef publique furent publiés à l’époque où il était question
de prendre le DES comme standard. Il en résulta une sorte de politique partisane dans
le milieu de la cryptographie. D i f f i e la décrivit dans ces termes [492] :
« L’excitation provoquée par les cryptosystèmes à clef publique dans la

presse populaire et la presse scientifique n’a pas été partagée par l’admi
nistration cryptographique. L’année de la découverte de la cryptographie
à clef publique, la « National Security Agency » (N SA) proposait d'adop
ter un système cryptographique conventionnel, conçu par « International
Business Machines » (IB M ), comme standard fédéral de chiffrement de
données (DES, « Data Encryption Standard »). Marty Hellman et moi
critiquions la proposition sur le fait que sa clef était trop courte, mais
les fabricants étaient prêts à soutenir le standard proposé et nos critiques
étaient vues par beaucoup comme une tentative d ’enrayer le processus de
création du standard au profit de nos propres travaux. La cryptographie à
clef publique fut attaquée à son tour dans la litérature commerciale [1131]
et par des articles se voulant techniques [850, 1159], comme si elle était plus
un produit en concurrence qu’une récente découverte. Ceci n’empêcha pas
néanmoins la NSA réclamer sa part de mérite. Son directeur précisa dans
l’Encyclopédie Britannica [1466] qu’« il avaient découvert la cryptographie
à deux clefs dix ans plus tôt », bien qu’aucune preuve de cette affirmation
n’ait jamais vu le jour. »
En pratique, les algorithmes à clef publique ne se substituent pas aux algorithmes à

clef secrète. On les utilise pour chiffrer des clefs et non des messages. Il y a deux raisons
à cela:
- Les algorithmes à clef publique sont lents. Les algorithmes à clef secrète sont
généralement au moins 1000 fois plus rapides que les algorithmes à clef publique.
Il est vrai que les ordinateurs sont de plus en plus rapides et qu’ils pourront
dans quinze ans utiliser la cryptographie à clef publique aussi rapidement que la
cryptographie à clef secrète aujourd’hui. Mais les besoins en bande passante aug
mentent aussi et on aura toujours besoin de chiffrer des données plus rapidement
que cela n’est possible avec la cryptographie à clef publique.
- Les cryptosystèmes à clef publique sont vulnérables aux attaques à texte en clair
choisi. Si C = E(Ai) où A i est un texte en clair parmi n textes en clair possibles,
alors il suffit à un cryptanalyste de chiffrer les n messages et de comparer les
textes chiffrés résultant avec C (la clef de chiffrement est publique). Il ne pourra
pas trouver la clef de déchiffrement de cette manière, mais il pourra déterminer
M.
Une attaque à texte en clair choisi peut être particulièrement efficace s’il y a relative
ment peu de messages chiffrés possibles. Par exemple, si A i est un montant en francs
inférieur à un million, cette attaque marchera; le cryptanalyste essaye les un million
de montants possibles. (Le chiffrement probabiliste résoud ce problème; voir § 23.15.)
Même si A i n’est pas aussi clairement défini, cette attaque peut être très efficace.
Savoir simplement qu’un texte chiffré ne correspond pas à un texte en clair particulier
peut s’avérer une information utile. Un cryptosystème à clef secrète ne présente pas
ce défaut car un cryptanalyste ne peut pas faire des chiffrements d’essai avec une clef
inconnue.
Dans la plupart des applications pratiques, la cryptographie à clef publique est utilisée
pour protéger et distribuer les clefs de session, et ces clefs d e session sont utilisées
dans des algorithmes à clef secrète pour protéger les messages transmis [879]. Cela est
parfois appelé im c r y p to sy stè m e hybride.
1° Bernard envoie sa clef publique à Alice.

2° Alice engendre une clef de session aléatoire, k, la chiffre avec la clef publique
de Bernard et envoie le résultat à Bernard.
E B{k)
3° Bernard utilise sa clef privée pour déchiffrer le message d’Alice et ainsi retrou
ver la clef de session.
D B(EB(k)) = k
4° Alice et Bernard utilisent alors la même clef de session pour chiffrer leur
conversation.
En ce qui concerne la distribution des clefs, la cryptographie à clef publique résout un

important problème de manipulation de clefs. Avec la cryptographie à clef secrète, la
clef de chiffrement repose quelque part avant de servir. Si Estelle met la main dessus,
elle peut déchiffrer les messages qui seront chiffrés avec cette clef. Avec le protocole
ci-dessus, la clef de chiffrement est créée au moment de son utilisation pour chiffrer
les communications et elle est détruite dès qu’on en a plus besoin. Cela réduit consi
dérablement le risque de compromettre la clef de session. Bien sûr, c ’est la clef privée
qui risque d’être compromise, mais à moindre risque puisqu’elle n’est utilisée qu’une
fois par communication pour chiffrer une clef de session. Il en sera question au para
graphe 3.1.
Les énigmes de Merkle

Ralph Merkle a inventé le premier un système de cryptographie à clef publique. En
1974, il s’est inscrit à un cours de sécurité en informatique donné par Lance Hoffman
2.6 Signatures numériques 37
à l’Université de Berkeley en Californie. Son devoir de fin dânnée, soumis bien avant
la fin de l’année avait pour sujet le problème des « Communications privées par des
canaux peu sûrs » [1073]. Hoffman ne put comprendre l’idée de Merkle et ce dernier
abandonna peut-être le cours. Il continua de travailler sur le problème, malgrès un
échec continuel à faire comprendre ces résultats.
La technique de Merkle était basée sur des « énigmes » plus faciles à résoudre pour
l’expéditeur et le destinataire que pour un espion. Voici comment Alice envoie un
message chiffré à Bernard sans avoir besoin d’échanger une clef avec lui.
1° Bernard engendre 220 (ou environ un million) de messages de la form e: « Ceci

est l’énigme numéro x. Voici la clef secrète y », où x est un nombre alâtoire
et y une clef secrète aléatoire, x et y sont tous les deux différents pour chaque
message. Il chiffre chaque message avec une clef de 20 bits différente et les
envoie à Alice.
2° Alice choisi un message au hasard et opère une attaque exhaustive pour retrou
ver le texte en clair. Cela demande un travail important mais pas impossible.
3° Alice chiffre son message secret avec la clef qu’elle a récupérée et l’envoie à
Bernard avec x.
4° Bernard connaît la clef secrète y qu’il avait mise dans le message x, aussi
peut-il déchiffrer le message.
Estelle peut casser ce système, mais elle doit faire beaucoup plus de travail que Alice
ou Bernard. Pour retrouver le message de l’étape 3, elle doit effectuer une attaque
exhaustive sur chacun des 220 messages de l’étape 1; cette attaque a une complexité
de 240. La valeur de x n’aidera pas Estelle car elle a été donnée au hasard à l’étape 1.
En général, Estelle doit effectuer un effort environ égal au carré de celui produit par
Alice.
Cet avantage de n par rapport à n2 est petit pour les standards cryptographiques mais
cela peut suffir dans certaines circonstances. Si Alice et Bernard pauvent tester dix
mille clefs par seconde, il leur faudra chacun une minute pour mener à bien leur étape
et une autre minute pour envoyer les énigmes de Bernard à Alice par une liaison à 1,544
mégaoctets. Si Estelle dispose de moyens de calcul comparables, il lui faut environ un
an pour casser le système. Il existe d ’autres algorithmes encore plus difficiles à casser.
2.6 Signatures numériques

Les signatures manuscrites sur des documents ont été longtemps utilisées pour prou
ver l’identité de leur auteur ou du moins l’accord du signataire avec le contenu du
document. Qu’est-ce qui rend une signature si importante [1396] ?
1. Une signature est authentique. La signature convainc le destinataire que le signa

taire a délibérément signé le document.
2. Une signature ne peut pas être falsifiée (imitée). La signature est la preuve que
le signataire a délibérément signé le document.
3. Une signature n’est pas réutilisable. La signature fait partie du document et

une personne malintentionnée ne peut pas déplacer la signature sur un autre
document.
4. Un document signé est inaltérable. Une fois le document signé, il ne peut plus
être modifié.
5. Une signature ne peut pas être reniée. La signature et le document sont des
objets physiques. Le signataire ne peut pas prétendre plus tard ne pas avoir
signé le document.
Dans la réalité, aucune de ces affirmations n’est, tout à fait vraie. Les signatures peuvent
être falsifiées; des signatures peuvent être transférées d ’un document à l’autre. Les
documents peuvent être altérés après avoir été signés. Toutefois, nous acceptons de
vivre avec ces problèmes : c ’est difficile de tricher et on risque d’être démasquer.
On aimerait bien faire la même chose avec des ordinateurs mais il y a des problèmes.
Premièrement, les fichiers informatiques sont facilement copiables. Même si la signature
de quelqu’un est difficile à falsifier (une image graphique de la signature manuscrite,
par exemple), il est facile de la transférer d ’un document à un autre par « couper,
coller ». La simple présence d ’une telle signature ne garantit rier. Deuxièmement, il
est facile de modifier un document après qu’il a été signé sans laisser de traces de la
modification.
Signature de documents à l’aide d’un cryptosystème à clef se

crète et d’un arbitre
Alice veut signer un message numérique et l’envoyer à Bernard. Avec l’aide d ’Ivan et
d ’un cryptosystème à clef secrète, elle peut le faire.
Tvan est un arbitre puissant et respecté. Il peut communiquer avec Alice et Bernard
(ou toute autre personne désirant signer un message numérique). Il partage une clef
secrète, K a avec Alice et une clef secrète différente K b avec Bernard. Ces clefs ont été
établies longtemps avant que le protocole ne soit exécuté et elles peuvent être utilisées
plusieurs fois pour plusieurs signatures.
1° Alice chiffre son message pour Bernard avec la clef K a et envoie le résultat à
Ivan.
2° Ivan déchiffre le message avec K a -
3° Ivan assemble le message déchiffré et un avis comme quoi il a reçu ce message
d ’Alice. Ivan chiffre le résultat avec K b -
4° Bernard déchiffre le tout avec K b - Il peut maintenant lire le message et la
certification d’Ivan comme quoi Alice a bien envoyé ce message.
Comment Ivan sait-il que le message vient bien d ’Alice et non pas d’un imposteur? Il
déduit cela du message chiffré. Comme seuls lui et Alice partagent la clef secrète, seule
Alice peut chiffrer un message avec cette clef.
Est-ce aussi valable qu’une signature sur papier? Voyons caractéristique par caracté
ristique :
1. La signature est authentique. Ivan est un arbitre en qui on a confiance et Ivan
sait que le message venait d’Alice. Le certificat d ’Ivan sert de preuve à Bernard.
2. La signature est infalsifiable. Seule Alice (et Ivan mais tout le monde lui fait
confiance) connaît K A, donc seule Alice peut envoyer un message chiffré avec K A
à Ivan. Si quelqu’un avait essayé de se faire passer pour Alice, Ivan s’en serait
rendu compte immédiatement à l’étape 2 du protocole et n’aurait pas certifié
l’authenticité du message.
3. La signature n’est pas réutilisable. Si Bernard essaie de prendre le certificat d ’Ivan

et qu’il l’associe à un autre message, Alice crierait à l’imposture. Alors, un arbitre
(qui peut être Ivan, mais cela peut être n’importe quel arbitre ayant accès à la
même information) demanderait à Bernard de produire le texte en clair. L’arbitre
chiffrerait le texte en clair avec K A et constaterait que le message chiffré ne
correspond pas à celui que Alice a donné à Ivan. Bien entendu, Bernard ne peut
pas produire un message chiffré valide puisqu’il ne connaît pas K A.
4. Le document signé est immuable. Si Bernard falsifiait le message après l’avoir

reçu, Ivan pourrait dévoiler l’imposture exactement de la même façon que celle
décrite au paragraphe précédent.
5. La signature ne peut pas être reniée. Même si plus tard, Alice prétend ne pas
avoir envoyé le message, le certificat d ’Ivan démontre le contraire. Rappelez-vous
que tout le monde a confiance en Ivan, ce qu’il dit est la vérité.
Si Bernard veut montrer le document signé par Alice à Christine, il ne peut pas révéler
sa clef secrète à Christine. Il doit passer par Ivan également :
1° Bernard prend le message en clair et le texte du certificat d’Ivan, chiffre le tout

avec K b et envoie cela à Ivan.
2° Ivan déchiffre le tout avec K b -
3° Ivan vérifie dans sa base de données que le message original venait bien d’Alice.
4° Ivan chiffre le tout avec K ç (la clef secrète qu’il partage avec Christine) et
envoie le résultat à Christine.
5° Christine déchiffre le tout avec K c . Elle peut maintenant lire le message en
clair et le certificat d’Ivan qui affirme qu’Alice a bien envoyé ce message.
Ces protocoles sont valables mais ils sont coûteux en temps pour Ivan. Il doit passer ses
journées à chiffrer et déchiffrer des messages, jouant le rôle d’intermédiaire pour toute
paire de correspondants qui veulent s’échanger des documents signés. Il doit garder une
copie de chaque message (encore que ceci puisse-être évité en envoyant au destinataire
une copie du message crypté de l’expéditeur). Ivan va devenir le goulot d ’étranglement
du système de communication même s’il est incarné par un programme informatique
sans âme.
Ce qui est plus ardu reste encore de créer et d ’entretenir quelqu’un comme Ivan, quel
qu’un en qui tout le monde dans le réseau a confiance. Ivan doit être infaillible ; même
s’il ne fait qu’une erreur sur un million de signatures, personne n’aura confiance en
lui. Ivan doit être totalement sûr. Si sa base de données de clefs secrètes venait à être
divulguée ou si quelqu’un modifiait son code, toute signature deviendrait inutilisable.
Des faux documents prétendument signés des années auparavant pourraient fleurir. Il
en résulterait le chaos. Cela pourrait marcher en théorie mais il en va autrement de la
pratique.
Signature de documents à l’aide d’un cryptosystème à clef pu

blique
Il existe des algorithmes à clef publique qui peuvent être utilisés pour des signatures
numériques. Pour certains algorithmes — l’algorithme R SA (voir § 19.3) en est un
exemple — la clef publique, ou la clef privée peuvent être utilisées pour le chiffrement.
Chiffrez un document avec votre clef privée et vous avez une signature numérique
sûre. Dans d’autres cas — l’algorithme DSA (voir § 20.1) en est un exemple — il
y a un algorithme séparé pour les signatures numériques qui ne peut pas être utilisé
pour le chiffrement. Cette idée a été exprimée pour la première fois par DIFFIE et
H e l l m a n [494] et a été étendue et améliorée par d ’autres [1293, 1339, 1034, 1294, 440].
Se référer à [1105] pour une vue générale sur le domaine.
Le protocole est simple :
1° Alice chiffre le document avec sa clef privée, signant ainsi le document.

2° Alice envoie le résultat à Bernard.
3° Bernard déchiffre le message avec la clef publique d ’Alice, vérifiant ainsi la

signature.
Ce protocole est nettement meilleur que le précédent. Ivan n’est pas nécessaire ni pour
signer, ni pour vérifier les signatures8. Alice et Bernard n’ont même pas besoin d’Ivan
pour résoudre les contestations : si Bernard ne peut effectuer l’étape 3, alors il sait que
la signature n’est pas valide.
Ce protocole a aussi les propriétés que nous recherchons :
1. La signature est authentique: quand Bernard vérifie le message avec la clef pu
blique d’ Alice, il sait qu’Alice l’a signé.
2. La signature est infalsifiable : seule Alice connaît sa clef privée.
3. La signature n’est pas réutilisable : la signature est une fonction du document et

elle ne peut être transférée sur n’importe quel autre document.
4. Le document signé est immuable : s’il y a la moindre falsification du document,

il ne peut plus être vérifié avec la clef publique d ’Alice.
5. La signature ne peut pas être reniée. Bernard n’a pas besoin de l’aide d ’Alice
pour vérifier sa signature.
Documents signés et datations

En fait, Bernard peut duper Alice dans certaines circonstances. Il peut réutiliser la
signature et le document ensemble. Ce n’est pas très intéressant si Alice a signé un
contrat (qu’est-ce qu’une copie de plus ou de moins du contrat original?) mais cela
devient très intéressant si Alice a signé un chèque numérique.
Supposons qu’ Alice envoie à Bernard un chèque numérique d’une valeur de 100 francs
Bernard porte le chèque à la banque, celle-ci vérifie la signature et transfère l’argent du
8. II est nécessaire pour assurer que la clef publique d ’A lice est bien la sienne.
compte d ’Alice au compte de Bernard. Bernard qui est un personnage peu recomman-
dable garde une copie du chèque numérique. La semaine suivante, il peut l’apporter de
nouveau à la banque (ou même à une autre banque). La banque vérifie la signature et
transfère l’argent d ’un compte à l’autre. Si Alice ne vérifie jamais ses relevés bancaires,
Bernard peut continuer ainsi ad vitam aeternam.
Pour éviter cela, les signatures numériques contiennent souvent une datation (date +
heure) Cette datation de la signature est attachée à l ’ensemble du message et signée
avec le reste du message. La banque stocke ces datations dans une base de données.
Dès lors, si Bernard essaie d ’encaisser le chèque d’Alice une deuxième fois, la banque
compare la datation avec sa base de données. Comme la banque à déjà honoré ce chèque
avec la même datation, la banque appelle la police. Bernard passe alors quhize ans en
prison et occupe son temps libre à apprendre les protocoles cryptographiques.
Signature de documents à l’aide d’un cryptosystème à clef pu

blique et d’une fonction de hachage à sens unique
Dans les applications pratiques, les algorithmes à clef publique sont souvent trop in
efficaces pour signer de longs documents. Pour gagner du temps, les protocoles de
signatures numériques sont souvent réalisés avec des fonctions de hachage à sens
unique [432, 433]. Au lieu de signer le document, Alice signe l’empreinte du document.
Dans ce protocole, les choix de la fonction de hachage à sens unique et de l’algorithme
de signature numérique ont été fixés avant qu’il ne se déroule.
1° Alice calcule, à l’aide de la fonction de hachage à sens unique, l’empreinte de

son document.
2° Alice chiffre, à l’aide de l’algorithme de signature numérique, cette empreinte

avec sa clef privée, signant ainsi par la même occasion le document.
3° Alice envoie le document et l’empreinte signée à Bernard.

4° Bernard calcule, à l’aide de la fonction de hachage à sens unique,l’empreinte
du document qu’Alice lui a envoyé. Ensuite, à l’aide de l’algorithme de signa
ture numérique, il déchiffre l’empreinte signée avec la clef publique d’Alice. La
signature est valide si l’empreinte de la signature est la même que l’empreinte
qu’il a produite.
La vitesse de ce procédé est beaucoup plus élevée et comme les chances d ’avoir deux
documents différents ayant la même empreinte de 160 bits sont seulement de 1 sur 2160,
tout le monde peut sans crainte identifier la signature de l’empreinte à la signature du
document lui-même. Si la fonction utilisée n’est pas à sens unique, il serait aisé de créer
plusieurs documents ayant la même empreinte et d ’amener quelqu’un à les signer tous
à son insu en ne lui faisant signer qu’un seul. Ce protocole n’est pas valable sans une
fonction de hachage à sens unique.
Ce protocole a d ’autres avantages. Premièrement, la signature peut être gardée sépa
rément du document. Deuxièmement, pour le destinataire, les exigences en espace de
stockage pour le document et la signature sont beaucoup plus restreintes. Un système
d’archivage peut utiliser ce type de protocole pour vérifier l’existence d ’un document
sans stocker son contenu. La base de données centrale ne stockerait que les empreintes
des fichiers. Elle ne doit avoir aucun accès aux fichiers ; les utilisateurs envoient leurs
Chapitre 2 Briques élémentaires
empreintes à la base de données, et la base de données enregistre ces empreintes ainsi

que la datation. S’il y a par la suite un désaccord quant à l’auteur et la datation d ’un
document, la base de données n’a qu’à rechercher l’empreinte dans ses fichiers. Cela a
des implications très importantes pour la vie privée : Alice peut obtenir le copyright
d’un document et cepandant garder le document secret. Ce n’est que si elle doit prouver
ses droits qu’il lui faut rendre le document public (voir § 4.1).
Algorithmes et terminologie
Il y a de nombreux algorithmes de signature numérique. Tous sont des algorithmes à
clef publique : il y a une information secrète pour signer les documents et il y a une
information publique pour vérifier les signatures. Parfois le procédé de signature est
appelé ch iffrem en t avec une c le f p riv é e et le procédé de vérification est appelé
déch iffrem en t avec une c le f pu bliqu e. Cela prête à confusion et n’est valable que
pour un seul algorithme, R SA . Et diffients algorithmes présentent des différences de
réalisation. Par exemple, l’utilisation de fonctions de hachage à sens unique et/ou
de datations ajoute des étapes aux procédés de signature et de vérification. Plusieurs
algorithmes peuvent être utilisés pour des signatures numériques mais pas pour chiffrer.
En général, je ferai référence aux procédés de signature et de vérification sans plus
entrer dans le détail des algorithmes utilisés. Signer un message avec une clef privée K
est noté :
Sk ( M )
et vérifier une signature avec une clef publique correspondante est :
Vk ( M) .
La séquence de bits associée au document signé (dans l’exemple ci-dessus, l’empreinte

du document signée avec la clef privée) sera appelée signature n um ériqu e ou sim
plement signature. Le protocole, par lequel le destinataire d’un message est convaincu
de l’identité de l’expéditeur et de l’intégrité du contenu du message, est appelé authen
tification. Ces protocoles sont exposés plus en détail dans le paragraphe 3.2.
Signatures multiples
Comment Alice et Bernard peuvent-ils signer le même document numérique? Sans les
fonctions de hachage à sens unique, il y a deux façons de procéder. Dans le premier
cas, Alice et Bernard signent séparément des copies du document lui-même. Le message
résultant aura le double de la taille du document original. Dans le deuxième cas, Alice
signe le document en premier et ensuite Bernard signe la signature d’Alice. Cela marche
sauf qu’il est impossible de vérifier la signature d’Alice sans vérifier celle de Bernard.
Si une empreinte du document est signée en lieu et place du document lui-même, alors
le protocole pour la signature multiple est facile :
1° Alice signe le document.

2° Bernard signe le document.
3° Bernard envoie sa signature à Alice.

4 ° Alice envoie le document, sa signature et la signature de Bernard à Christine.
5° Christine vérifie les signatures d’Alice et de Bernard.
Alice et Bernard peuvent faire les étapes 1 et 2 en série ou en parallèle. Dans l’étape
5, Christine peut vérifier n’importe quelle signature sans vérifier l’autre.
Non désaveu et signatures numériques

Alice peut tricher avec les signatures numériques et il n’y a rien que l’on puisse faire
pour l’éviter. Elle peut signer un document et prétendre après coup qu’elle ne l’a
pas signé. D ’abord, elle signe le document normalement. Ensuite, elle publie de façon
anonyme sa clef privée, ou elle la laisse traîner dans un lieu public, ou elle prétend
seulement avoir fait l’une de ces deux actions. Alice prétend alors que sa clef privée est
compromise et que d ’autres s’en servent en se faisant passer pour elle. Elle nie avoir
signé le document et tout ceux qu’elle avait signés avec sa clef privée. Ceci s’appelle
un désaveu.
La datation permet de limiter la portée de ce type de tricherie mais Alice peut toujours
prétendre que sa clef a été compromise avant la signature du document. Si Alice fait les
choses dans les temps, elle peut signer un document puis prétendre ne pas l’avoir fait.
Voila pourquoi on entend si souvent parler de clefs privées cachées dans des dispositifs
résistant à l’investigation afin qu’Alice n’y ait pas accès et qu’elle ne puisse en abuser.
Bien que rien ne puisse être fait pour éviter ce type d’abus, on peut prendre des
mesures pour éviter que d’anciennes signatures ne puissent être remises en cause lors
de la contestation d ’une nouvelle signature. Par exemple, Alice pourrait « perdre » sa
clef pour éviter de payer à Bernard la babiole qu’il lui a vendue la veille et par la même
occasion remettre en cause tout débit sur son compte en banque. La solution est pour
le destinataire d’un document signé de le faire dater [456],
Le protocole général se trouve dans [32]:
1° Alice signe un message.

2° Alice remplie une entête avec des informations sur son identité. Elle signe cette
entête et le message signé et envoie le tout à Ivan.
3° Ivan vérifie la signature globale et l’identité d’Alice. Il ajoute une datation au

message signé et à l’entête. Ensuite, il signe et envoie le tout à Bernard et
Alice.
4° Bernard vérifie la signature d’Ivan, l’identité d’Alice et la signature de celle-ci.
5° Alice vérifie le message que Ivan a envoyé à Bernard. Si elle n’a pas émis le
message, elle le fait rapidement savoir.
Un autre protocole utilise Ivan après le fait [213]. Après avoir reçu un message signé,
Bernard peut en envoyer une copie à Ivan pour vérification. Ivan peut attester de la
validité de la signature d’Alice.
Applications des signatures numériques

Une des premières utilisations des signatures numériques fut de vérifier les traités de
limitations des essais nucléaires [1460, 1472]. Les États-Unis et l’Union soviétique (quel
qu’un sait-il encore ce qu’était l’Union Soviétique?) pouvaient mettre des sismographes
sur le territoire de leur homologue pour contrôler les essais nucléaires réellement effec
tués. Le problème était que la nation qui contrôlait voulait être sûre que l’homologue
ne truquait pas les données produites par les sismographes placés sur son sol. De plus,
chaque nation voulait s’assurer que les sismographes n’envoient que les informations
spécifiquement nécessaires au contrôle.
Les techniques d ’authentification traditionnelles permettaient de faire face au premier
problème mais seules les signatures numériques permettaient de faire face aux deux
problèmes. Grâce à ces dernières, la nation contrôlée pouvait lire les données des sis
mographes sur son territoire et la nation qui contrôle savait que les données n’avaient
pas été falsifiées.
2.7 Signatures numériques avec chiffrement

En combinant les signatures numériques avec la cryptographie à clef publique, nous
pouvons concevoir un protocole qui combine la sécurité du chiffrement avec l’authen-
tification des signatures numériques. Pensez à une lettre signée dans une enveloppe :
la signature numérique donne une preuve de l’identité de son auteur et le chiffrement
offre la confidentialité.
1° Alice signe le message avec sa clef privée.
Sa ( M )
2° Alice chiffre le message signé avec la clef publique de Bernard et lui envoie le
résultat.
E b (Sa ( M ) )
3° Bernard déchiffre le message avec sa clef privée.
D b (E b (Sa { M ) ) ) = S a { M )
4° Bernard vérifie avec la clef publique d ’Alice et obtient le message initial.
Va (Sa ( M ) ) = M
Il semble naturel de signer avant de chiffrer. Quand Alice écrit une lettre, elle la signe
et le met ensuite dans l’enveloppe. Si elle met la lettre non signée dans l’enveloppe
et signe ensuite l’enveloppe, alors Bernard pourrait craindre que la lettre n’aie été
remplacée. Si Bernard montrait à Christine la lettre et l’enveloppe d’Alice, Christine
pourrait l’accuser de mentir sur la lettre qui est arrivée dans l’enveloppe.
En matière de correspondance aussi il est prudent de signer avant de chiffrer. C ’est
non seulement plus sûr — un adversaire ne peut retirer la signature d’un message pour
y mettre la sienne — mais il faut prendre en compte des considérations légales: si le
signataire ne peut pas voir le texte qu’il signe, sa signature pourrait alors être contestée
au vues de la loi [1323]. De plus, il existe des attaques cryptanalytiques contre cette
technique utilisée avec des signatures R S A (voir § 19.3).
Alice n’a aucune raison d’utiliser la même paire clef publique, clef privée pour chiffrer
et signer. Elle peut avoir deux paires de clef: une pour chiffrer et une pour signer. La
Ü.7 Signatures numériques avec chiffrement
séparation présente des avantages: elle peut livrer sa clef de chiffrement à la police sans
compromettre sa signature, une clef peut être mise en dépôt (voir § 4.13) sans affecter
l’autre, et les clefs peuvent avoir des tailles différentes ou encore expirer à des dates
différentes.
Bien sûr, les messages doivent être datés pour éviter qu’ils ne soient réutilisés. La
datation peut aussi aider à se prémunir contre d’autres ennuis comme celui décrit dans
le paragraphe suivant.
Renvoyer un message comme accusé de réception

Considérons une réalisation de ce protocole avec en plus la possibilité d’envoyer des
messages de confirmation. Chaque fois que quelqu’un reçoit un message, il ou elle le
renvoie à l’expéditeur comme accusé de réception.
1° Alice signe un message avec sa clef privée, le chiffre avec la clef publique de
Bernard et lui envoie le résultat.
E b {Sa { M) )
2° Bernard déchiffre le message avec sa clef privée et vérifie la signature avec la

clef publique d’Alice, s ’assurant ainsi que c ’est bien Alice qui a signé le message
et obtenant également le message en clair.
Va (D b (E b (Sa ( M )))) - M
3° Bernard signe le message avec sa clef privée, le chiffre avec la clef publique
d’Alice et envoie le résultat à Alice.
E A(SB( M ) )
4° Alice déchiffre le message avec sa clef privée, et vérifie la signature avec la

clef publique de Bernard. Si le message obtenu est le même que celui qu’elle a
envoyé à Bernard, elle sait que celui-ci a reçu le message correctement.
Si le même algorithme est utilisé pour la signature numérique et le chiffrement, une

attaque est possible [505]. Dans ce cas, l’opération de signature numérique est l’inverse
de l’opération de chiffrement : Vx — E x et S x = E>x •
Faisons l’hypothèse que Martin est un utilisateur légitime du système ayant sa propre
clef publique et sa propre clef privée. Voyons ce qui se passe si Martin lit le courrier
de Bernard. Martin enregistre le message qu’ Alice envoie à Bernard à l’étape 1, puis
il envoie ce message à Bernard prétendant en être l’auteur. Bernard pense que c’est
un message légitime de Martin, il le déchiffre donc avec sa clef privée et essaie ensuite
de vérifier la signature de Martin en le déchiffrant avec la clef publique de Martin. Le
message obtenu qui est du pur charabia est :
E m {D b {E b {D a {M)))) = E m {D a { M) ) .
Même ainsi, Bernard continue à exécuter le protocole et envoie un accusé de réception

à Martin :
E m (D b (E m (D a (M)))).
Maintenant, il suffit à Martin de déchiffrer le message avec sa clef privée, de le chiffrer

avec la clef publique de Bernard, de le déchiffrer une fois de plus avec sa clef privée et
finalement de chiffrer le résultat avec la clef publique d ’Alice. Voilà! Martin a A4.
Il n’est pas déraisonnable d’imaginer que Bernard puisse envoyer l’accusé de réception
de manière automatique. Le protocole peut être, par exemple, inclus dans le logiciel
de communication et celui-ci peut envoyer les accusés de réception de manière au
tomatique. C ’est, cette obstination à envoyer un accusé de réception à du charabia
qui affaiblit le protocole. Si Bernard vérifiait la lisibilité du message avant d ’envoyer
l’accusé de réception, il éviterait ce problème de sécurité.
Il y a moyen d ’améliorer cette attaque de telle manière que Martin puisse envoyer un
message différent de celui qu’il a enregistré. Il est très important de ne jamais signer
n’importe quel message envoyé par d ’autres personnes ni de déchiffrer des messages
quelconques et de donner le résultat à quelqu’un d’autre.
Protection contre l’attaque

L ’attaque ci-dessus marche parce que l’opération de chiffrement est la même que l’opé
ration de vérification de signature et que l’opération de déchiffrement est la même que
l’opération de signature. Un protocole sûr utiliserait une opération pour le chiffrement
légèrement différente de l’opération de signature numérique, l’attaque serait évitée.
Le problème peut être résolu en utilisant au choix des clefs différentes pour chaque
opération, des algorithmes différents pour chaque opération, des datations qui rendent
le message entrant différent du message sortant, ou encore des signatures numériques
avec fonction de hachage à sens unique(voir § 2.6).
En général, le protocole suivant est parfaitement sûr :
1° Alice signe le message.

2° Alice chiffre le message et sa signature avec la clef publique de Bernard (uti
lisant un algorithme de chiffrement différent de celui utilisé pour la signature)
et envoie le résultat à Bernard.
3° Bernard déchiffre le message avec sa clef privée.
4° Bernard vérifie la signature d’Alice.
Il est possible de modifier le protocole afin qu’Alice chiffre le message avant de le signer.
Bien que cela puisse être utile dans certaines circonstances — quand un intermédiaire
doit pouvoir vérifier la signature sans être capable de lire le message — en général c ’est
mieux de chiffrer tout. Pourquoi donner de l’information à Estelle après tout?
Attaques contre la cryptographie à clef publique

Dans tous ces protocoles à clef publique, j ’ai passé sous silence comment Alice obtient
la clef publique de Bernard. Le paragraphe 3.1 explique cela en détail mais cela vaut
la peine d’en parler maintenant.
La méthode la plus facile pour obtenir une clef publique est de l’obtenir à partir d ’une
base de données sûre quelque part. Cette base de données doit être publique de telle
manière que n ’importe qui puisse y quérir la clef publique de quelqu’un d ’autre. La base
de données doit aussi être protégée en écriture sauf pour Ivan ; sinon Martin pourrait
2.8 Générateurs aléatoires et pseudo-aléatoires
remplacer la clef publique de Bernard par une de son choix. Après cela, Bernard ne
pourrait plus lire les messages qui lui seraient destinés tandis que Martin le pourrait.
Même si les clefs publiques sont stockées dans une base de données sûre, Martin peut
encore remplacer une clef par une autre pendant sa transmission. Pour éviter cela, Ivan
peut signer chaque clef publique avec sa propre clef privée (voir § 2.6). Quand Ivan
fait cela, il agit comme une Autorité d ’Authentification de Clefs ou comme un
Centre de Distribution de Clefs (appelons-le C D C en abrégé). Dans les réalisations
pratiques, le C D C signe un message composite contenant le nom de l’utilisateur, la clef
publique et toute autre information importante concernant l’utilisateur. Ce message
composite signé est stocké dans la base de données du C D C . Quand Alice obtient la
clef publique de Bernard, elle vérifie la signature du C D C pour s’assurer de la validité
de la clef qu’elle a obtenue.
En analyse finale, cela ne rend pas les choses impossibles pour Martin, juste plus
difficiles. Alice a encore la clef publique du C D C stockée quelque part. Martin doit
remplacer cette clef par la sienne, fausser la base de données et remplacer les clefs
valides par les siennes toutes signées avec sa clef privée comme s’il était le C D C et
alors il est arrivé à ses fins. Même des signatures sur papier peuvent être contrefaites si
Martin s’en donne la peine. Comme il a été dit précédemment, cela sera raconté dans
les moindres détails au paragraphe 3.1.
2.8 Générateurs aléatoires et pseudo

aléatoires
Pourquoi se préoccuper de générateurs aléatoires de nombres dans un livre sur la
cryptographie? Il y a déjà un générateur aléatoire de nombres inclus dans chaque
compilateur ; ce n’est qu’un simple appel de fonction après tout. Malheureusement,
ces générateurs aléatoires de nombres ne sont en général pas sûrs du tout du point de
vue cryptographique et probablement même pas très aléatoires. La plupart d’entre eux
sont désespérément mauvais.
Les générateurs aléatoires de suites ne sont pas aléatoires parce qu’ils ne doivent pas
l’être. La plupart des applications simples, telles que les jeux informatiques, ont besoin
de tellement peu de nombres aléatoires qu’on ne s’en rend même pas compte. Toutefois,
la cryptographie est très sensible aux propriétés des générateurs aléatoires de nombres.
Utilisez un générateur de mauvaise qualité et vous commencerez à avoir des corrélations
gênantes et des résultats étranges [1239, 1248]. Si la sécurité dépend de votre générateur
aléatoire de nombres, des corrélations non désirées ou des résultats étranges ne font
pas votre affaire.
Le problème d’un générateur aléatoire de nombres est qu’il ne produit pas une suite
aléatoire. Probablement, ce qu’il produit ne ressemble même pas de loin à une suite
aléatoire. Bien sûr, il est impossible de produire une suite aléatoire à l’aide d ’un or
dinateur. K n u t h cite John VON N e u m a n n comme maxime: « Toute personne qui
envisage d’utiliser des méthodes arithmétiques pour produire des chiffres aléatoires est,
bien sûr, en état de péché. » [864] Les ordinateurs sont des bestioles déterministes : on
les alimente à l’entrée, des opérations tout à fait prévisibles — déterministes — ont
lieu à l’intérieur et finalement un résultat sort à l’autre bout. Entrez la même chose
en deux instants différents et vous obtiendrez le même résultat à la sortie à chaque
fois. Entrez la même chose dans deux ordinateurs identiques et le même résultat sera
produit par chacun d ’eux. Il n’y a qu’un ensemble fini d ’états dans lesquels peut se
trouver un ordinateur (un grand nombre fini, mais un nombre fini toutefois) et ce qui
sort sera toujours une fonction déterministe de ce qui entre et de l’état de l’ordinateur.
Cela veut dire que tout générateur aléatoire de nombres sur ordinateur (du moins, sur
une machine de Turing) est, par définition, périodique. Tout ce qui est périodique est,
par définition, prévisible. Et ce qui est prévisible n’est pas aléatoire. Un vrai générateur
aléatoire de suites nécessite une entrée vraiment aléatoire ; un ordinateur ne peut pas
fournir cela.
Suites pseudo-aléatoires
Le mieux que peut produire un ordinateur est un gén érateu r p seu d o-a léa toire de
suites. Qu’est-ce? Beaucoup de gens se sont attaqués au problème de définir cela
formellement, mais je m ’abstiendrai ici. La période de la suite doit être suffisamment
longue de telle manière qu’une suite finie de longueur raisonnable — c ’est-à-dire une
suite qui soit utile dans un contexte donné — ne soit pas périodique. En d’autres
termes, si vous avez besoin d ’une suite d’un milliard de bits aléatoires, ne choisissez
pas un générateur qui a une période de 16000 bits. Ces sous-suites non périodiques
relativement courtes, doivent être autant que possible indiscernables d ’une suite aléa
toire. Par exemple, elles doivent avoir le même nombre de 1 que de 0 ; à peu près la
moitié des segments (suites de bits ayant la même valeur) doivent être de longueur 1,
un quart de longueur 2, un huitième de longueur 3, etc. On ne doit pas pouvoir les
compresser. Les distributions des segments de 0 et des segments de 1 doivent être les
mêmes [645, 864, 106, 1359]. Ces propriétés peuvent être mesurées empiriquement et
comparées aux prévisions statistiques en utilisant un test en y 2.
Pour nos besoins, un générateur de suites est pseudo-aléatoire s’il satisfait la propriété
suivante :
1. Il a l’air aléatoire. Cela veut dire qu’il réussit tous les tests statistiques que l’on
peut trouver. (Commencez par ceux décrits dans [864].)
Pas mal d’efforts ont été investis pour produire des bonnes suites pseudo-aléatoires
sur ordinateur. Les descriptions de tels générateurs abondent dans la littérature aca
démique, avec des tests variés sur leur caractère aléatoire. Tous ces générateurs sont
périodiques (il n’y a pas moyen de l’éviter) ; mais avec des périodes potentielles de 2256
bits et plus, il peuvent être utilisés pour les applications les plus exigeantes.
Mais le problème des corrélations non désirées et des résultats étranges est toujours
présent. Tout générateur déterministe en produira si vous l’utilisez d’une certaine façon.
Et c’est cette propriété que le cryptanalyste utilisera pour attaquer le système.
Générateurs pseudo-aléatoires cryptographiquement sûrs

Les applications cryptographiques exigent plus des générateurs pseudo-aléatoires de
suites que les autres applications informatiques. « Aléatoire du point de vue de la
cryptographie » ne signifie pas statistiquement aléatoire bien que cela en fasse partie.
Pour qu’une suite pseudo-aléatoire soit cry p tog ra p h iq u em en t sûre, le générateur
2.8 Générateurs aléatoires et pseudo-aléatoires 49
doit en plus satisfaire la propriété suivante :
2. Il est imprévisible. Il doit être impossible par calcul de prédire quel sera le bit aléa
toire suivant, connaissant complètement l’algorithme ou le matériel qui engendre
la suite et connaissant tous les bits déjà engendrés.
Les suites pseudo-aléatoires cryptographiquement sûres ne peuvent être comprimées...à

moins d’avoir le secret : le germe utilisé pour initialiser le générateur.
Comme tout algorithme cryptographique, les générateurs pseudo-aléatoires de suites
cryptographiquement sûrs peuvent subir des attaques. Tout comme il est possible de
casser un algorithme de chiffrement, il est possible de casser un générateur pseudo
aléatoire de suites cryptographiquement sûr. Faire des générateurs résistant aux at
taques est tout l’intêret de la cryptographie.
Suites vraiment aléatoires

Maintenant nous entrons dans le domaine des philosophes. Existe-t-il quelque chose
d'aléatoire! Qu’est-ce qu’une suite aléatoire? Comment savoir si une suite est aléatoire?
Est-ce que « 101110100 » est plus aléatoire que « 101010101 » ? La mécanique quantique
nous apprend qu’il y a des phénomènes physiques que l’on peut qualifier d’aléatoire
dans le monde réel. Mais est-ce que ce caractère aléatoire est préservé quand on le
transpose dans le monde macroscopique des puces informatiques et des machines à
nombre d’états fini?
Toute philosophie mise à part, de notre point de vue, un générateur de suites est
vraiment aléatoire s’il jouit de la propriété suivante :
3. Il ne peut pas être reproduit de manière fiable. Si vous exécutez le générateur de

suites deux fois avec exactement les mêmes entrées (du moins des entrées aussi
identiques que possible), vous obtenez deux suites aléatoires différentes.
La sortie d’un générateur satisfaisant ces trois propriétés conviendrait pour engendrer
un masque jetable, générer des clefs ou pour toute autre application cryptographique
qui a besoin d ’un générateur vraiment aléatoire. La difficulté est de déterminer si une
suite est vraiment aléatoire. En chiffrant de manière répétée une chaîne avec DES et
une clef fixée, on obtient une suite qui a l’air aléatoire; vous ne pourrez pas savoir si elle
n’est pas aléatoire, à moins d ’employer l’équipe de la NSA qui travaille sur le DES.
Chapitre 3
Protocoles élémentaires
*
3.1 Echange de clefs
Une technique cryptographique courante consiste à utiliser une clef différente pour
chiffrer chaque conversation entre deux individus. On parlera alors de clef de session
parce qu’elle n’est utilisée que pour une session particulière de communication. Comme
on le vera au paragraphe 8.5, les clefs de session sont utiles car elles n ’existent que
durant la durée de la communication. Il n’est pas simple de faire aboutir cette clef de
session commune entre les mains des participants de la conversation.
Échange de clefs à l’aide de la cryptographie à clef secrète

On fait l’hypothèse que Alice et Bernard sont des utilisateurs d’un réseau, et partagent
chacun une clef avec, le Centre de Distribution des Dlefs (CDC)[1270], Ivan dans notre
protocole. Ces clefs doivent être mises en service avant le protocole1.
1° Alice appelle Ivan et demande une clef de session pour communiquer avec
Bernard.
2° Ivan engendre aléatoirement une clef de session. Il chiffre deux copies de celle-
ci, l’une avec une clef secrète qu’il partage avec Alice, et l’autre avec une clef
secrète qu’il partage avec Bernard. Ivan envoie les deux copies à Alice.
3° Alice déchiffre sa copie de la clef de session.

4° Alice envoie à Bernard sa copie de la clef de session.
5° Bernard déchiffre sa copie de la clef de session.
6° Alice et Bernard utilisent la clef de session pour communiquer confidentielle
ment.
Ce protocole repose sur la sécurité absolue de Ivan qui sera plutôt un programme
informatique de confiance qu’une personne de confiance. Si Martin corrompt Ivan,
tout le réseau est compromis. Il a alors à sa disposition toutes les clefs secrètes que
1. Le protocole passe sous silence le réel problèm e de la distribution de ces clefs secrètes; on fait
l’hypothèse q u ’elles sont en service et que M artin ne sait pas où elles se trouvent.
52 Chapitre 3 Protocoles élémentaires
Ivan partage avec tous les utilisateurs ; il peut lire tous les messages passés qu’il a
enregistrés et toutes les communications futures. Tout ce qu’il doit faire c’est placer
une écoute sur les lignes de communication et enregistrer le trafic des messages chiffrés.
L’autre inconvénient de ce système est que Ivan représente un potentiel goulot d ’étran
glement. Il doit participer à chaque échange de clef. Si Ivan se trompe, cela perturbe
tout le système.
Échange de clefs à l’aide de la cryptographie à clef publique

Le cryptosystème hybride de base a été décrit dans le paragraphe 2.5. Alice et Bernard
utilisent la cryptographie à clef publique pour se mettre d’accord sur une clef de session,
et l’utilisent pour chiffrer des données. Dans une application pratique, les deux clefs
publiques signées d’Alice et Bernard seront accessibles dans une base de donnée. Cela
rend le protocole plus simple, et Alice peut envoyer de manière sûre un message à
Bernard, même s’il n’a jamais entendu parler d ’elle :
1° Alice obtient la clef publique de Bernard de la part du C D C .

2° Alice engendre une clef de session aléatoire, la chiffre avec la clef publique de
Bernard et envoie le résultat à Bernard.
4° Alice et Bernard utilisent alors la même clef de session pour chiffrer leur
conversation.
L’attaque de l’intercepteur
Tandis qu’Estelle ne peut pas faire mieux que tenter de casser l’algorithme à clef
publique, ou tenter une attaque à texte chiffré seulement contre les textes chiffrés,
Martin peut déchiffrer les messages entre Alice et Bernard. Martin est beaucoup plus
fort qu’Estelle. Non seulement il peut écouter les messages entre Alice et Bernard, mais
il peut aussi modifier des messages, détruire des messages et en insérer des nouveaux
de son cru. Martin peut se faire passer pour Bernard en s’adressantà Alice et se
faire passer pour Alice en s’adressant à Bernard. Voici comment l’attaque peut être
conduite :
1° Alice envoie sa clef publique à Bernard. Martin intercepte cette clef et envoie
sa propre clef publique à Bernard.
2° Bernard envoie sa clef publique à Alice. Martin intercepte cette clef et envoie
sa propre clef publique à Alice.
3° Quand Alice envoie un message à Bernard, chiffré avec ce qu’elle croit être
la clef publique de Bernard, Martin l ’intercepte. Comme ce message est en
fait chiffré avec sa clef publique, il le déchiffre avec sa clef privée, le chiffre à
nouveau avec la clef publique de Bernard et envoie le résultat à Bernard.
4° Quand Bernard envoie un message à Alice, chiffré avec ce qu’il croit être la
clef publique d’Alice, Martin l’intercepte. Comme ce message est en fait chiffré
avec sa clef publique, il le déchiffre avec sa clef privée, le chiffre à nouveau avec
la clef publique d’Alice et envoie le résultat à Alice.
3.1 Échange de clefs 53
Même si les clefs publiques d ’Alice et de Bernard sont stockées dans une base de
données, cette attaque peut être conduite. Il suffit que Martin intercepte la requête
d’Alice vers la base de données et qu’il envoie à Alice sa propre clef publique à la
place de celle de Bernard. Il peut faire la même chose avec Bernard et remplacer la clef
d’Alice par la sienne. Il peut même subrepticement pénétrer dans la base de données
et remplacer les clefs d’Alice et Bernard par sa clef publique. Le lendemain, il attend
simplement qu’Alice et Bernard dialoguent entre eux. Il intercepte alors les messages
et les modifie. Il a réussi.
L’attaque de l’intercepteur marche parce qu’Alice et Bernard n’ont aucun moyen de
vérifier qu’ils parlent bien l’un à l’autre. En faisant l’hypothèse que Martin est rapide
et qu’il n’introduit pas de délai notable dans le comportement du réseau, aucun des
deux ne peut soupçonner que quelqu’un est là entre eux deux en train d ’espionner toute
leur correspondance supposée confidentielle.
Protocole à cliquets
Le protocole à cliquets, inventé par Ron R i v e s t et Adi S h a m i r [1338] a de bonnes
chances de repousser l’attaque de l’intercepteur. Voici comment cela marche :
1° Alice envoie sa clef publique à Bernard.
2° Bernard envoie sa clef publique à Alice.

3° Alice chiffre son message avec la clef publique de Bernard. Elle envoie la moitié
du message chiffré à Bernard.
4° Bernard chiffre son message avec la clef publique d’Alice. Il envoie la moitié
du message chiffré à Alice.
5° Alice envoie l’autre moitié de son message chiffré à Bernard.
6° Bernard réunit les deux morceaux du messagechiffré venant d’Alice et déchiffre

le résultat avec sa clef privée. Bernard envoie l’autremoitié de son message
chiffré à Alice.
7° Alice réunit les deux morceaux du message chiffré venant de Bernard et dé
chiffre le résultat avec sa clef privée.
Le point important est qu’une moitié de message est inutilisable sans l’autre moitié ;
on ne peut déchiffrer les moitiés séparément. Bernard ne peut lire aucune partie du
message d ’Alice avant l’étape 6 et Alice ne peut lire aucune partie du message de
Bernard avant l’étape 7. Il y a plusieurs moyens de réaliser cela :
- Si l’algorithme de chiffrement est un algorithme par blocs, chaque moitié de

chaque bloc (par exemple, un bit sur deux) peut être envoyée dans chaque moitié
de message chiffré.
- Le déchiffrement du message peut être dépendant du vecteur d’initialisation (voir

§ 9.3) qui ne serait envoyé qu’avec la deuxième moitié du message.
- La première moitié du message pourrait être une empreinte du message chiffré

(voir § 2.4) et le message chiffré lui-même pourrait être la seconde moitié.
Pour voir comment cela complique la vie de Martin, revoyons sa tentative de corruption
du protocole. Il peut toujours remplacer les clefs publiques d ’Alice et de Bernard par
sa propre clef publique dans les étapes 1 et 2. Mais maintenant, quand il intercepte
la première moitié du message d’ Alice à l’étape 3, il ne peut pas le déchiffrer avec sa
clef privée et le rechiffrer avec la clef publique de Bernard. Il doit inventer un nouveau
message et envoyer la moitié à Bernard. Quand il intercepte la moitié du message de
Bernard vers Alice à l’étape 4, il a le même problème. Il ne peut pas le déchiffrer avec
sa clef privée et le rechifîrer avec la clef publique d’Alice. Il doit inventer un nouveau
message et envoyer la moitié de celui-ci à Alice. Quand il intercepte les deux autres
moitiés des messages d ’Alice et de Bernard aux étapes 5 et 6, il est trop tard pour qu’il
puisse changer les nouveaux messages qu’il a inventés. La conversation entre Alice et
Bernard sera forcément complètement différente de ce qu’elle aurait dû être.
Martin peut peut-être appliquer ce schéma. S’il connaît Alice et Bernard suffisamment
pour imiter les deux côtés d ’une conversation entre eux, alors ils ne se rendront jamais
compte qu’ils sont dupés. Mais c ’est certainement plus difficile pour Martin que de
simplement intercepter et lire les messages qu’ils s’échangent.
Échange de clefs à l’aide de signatures numériques

L’utilisation de signatures numériques pendant un protocole d ’échange de clefs de ses
sion permet également d’éviter l’attaque de l’intercepteur. Ivan signe les clefs publiques
d’Alice et de Bernard. Les clefs signées contiennent un certificat de propriété signé.
Quand Alice et Bernard reçoivent les clefs, ils vérifient chacun la signature d’Ivan.
Après cela, ils savent que la clef publique appartient bien à leur correspondant. Le
protocole d ’échange de clefs de session peut alors avoir lieu.
Martin a de sérieux problèmes. Il ne peut pas se faire passer pour Alice ou Bernard car
il ne connaît pas leurs clefs privées. Il ne peut pas remplacer une des clefs publiques
par la sienne parce que sa clef est signée comme étant celle de Martin. Tout ce qu’il
peut faire c ’est écouter le trafic entre Alice et Bernard ou encore il peut couper la ligne
pour empêcher Alice et Bernard de dialoguer.
Ce protocole repose sur Ivan mais le risque de corrompre le C D C est nettement in
férieur. Si Martin corrompt Ivan (s’il investit le C D C ), tout ce qu’il obtient c ’est la
clef privée d ’Ivan. Cette clef ne lui permet que de signer de nouvelles clefs ; il ne peut
déchiffrer aucune clef de session ou lire quelque message que ce soit. Pour pouvoir lire
les messages qui transitent, Martin doit pouvoir se faire passer pour un utilisateur du
réseau et amener des utilisateurs légitimes à chiffrer des messages avec sa fausse clef
publique.
Martin peut monter ce geiue d’attaque. Avec la clef privée d’Ivan, il peut créer des clefs
signées factices pour tromper Alice et Bernard. Après, soit il peut les enregistrer dans
la base de données à la place des clefs légitimes, soit il peut intercepter les requêtes
vers la base de données et répondre à la place de celle-ci en envoyant ses clefs factices.
Cela lui permet de mettre en œuvre une attaque de l’intercepteur et d’écouter les
communications des utilisateurs.
Cette attaque marche, mais rappelez-vous que Martin doit être un attaquant puissant.
Intercepter et modifier des messages est nettement plus difficile que de lire et déchiffrer
les messages qui transitent sur un réseau qui utilise un algorithme à clef secrète. Sur
un canal de diffusion, tel qu’un réseau radio, il est presque impossible de remplacer
un message par un autre, encore que le réseau entier puisse être brouillé. Dans les
3.1 Échange de clefs 55
réseaux informatiques, c’est plus facile et il semble que cela devienne plus facile chaque
jour. Il est possible de duper les protocoles d ’intercommunication et d ’attaquer les
routeurs d’un réseau; les attaque actives ne signifient pas quelqu’un dans les égouts
avec un stétoscope et elles ne sont pas réservées aux agences dont le nom comporte
trois lettres.
Transmission simultanée de clefs et de messages

Alice et Bernard n’ont pas besoin de terminer le protocole d ’échange de clefs avant
d’échanger des messages. Dans le protocole suivant, Alice envoie un message, A4, à
Bernard sans qu’il n’y ait eu d ’échange de clefs au préalable :
1° Alice engendre une clef de session aléatoire, K , et chiffre A4 en utilisant K .
E k (M)
2° Alice obtient la clef publique de Bernard par la base de données.

3° Alice chiffre K avec la clef publique de Bernard.
E b ( K)
4° Alice envoie le message chiffré et la clef de session chiffrée à Bernard.
E k (A4),E b ( K )
Pour mieux se prémunir contre une attaque de l’intercepteur, Alice peut signer
la transmission.
5° Bernard déchiffre la clef de session, K , en utilisant sa clef privée.
6° Bernard déchiffre le message d’Alice en utilisant la, clef de session.
C’est avec ce système hybride que la cryptographie à clef publique est souvent utilisée
dans les systèmes de communication. Elle peut être combinée aux signatures numé
riques, à la datation, ou à tout autre protocole de sécurité.
Diffusion de clef et de message

Il n’y a pas de raison pour qu’Alice ne puisse envoyer le message chiffré à plusieurs
personnes. Dans l’exemple suivant, Alice envoie le message chiffré à Bernard, Christine
et David :
1° Alice engendre une clef de session aléatoire, K , et chiffre A4 avec K .
E k (A4)
2° Alice obtient les clefs publiques de Bernard, Christine et David par la base de
données.
3° Alice chiffre K avec la clef publique de Bernard, chiffre K avec la clef publique
de Christine et chiffre K avec la clef publique de David.
E b (K) , E c ( K) ,E d (K)
4° Alice diffuse le message chiffré et toutes les clefs chiffrées à qui veut bien les
recevoir.
E b (K),Ec (K),Ed (K),Ek ( M )
5° Seuls Bernard, Christine et David peuvent déchiffrer la clef de session K à

l’aide de leur clef privée.
6° Seuls Bernard, Christine et David peuvent déchiffrer le message d'Alice en

utilisant K .
Cet algorithme peut être réalisé dans un réseau « stocke-et-relaie ». Un serveur central
peut relayer le message d’Alice à Bernard, Christine et David avec chacun une version
chiffrée de la clef de session. Le serveur n’a pas à être sûr et il n’a pas à avoir la
confiance des utilisateurs car il ne peut déchiffrer aucun message.
3.2 Authentification
Quand Alice accède à un ordinateur (ou un distributeur de billets automatique, ou un
service de banque à domicile, ou tout autre type de terminal), comment l’ordinateur
peut-il savoir qui elle est? Comment l’ordinateur sait-il qu’elle n’est pas Estelle essayant
de se faire passer pour Alice? Traditionnellement, les mots de passe servent à résoudre
ce problème. Alice entre un mot de passe, et l’ordinateur confirme qu’il est correct.
Alice et l’ordinateur connaissent tous deux cette information secrète, et l’ordinateur le
demande à Alice chaque fois qu’elle essaie d’entrer en communication avec lui.
Authentification à l’aide de fonctions à sens unique

Ce que Roger N e e d i i a m et Mike G u y ont réalisé, c’est que l’ordinateur n’a pas besoin
de connaître les mots de passe: l’ordinateur doit juste être capable de distinguer un
mot de passe correct d ’un mot de passe incorrect. C ’est facile à l’aide de fonctions à
sens unique [1601, 528, 1285, 1127]. Au lieu de stocker les mots de passe, l’ordinateur
stocke le résultat de la fonction à sens unique appliquée à chacun des mots de passe.
1° Alice envoie son mot de passe à l’ordinateur.

2° L ’ordinateur calcule la fonction à sens unique du mot de passe.
3° L ’ordinateur compare le résultat de ce calcul à celui qu’il a danssa basede

données.
L’attaque de quelqu’un qui pénètre dans le système informatique et qui vole la liste
des mots de passe est moins à craindre, car l’ordinateur ne stocke plus la table des
mots de passe corrects mais bien la liste des résultats de l’application de la fonction à
sens unique aux mots de passe. Cette liste est inutilisable parce que la fonction à sens
unique ne peut pas être inversée pour retrouver les mots de passe.
Attaque par dictionnaire et salage

Même le fichier des mots de passe chiffrés avec une fonction à sens unique est vulnérable.
Pendant son temps libre, Martin construit la liste des 1000 000 mots de passe les plus
3.2 Authentification 57
utilisés. Il calcule alors la fonction à sens unique pour tous les 1000 000 mots de passe
et stocke le résultat.
Si chaque mot de passe a environ 8 octets, le fichier résultant n’aura pas plus de 8
méga-octets ; ce qui tient aisément sur quelques disquettes. Ensuite, Martin vole le
fichier des mots de passe chiffrés. Il compare les mots de passe chiffrés avec son fichier
des mots de passe chiffrés possibles et localise ceux qui sont identiques.
C’est une attaque par dictionnaire. Celle-ci est étonnamment efficace en pratique
(voir § 8.1). Le salage est un moyen de rendre cette attaque plus difficile. Le sel est
une chaîne aléatoire qui est jointe au mot de passe avant qu’il ne soit transformé par la
fonction à sens unique. Ensuite, le sel utilisé et le résultat de la fonction à sens unique
sont tous deux stockés dans la base de données. Si le nombre de valeurs de sel possibles
est suffisamment grand, cela empêche presque tout à fait l’attaque par dictionnaire
de mots de passe communs car Martin doit calculer les valeurs de la fonction à sens
unique pour chaque sel. C ’est un embryon de vecteur d ’initialisation (voir § 9.3).
L’idée ici est d’obliger Martin à chiffrer chacun des mots de passe de son dictionnaire
qu’il tente comme mot de passe de quelqu’un et ce pour chaque nouvelle personne et
non une fois pour toutes.
Il faut pas mal de sel. La plupart des systèmes U N IX n’utilisent que 12 bits pour
le sel. Même avec cela, Daniel K l e in a développé un programme qui retrouve 21 %
des mots de passe sur un système donné en à peu près une semaine [848, 849]. David
F e l d m e ie r et Philip K a r n ont rassemblé une liste d ’environ 732 000 mots de passe
communs combinés avec 4096 valeurs possibles de sel. Ils estiment qu’environ 30 %
des mots de passe d’un système donné peuvent être retrouvés grâce à cette liste [563].
Saler n’est par le remède universel; augmenter le nombre de bits du sel ne va pas
résoudre tous les problèmes. Le sel ne protège que contre les attaques par dictionnaires
contre un fichier de mots de passe chiffrés, mais non contre une attaque concertée
dirigée contre un seul mot de passe. Le salage masque le fait que certaines personnes
ont le même mot de passe sur plusieurs systèmes mais cela ne rend pas meilleurs des
mots de passe mal choisis.
SKEY
SKEY est un programme d’authentification dont la sécurité repose sur une fonction à
sens unique / . Il est facile à expliquer.
Pour mettre en place le système, Alice entre un nombre aléatoire R. L ’ordinateur calcule
f(R), f {f {R)) , f(.f(f(R))) et ainsi de suite cent fois. Notons ces nombres X i , . . . , x 10o-
L’ordinateur affiche la liste de ces nombres et Alice la met dans sa poche à l’abri.
L’ordinateur conserve aussi Xioi en clair dans une base de données à côté du nom
d’Alice.
La première fois qu’Alice veut se connecter, elle entre son nom et aqoo- L’ordinateur cal
cule f ( x ioo) et le compare avec arioiî s’il sont égaux, Alice est authentifiée. L’ordinateur
remplace alors aqoi par .x10o dans la base de données. Alice barre aqoo de sa liste.
Chaque fois qu’Alice se connecte, elle entre le dernier nombre x* qu’elle n’a pas encore
barré sur sa liste. L ’ordinateur calcule f{xf) et le compare avec xi + 1 qui se trouve dans
la base de donnée. Estelle ne peut pas obtenir d ’information intéressante car chacun
des nombres n’est utilisé qu’une seule fois, et la fonction est à sens unique. De cette
manière, un attaquant ne peut pas se servir de la base de données. Bien sûr, quand
Alice est à court de nombres sur sa liste, elle doit refaire l’opération d ’initialisation du
système.
Authentification grâce à la cryptographie à clef publique

Même avec du sel, le premier protocole présente des défauts de sécurité sérieux. Quand
Alice entre son mot de passe dans le système, toute personne qui a accès au chemin
des données entre le point de saisie et l’ordinateur hôte 2 peut le lire. Elle peut accéder
à l’ordinateur hôte à travers un long chemin tortueux en passant par quatre sociétés
industrielles concurrentes, trois pays, ou encore deux universités avant-gardistes. En
chacun de ces points de passages, Estelle peut écouter la séquence d’accès. Si Estelle a
accès au processeur et à la mémoire de l’ordinateur hôte, elle peut lire le mot de passe
avant qu’il ne soit chiffré.
La cryptographie à clef publique peut résoudre ce problème. L’ordinateur hôte gère
un fichier avec la clef publique de chaque utilisateur ; chaque utilisateur garde sa clef
privée. Voici un premier protocole naïf. Lors de la séquence d ’accès, le protocole se
déroule comme suit :
1° L ’ordinateur hôte envoie une chaîne de caractères aléatoire à Alice.

2° Alice chiffre cette chaîne avec sa clef privée et envoie le résultat à l’ordinateur
hôte avec son nom.
3° L ’ordinateur hôte utilise la clef publique d’Alice qui est dans sa base de données
et déchiffre le message à l ’aide de celle-ci.
4° Si la chaîne obtenue est la même que celle que l’ordinateur hôte a envoyée
à Alice en premier lieu, l’ordinateur hôte sait que c ’est bien Alice qui essaie
d ’accéder au système.
Personne d’autre n’a accès à la clef privée d’Alice et donc personne ne peut se faire
passer pour Alice. Ce qui est plus important encore : Alice n’envoie jamais sa clef privée
sur la ligne de communication vers l’ordinateur hôte. Estelle, qui écoute le protocole,
ne peut obtenir aucune information qui lui permette de deviner la clef privée ou de se
faire passer pour Alice.
La clef privée est longue et non mnémonique. De plus, elle sera manipulée automatique
ment par le logiciel et le matériel de communication de l’utilisateur. Le terminal d’Alice
doit donc être « intelligent » et Alice doit avoir confiance en lui, mais ni l’ordinateur
hôte à distance, ni le canal de communication n’ont à être sûrs.
En général, il est idiot de chiffrer des chaînes de caractères aléatoires envoyées par
un autre participant : des attaques telles que celles décrites dans le paragraphe 19.3
peuvent être montées.
Un protocole de preuve d ’identité sûr prend la forme plus compliquée suivante :
1° Alice effectue des calculs à partir de quelques nombres aléatoires et de sa clef

privée. Elle envoie le résultat à l’ordinateur hôte.
2° L ’ordinateur hôte envoie à Alice un nombre aléatoire différent.
2. N ote du traducteur : on parlera ici d ’ « ordinateur hôte » pour désigner l’ordinateur auquel Alice
désire se connecter pour le différencier de l’ordinateur dont A lice se sert éventuellement pour se
connecter, stocker sa clef privée et effectuer sa part des calculs. C e dernier ne doit pas forcément être
un P C mais peut tou t aussi bien être une carte à puces.
3.2 Authentification 59
3° Alice effectue des calculs à partir des nombres aléatoires (ceux qu’elle avait
choisis et celui qui lui a été envoyé par l’ordinateur) et de sa clef privée. Elle
envoie le résultat à l’ordinateur hôte.
4° L ’ordinateur hôte effectue un calcul à partir des différents nombres qu ’il a reçus
d’Alice et de la clef publique d’Alice pour vérifier qu’Alice connaît bien sa clef
privée.
5° Si tel est le cas, l’identité d’Alice est vérifiée.
Si Alice n’a pas plus confiance en l’ordinateur hôte que l’ordinateur hôte n’a confiance
en Alice, alors Alice peut demander à l’ordinateur hôte de prouver son identité de la
même manière.
L’étape 1 peut paraître superflue et déroutante mais elle est nécessaire pour résister
à certaines attaques. Les sections 21.1 et 21.2 décrivent mathématiquement plusieurs
algorithmes et protocoles. Voyez aussi [946].
Authentification mutuelle par protocole à cliquets

Alice et Bernard sont deux utilisateurs qui veulent s’identifier mutuellement. Chacun
d’entre eux a un mot de passe que l’autre connaît: Alice a Pa et Bernard a Pg. Voici
un protocole qui ne marche pas :
1° Alice et Bernard échangent leurs clefs publiques.

2° Alice chiffre Pa avec la clef publique de Bernard et envoie le résultat à Bernard.
3° Bernard chiffre Pg avec la clef publique d’Alice et envoie le résultat à Alice.

4° Alice déchiffre PB et vérifie que c 'est correct.
5° Bernard déchiffre P a et vérifie que c ’est correct.
Martin peut monter avec succès une attaque de l’intercepteur (voir § 3.1) :
1° Alice et Bernard échangent leurs clefs publiques. Martin intercepte les deux
messages. Il remplace la clef publique de Bernard par la sienne et envoie le
résultat à Alice. Il remplace la clef publique d’Alice par la sienne et envoie le
résultat à Bernard.
2° Alice chiffre Pa avec la clef publique qu’elle croit être celle de Bernard et envoie
le résultat à Bernard. Martin intercepte le message, déchiffre P a avec sa clef
privée, rechiffre Pa avec la clef publique de Bernard et envoie le résultat à
Bernard.
3° Bernard chiffre Pg avec la clef publique qu’il croit être d’Alice et envoie le
résultat à Alice. Martin intercepte le message, déchiffre Pg avec sa clef privée,
rechiffre Pg avec la clef publique d’Alice et envoie le résultat à Alice.
4° Alice déchiffre Pg et vérifie que c ’est correct.

5° Bernard déchiffre P a et vérifie que c ’est correct.
Du point de vue d’Alice et Bernard, rien ne change. Mais maintenant, Martin connaît
Pa et Pg
Donald D a v ie s et W yn P r ic e décrivent comment le protocole à cliquets peut empêcher

cette attaque [435] : Steve B e l l o v i n et Michael M e r r i t t décrivent des méthodes
d’attaque contre ce protocole [118]. Si Alice est un utilisateur et Bernard un ordinateur
hôte, Martin peut prétendre être Bernard, exécuter les étapes 1 à 5 du protocole avec
Alice et ensuite couper la communication. Cela doit être idéalement fait avec grand art
par Martin en simulant du bruit de ligne ou des pannes de réseau mais peu importe,
Martin a le mot de passe d’Alice. Il peut maintenant se mettre en communication avec
Bernard et compléter le protocole. Voilà ! Martin a le mot de passe de Bernard.
Le protocole peut être modifié de telle manière que Bernard donne son mot de passe
avant Alice en faisant l’hypothèse que le mot de passe de l’utilisateur est nettement
plus sensible que le mot de passe de l’ordinateur hôte. Une variante plus compliquée
permet d’attaquer cette version modifiée du protocole (voir [118]).
SKID
SKID2 et SK ID 3 sont des protocoles d’identification à clef secrète développés pour
le projet R IP E du programme R A C E [1316] (voir § 25.7). Ils utilisent une fonction
à sens unique à clef (un C A M , pour « Code d'Authentification de Messages », voir
§ 2.4) pour fournir la sécurité, et tous les deux font l’hypothèse qu’Alice et Bernard
partagent une clef secrète K .
SKID2 permet à Bernard de prouver son identité à Alice. Voici le protocole :
1° Alice choisit un nombre aléatoire, R a ■ Le document R IP E précise qu’il doit

avoir 64 bits. Elle l’envoie à Bernard.
2° Bernard choisit un nombre aléatoire, R b - Le document R IP E précise qu’il doit

avoir 64 bits. Il envoie à Alice :
R b ,H k {R a ,Rb ,B)
H k est le C A M . (Le document R IP E suggère d’utiliser la fonction R IP E -

M A C — voir § 18.14). Dans la formule, B est le nom de Bernard.
3° Alice calcule H k (R a , R b ,B) et compare avec ce qu’elle a reçu de Bernard. Si

les valeurs sont égales alors Alice sait qu’elle communique avec Bernard.
SKID3 offre l’identification mutuelle d ’Alice et Bernard. Les étapes1 à3 sontiden

tiques à celles de SKID2 et le protocole se poursuit ainsi :
4° Alice envoie à Bernard :

H k {R b ,A)
Dans la formule, A est le nom d’Alice.
5° Bernard calcule H k {R b ,A) et compare avec ce qu’il a reçud’Alice. Silès va

leurs sont égales alors Bernard sait qu’il communique avec Alice.
Ce protocle n’est pas sûr contre l’attaque de l’intercepteur. En général, l’attaque de

l’intercepteur est à redouter dans les protocoles qui ne mettent pas en jeu un secret de
quelque nature que ce soit.
3.3 Authentification et échange de clefs 61
Authentification de message
Quand Bernard reçoit un message de la part d ’Alice, comment est-il sûr de son authen
ticité? Si Alice a signé son message, c’est facile. La signature numérique suffit pour
convaincre n’importe qui de l’authenticité du message.
La cryptographie à clef secrète permet une part d’authentification. Quand Bernard
reçoit de la part d ’Alice un message chiffré avec la clef qu’il partagent, il sait qu’il
vient bien d’Alice. Personne d’autre ne connaît leur clef. Toutefois, Bernard n’a aucun
moyen de prouver ce fait à un troisième parti. Bernard ne peut pas montrer le message
à Ivan et le convaincre qu’il vient d ’Alice. Ivan peut être convaincu que le message
vient soit d ’Alice, soit de Bernard (car ils sont les seuls à posséder cette clef secrète),
mais il ne peut pas savoir lequel.
Si le message n’est pas chiffré, Alice pourrait aussi utiliser un CAM . Cela convaincra
aussi Bernard de l’authenticité du message, mais cela présente le problème que la
solution apportée par la cryptographie à clef secrète.
3.3 Authentification et échange de clefs

Les protocoles suivants résolvent un problème informatique général.
Alice et Bernard sont en deux points distants d’un réseau. Ils veulent dialoguer entre
eux en toute confidentialité. Comment Alice et Bernard peuvent-ils échanger une clef
secrète et en même temps être sûrs qu’ils se parlent bien l’un à l’autre et non pas à
Martin? Dans la plupart des cas, on fait l’hypotlièse qu’Ivan partage une clef secrète
distincte avec chaque participant et que ces clefs ont été mises en place avant le début
du protocole.
La tableau 3.1 récapitule les symboles rencontrés dans les protocoles.
T a b . 3.1 - Symboles utilisés dans les protocoles d’authentification et déchange de clefs

A le nom d’Alice
B le nom de Bernard
ea chiffrement avec une clef partagée par Ivan et Alice
Eg chiffrement avec une clef partagée par Ivan et Bernard
I un numéro d’ordre °
K une clef de session aléatoire
L une longévité
Ta ,Tb des datations
Il a ; l ig des nombres aléatoires choisis par Alice et Bernard respectivement
“ Note du traducteur: ce num éro perm et différencier les différentes utilisations d ’un mêm e protocole.
« Wide-Mouth Frog »
Le. protocole « Wide-Mouth Frog » [287, 288] est probablement le protocole de gestion
de clefs secrètes le plus simple qui utilise un serveur en qui l’on a confiance. Alice
et Bernard partagent chacun une clef secrète avec Ivan. Ces clefs ont elles-mêmes été
distribuées secrètement et avec garantie d ’authenticité par un autre canal externe dont
62 Chapitre S Protocoles élémentaires
nous admettrons qu’il est sûr. Ces clefs sont seulement utilisées pour la distribution
des clefs et non pas pour chiffrer des messages entre utilisateurs. Rien qu’en utilisant
deux messages, une clef de session est transférée d ’Alice à Bernard :
1° Alice combine la datation, le nom de Bernard, B et une clef de session aléatoire

et chiffre le tout avec la clef secrète qu ’elle partage avec Ivan. Elle envoie le
résultat chiffré à Ivan avec son nom.
A , E a (Ta , B, K)
2° Ivan déchiffre le message d’Alice. Ivan combine une nouvelle datation, le nom,
d’Alice, et la clef de session aléatoire. Il chiffre le tout avec la clef secrètequ’il
partage avec Bernard. Ivan envoie le résultat chiffré à Bernard.
E B(TB, A , K )
L’hypothèse la plus risquée faite par ce protocole est qu’Alice est suffisamment com
pétente pour engendrer des clefs de session valables. Rappelez-vous qu’il n’est pas aisé
d’engendrer des nombres aléatoires ; le protocole fait peut-être trop confiance à Alice
à ce propos.
Yahalom
L’auteur de ce protocole est Y a h a l o m [187]. Comme dans le protocole précédent, Alice
et Bernard partagent une clef secrète avec Ivan [287, 288].
1° Alice combine son nom avec un nombre aléatoire et envoie le tout à Bernard:
A, R a
2° Bernard combine le nom d ’Alice, le nombre aléatoire d’Alice, un autre nombre

aléatoire et chiffre le tout avec la clef secrète qu ’il partage avec Ivan. Il envoie
ceci à Ivan avec son nom :
B , E b (A,R a ,R b )
3° Ivan engendre deux messages. Le premier est constitué du nom de Bernard,

une clef de session aléatoire pour Alice et Bernard, le nombre aléatoire d’Alice
et le nombre aléatoire de Bernard; le tout étant chiffré avec la clef secrète qu'il
partage avec Alice. Le deuxième est constitué du nom d’Alice et de la clef de
session aléatoire; le tout étant chiffré avec la clef secrète qu’il partage avec
Bernard. Il envoie les deux messages chiffrés à Alice :
E a ( B , K , R a ,R b ),E b (A, K)
4° Alice déchiffre le message chiffré avec sa clef secrète, extrait K , et confirme que
R a a la même valeur qu’à l’étape 1. Alice envoie à Bernard deux messages. Le
premier est le message qu’elle a reçu d’Ivan, chiffré avec la clef de Bernard. Le
deuxième est R B, chiffré avec la clef de session:
E b ( A , K) , E k (R b )
5° Bernard déchiffre le message chiffré avec sa clef, extrait K et confirme que R b

est le même que celui de l’étape 2.
Finalement, Alice et Bernard sont convaincus qu’ils se parlent bien l’un à l’autre et
non pas à un tiers. La nouveauté ici c ’est que Bernard est le premier à contacter Ivan
qui n’envoie qu’un seul message à Alice.
Needham et Schroeder
Ce protocole, inventé par Roger N e e d h a m et Michael S c h r o e d e r [1159], utilise aussi
la cryptographie à clef secrète et Ivan.
1° Alice envoie un message à Ivan constitué de son nom, du nom de Bernard, et

d’une valeur aléatoire:
(A , B , R a )
2° Ivan chiffre, avec la clef secrète qu ’il partage avec Bernard, un message consti
tué d’une clef de session aléatoire et du nom d’Alice. Ensuite, il chiffre, avec la
clef secrète qu ’il partage avec Alice, un message constitué de la valeur aléatoire
d’Alice, du nom de Bernard, de la clef de session et du message chiffré avec la
clef secrète qu’il partage avec Alice. Finalement, il envoie à Alice le message
chiffré :
E a (Ra , B , K , E b (K,A))
3° Alice déchiffre le message et extrait K . Elle confirme que R a est bien la même
valeur qu’elle a envoyée à Ivan à l’étape 1. Ensuite, elle envoie à Bernard le
message qu ’lvan a chiffré avec la clef de Bernard :
E b (K,A)
4° Bernard déchiffre le message et extrait K . Il engendre alors un autre nombre

aléatoire. Il chiffre ce nombre avec K et envoie le résultat à Alice:
E k {Bb )
5° Alice déchiffre le message avec K . Elle engendre R b — 1 et le chiffre avec K .

Elle envoie le résultat à Bernard:
E k {Rb — 1 )
6° Bernard déchiffre le message avec K et vérifie qu’il s ’agit bien de R b ~ 1.
Toutes ces allées et venues avec Ra , R b et R b —1 garantissent qu’il n’y a pas d’attaque
où les messages sont rejoués. La présence de R a à l’étape 3 confirme à Alice que le
message d’Ivan est légitime et non pas une répétition d ’une réponse à une exécution
antérieure du protocole. Quand Aüce déchiffre R b avec succès et qu’elle envoie R b — 1
chiffré à Bernard à l’étape 5, celui-ci est assuré que les messages d ’Alice ne sont pas
des répétitions de messages d’exécutions antérieures du protocole.
Le plus grand problème de sécurité avec ce protocole est que les vieilles clefs de session
ont de la valeur. Si Martin parvient à obtenir une ancienne clef de session K , il peut
monter l’attaque suivante avec succès [467]. Tout ce qu’il doit faire c ’est enregistrer
les messages d ’Alice à Bernard pendant l’étape 3. Alors, une fois qu’il a K , il peut
prétendre être Alice :
1° Martin envoie à Bernard, le message suivant :
E b (K ,A )
2° Bernard extrait K , engendre R b et envoie à celle qu’il croit être Alice:
E k (R b )
3° Martin intercepte le message, le déchiffre avec K et envoie à Bernard :
E k {R b - 1)
4° Bernard vérifie que le message prétendument d’Alice est Rb — 1.
Maintenant, Martin a convaincu Bernard qu’il est Alice.

Un protocole avec datation peut faire échouer cette attaque [467, 462]. Une datation
est ajoutée au message d ’Ivan chiffré à l’étape 2 avec la clef de Bernard: E B(K,A,T).
Pour les datations, une horloge système sûre et précise est nécessaire, ce qui n’est pas
trivial en soit à réaliser.
Les conséquences sont dramatiques si la clef secrète partagée entre Alice et Ivan vient à
être compromise. Martin peut l’utiliser pour obtenir des clefs de session pour dialoguer
avec Bernard (ou toute autre personne avec qui il veut converser). Pis encore, Martin
peut continuer à faire cela même si Alice change sa clef [96].
N e e d h a m et S c h r o e d e r ont essayé de corriger leur protocole pour faire face à ces at
taques [1160]. Leur nouveau protocole est essentiellement le m êm e que celui d ’ OTWAY-
R e e s publié dans le même numéro du même journal.
Otway-Rees
Ce protocole utilise aussi la cryptographie à clef secrète [1234].
1° Alice engendre un message constitué d’un numéro d ’ordre, de son nom, du nom
de Bernard, et d’un nombre aléatoire, le tout chiffré avec la clef secrète qu’elle
partage avec Ivan. Elle envoie le message chiffré à Bernard avec le numéro
d ’ordre, son nom à elle et son nom à lui:
I , A , B , E a (R a ,I,A,B)
2° Bernard engendre un message constitué d’un nouveau nombre aléatoire, du

numéro d’ordre, du nom d’Alice et celui de Bernard, le tout chiffré avec la clef
secrète qu’il partage avec Ivan. Il envoie le message chiffré résultant à Ivan
avec le message chiffré qu’il a reçu d’Alice, le numéro d’ordre, son nom à elle
et son nom à lui:
I,A ,B ,E a {R a ,I,A ,B ),E b {R b ,I,A,B)

3° Ivan engendre une clef de session aléatoire. Il crée alors deux messages. L ’un
est composé du nombre aléatoire d’Alice et de la clef de session, et est chiffré
avec la clef qu ’il partage avec Alice. L ’autre est composé du nombre aléatoire
de Bernard et de la clef de session, et est chiffré avec la clef qu’il partage avec
Bernard. Il envoie les deux messages avec le numéro d’ordre à Bernard:
I , E a (RA jK ) , E b (R b , K )
4° Bernard envoie à Alice le message chiffré avec la clef d’Alice et avec le numéro
d’ordre:
I , E a {R a , K)
En émettant l’hypothèse que tous les nombres aléatoires sont corrects et que le numéro
d’ordre n’a pas changé en cours de route, Alice et Bernard sont maintenant convaincus
de leurs identités respectives et ils ont une clef secrète avec laquelle communiquer.
Kerberos
K e r b e r o s est une variante du protocole de Needham et Schroeder, il est présenté en
détail dans le paragraphe 17.4. Dans le protocole de base K e r b e r o s version 5, Alice et
Bernard partagent chacun des clefs avec Ivan. Alice veut engendrer une clef de session
pour dialoguer avec Bernard.
1° Alice envoie un message à Ivan avec son identité et celle de Bernard:
A ,B
2° Ivan engendre un message avec la datation, une longévité, une clef de ses
sion aléatoire, et l’identité d’Alice. Il chiffre cela avec la clef qu’il partage avec
Bernard. Ensuite il engendre un autre message avec la datation, la longévité,
la clef de session et l’identité de Bernard, et il chiffre le résultat avec la clef
qu’il partage avec Alice. Il envoie les deux messages chiffrés à Alice:
E a ( T, L,K,B) ,E b (T,L,K,A)
3° Alice engendre un message avec son identité et la datation, chiffre cela avec K
et envoie le résultat à Bernard. Alice envoie aussi à Bernard le message qu ’elle
a reçu d’Ivan, chiffré avec la clef de Bernard :
E k (T,A),E b (T,L,K,A)
4° Bernard engendre un message avec la datation plus un, le chiffre avec K et

envoie le résultat à Alice :
E k (T + 1)
Le protocole marche mais il présume que toutes les horloges sont synchronisées avec
l’horloge d’Ivan. En pratique, cet effet est obtenu en synchronisant les horloges à
quelques minutes près d ’une horloge de référence et en détectant les répétitions dans
l’intervalle de temps donné.
Neuman-St ubblebine
Que ce soit par des erreurs de système ou par sabotage, il se peut que les horloges se
désynchronisent, Si cela arrive, il existe une attaque possible contre la plupart de ces
protocoles [646]. Si l’horloge de l’expéditeur est en avance, Martin peut intercepter un
message de l’expéditeur et le rejouer plus tard quand la datation devient à jour sur le
site du destinataire. Cette attaque peut avoir des conséquence désagréables.
Ce protocole présenté pour la première fois dans [821] et corrigé dans [1162] tente de
contrer cette attaque. C ’est une amélioration du protocole Yalahom qui en fait un
excellent protocole.
1° Alice engendre un message avec son nom, un nombre alâtoire et l’envoie à
Bernard.
A, R a
2° Bernard chiffre le nom d’Alice, le nombre aléatoire, et la datation avec la clef

qu ’il partage avec Ivan. Il envoie le résultat, son nom et un autre nombre aléa
toire à Ivan.
B , R b ,E b (A,R a ,Tb )
3° Ivan engendre une clef de session aléatoire et crée alors deux messages. Le
premier est constitué du nom de Bernard, du nombre aléatoire d ’Alice, de la
clef de session, et de la datation, le tout chiffré avec la clef qu'il partage avec
Alice. Le second se compose du nom d ’Alice, de la clef de session, et de la
datation, le tout chiffré avec la clef qu ’il partage avec Bernard. U envoie les
deux messages à Alice avec le nombre aléatoire de Bernard.
E a (B, R a ,K,T b ),E b (A,K,T b ),R b
4° Alice déchiffre le message chiffré avec sa clef, extrait K , et vérifie que R a est
bien le même quà l’étape 1. Alice envoie deux messages à Bernard. Le premier
est celui qu’elle a reçu de Ivan et qui est chiffré avec la clef de Bernard. Le
second est R b , chiffré avec la clef de session.
E b (B, K, T b ),E k (Rb )
5° Bernard déchiffre le message chiffré avec sa clef, extrait K , et vérifie que TB

et R b ont la même valeur qu’à l’étape 2.
Si les nombres aléatoires et les datations correspondent, Alice et Bernard sont convain
cus de l’identité de l’un l’autre et ils partagent une clef secrète. Il n ’est pas nécessaire
que les horloges soient synchronisées car les datations proviennent toutes de l’horloge
de Bernard ; il vérifie uniquement des datations qu’il a engendrées lui-même.
Ce protocole présente un autre avantage: Alice peut utiliser le message qu’elle a reçu de
Ivan pour d ’autres authentifications avec Bernard jusqu’à une certaine limite de temps
fixée à l’avance. Supposons que Bernard et Alice ont terminé le protocole ci-dessus
et ont fini de communiquer. Alice et Bernard sont en mesure de mener une nouvelle
authentification en trois étapes, sans l’aide de Ivan.
1° Alice envoie à Bernard le message que Ivan lui avait envoyé à l’étape 3 et un
nouveau nombre aléatoire.
E b (A,K,T b ),R’a
2° Bernard envoie à Alice un autre nouveau nombre aléatoire, et le nouveau

nombre aléatoire d’Alice chiffré avec leur clef de session.
R'B,E K (R'A)
3° Alice envoie à Bernard son nouveau nombre aléatoire chiffré avec leur clef de
session.
E k (R'b )
Les nouveaux nombres aléatoires empêchent toute attaque consistant à rejouer de vieux
messages.
DASS
Les protocoles DASS, développés par D i g it a l E q u i p m e n t C o r p o r a t i o n , per
mettent aussi l’authentification mutuelle et l’échange de clefs [606, 1523, 1522].
Contrairement aux autres protocoles, DASS utilise à la fois la cryptographie à clef
secrète et la cryptographie à clef publique. Alice et Bernard ont chacun une clef privée.
Ivan possède des copies signées de ces clefs privées.
1° Alice envoie à Ivan un message constitué du nom de Bernard.
2° Ivan envoie à Alice la clef publique de Bernard, K b , signée avec la clef privée
d’Ivan, T . Le message signé comprend le nom de Bernard.
St ( B , K b )
3° Alice vérifie la signature d’Ivan pour confirmer que la clef qu’elle a reçue est
bien la clef publique de Bernard. Elle engendre une clef secrète aléatoire, et une
paire aléatoire « clef publique, clef privée » : Kp. Elle chiffre une datation avec
K . Elle signe une longévité de clef, L, son identification, A , et K p avec sa clef
privée, K A. Enfin, elle chiffre K avec la clef publique de Bernard et signe le
résultat avec K p. Elle envoie le tout à Bernard:
E k (Ta ),SKa ( L, A, K p),Sk p (EKb ( K ))
4° Bernard envoie à Ivan (ce peut être un autre Ivan) un message contenant le
nom d’Alice:
A
5° Ivan envoie la clef publique d’Alice à Bernard, signée avec la clef publique
d’Ivan :
St ( K a )
6° Bernard vérifie la signature d ’lvan pour confirmer que la clef qu ’il a reçue est
bien la clef publique d’Alice. Il vérifie alors la signature d’Alice et récupère
K p. Il vérifie la signature et utilise sa clef privée pour retrouver K . Ensuite, il
déchiffre TA pour être sûr que le message n’est pas périmé.
7° Si Vauthentification mutuelle est nécessaire, Bernard, chiffre une nouvelle da

tation avec K et envoie le résultat à Alice.
E k (Tb )
8° Alice déchiffre Tb avec K pour être sûre que le message n’est pas périmé.
D E C a réalisé les protocoles DASS. Vous trouverez plus d ’informations dans [35].
Denning-Sacco
Ce protocole utilise aussi la cryptographie à clef publique [467]. Ivan conserve une base
de donnée contenant toutes les clefs publiques.
1° Alice envoie un message à Ivan avec son nom et celui de Bernard:
A ,B
2° Ivan envoie à Alice la clef publique de Bernard, K b , qu’il signe avec sa propre
clef privée, T. Ivan envoie aussi à Alice la clef publique de celle-ci, K a , qu’il
signe avec sa clef privée.
St ( B , K b ),St ( A, K a )
3° Alice envoie à Bernard une clef de session aléatoire et une datation signés avec
sa clef privée et chiffrés avec la clef publique de Bernard, le tout accompagné
des deux clefs publiques signées.
E b (Sa (K,T a )),St { B , K b ),St ( A , K a)
4° Bernard déchiffre le message d’Alice avec sa clef privée et vérifie la signature

d’Alice avec la clef publique de celle-ci. Pour plus de sûreté, il vérifie que la
datation est toujours valide.
À ce niveau, Alice et Bernard ont tous les deux la clef K , et peuvent communiquer en
sécurité.
Cela a l’air de fonctionner mais il n’en est rien. Après avoir terminer le protocole avec
Alice, Bernard peut se faire passer pour Alice [9]:
1° Bernard envoie à Ivan son nom et celui de Christine .
B ,C
2° Ivan envoie à Bernard les clefs publiques de Bernard et Christine qu ’il signe.
St ( B , K b ),St (C, Kc )
3° Bernard envoie à Christine la clef de session et la datation qu’il a reçus d’Alice

après les avoir chiffrés avec la clef publique de Christine, le tout accompagné
des certificats d’Alice et de Christine.
E c (Sa (K,T a )),St ( C, K c ),St ( A , K a)

4° Christine déchiffre le message d’« Alice » avec sa clef privée et contrôle la

signature d’Alice avec la clef de celle-ci. Elle vérifie que la datation est toujours
valide.
Christine croit maintenant parler avec Alice; Bernard l’a trompée avec succès. En fait,
Bernard peut tromper n’importe quel membre du réseau jusqu’à ce que la datation
expire.
Ce problème est facile à régler. Il suffit d ’ajouter les noms dans le message chiffré à
l’étape 3:
E b {Sa {A, B, K, T a )),St { B , K b ),St { A , Ka )
Maintenant Bernard ne peut plus réutiliser le vieux message d ’Alice avec Christine
parce qu’il est clairement dédié à la communication entre Alice et Bernard.
Woo-Lam
Ce protocole utilise encore la cryptographie à clef publique [1612, 1613]:
1° Alice envoie à Ivan un message contenant son nom et celui de Bernard.

A ,B
2° Ivan envoie à Alice la clef publique de Bernard qu’il signe avec sa propre clef
privée.
St ( K b )
3° Alice vérifie la signature de Ivan. Elle envoie alors à Bernard son nom et un
nombre aléatoire, qu’elle chiffre avec la clef publique de Bernard.
E k b ( A, R a )
4° Bernard envoie à Ivan son nom, celui d’Alice et le nombre aléatoire d’Alice
qu’il chiffre avec la clef publique de Ivan.
A , B , E k t {Ra )
5° Ivan envoie à Bernard la clef publique d’Alice qu’il signe avec sa propre clef
privée. Il lui envoie aussi le nombre aléatoire d’Alice, une clef de session aléa
toire, le nom d’Alice, le nom de Bernard, le tout signé avec la clef privée de
Ivan et chiffré avec la clef publique de Bernard.
S t ( K a ),EKb (St (Ra ,K, A, B))
6° Bernard contrôle la signature de Ivan. Il envoie alors à Alice la deuxième partie

du message que Ivan lui a envoyé à l’étape 5 et un autre nombre aléatoire, le
tout chiffré avec la clef publique d’Alice.
E Ka (St (Ra , K, A, B) , Rb )
7° Alice vérifie la signature de Ivan et son nombre aléatoire. Elle envoie alors à
Bernard le second nombre aléatoire qu’elle chiffre avec la clef de session.
E k (R b )
8° Bernard déchiffre son nombre aléatoire et vérifie qu’il n’a pas changé.
Autres protocoles
Il y a beaucoup d ’ autres protocoles dans la littérature. Les protocoles X .509 sont
décrits dans le paragraphe24.9. Le protocole K r y p t o K n ig h t est décrit dans le pa
ragraphe 24.6. Le protocole: « Echange de Clef Chiffré » 3, est décrit dans le para
graphe 22.5.
K u p e r e e [695] est un autre protocole à clef publique. D ’autres protocoles à l’étude
utilisent beacons, un noeud du réseau en qui l’on a confiance et qui émet en continu
des nombre aléatoires authentifiés [783].
Les leçons
Il faut tirer quelques leçons importantes des protocoles précédents, à la fois de ceux
qui ont étés cassés et de ceux qui ne l’on pas été:
- Beaucoup de protocoles échouent parce que leurs concepteurs essayent d’être

trop intelligents. Ils optimisent leurs protocoles en laissant de côté des points
importants: les noms, des nombres aléatoires, et ainsi de suite. Le remède est de
tout rendre explicite [44, 45].
- On a vite fait de s’embrouiller en essayant d’optimiser, cela dépend beaucoup des

hypothèses que l’on fait. Par exemple, si l’on dispose de datations sûres, on peut
faire beaucoup de choses impossibles sans cela.
Le choix du protocole dépend de l’architecture du réseau utilisé pour les commu

nications. Voulez-vous minimiser la taille des messages ou leur nombre? Est-ce
que tous les partis peuvent se parler les uns les autres ou seulement quelques uns
d’entre eux.
De telles questions permettent de développer des méthodes formelles pour l’analyse

des protocoles.
3.4 Analyse formelle des protocoles d’au

thentification et d’échange de clefs
Le problème d ’obtenir une clef de session sûre entre deux ordinateurs (et deux per
sonnes) est si important qu’il a mené à de nombreuses recherches. Une part des re
cherches a été dévouée au développement de protocoles tels que ceux examinés dans
les paragraphes 3.1, 3.2, et 3.3. Ceci a conduit à de plus amples et plus intéressants
problèmes: l’analyse formelle des protocoles d’authentification et d ’échange de clefs. On
a trouvé des failles dans certains protocoles apparament sûrs des années après qu’ils
furent proposés et les chercheurs voulaient des outils permettant de prouver la sécurité
d ’un protocole dès le début. Bien que la plupart de ce travail puisse s’appliquer aux pro
tocoles cryptographiques en général, l’emphase en recherche concerne principalement
l’authentification et l’échange de clefs.
3. E n c r y p te d K e y E x ch a n g e.
3-4 Analyse formelle des protocoles d’authentification et d’échange de clefs 71
Il y a quatre approches fondamentales de l’analyse de protocoles cryptographiques

[1053] :
1. Modéliser et vérifier le protocole en utilisant des languages de spécification et

des outils de vérification qui ne sont pas spécifiquement dédiés à l’analyse de
protocoles cryptographiques.
2. Développer des systèmes experts avec lequel un concepteur de protocoles peut

inventer et tester différents scénarios.
3. Modéliser les nécéssités d’une famille de protocoles à l’aide de régies logiques sur
l’anlyse de savoir et de croyance.
4. Développer une méthode formelle basée sur les propriétés de réécriture de termes
algébriques dans les sytèmes cryptographiques.
Une discussion complète de ces quatres approches et des recherches qui tournent autour
dépasse largement le sujet de ce livre. Voir [1055, 1357] pour une bonne introduction;
nous allons juste toucher du bout des doigts les avancées majeures dans le domaine.
La première approche traite un protocole cryptographique comme n’importe quel autre
programme et s’occuppe de prouver son exactitude. Certains chercheurs présentent un
protocole comme une machine à état fini [1455, 1357], d’autres utilisent des exten
sions du calcul des prédicats du premier ordre [823], et d ’autres encore analysent les
protocoles à l’aide de languages de spécification [1568]. Toutefois, ce n’est pas pareil
de prouver l’exactitude que de prouver la sécurité et cette approche ne permet pas
de détecter de nombreux protocoles défectueux. Bien qu’elle fût largement étudiée en
premier lieu, la plupart des travaux dans le domaine ont étés redirigés alors que la
troisième approche gagnait en popularité.
La deuxième approche utilise des systèmes experts pour déterminer si le protocole peut
atteindre un état indésirable (comme la divulgation d ’une clef par exemple). Si cette
approche est plus apte à détecter les failles, elle ne garantie pas la sécurité et ne fournit
pas non plus de technique pour découvrir des attaques. C ’est efficace pour déterminer
si un protocole a une faille donnée mais pas pour trouver une faille inconnue dans un
protocole. On trouvera des exemples d’une telle approche dans [997, 1525]; un système
à base de règles développé par l’armée américaine qui s’appelle l’ « Interrogateur4 » est
examiné dans [1098].
La troisième approche est de loin la plus populaire, elle fut lancée par Michael
B u r r o w s , Martin A b a d i et Roger N e e d h a m . Ils ont développé un modèle de logique
formelle pour l’analyse de savoir et de croyance appelé la logiqu e B A N [287, 288].
BAN est la logique la plus utilisée pour analyser les protocoles d’authentification. Elle
repose sur l’hypothèse que l’authentification est une fonction dépendant de l’intégrité
et de la fraîcheur, et elle permet de suivre la valeur de ces deux attributs au cours
du protocole au moyen de règles logiques. Malgrès le développement de beaucoup de
variantes et d ’extensions, la plupart des concepteurs de protocoles se réfèrent encore
aux premiers travaux.
La logique BAN ne permet pas de prouver la sécurité; elle permet seulement de rai
sonner sur l’authentification. Cette logique est simple et immédiate, facile à appliquer
4. L’« I n te r ro g a to r » en anglais.
et pourtant utile pour détecter des failles. Certaines formulations de la logique BAN
ressemblent à ceci:
Alice croit A . (Alice agit comme si X était vrai.)

Alice voit X . (Quelqu’un a envoyé à Alice un message contenant X .
Celle-ci peut le lire et l’envoyer à nouveau — après un éventuel déchiffre
ment.)
Alice a dit X . (À un moment donné, Alice a envoyé un message conte
nant X . On ne sait pas quand il a été envoyé ou même s’il a été envoyé
durant le protocole en cours. On sait seulement que Alice croyait X quand
elle l’a dit.)
X est récent (ou frais). (A n’a jamais été envoyé dans un message à
quelqu’instant que ce soit avant le protocole en cours.)
Et ainsi de suite. La logique B A N fournit aussi des règles pour raisonner sur des
croyances à l’intérieur d’un protocole. En appliquant ces règles aux formulations lo
giques concernant le protocole, on peut prouver certaines choses ou répondre à certaines
questions à propos du protocole. Par exemple, une des règles est celle de la signification
d’un message:
Si Alice croit qu’elle et Bernard partagent une clef secrète K et si Alice

voit X chiffré avec K , et si Alice n’a pas chiffré X avec K , alors Alice croit
que Bernard a dit X .
Une autre règle est celle de la vérification de nombre aléatoire
Si Alice croit que X n’a pu être prononcé que récemment et que Bernard
a dit A , alors Alice croit que Bernard croit A .
Il y a quatre étapes dans une analyse avec BAN :
1. Décrire le protocole dans une forme idéalisée à l’aide de formulations logiques

telles que les précédentes.
2. Ajouter toutes les hypothèses concernant l’état initial du protocol.
3. Insérer des formules logiques inhérentes aux formulations: des assertions à propos
de l’état du système après chaque formulation.
4. Applliquer les règles logiques aux assertions et aux hypothèses pour trouver les
croyances de chaque parti au cours du protocole.
Les auteur de la logique B A N « voient les protocoles idéalisés comme des spécifications
plus claires et plus complètes que les descriptions traditionnelles de la littérature... »
[287, 288]. D ’autres ne se laissent pas impressionner et critiquent cette étape car elle
pourrait dénaturer le protocole réel [1161, 1614], Voir [225, 1563] pour une poursuite
du débat. D ’autres détracteurs essayent de montrer que la logique BAN peut conduire
pour certains protocoles à des caractéristiques clairement fausses [1161] — voir [289,
1513] pour une réfutation — et que la logique BA N concerne seulement la confiance
et pas la sécurité [1513]. De plus amples débats se trouvent dans [1495, 707, 1011],
3-4 Analyse formelle des protocoles d’authentification et d’échange de clefs 73
Malgrès ces critiques, la logique B A N est un succès. Elle a contribué à trouver des failles
dans différents protocoles dont N E E D H A M -S C H R O E D E R et une première version d’un
protocole C C IT T X .509 [308]. Elle a permis de montrer des redondances dans beau
coup de protocoles comme Y a h a l o m , N e e d h a m - S c h r o e d e r , et K e r b e r o s . Bien
des articles publiés font état de la sécurité de leurs protocoles grâce à la logique BAN
[41, 1162, 80].
D’autres systèmes de logique ont étés publiés, certains sont des extensions de la logique
BAN [647, 588,1562, 829], et les autres sont basés sur B A N pour palier à des faiblesses
connues [1495, 1011]. La plus prisée parmi celles-là est G N Y [647] bien qu’elle présente
certains défauts [41]. Des probabilités de croyance ont été ajoutées à la logique B A N
avec un succès mitigé [296, 507]. D ’autres logiques formelles sont proposées dans [163,
799, 292]; dans [1518], les auteurs essayent de combiner les aspects de plusieurs logiques.
Enfin, il existe des logiques où les croyances peuvent changer avec le temps [1130, 1515].
Avec quatrième approche à l’analyse des protocoles cryptographiques, on modélise le
protocole par un système algébrique, on exprime l’état de connaissance des participants
en ce qui concerne le protocole, et on analyse alors s’il est possible d’ateindre certains
états. Cette approche n’a pas connu autant d ’égards que les logiques formelles, mais ça
ne saurait tarder. Michael M e r r i t t l’a utilisée le premier en montrant qu’un modèle
algébrique permet d’analyser les protocoles cryptographiques. On trouvera d’autres
approches dans [506, 1512, 1538, 1539, 1540, 1514, 1614],
L’Analyseur de Protocoles des laboratoires de recherche de la marine américaine5 est
probablement l’application la plus réussie de ces techniques [1516, 824, 1054, 1517]; il
a mis en évidence de nouvelles failles et d ’autre déjà connues dans quelques protocoles
[1052, 1053, 1055]. L 'Analyseur de Protocoles utilise des définitions d ’actions du type:
- Accepter (Bernard, Alice, A i, N ). (Bernard accepte le message A i comme prove

nant d ’Alice durant la manche N de Bernard.)
- Apprendre(Estelle,A4). (Estelle apprend A4.)
- Envoyer(Alice, Bernard, Q, A i). (Alice envoie A4 à Bernard en réponse à la

requête Q.)
Request(Bernard, Alice, Q, N ). (Bernard envoie Q à Alice durant la manche N

de Bernard.)
A parjjr de ces actions, on peut spécifier des exigences. Par exemple:
- Si Bernard a accepté un message A4 de la part d ’Alice à un moment donné, alors

Estelle n ’a appris A4 à aucun moment.
- Si Bernard a accepté un message A4 de la part d ’Alice dans la manche N de

Bernard, alors Alice a envoyé A4 à Bernard en réponse à une requête survenue
durant la manche N de Bernard.
Pour utiliser l’ Analyseur de Protocoles, le protocole doit être spécifier avec les construc
teurs précédents. On distingue alors quatre phases dans l’analyse: la définition des
règles de transition pour les participants honêtes, la description des opérations acces
sibles à tous les participants (honêtes ou malhonêtes), la description des blocs de base
5. N a vy R esea rch L a b o ra to ry (N R L ).
constituant le protocole, et la description des exigences. Le but de tout ceci est de

montrer qu’un protocole donné remplit ses exigences. Les outils comme YAnalyseur
de Protocoles pourrait éventuellement conduire à des protocoles dont la sécurité serait
prouvée.
Alors que le gros du travail dans les méthodes formelles vise à appliquer les dites
méthodes à des protocoles existants, d’autres travaux tendent à utiliser les méthodes
formelles pour concevoir le protocole dès le départ. Les premiers pas dans cette direction
sont dans [713]. L 'Analyseur de Protocoles tente aussi d ’accomplir cela [1516, 224,
1517].
L’application de méthodes formelles aux protocoles cryptographiques reste une idée
assez nouvelle et il est vraiment difficile de savoir où elle mène. Pour l’instant, le point
sensible semble résider dans le processus de formalisation.
3.5 Cryptographie à clef publique à clefs

multiples
Pour la cryptographie à clef publique, il y a deux clefs. Un message est chiffré avec l’une
et déchiffré avec l’autre. En général, l’une des clefs est privée et l’autre est publique.
Toutefois, faisons maintenant l’hypothèse qu’Alice a une clef et Bernard l’autre. Alice
peut chiffrer un message que seul Bernard pourra déchiffrer et Bernard peut chiffrer
un message que seule Alice pourra lire.
Ce concept a été généralisé par Colin B o y d [220]. Imaginez une variante de la crypto
graphie à clef publique avec trois clefs: K a , K b , K c , distribuées comme indiqué dans
le tableau 3.2.
T a b . 3 .2 - Clefs en possession de chacun des participants
Participant : Clef(s) en sa possession :

Alice Ka
Bernard Kb
Christine Kc
David K a et K b
Etienne K b et K c
Francis K a et K c
Alice peut chiffrer un message avec K a de manière qu’Étienne qui dispose de K b et de

K c puisse le déchiffrer, de même que Bernard et Christine s’ils se mettent ensemble.
Bernard peut chiffrer un message afin que Francis puisse le lire et Christine peut chiffrer
un message de façon que David puisse le lire. David peut chiffrer un message avec K a
de manière qu’Etienne puisse le lire, avec K b de manière que Francis puisse le lire,
ou encore avec K a et K b de manière que Christine puisse le lire. De même, Etienne
peut chiffrer un message de telle manière qu’Alice, David ou Francis puissent le lire.
Les différentes possibilités sont résumées par le tableau 3 .3 et il n’y en a pas d’ autres.
Ce schéma peut être étendu à n clefs. Si un sous-ensemble de ces clefs est utilisé pour
chiffrer le message, le complément de celui-ci (les clefs non utilisées pour le chiffrement)
3.6 Secret morcelé 75
T a b . 3 .3 - Chiffrement à trois clefs
Chiffré avec les clefs : Doit être déchiffré avec les clefs :
Ka K b et K c
Kb K a et K c
Kc K a et K b
K a et K b KC
K a et K c Kb
K b et K c Ka
est nécessaire pour déchiffrer le message.
Diffusion de message
Imaginez que vous ayez cent opérateurs sur le terrain. Vous voulez envoyer des messages
à certains sous-ensembles de vos opérateurs mais vous ne connaissez pas à l’avance
la composition des sous-ensembles. Vous pouvez chiffrer le message séparément pour
chaque destinataire, ou créer des clefs pour chaque combinaison possible. La première
option augmente considérablement le trafic des communications ; la deuxième nécessite
un très grand nombre de clefs.
La cryptographie à clefs multiples est nettement plus facile. Considérons trois opéra
teurs: Alice, Bernard et Christine. Vous donnez à Alice K a et K b , à Bernard K b et
K c , et à Christine K a et K c - Ainsi, vous pouvez dialoguer avec n’importe quel sous-
ensemble d’entre eux. Si vous voulez envoyer un message que seule Aüce puisse lire,
chiffrez-le avec K c - Quand elle reçoit le message, elle le déchiffre avec K a et puis K r .
Si vous voulez envoyer un message que seul Bernard puisse lire, chiffrez-le avec K a - Si
vous voulez envoyer un message que seule Christine puisse lire, chiffrez-le avec K b - Si
vous voulez envoyer un message qu’Alice et Bernard puissent lire, chiffrez-le avec K a
et K c , et ainsi de suite.
Cela peut paraître peu excitant, mais avec 100 opérateurs, ce schéma est pour le moins
efficace. Envoyer des messages individuels nécessite de partager une clef avec chaque
opérateur (100 clefs au total). Pour couvrir tous les sous-ensembles possibles, il faut
2100 — 2 clefs (on exclus les messages destinés à tous les opérateurs et à aucun). Le
schéma qui vient d ’être décrit marche avec un seul texte chiffré et 100 clefs différentes.
Le seul inconvénient est qu’il faut aussi diffuser le sous-ensemble d’opérateurs auquel ce
message est destiné; sans cela, chaque opérateur devrait essayer toutes les combinaisons
de clefs possibles à la recherche de la bonne. Les nom des destinataires suffisent. Dans
la réalisation directe de ceci, chacun reçoit une quantité massive de données relatives
aux clefs.
Il y a d’autres techniques pour la diffusion de messages, certaines ne présentent pas le
problème précédent. Elles sont décrites dans le paragraphe 22.7.
3.6 Secret morcelé

Imaginer que vous ayez inventé une nouvelle crème de garniture super-collante et super
sucrée. Peut-être avez vous fait une sauce pour hamburger encore plus insipide que
celle de vos concurrents. C ’est important, vous devez garder le secret. Vous ne pouvez
indiquer la composition exacte des ingrédients qu’à vos employés en qui vous avez
le plus confiance: mais qu’arrive-t-il si l’un d ’entre eux vous quitte pour aller à la
concurrence? Le secret est dévoilé et il ne faudra pas attendre longtemps avant que
tous les marchands de « fastfood » du quartier ne fassent des hamburgers aussi insipides
que les vôtres.
Pour remédier à cela, on fera appel au secret m orcelé. Il y a moyen de prendre un
message et de le couper en morceaux [553]. Chaque morceau en lui-même n’a aucune
signification mais si vous les rassemblez vous pouvez faire la sauce. Si un employé vous
quitte avec un morceau de la recette, cette information est inutilisable par elle-même.
Le morcellement de secret le plus simple partage un message entre deux personnes.
Voici un protocole où Ivan partage un message entre Alice et Bernard.
1° Ivan engendre une chaîne aléatoire de bits, R, ayant la même longueur que le
message A i.
2° Ivan combine A i avec R par ou exclusif pour obtenir S.
A4 ® R = S
3° Ivan donne R à Alice et S à Bernard.
Pour reconstruire le message, Alice et Bernard n’ont qu’une étape à effectuer :
4° Alice et Bernard combinent leurs morceaux par ou exclusif pour reconstruire le

message :
R ® S = A4
Cette technique, pour autant que tout soit fait correctement, est absolument sûre.
Chaque élément est en lui-même sans valeur. Essentiellement, Ivan chiffre le message
avec un masque jetable. Il donne ensuite le masque à une personne et le message chiffré
à l’autre. Le paragraphe 1.5 explique la technique du masque jetable; ce système de
chiffrement est absolument sûr. Aucune puissance de calcul ne permet de retrouver le
message avec un seul morceau.
Il est aisé d ’étendre ce schéma à plusieurs personnes. Pour morceler un message entre
plus de deux personnes, on combine d’autres chaînes aléatoires de bits avec le message
Dans l’exemple qui suit, Ivan partage le message en quatre morceaux :
1° Ivan engendre trois chaînes aléatoires de bits, R, S et T , ayant chacune la

même longueur que le message A i.
2° Ivan combine par ou exclusif A i avec les trois chaînes :
AA@R®S®T = U
3° Ivan donne R à Alice, S à Bernard, T à Christine et U à David.
Et voici comment Alice, Bernard, Christine et David reconstruisent le message :
4° Alice, Bernard, Christine et David se mettent ensemble pour calculer:
R @ S < $ > T ® U = A4
3.7 Secret réparti 77
C’est un protocole à juge-arbitre. Ivan a tous les pouvoirs et il peut faire ce qu’il
veut. Il peut donner du charabia et prétendre que ce sont les bons éléments du secret ;
personne ne le saura jusqu’à ce qu’ils essaient de reconstruire le secret. Il peut donner
un morceau à Alice, Bernard, Christine et David, puis dire à tout le monde que seuls
Alice, Christine et David sont nécessaires pour reconstruire le secret. Il peut alors
licencier Bernard. Et comme c ’est Ivan qui décide comment partager le secret, c ’est en
son pouvoir d’agir ainsi.
Il y a toutefois un défaut à ce protocole : si un des morceaux est perdu, le message est
perdu aussi. Par exemple, si Christine s’en va chez le concurrent avec son morceau de
la recette de la sauce, les autres sont dans l’embarras. Elle ne peut pas reproduire la
recette, mais il en est de même pour Alice, Bernard et David. Alice, Bernard et David
n’ont qu’une information commune : la longueur du message — rien de plus. Cela est
dû au fait que R, S, T, U et A4 ont tous la même longueur; dès que l’on connaît l’un
d’eux, on connaît la longueur du message. Rappelons que A4 n’est pas morcelé dans le
sens usuel du terme, il est combiné par ou exclusif avec des chaînes aléatoires de bits.
3.7 Secret réparti

Vous mettez au point un programme de lancement de missiles nucléaires. Vous voulez
être sûr qu’un fou furieux ne puisse pas déclencher le lancement. Vous voulez être sûr
que deux fous furieux ne puissent pas déclencher le lancement. Vous voulez que trois
officiers parmi cinq deviennent fous furieux avant d’autoriser le lancement.
C’est un problème facile à résoudre. Construisez un système de lancement mécanique.
Donnez une clef à chacun des cinq officiers et arrangez-vous pour qu’il faille qu’au moins
trois officiers mettent leur clef dans la bonne serrure avant que vous ne les autorisiez à
faire sauter l’ennemi du jo u r6.
On peut faire encore plus sophistiqué. Peut-être qu’ un général et deux colonels peuvent
lancer le missile, mais si le général est occupé à jouer au golf alors il faut cinq colonels
pour autoriser le lancement du missile. Fabriquez le contrôleur de lancement de manière
qu’il nécessite cinq clefs. Donnez trois clefs au général et une clef à chaque colonel. Le
général avec l’aide de deux colonels peut lancer le missile. Cinq colonels peuvent faire
de même mais un général et un colonel ne peuvent rien faire, ni quatre colonels.
Un schéma de répartition, appelé schéma à seüil permet tout cela et plus encore.
Au niveau le plus simple, vous pouvez prendre n’importe quel message (par exemple,
une recette secrète, un code de lancement, ou même une liste de blanchissage) et le
diviser en n éléments, appelés parts, de telle manière que n’importe quel ensemble de
m parts puisse être utilisé pour reconstruire le message. Plus précisément, on parlera
de schéma à seuil—(m ,n). Avec un schéma à seuil-(3,4), Ivan divise la recette secrète
de la sauce entre Alice, Bernard, Christine et David de manière que trois d’entre eux
puissent mettre leurs parts ensemble pour reconstruire le message. Si Christine est en
vacances, Alice, Bernard et David peuvent le faire. Si Bernard est écrasé par un bus,
Alice, Christine et David peuvent le faire. Mais si Bernard est écrasé par un bus et que
Christine est en vacances, Alice et David ne peuvent pas reconstruire le message.
6. Si vous êtes vraim ent inquiet, vous pou vez éloigner les serrures à grande distance et exiger que
les clefs soient insérées simultanément. Vous ne voudriez quand m êm e pas qu ’ un officier fou furieux
qui aurait volé deux clefs soit capable d ’annihiler tou te une ville?
Les schémas à seuil sont plus variés que cela. Tout scénario de répartition peut être
modélisé à l’aide de schémas. Vous pouvez diviser un message entre les occupants de
votre immeuble, pour cela vous avez besoin de : 1°) sept occupants du premier étage et
cinq occupants du deuxième étage ; 2°) il y a quelqu’un du troisième étage, dans ce cas
il ne faut que cet occupant-là, trois occupants du premier étage et deux personnes du
deuxième étage ; 3“) il y a quelqu’un du quatrième étage, auquel cas il faut cet occupant
et un occupant du troisième étage, ou cet occupant et deux personnes du premier étage
avec une personne du deuxième étage, etc.
Cette idée a été inventée indépendamment par Adi S h a m i r [1421] et George B l a k l e y
[189], et étudiée en profondeur par Gus SiMMONS [1473]. 11 y a plusieurs algorithmes
différents décrits dans le paragraphe 23.2.
Répartition de secret avec des tricheurs

Il y a plusieurs moyens de tricher avec le schéma à seuil. Voici seulement quelques-uns
d’entre eux :
Scénario 1 : Les colonels Alice, Bernard et Christine sont dans un bunker quelque part
sous terre. Un jour, ils reçoivent un message codé de leur président: « Lancer les
missiles. Nous allons rayer de la carte la recherche sur les réseaux neuronaux. » Alice,
Bernard et Christine révèlent leur part, mais Christine donne un nombre aléatoire. Elle
est en fait une pacifiste et elle ne veut pas lancer les missiles. Comme Christine n ’a pas
donné la bonne part, le secret qu’ils récupèrent n’est pas le bon. Les missiles restent
dans leurs silos. Pis encore, personne ne sait pourquoi. Alice et Bernard, même s’ils
collaborent, ne peuvent pas prouver que la part de Christine n’est pas valable.
Scénario 2 : Les colonels Alice et Bernard sont dans leur bunker avec Martin. Martin
s’est déguisé en colonel et aucun des autres ne soupçonne la supercherie. Le même
message est envoyé par le président et chacun révèle sa part. « Ha, Ha ! » s’écrie Martin,
« Ce message du président est factice et j ’en suis l ’auteur. Maintenant je connais vos
parts. » Il s’enfuit alors par l’escalier avant que quiconque ne puisse l’attraper.
Scénario 3 : Les colonels Alice, Bernard et Christine sont dans leur bunker avec Martin
qui une fois de plus s’est déguisé. Le même message vient du président et chacun révèle
sa part. Martin ne révèle la sienne qu’après avoir entendu les trois autres. Comme les
trois autres permettent de reconstituer le secret, il fabrique rapidement une part valide
et révèle celle-ci. Maintenant, non seulement il connaît le secret mais de plus personne
ne se rend compte qu’il ne fait pas partie du schéma.
Certains protocoles qui contrent ce type de tricheurs sont décrits dans le para
graphe 23.2.
Répartition de secret sans Ivan

Une banque veut que sa chambre forte ne s’ouvre que si trois employés parmi cinq
utilisent leur clef. Cela ressemble à un schéma à seuil (3,5), sauf qu’il y a un hic.
Personne ne doit connaître tout le secret. Il n’y a pas d ’Ivan pour répartir le secret
en cinq parties. Il existe des protocoles par lesquels cinq personnes peuvent créer un
secret et recevoir chacun un élément de manière qu’aucun des participants ne puisse
reconstruire le secret sans les autres. Ces protocoles ne seront pas abordés dans ce livre,
voyez [445] pour les détails.
3.7 Secret réparti 79
Répartition de secret sans révélation des parts
Ces schémas présentent un problème. Quand tout le monde se réunit pour reconstruir
le secret, chacun doit révéler sa part. Il peut en être autrement. Si le secret réparti est
une clef privée (pour une signature numérique par exemple), alors n détenteurs d’une
partie du secret peuvent partiellement signer un document. Le document est signé avec
la clef privée répartie seulement après la derniere signature partielle et personne n’est
informé de la part d’un autre. Le secret peut alors être réutilisé et son maniement
ne nécessite pas d ’opérateur de confiance. Ce concept est exploré plus avant par Yvo
D e s m e d t et Yair F r a n k e l [481, 482].
Secret réparti vérifiable
Ivan donne à Alice, Bernard, Christine et David une part du secret à chacun, ou du
moins prétend le faire. La seule façon pour chacun d ’eux pour savoir s’il a une part
valide est de reconstruire le secret. Ivan a pu envoyer à Bernard une part de rien
du tout, ou bien Bernard a reçu accidentellement une mauvaise part à cause d’une
erreur de transmission. Le secret réparti vérifiable permet à chacun d’eux de contrôler
individuellement qu’il possède une part valide, sans qu’il soit nécessaire de reconstruire
le secret [560, 1245].
Secret réparti avec veto
Un secret est réparti entre cinquante personnes de manière que dix d ’entre-elles puissent
reconstituer le secret. C ’est facile. Mais peut-on réaliser un schéma de secret réparti
avec la contreinte supplémentaire que vingt personnes puissent empêcher les autres -
quel que soit leur nombre - de reconstruire le secret? Il se trouve que c’est possible
[160].
Les mathématiques sous-jacentes sont compliquées, mais l’idée de base est que chacun
reçoit deux parts : un « oui » et un « non ». Au moment de reconstruire le secret, chacun
soumet une de ses deux parts. Le choix de la part dépend du souhait du participant
quand à la reconstruction du secret. S’il y a au moins m parts « oui » et au plus n
parts « non », alors le secret est reconstruit. Dans la cas contraire, il ne l’est pas.
Bien sûr, rien n’empêche un nombre suffissant de personnes favorables d’aller dans un
coin sans les autres (en supposant qu’ils se connaissent) et de reconstruire le secret.
Mais dans la situation ou chacun soumet sa part dans un ordinateur central, cela n’est
pas possible.
Secret réparti avec désistement
Vous avez installé votre de système de secret réparti et vous voulez maintenant licencier
un des participants. Vous pourriez instaurer un nouveau schéma mais cela demande
du temps. Il existe des méthodes pour copier ce système. Elles permettent d ’activer
instantanément un nouveau schéma dès qu’un participant devient indésirable [851].
3.8 Protection cryptographique de bases de

données
La liste des membres d’une association professionnelle est une information intéressante.
D ’une part, vous voulez distribuer la base de données à tous les membres : vous voulez
qu’ils puissent communiquer entre eux, échanger des idées, et s’inviter les uns les autres
pour boire une tasse de thé. D’autre part, si vous distribuez des copies de la base de
données des membres, une copie finira tôt ou tard par tomber dans les mains d’agents
d’assurance ou d’autres fournisseurs de courrier publicitaire.
La cryptographie peut améliorer la situation. Vous pouvez chiffrer la base de données
de manière qu’il soit facile d ’extraire l’adresse d’un membre mais qu’il soit difficile
d ’obtenir la liste d’adresses complète.
Ce schéma, décrit dans [552, 551], est évident. Choisissez une fonction de hachage à
sens unique et un algorithme à clef secrète. Chaque enregistrement dans la base de
données est composé de deux champs. Le champ d ’indexation est le nom de famille de
l’adhérent converti par la fonction de hachage à sens unique. Le champ de données est
le nom complet et l’adresse de l’adhérent, chiffré en utilisant le nom de famille comme
clef.
Chercher un membre ayant un nom de famille donné est facile. Premièrement, calculez
l’empreinte du nom de famille par la fonction de hachage à sens unique et cherchez cette
empreinte dans les champs d’index de la base de données. S’il y a une concordance, alors
il existe un membre ayant ce nom de famille. S’il y a plusieurs concordances, alors il y a
plusieurs personnes dans la base de données ayant le même nom de famille. Finalement,
pour chaque concordance, déchiffrez le nom complet et l’adresse en utilisant le nom de
famille comme clef.
Dans [552], les auteurs utilisent ce système pour protéger un dictionnaire de 6000
verbes espagnols. Ils indiquent que les dégradations de performance dues au chiffrement
sont minimes. Des possibilités supplémentaires sont offertes par [551] pour faire des
recherches sur des index multiples mais l’idée est la même. Le problème principal avec
ce système est que vous ne pouvez pas retrouver un enregistrement d ’une personne si
vous ne connaissez pas l’orthographe exacte du nom de famille de celle-ci. Vous pouvez
essayer plusieurs orthographes jusqu’à ce que vous trouviez la bonne, mais ce n’est pas
très pratique de passer en revue tous les noms commençant par « Sch » quand vous
recherchez « Schneier ».
Cette protection n’est pas parfaite. Il est possible pour un vendeur particulièrement
persévérant de reconstruire la base de données des membres en essayant tous les noms
de famille possibles. S’il dispose du Bottin, il peut le faire. Cela peut prendre plusieurs
semaines à un ordinateur dédié à cette tâche, mais c ’est faisable. Toutefois, la tâche est
plus difficile, ce qui signifie « plus cher » pour un fournisseur de courriers publicitaires.
Une autre approche, décrite dans [192], permet d ’extraire des statistiques concernant
des données chiffrées.
Chapitre 4
Protocoles intermédiaires
4.1 Services de datation

Dans de nombreuses situations les gens veulent pouvoir certifier qu’un document exis
tait à une date donnée. Pensez à une contestation de copyright ou de brevet : celui qui
peut produire le document le plus ancien gagne la partie. Il y a plusieurs manières de
faire cela avec des documents papier. Des notaires peuvent signer les documents ; des
hommes de loi peuvent garder des copies. Si un litige apparaît, le notaire ou l’homme
de loi peut attester de l’existence de la lettre à une certaine date.
Dans le monde numérique, c ’est beaucoup plus difficile. Il n ’y a pas moyen d’examiner
des documents numériques pour détecter des signes de falsification. Ils peuvent être
copiés et modifiés à volonté sans que cela soit décelable. Il est trivial de changer la
date de création d’un fichier informatique. Personne ne peut regarder un document
numérique et affirmer: « Oui, ce document a été créé avant le 4 novembre 1952. »
Stuart H a b e r et W . Scott S t o r n e t t a chez B e l l c o r e ont réfléchi au problème [683,
684, 99]. Ils voulaient un protocole de datation de documents qui ait les trois propriétés
suivantes :
- les données elles-mêmes doivent être datées indépendamment de leur support

physique ;
- il ne doit pas être possible de changer le moindre bit d’un document sans que
cela soit apparent ;
- il doit être impossible de dater un document avec une date et une heure différentes
de la vraie date.
Solution arbitrée
Ce protocole utilise Ivan, qui assume le rôle d ’un service de datation sûr et fiable. Bien
sûr, Alice veut dater un document :
1° Alice transmet une copie du document à Ivan.

2° Ivan enregistre la date et l’heure auxquelles il a reçu le document et garde une
copie de sauvegarde du document.
82 Chapitre 4 Protocoles intermédiaires
Maintenant, si quelqu’un met en doute l’affirmation d ’Alice concernant la date de créa

tion du document, elle doit juste faire appel à Ivan. Il produira sa copie du document
et vérifiera qu’il l’a bien reçue à la date mentionnée.
Ce protocole marche mais il a des défauts. Premièrement, il n ’y a pas de confidentialité :
Alice doit donner une copie du document à Ivan. Toute personne à l’écoute pendant
cette transaction peut le lire. Elle peut chiffrer le document, mais même ainsi il doit
encore être stocké dans les bases de données d ’Ivan. Quelle est la sécurité de ces bases
de données ?
Deuxièmement, la base de données elle-même doit être gigantesque car les besoins
d ’archivage seraient énormes. De plus une très large bande passante serait requise pour
envoyer de grands documents à Ivan.
Le troisième défaut est lié aux erreurs potentielles. Une erreur de transmission ou un
défaut magnétique dans l’ordinateur central d ’Ivan pourrait invalider complètement
l’affirmation d’ Alice quant à la date de création du document.
Quatrièmement, il se peut que quelqu’un d’aussi honnête qu’Ivan pour gérer le service
de datation n’existe pas. Peut-être qu’Alice fait appel aux services de la société de
Bernard: « Datation et Art Nouveau. » Il n’y a rien qui empêche Alice et Bernard
d’être complices et de dater des documents comme bon leur semble.
Solution arbitrée améliorée

L’utilisation des fonctions de hachage à sens unique et les signatures numériques
peuvent éviter la plupart de ces défauts :
1° Alice produit, à l’aide de la fonction de hachage à sens unique, une empreinte

du document.
2° Alice transmet l’empreinte à Ivan.
3° Ivan date l’empreinte avec la date et l’heure auxquelles il a reçu l’empreinte et
signe le résultat.
4° Ivan envoie l’empreinte signée et la datation à Alice.
Cela permet de pallier tous les défauts sauf le dernier mentionné. Alice ne doit plus
craindre de devoir révéler le contenu de son document : l’empreinte est suffisante. Ivan
ne doit plus stocker des copies des documents (ni même de leur empreinte), ainsi les
problèmes de capacité de stockage excessive sont résolus (rappelez-vous que les fonc
tions de hachage à sens unique n’ont pas de clef). Alice peut immédiatement examiner
l’empreinte datée et signée qu’elle a reçue à l’étape 4 et ainsi détecter toute erreur de
transmission. Il reste le risque qu’Alice et Ivan puissent être complices pour produire
n’importe quelle datation.
Protocole de filiation
Un moyen d ’éviter ce dernier défaut est de lier la datation d ’Alice avec les autres
datations déjà produites par Ivan, pour d’autres utilisateurs éventuels. Comme l’ordre
dans lequel Ivan recevra les requêtes n’est pas connu d’avance, la datation d ’Alice doit
être plus récente que celle de la requête précédente. Et comme la requête qui suit celle
d’Alice est liée à la datation qu’ Alice a obtenue, sa requête doit forcément avoir eu lieu
avant. La requête d’Alice est donc prise en sandwich dans le temps.
4-1 Services de datation 83
Si A est le nom d ’Alice, l’empreinte qu’Alice veut dater est Hn, et la datation précédente
est Tn- 1 , alors le protocole est donné par:
1° Alice envoie Hn et A à Ivan.

2° Ivan envoie en réponse à Alice :
S K ( n , A , 11n fljL i f n — ly S n —li-^ n )
où Ln est l ’information qui relie à la datation précédente:
H ( I n - l , H n - \ , T n -.\ )
Sk signifie que le message est signé avec la clef publique d’Ivan. Le nom d’Alice
certifie celle-ci comme auteur de la requête. Le paramètre n indique le numéro
d’ordre de la requête: c ’est la ne datation produite par Ivan. La datation est
donnée par le paramètre Tn. L ’information additionnelle consiste en l'identi
fication de l’auteur, l’empreinte, la datation et l’empreinte de la datation du
document précédent qu’Ivan a daté.
3° Après qu’Ivan ait daté le document suivant, il envoie à Alice l’identification de
l’auteur de ce document: In+ i ■
Si quelqu’un met en doute la datation d’Alice, elle contacte les auteurs des documents
antérieurs et postérieurs : In- t et In+i- Si leurs documents sont aussi remis en question,
ils se mettent en contact avec In- 2 et In+2 , et ainsi de suite. Chacun peut montrer que
son document a été daté après celui qui précède et avant celui qui suit.
Ce protocole rend très difficile la complicité entre Alice et Ivan et les empêche de pro
duire un document avec une fausse datation. Ivan ne peut pas postdater un document
car cela nécessiterait de connaître à l’avance la requête qui précédera ce document.
Même s’il pouvait falsifier cela, il devrait alors connaître d’avance la requête avant
* cela » , et ainsi de suite. Il ne peut pas antidater un document car la datation
doit être prise en sandwich entre des documents datés juste avant et juste après : or
ces documents ont déjà été datés. Le seul moyen de contrer ce schéma est d ’inventer
des chaînes de requêtes fictives, passées et futures par rapport au document d’Alice,
suffisamment longues pour décourager toute personne de contester la datation.
Protocole distribué
Les gens meurent. Les datations se perdent. Beaucoup d’événements peuvent se pro
duire entre le moment de la datation et la contestation de celle-ci. Quand la contestation
arrive, Alice ne pourrait plus forcément obtenir une copie de la datation d’/ „ _ i . Ce
défaut peut être évité en incorporant dans la datation d ’Alice les datations des 10
requêtes qui ont précédé celle d ’Alice et en envoyant à Alice les identifications des
auteurs des 10 requêtes qui ont suivi la sienne. Alice a ainsi plus de chance de trouver
quelqu’un qui a encore sa datation.
Suivant le même ordre d’idée, le protocole suivant se passe tout à fait de la collaboration
d’Ivan :
1° A partir d’Hn, Alice engendre une suite de valeurs aléatoires en se servant d’un
générateur aléatoire de suites cryptographiquement sûr:
v 1,v2,v3,...yk
2° Alice interprète chacune de ces valeurs comme l’identification I d’une autre

personne. Elle envoie H n à chacune d’entre elles.
3° Chacune de ces personnes associe la date et l’heure à l ’empreinte, signe le
résultat et envoie le résultat à Alice.
4° Alice collecte et stocke toutes les signatures pour former la datation.
Le générateur aléatoire de suites cryptographiquement sûr de l’étape 1 empêche Alice

de choisir des identificateurs corrompus comme vérificateurs. Même si elle fait des
changements mineurs à son document pour obtenir un ensemble d’identificateurs cor
rompus, ses chances de réussir sont négligeables. La fonction de hachage rend aléatoire
le choix des I ; Alice ne peut pas les forcer.
Ce protocole marche car le seul moyen dont dispose Alice pour tricher est de convaincre
les k personnes de collaborer. Comme elle les choisit aléatoirement à l’étape 1, les
chances d’y arriver sont quasi inexistantes. Plus la société est corrompue, plus k doit
être élevé.
De plus, il faut prévoir un mécanisme qui tienne compte des personnes qui ne peuvent
pas produire une datation sur le champ. Dans ce cas, tout ce qui serait nécessaire
serait un sous-ensemble des k réponses attendues pour former une datation valable.
Les détails dépendent de la réalisation.
Développements futurs
D ’autres améliorations des protocoles de datation sont présentées dans [99]. Les au
teurs utilisent des arbres binaires pour augmenter le nombre de datations qui dépendent
d’une datation donnée, réduisant par la même occasion la possibilité de produire des
chaînes de datations fictives. Ils recommandent également d’éditer publiquement l’em
preinte des datations du jour, dans les journaux par exemple. Cela remplit une fonction
similaire à l’envoi de l’empreinte à un ensemble aléatoire de personnes dans le protocole
distribué. De fait, B e l l C O R E fait cela dans chaque numéro du New York Times du
dimanche depuis 1992.
Ces protocoles de datation sont brevetés [685, 686, 687]. Une société inattendue de
Bellcore, SU RETY TECHNOLOGIES, détient les brevets et a mis sur le marché un « sys
tème de notaire numérique » mettant en oeuvre ces protocoles. Dans la première ver
sion, les clients envoyaient une requête « certifiée » à un serveur central de coordination.
En suivant la technique de Ralph M e r k l e [590], qui permet de construire des arbres
grâce à des fonctions de hachage [77], le serveur produit un arbre d ’empreintes dont les
feuilles sont toutes les requêtes reçues durant une seconde, et renvoie à chaque client
la liste des empreintes du chemin allant de la feuille lui correspondant jusqu’à la racine
de l’arbre. Le client la conserve localement et peut produire un « certificat de notaire
numérique » pour chacun des fichiers qui ont étés certifiés. La suite des racines de ces
arbres forme le « dossier de validation universel » qui est accessible dans de multiples
banques de données et publié sur CD-ROM. Le logiciel client comprend une fonction
de « validation » qui permet à l’utilisateur de tester si un fichier a été certifié dans sa
forme actuelle 1 2.
1. Pour cela il faut récupérer la racine de l’arbre approprié et la com parer à la valeur obtenue en
appliquant la fonction de hachage adéquate sur le fichier et son certificat.
2. Pour plus d’ informations, contacter Surety T ech n ologies, 1 Main S t ., Chatham, NJ, 07928
É tats-U nis, T é l: (201) 701-0600, Fax: (201) 701-0601.
4-2 Canal subliminal 85
4.2 Canal subliminal

Alice et Bernard ont été arrêtés et vont aller en prison. Il entre à la prison des hommes
et elle entre à la prison des femmes. Leur seul moyen de communiquer est par missives.
Gatien, le gardien, est disposé à permettre l’échange de messages entre Alice et Bernard
pour autant que ceux-ci ne soient pas chiffrés. Gatien s’attend à ce qu’ils complotent
pour concocter un plan d ’évasion, aussi veut-il pouvoir tout lire.
Gatien espère aussi duper soit Alice, soit Bernard. Il veut que l’un accepte un message
factice comme un message valide venant de l’autre. Alice et Bernard sont prêts à
prendre le risque d’être dupés, sinon ils ne pourraient pas communiquer du tout et ils
doivent préparer leurs projets. Pour mener cela à bien, ils doivent duper le gardien
et trouver un moyen de communiquer confidentiellement. Ils doivent mettre en place
un canal subliminal, un canal caché de communication entre eux, au nez et à la
barbe de Gatien, bien que les messages eux-mêmes ne contiennent pas d’information
confidentielle. A l’aide de messages signés inoffensifs ils vont échanger de l’information
confidentielle bien que Gatien lise toute la correspondance.
Un canal subliminal simple pourrait être le nombre de mots dans une phrase. Un
nombre impair de mots correspondrait à « 1 », tandis qu’un nombre pair de mots
correspondrait à « 0 ». Ainsi, tandis que vous lisez ce paragraphe d ’apparence innocente,
j ’ai envoyé à mes collaborateurs sur le terrain le message « 110 ». Le défaut de cette
technique est d’être de la simple stéganographie (voir § 1.2); il n’y a pas de clef: la
sécurité dépend uniquement de la confidentialité de l’algorithme. Une meilleure sécurité
est certainement possible.
Gustavus SlMMONS a inventé le concept de canal subliminal dans les algorithmes de si
gnature numérique conventionnels [1464, 1477]. Comme les messages subliminaux sont
cachés dans ce qui ressemble à des signatures numériques normales, c ’est une forme
de dissimulation. Gatien voit transiter des messages innocents signés mais il rate com
plètement l’information qui circule sur le canal subliminal. En fait, l’algorithme de
signature numérique subliminal est indiscernable d’un algorithme de signature numé
rique normal, du moins pour Gatien. Gatien non seulement ne peut pas lire le canal
subliminal mais il ne peut même pas déceler sa présence.
En général, le protocole ressemble à ceci :
1° Alice engendre un message innocent, aléatoirement.

2° A l’aide d’une clef secrète qu’elle partage avec Bernard, Alice signe ce message
innocent de manière à cacher son message subliminal dans la signature. C ’est
le cœur du protocole à canal subliminal (voir § 20.S).
3° Alice envoie le message signé à Bernard via Gatien.
4° Gatien lit le message innocent et vérifie la signature. Ne détectant rien d’anor
mal, il passe le message à Bernard.
5° Bernard vérifie la signature du message innocent, confirmant ainsi que le mes
sage vient bien d’Alice.
6° Bernard ignore le message innocent et, utilisant la clef secrète qu’il partage
avec Alice, il extrait le message subliminal.
Qu’en est-il de la tricherie? Gatien ne fait confiance à personne et personne ne lui

fait confiance. Il peut toujours empêcher la communication, mais il n’a aucun moyen
d’introduire des messages factices. Comme il ne peut pas engendrer de signature valide,
Bernard détecterait la tentative de Gatien à l’étape 5. Et comme il ne connaît pas la
clef secrète partagée, il ne peut pas lire le canal subliminal. Plus important encore, il
n’a pas la moindre idée que des messages subliminaux sont échangés. Des messages
numériques signés ne sont pas différents d’aspect des messages numériques signés avec
messages subliminaux cachés dans la signature.
La tricherie entre Alice et Bernard est plus problématique. Dans certaines réalisations
du canal subliminal, l’information secrète dont Bernard a besoin pour lire les messages
subliminaux est la même information dont Alice a besoin pour signer les messages
innocents. Si tel est le cas, Bernard peut se faire passer pour Alice. Il peut signer
des messages dont Alice serait alors prétendûment l’auteur et Alice ne peut rien faire
pour l’en empêcher. Si elle doit lui envoyer des messages subliminaux, elle doit lui faire
confiance pour qu’il n ’abuse pas de sa clef privée
D’autres réalisations du canal subliminal n’ont pas ce défaut Une clef secrète partagée
entre Alice et Bernard permet à Alice d ’envoyer des messages subliminaux à Bernard
mais elle est différente de la clef privée d ’Alice. Cette clef secrète ne permet pas à
Bernard de signer des messages à la place d ’Alice. Alice n’a pas à faire confiance à
Bernard pour qu’il n’abuse pas de sa clef privée.
Applications du canal subliminal
L’application la plus évidente du canal subliminal est observée dans un réseau d’es
pionnage. Si tout le monde envoie et reçoit des messages signés, les espions ne se feront
pas remarquer en envoyant des messages subliminaux dans des documents signés. Bien
entendu, les espions de la partie adverse peuvent faire la même chose.
Grâce à un canal subliminal, Alice peut signer un contrat sous la menace. Quand elle
signe le contrat, elle introduit le message subliminal : « J ’y suis contrainte. » D ’autres
applications sont plus subtiles. Une société peut signer des documents et cacher des
messages subliminaux, lui permettant ainsi de suivre les documents tout au long de leur
existence. Le Gouvernement peut marquer de la monnaie numérique. Un programme de
signature malveillant peut dévoiler la clef privée par le canal subliminal. Les possibilités
sont sans fin.
Signature numérique exempte de canal subliminal
Alice et Bernard échangent des messages signés pour négocier les termes d’un contrat.
Ils utilisent un protocole de signature numérique. Toutefois, cette négociation de
contrat sert de façade à leurs activités d’espionnage. Quand ils usent de l’algorithme
de signature numérique, peu leur importe les documents qu’ils signent. Ils utilisent un
canal subliminal dans les signatures pour échanger de l’information secrète entre eux.
Les services de contre-espionnage, en revanche, ne savent pas que cette négociation
de contrat et leurs signatures sont des façades. Ceci a conduit certaines personnes à
créer des schémas de signature exempts de canal subliminal. Ce sont des sché
mas de signature numérique qui ne peuvent pas être modifiés pour contenir un canal
subliminal [477, 479].
4-3 Signatures numériques incontestables 87
4.3 Signatures numériques incontestables

Des signatures numériques conventionnelles peuvent être copiées intégralement. Parfois,
cette propriété est souhaitable comme dans le cas des annonces publiques par exemple.
Dans d ’autres situations cela peut être un défaut. Imaginez une lettre signée, person
nelle ou commerciale. Si plusieurs copies de cette lettre circulent dans la nature, cela
peut être embarrassant et même prêter au chantage. La meilleure solution est une si
gnature numérique qui peut être reconnue valable, mais que le destinataire ne peut pas
montrer à un tiers sans le consentement du signataire.
La société A l i c e S o f t w a r e C o m p a n y distribue le célèbre logiciel D E W (« D o-
EVERYTHiNG -W O RD tm »). Pour garantir que leur logiciel n’est pas infecté par un virus,
ils ajoutent une signature numérique. Toutefois, ils veulent que seuls les acheteurs légi
times du logiciel, pas les pirates, puissent vérifier la signature. Cependant, si des copies
de DEW sont infectées, il n’y aurait aucun moyen pour la société A l i c e S o f t w a r e
C o m p a n y de contester une signature valable.
Les signatures in con testa b les [211] conviennent pour ce genre de tâche. Tout comme
les signatures numériques normales, une signature incontestable dépend du document
signé et de la clef privée du signataire. Mais contrairement à une signature numérique
normale, une signature incontestable ne peut être vérifiée sans le consentement du
signataire. « Signature intransférables » serait un nom plus approprié, mais on continue
à les appeler ainsi car si Alice est forcée de confirmer ou de désavouer une signature— au
tribunal par exemple—elle ne peut pas contester sa propre signature.
Les mathématiques sur lesquelles repose ce protocole sont décrites dans le para
graphe 16.7, mais l’idée de base est simple:
1° Alice présente une signature à Bernard.

2° Bernard engendre un nombre aléatoire et l’envoie à Alice.
3° Alice effectue un calcul, utilisant le nombre aléatoire et sa clef privée, et envoie
le résultat à Bernard. Alice ne peut faire ce calcul que si la signature est valide.
4° Bernard confirme ce fait.
Il y a un protocole suplémentaire dans lequel Alice prouve qu’elle n’a pas signé un
document, sans pouvoir le contester s’il s’agit bien de sa signature.
Bernard ne peut pas contourner le protocole et convaincre Christine que la signature
d’Alice est valide, parce que Christine ne sait pas que les nombres de Bernard sont
aléatoires. Il peut très bien avoir refait le protocole à l’envers sur papier sans l’aide
d’Alice et ensuite montrer le résultat à Christine. Christine ne peut pas être convaincue
que la signature d’Alice est valide à moins d’exécuter le protocole avec Alice elle-même.
Cela peut ne pas avoir beaucoup de sens maintenant mais cela en aura une fois que les
mathématiques sous-jacentes auront été présentées au paragraphe 23.4.
Cette solution n ’est pas parfaite. Y vo D e s m e d t et Moti Y u n g montrent que Bernard
peut, dans certaines applications convaincre Christine de la validité de la signature
d’Alice [487].
Par exemple, Bernard achète une copie légale du logiciel D E W . Il peut valider la
signature qui accompagne le logiciel quand il le veut. Bernard peut alors convaincre
Christine qu’il est un vendeur de la société A l i c e S o f t w a r e C o m p a n y . Il lui vend
une copie pirate du logiciel D E W . Quand Christine essaie de valider la signature avec
Bernard, il valide simultanément la signature avec Alice. Quand Christine lui envoie
le nombre aléatoire, il l’envoie à Alice. Quand Alice répond, il envoie la réponse à
Christine. Christine est alors convaincue qu’elle est une acheteuse légitime du logiciel
alors qu’il n’en est rien. Cette attaque est un cas particulier du problème du grand
maître aux échecs qui est décrit en détail dans le paragraphe 5.2.
Telles quelles, les signatures icontestables ont de nombreuses applications; il y a beau
coup de situation où Alice ne veut pas que n ’importe qui puisse vérifier sa signature.
Elle ne veut sûrement éviter que sa correspondance personnelle puisse être vérifiée par
la presse, montrée et vérifiée hors du contexte, où même vérifiée après que les choses ont
changé. Si elle signe une bribe d’information qu’elle a vendue, elle ne veut pas que ceux
qui n’ont pas payé pour l’information puissent tout de même en vérifier l’authenticité.
En contrôlant ceux qui vérifient sa signature, Alice protège sa vie privée.
Une variante des signatures incontestables permet de séparer le lien entre le signataire
et le message, et le lien entre le signataire et la signature [911]. Dans ce cadre, n’im
porte qui est capable de vérifier que le signataire a bien produit la signature, mais la
coopération du signataire est nécessaire pour vérifier que la signature est valide pour
le message en question.
Il existe une notion similaire, celle de signatures incontestables arbitrées. Imaginez
qu’Alice travaille pour la société Toxines et envoie des documents compromettants à
un journal en utilisant un protocole de signature incontestable. Alice peut confirmer sa
signature au prés du journaliste, et à personne d ’autre. Toutefois, Bernard, le contre
maître suspecte Alice d ’avoir divulgué les documents. Il demande à Alice de contester
le protocole pour se laver de tout soupçon, et Alice refuse. Bernard prétend que la seule
raison poussant Alice à refuser est sa culpabilité et il la licencie.
Les signatures incontestables arbitrées s’utilisent comme les signatures incontestables
sauf que seul Ivan peut effectuer le protocole de contestation. Bernard ne peut pas
demander à Alice de contester sa signature car seul Ivan en est capable. Si Ivan est le
sytème judiciaire, il ne devra effectuer le protocole qu’en cas de dispute.
4.4 Signatures numériques à vérificateur

dédié
La SARL Logiciels Alice fait des ventes astronomiques de D E W , à tel point que Alice
passe plus de temps à vérifier des signatures incontestables qu’à élaborer de nouveaux
logiciels.
Alice voudrait engager une presonne chargée de vérifier les signatures pour toute l’en
treprise. Alice, ou tout autre programmeur, pourrait signer des documents avec un
protocole de signature incontestable; mais les vérifications seraient toutes faites par
Christine.
Il se trouve que c ’est possible grâce aux signatures à vérificateur dédié [337, 1221].
Alice peut signer un document de sorte que Bernard est convaincu de la validité de
la signature sans pouvoir convaincre un troisième parti; ce faisant, Alice peut désigner
Christine comme future vérificatrice de la signature. Alice n’a pas même besoin de
la permission de Christine; il lui suffit d’utiliser la clef publique de celle-ci. De plus
Christine peut encore confirmer la signature d’Alice qu’Alice soit partie en voyage,
qu’elle ait quitté la société, ou qu’elle soit morte.
4-5 Signatures par procuration 89
Les signatures à vérificateur dédié sont une sorte de compromis entre les signatures nu
mériques classiques et les signatures incontestables. Dans certaines circonstances, Alice
voudra restreindre le nombre des personnes capables de vérifier sa signature. D ’un autre
côté, donner un contrôle total à Alice peut compromettre l’utilisation des signatures :
Alice pourrait refuser de coopérer pour confirmer ou désavouer une signature en pré-
texant qu’elle a perdu les clefs nécessaires, ou en étant simplement injoignable. Les
signatures à vérificateur dédié assurent à Alice la protection d ’une signature incontes
table sans lui permettre d’abuser de cette protection. Alice préférera voir les choses
ainsi: les signatures à vérificateur dédié lui permettent d ’éviter des utilisations indé-
risables, de la protéger si elle perd sa clef, et d’assurer la pérénité du fonctionnement
des signatures si elle est en vacances, à l’hopital, ou morte.
Cette idée permet toutes sortes d ’applications. Christine peut se déclarer « notaire
publique ». Elle publie sa clef et n’importe qui peut la désigner comme vérificatrice de
ses signatures. Elle peut faire payer chaque confirmation de signature et mener une vie
tranquille.
Christine peut être un bureau de brevetage, une agence gouvernementale, ou l’ordi
nateur hôte d ’une organisation. Ce protocole permet de différencier les personnes qui
signent les documents de celles qui vérifient les signatures.
4.5 Signatures par procuration

Les signatures à vérificateur dédié permettent de désigner quelqu’un d’autre comme
vérificateur des signatures. Alice doit par exemple partir en voyage d’affaires quelque
part où elle n’a pas accès à un réseau informatique, comme la jungle africaine. Ou il
se peut qu’elle soit indisposée après une opération chirurgicale. Elle attend un courrier
électronique important et a briffé son secrétaire Bernard pour répondre en conséquence.
Comment Alice peut-elle permettre à Bernard de signer des messages pour elle, sans
lui donner sa clef privée?
Les signatures par procuration apportent une solution [1010], Alice peut donner
une procuration à Bernard, en remplissant les propriétés suivantes:
- Distingabilité. N’importe qui peut distinguer une signature par procuration

d’une signature usuelle.
- Non falsification. Seul le signataire original et le signataire interposé peuvent

produire une signature par procuration.
- Signataire interposé malveillant. Un signataire interposé ne peut pas pro

duire de signature de signature sans qu’on puisse détecter qu’il s’agit d’une si
gnature par procuration.
- Vérification. Une signature par procuration peut convaincre un vérificateur de

l’accord du signataire original sur le message signé.
- Identification. Le signataire original peut déterminer l’identité du signataire

interposé à partir d’une signature par procuration.
- Non désaveu. Un signataire interposé ne peut pas désavouer une signature par
procuration qu’il a produit.
Dans certains cas, une forme d’identification plus large est nécessaire, permettant à
n’importe qui de déterminer l’identité du signataire interposé à partir de la signature
par procuration. Des protocoles de signatures par procuration, basés sur différentes
réalisations de signatures numériques, se trouvent dans [1010].
4.6 Signatures collectives

David C h a u m présente ainsi ce problème dans [333] :
« Une société a plusieurs ordinateurs. Chacun est connecté au réseau local.

Chaque département de la société a sa propre imprimante (aussi connec
tée au réseau local) et seul le personnel du département a le droit de se
servir de cette imprimante. Avant d’imprimer, l’imprimante doit donc être
convaincue que l’utilisateur travaille dans ce département . En même temps,
la société impose la confidentialité ; le nom de l’utilisateur ne peut pas être
révélé. Toutefois, si quelqu’un découvre en fin de journée qu’une imprimante
a été utilisée trop souvent, le directeur doit être capable de retrouver qui
en a abusé pour envoyer une facture au coupable. »
La solution à ce problème est appelée signature collective. Les signatures collectives

ont les propriétés suivantes :
- Seuls les membres du groupe peuvent signer des messages.
- Celui qui reçoit une signature peut vérifier que c’est une signature valide de ce
groupe mais ne peut pas déterminer quel membre du groupe a signé.
- En cas de litige, la signature peut être « ouverte » pour révéler l’identité du

signataire.
Signature collective avec arbitre

Ce protocole utilise un arbitre en qui l’on a confiance :
1° Ivan engendre un lot de paires « clef privée, clef publique » et donne à chaque
membre du groupe une liste différente de clefs privées uniques. Il n’y a pas de
doublon entre les listes3.
2° Ivan publie la liste principale de toutes les clefs publiques pour le groupe dans
un ordre aléatoire. Il reste seul à savoir qui possède quelle clef.
3° Quand un membre du groupe veut signer un document, il choisit une clef au

hasard parmi sa liste personnelle.
4° Quand quelqu’un veut vérifier qu’une signature appartient au groupe, il re

cherche dans la base de données publique la clef publique et vérifie la signature.
5° En cas de litige, Ivan connaît la correspondance entre les clefs publiques et les
membres du groupe.
3. Si le groupe com porte n membres, et chaque m em bre a m paire de clefs, il y a en tou t n X m

paires de clefs au total.
1^.1 Signatures numériques « Fait-Stop » 91
Le défaut de ce protocole est qu’il nécessite l’intégrité d ’Ivan. Il connaît les clefs privées
de tout le monde et il peut imiter des signatures. De plus, la liste des clefs de chaque
membre doit être suffisamment longue pour éviter que l’on puisse analyser quelles clefs
ils ont utilisées.
L’article de C h a u m [333] donne d ’autres protocoles. Pour certains d ’entre eux, Ivan
ne peut pas imiter de signatures. Dans d’autres Ivan n’est pas toujours nécessaire.
Un autre protocole [352] permet non seulement de cacher l’identité du signataire, mais
aussi d’élargir le groupe à de nouveaux membres. On trouvera encore un autre protocole
dans [1241]
4.7 Signatures numériques « Fail-Stop »

Faisons l’hypothèse qu’Estelle est un adversaire puissant. Elle a de grands réseaux in
formatiques, des pièces pleines d ’ordinateurs Cray : une puissance informatique consi
dérablement plus importante que celle d ’Alice. Tous ces ordinateurs fonctionnent jour
et nuit pour trouver la clef privée d ’Alice. Et enfin, le résultat tombe. Estelle peut
maintenant se faire passer pour Alice signant à sa place des documents à volonté.
Les signatures numériques « Fail-Stop », introduites par Birgit P f i t z m a n n et Michael
W a i d n e r [1250], empêchent ce genre de tricherie. Si Estelle falsifie des signatures de
cette manière, alors Alice peut prouver qu’il y a eu falsification. Si Alice signe des
documents et renie sa signature après coup, prétendant qu’il y a eu falsification, un
tribunal peut vérifier ses dires.
L’idée de base des signatures numériques « Fail-Stop » est que pour chaque clef publique
possible, de nombreuses clefs privées conviendraient. Chacune de ces clefs privées donne
des signatures numériques différentes. Toutefois, Alice n’a qu’une clef privée et elle ne
peut calculer qu’une signature. Alice ne sait rien des autres clefs privées.
Estelle essaie de retrouver la clef privée d ’Alice (dans ce cas-là, Estelle peut être Alice
qui essaie de trouver une seconde clef privée pour elle-même). Elle collectionne les
messages signés et, en utilisant sa batterie d’ordinateurs Cray, elle essaie de retrouver
cette clef privée. Même si elle finit par trouver une clef privée valide, comme il y en a
de nombreuses possibles, il est fort probable qu’elle en ait découvert une différente de
celle qu’Alice utilise. La probabilité qu’Estelle retrouve la bonne clef peut être rendue
si faible qu’elle est négligeable.
Maintenant, quand Estelle falsifie une signature au bas d’un document avec la clef
privée qu’elle a trouvée, cette signature sera différente de celle qui aurait été calculée
par Alice. Quand Alice est traînée devant les tribunaux, elle peut produire les deux
signatures différentes du même message : celle obtenue à l’aide de sa clef privée et celle
produite par Estelle. Elle peut ainsi prouver qu’il y a eu falsification. De même, Alice
ne peut pas fabriquer les deux signatures différentes et Alice est toujours liée par sa
signature.
Ce schéma de signature empêche Estelle d’imiter la signature d ’Alice par puissance
de calcul seulement ; en revanche, il ne peut rien contre Martin qui fort probablement
entrera par effraction au domicile d ’Alice et volera sa clef privée, ou encore contre Alice
qui signe un document et puis qui soi-disant perd sa clef. Pour se protéger du premier,
Alice devrait s'acheter un bon chien de garde; ce genre de choses dépasse le cadre de
la cryptographie.
Des développements théoriques et des applications concernant les signatures « Fail-

Stop » sont décrits dans [1249, 1251, 732, 733].
4.8 Calcul avec données chiffrées

Alice veut connaître la valeur d ’une certaine fonction f ( x ) pour une valeur particulière
de x. Malheureusement, son ordinateur est en panne. Bernard est disposé à lui calculer
f(x) mais Alice ne veut pas que Bernard connaisse x. Comment Alice peut-elle laisser
Bernard calculer f ( x ) sans lui révéler x ?
C ’est le problème général du calcul avec données chiffrées, appelé aussi « cacher de
l’information à un oracle ». Dans l’exemple ci-dessus, Bernard est l’oracle : il répond
à des questions. On peut appliquer cela à certaines fonctions ; nous en reparlerons dans
le paragraphe 23.6.
4.9 Mise en gage

La Grande Alice, magicienne extraordinaire, va maintenant vous prouver son talent.
Elle va deviner quelle carte Bernard va choisir avant même qu’il ne le fasse ! Observez
comment Alice écrit sa prédiction sur un bout de papier. Emerveillez-vous quand Alice
met le bout de papier dans une enveloppe et scelle celle-ci. Frissonnez quand Alice
tend cette enveloppe à un membre de l’assemblée choisi au hasard. « Choisis une carte,
Bernard, n’importe quelle carte. » Il la regarde et la montre à Alice et au public. C ’est
un sept de carreau. Alice récupère maintenant l’enveloppe. Elle l’ouvre. La prédiction,
écrite avant que Bernard ne choisisse, dit « sept de carreau » ! Applaudissements.
Le truc est qu’Alice change d ’enveloppe à la fin du tour. Toutefois, les protocoles
cryptographiques peuvent fournir une méthode où ce tour de passe-passe est impossible.
Pourquoi est-ce utile? Voici une histoire plus banale:
Alice la cambiste, veut convaincre l’investisseur Bernard que sa méthode

de choix d’actions en hausse est fiable.
Bernard : « Choisis cinq actions pour moi. Si elles sont toutes en hausse,
je te confie mes affaires. »
Alice : « Si je choisis cinq actions pour toi, tu peux investir toi-même
sans me payer en retour. Pourquoi est-ce que je ne te montrerais pas plutôt
les actions que j ’ai choisies le mois dernier? »
Bernard : « Comment puis-je savoir que tu n ’as pas changé ton choix
du mois dernier après avoir connu les résultats? Si tu m’indiques ton choix
maintenant, je sais que tu ne peux pas le changer. Je n’investirai pas dans
ces actions avant d ’avoir acheté ta méthode. Fais-moi confiance. »
Alice : « Je préfère te montrer mon choix du mois précédent. Fais-moi
confiance. »
Voilà le problème : Alice veut s’en remettre à un choix mais elle ne veut pas révéler ce
choix avant un certain temps. Bernard, de son côté, veut être sûr qu’Alice ne puisse
pas changer son choix après coup.
4-9 Mise en gage 93
Mise en gage à l’aide de la cryptographie à clef secrète

Ce protocole de mise en gage utilise la cryptographie conventionnelle :
1° Bernard engendre une chaîne de bits aléatoire, R, et l’envoie à Alice :
2° Alice crée un message constitué du bit qu’elle veut mettre en gage, b (cela peut
même être plusieurs bits), et de la chaîne aléatoire de Bernard. Elle chiffre le
tout avec une clef aléatoire, K et envoie le résultat à Bernard.
E K (R,b)
C’est la partie de mise en gage du protocole. Bernard ne peut pas déchiffrer le message
et donc il ne connaît pas la valeur du bit.
Quand vient le moment pour Alice de révéler la valeur du bit, le protocole se poursuit
ainsi :
3° Alice envoie la clef à Bernard.

4° Bernard déchiffre le message pour retrouver le bit. Il vérifie la chaîne aléatoire
pour vérifier la validité du bit.
Si le message ne contenait pas la chaîne aléatoire de Bernard, Alice pourrait, en ca

chette, déchiffrer le message qu’elle a donné à Bernard en essayant différentes clefs,
jusqu’à ce qu’elle en trouve une qui donne au bit une valeur autre que celle qu’elle avait
mise en gage. Comme le bit ne peut avoir que deux valeurs, elle serait sûre de trouver
une clef qui convienne après très peu d’essais. La chaîne aléatoire de Bernard empêche
cette attaque. Alice doit trouver un nouveau message qui non seulement contient son
bit inversé mais aussi la chaîne aléatoire de Bernard inchangée. Si l’algorithme de chif
frement est bon, les chances pour Alice de trouver une autre clef sont infimes. Alice ne
peut pas changer la valeur du bit après l’avoir mis en gage.
Mise en gage à l’aide de fonctions à sens unique

Ce protocole utilise des fonctions à sens unique4 :
1° Alice engendre deux chaînes de bits aléatoires, Ri et R ? .
R i ,R2
2° Alice crée un message contenant les deux chaînes aléatoires et le bit qu’elle veut
mettre en gage (cela peut même être plusieurs bits).
(Ri,R2,b)
3° Alice applique la fonction à sens unique H au message et envoie le résultat à

Bernard ainsi qu’une des deux chaînes aléatoires.
H(Ri,R2,b),Ri
4. Remarquez que tou te fonction à sens unique générale convient pou r ce ty p e d e protocole, pas
seulement les fonctions de hachage à sens unique.
Cette dernière transmission est la mise en gage proprement dite. Alice a utilisé une
fonction à sens unique à l’étape 3 et donc Bernard ne peut pas l’inverser pour retrouver
la valeur du bit.
Quand.vient le tour d ’Alice pour révéler le bit, le protocole se poursuit ainsi:
4° Alice envoie à Bernard le message d’origine:
5° Bernard applique la fonction à sens unique à ce message et compare la valeur

obtenue et R\ à la valeur qu’Alice avait envoyée à l’étape S et R\. Si elles
concordent, le bit est valable.
L’avantage de ce protocole sur le précédent est que lorsque la communication est établie,
seule une communication unidirectionnelle est nécessaire : Bernard n’a pas à parler à
Alice. Alice envoie à Bernard un message pour mettre en gage le bit et un message
pour le révéler.
La chaîne aléatoire de Bernard n’est pas nécessaire car le message de mise en gage
d ’Alice est le résultat d ’une fonction à sens unique. Alice ne peut pas tricher et trouver
un autre message (Ri,R'2,b'), tel que H(Ri,R'2,b') = H(R\,R 2 ,b). Si Alice n’envoyait
pas Ri, alors elle pourrait changer les valeurs de Ri et R^ et ainsi changer la valeur
de b. Le fait que Bernard connaisse déjà R\ l’en empêche.
Mise en gage à l’aide d’un générateur pseudo-aléatoire de suites

Ce protocole est encore plus simple [1146] :
1° Bernard engendre une chaîne aléatoire de bits et l ’envoie à Alice.
Rb
2° Alice engendre un germe aléatoire pour un générateur pseudo-aléatoire de

bits. Ensuite pour chaque bit de la chaîne aléatoire de Bernard, elle envoie
à Bernard:
(a) soit la sortie du générateur aléatoire si le bit de Bernard est 0 ;
(b) soitle « ou exclusif » de la sortie du générateur et de son bit, si le bit de

Bernard est 1.
Quand vient le moment pour Alice de révéler son bit, le protocole se poursuit ainsi :
3° Alice envoie à Bernard le germe aléatoire.
4° Bernard effectue l ’étape 2 du protocole pour vérifier qu’Alice était honnête.
Si la chaîne aléatoire de Bernard est assez longue, et que le générateur pseudo-aléatoire

de bits est imprévisible, Alice n’a aucun moyen pratique de tricher.
f.10 Jouer à pile ou face 95
Pâtés
Les chaînes de mise en gage qu’Alice envoie à Bernard sont parfois appelées pâtés. Un
pâté est une suite de bits, bien que les protocoles n’utilisent pas cette propriété. Comme
le dit Gilles B r a s s a r d : « Ils pourraient tout aussi bien être faits de poussière d’étoile
(ou de photons polarisés!) si cela s ’avérait utile. » [239] Les pâtés ont les propriétés
suivantes :
- Alice peut mettre un pâté en gage. Ce faisant, elle s’engage quant à la valeur
d’un bit spécifique.
- Alice peut ouvrir n’importe quel pâté qu’elle a mis en gage. Quand elle ouvre un
pâté, elle peut convaincre Bernard de la valeur du bit qu’elle a mis en gage lors
qu’elle a mis le pâté en gage. Donc, elle ne peut pas ouvrir un pâté indifféremment
à la fois comme un 0 ou comme un 1.
- Bernard ne peut rien apprendre sur la méthode pour ouvrir un pâté non encore
ouvert et mis en gage par Alice. C ’est vrai même après qu’Alice a ouvert d’autres
pâtés.
- Les pâtés ne contiennent pas d’autre information que le bit mis en gage par Alice.
Les pâtés eux-mêmes ainsi que les procédés de mise en gage et d ’ouverture ne sont
en aucune façon corrélés avec d ’autres secrets qu’Alice pourrait vouloir cacher à
Bernard.
4.10 Jouer à pile ou face

C’est l’heure d ’une petite histoire, avec Joe K i l i a n [832] :
Alice et Bernard veulent jouer à pile ou face mais ils n’ont pas de pièce
à lancer. Alice propose une méthode pour jouer à pile ou face mentalement.
« Premièrement, tu penses à un bit aléatoire, ensuite je pense à un bit
aléatoire. Ensuite on prend le ou exclusif des deux bits. » suggère-t-elle.
« Mais que se passe-t-il si l’un de nous deux ne choisit pas aléatoire
ment? » demande Bernard.
« Peu importe. Aussi longtemps que l’un des deux bits est vraiment
aléatoire, le ou exclusif des deux bits doit être aléatoire. » répond Alice, et
après un moment de réflexion, Bernard est d ’accord.
Peu de temps après, Alice et Bernard trouvent dans la rue un livre sur
l’intelligence artificielle. En bonne citoyenne, Alice dit : « L ’un de nous deux
doit ramasser le livre et le mettre dans une poubelle. » Bernard est d ’accord
et suggère qu’ils utilisent leur protocole de tirage à pile ou face pour décider
qui devra jeter le livre.
« Si le dernier bit est 0, alors tu ramasseras le livre, et si c ’est un 1,
alors je le ferai. Quel est ton bit ? » dit Alice.
Bernard répond « 1. »
« Comme le mien, répond-t-elle avec espièglerie. Ce n’est pas ton bon
jour. »
Inutile d ’insister, ce protocole de tirage à pile ou face a un défaut ma

jeur. Bien qu’il soit vrai qu’un bit x vraiment aléatoire, combiné par ou
exclusif avec un autre bit x non corrélé donne un bit vraiment aléatoire, le
protocole d ’Alice ne garantit pas que les deux bits aient des distributions
indépendantes. En fait, il n’est pas difficile de vérifier qu’aucun protocole
mental ne permet à deux parties, avec des ressources infinies, de jouer à pile
ou face honnêtement. Alice et Bernard étaient bien embêtés jusqu’à ce qu’ils
reçoivent une lettre d ’un obscur étudiant en cryptographie. L’information
que contenait la lettre était bien trop théorique pour avoir une quelconque
utilité pratique mais l’enveloppe qui contenait la lettre était par contre
d’une très grande utilité.
Lorsqu’Alice et Bernard voulurent à nouveau jouer à pile ou face, ils
jouèrent une version modifiée du protocole. D ’abord, Bernard choisissait
un bit, mais au lieu de l’annoncer immédiatement, il l’écrivait sur un bout
de papier et plaçait celui-ci dans une enveloppe. Ensuite, Alice annonçait
son bit. Finalement, Alice et Bernard sortaient de l’enveloppe le bit de
Bernard et calculaient le bit aléatoire. Ce bit était vraiment aléatoire si un
d ’entre eux au moins avait joué honnêtement. Alice et Bernard avaient un
protocole qui marchait ; le rêve du cryptographe d ’avoir un rôle social était
satisfait et ils vécurent heureux jusqu’à la fin de leurs jours.
Ces enveloppes ressemblent à des pâtés. Quand Manuel B lum introduisit le problème
du jeu à pile ou face au téléphone [201], il obtint une solution grâce au protocole de
mise en gage suivant :
1° Alice met en gage un bit aléatoire, en utilisant l ’un des protocoles de mise en
gage décrits au paragraphe 4-9.
2° Bernard essaie de deviner le bit.

3° Alice révèle le bit à Bernard. Bernard gagne le tirage s ’il a deviné correctement
le bit d’Alice.
En général, un tel protocole doit satisfaire les propriétés suivantes :
- Alice doit tirer à pile ou face avant que Bernard ne devine.
- Alice ne doit pas être capable de changer la pièce après avoir entendu le choix de
Bernard.
- Bernard ne doit pas pouvoir savoir comment la pièce a atterri avant de faire son
choix.
Il y a de nombreuses façons de réaliser cela.
Jouer à pile ou face à l’aide de fonctions à sens unique

Si Alice et Bernard peuvent se mettre d ’accord sur le choix d ’une fonction à sens
unique, le protocole est simple :
1° Alice choisit un nombre aléatoire, x. Elle calcule y = f (x), où f {x) est la

fonction à sens unique.
4-10 Jouer à pile ou face 97
2° Alice envoie y à Bernard.

3° Bernard devine si x est pair ou impair et envoie sa supposition à Alice.
4° Si la supposition de Bernard est correcte, le résultat du lancer est face. Si
la supposition de Bernard est incorrecte, le résultat du lancer est pile. Alice
annonce le résultat du lancer et envoie x à Bernard.
5° Bernard vérifie que y = f(x).
La sécurité de ce protocole dépend du choix de f(x). Si Alice peut trouver x et x', où

x est pair et x' est impair et où y = f { x ) = f{x'), alors elle peut tromper Bernard à
chaque lancer. De plus, Alice doit veiller à ce que le bit de poids faible de x ne soit pas
corrélé avec f(x). Sinon, Bernard peut tromper Alice de temps à autre. Par exemple,
si x est pair dans 75 % des cas, Bernard est avantagé5.
Jouer à pile ou face à l’aide de la cryptographie à clef publique

11 y a un autre protocole qui marche avec soit la cryptographie à clef publique, soit
la cryptographie à clef secrète. La seule exigence est que l’algorithme soit commutatif,
comme suit :
D Kl ( E k2 (EKl ( M) ) ) = E k , {A4)
En général, cette propriété n’est pas satisfaite par les algorithmes à clef secrète,
mais l’est par les algorithmes à clef publique (l’algorithme à clef publique R S A , par
exemple). Voici le protocole:
1° Alice et Bernard engendrent chacun une paire « clef publique, clef privée ».
2° Alice engendre deux messages, l’un indiquant face et l’autre pile. Ces messages
doivent contenir une chaîne aléatoire unique, de manière qu’Alice puisse véri
fier leur authenticité plus tard dans le protocole. Alice chiffre les deux messages
avec sa clef et les envoie à Bernard.
E A ( M l ) , E A ( M 2)
3° Bernard, qui ne peut lire aucun des deux messages, choisit l’un d’entre eux au
hasard (il peut lancer une pièce de monnaie, engager un ordinateur malfaisant
pour tenter en vain de décider lequel choisir, ou même consulter son horoscope
chinois - peu importe). Il chiffre celui qu’il a choisi avec sa clef et envoie le
résultat à Alice.
E b (E a ( M ) )
A4 représente donc soit A4i soit A42.
4° Alice qui ne peut pas lire ce message, le déchiffre avec sa clef et envoie le résultat
à Bernard.
D a {E b (E a ( M) ) ) = E b ( M i ) si M = M !
= E b {A42) si A4 — A42
5. Le bit de poids faible constitue parfois un mauvais ch oix car il arrive q u ’il soit plus facile à
calculer.
5° Bernard déchiffre le message avec sa clef pour découvrir le résultat du lancer.

Il envoie le message déchiffré à Alice.
D b (E b ( M ) ) = Mi si M = M i
— M 2 si M = M 2
6° Alice lit le résultat du lancer et vérifie que la chaîne aléatoire est correcte.
7° Alice et Bernard révèlent tous les deux leurs clefs de telle manière qu’ils
puissent vérifier que ni l’un ni l’autre n’a triché.
Ce protocole est à sécurité intrinsèque. Chaque participant peut immédiatement détec

ter toute tentative de tricherie de l’autre. Aucun tiers n’est nécessaire pour conduire
le protocole ni pour résoudre les litiges après que le protocole a été exécuté. Pour voir
pourquoi il en est ainsi, essayons de tricher.
Si Alice veut tricher et imposer le tirage face, elle dispose de trois moyens pour modifier
le lancer.Premièrement, elle peut chiffrer deux messages face àl’étape 2. Bernard
découvrirait celalorsqu’Alice révèle sa clef (ou ses clefs) à l’étape 7.Deuxièmement,
elle peut mal déchiffrer le message à l’étape 4. Toutefois, elle ne peut pas trouver
un moyen de déchiffrer le message pour imposer un autre contenu qui ne soit pas
du charabia. Bernard découvrirait la supercherie à l’étape 5. Troisièmement, elle peut
mentir quand à la validité du message à l’étape 6. Bernard s’en rendrait compte à l’étape
7, quand Alice ne pourrait pas prouver que le message n ’est pas valide. Bien sûr, Alice
peut refuser de participer à toute étape du protocole, auquel cas la supercherie d’Alice
serait évidente pour Bernard.
Si Bernard veut tricher et imposer le tirage pile, il n ’a pas plus de possibilités. Il peut
mal chiffrer le message à l’étape 3, mais Alice découvrirait la supercherie à l’étape 6 en
lisant le message. Il peut mal exécuter l’étape 5 mais cela donnerait aussi du charabia
qu’Alice découvrirait à l’étape 6. Il peut prétendre n’avoir pu bien exécuter correcte
ment l’étape 5 à cause d ’une tricherie d ’Alice, mais ce type de tricherie serait découvert
à l’étape 7. Finalement, il peut envoyer un message pile à l’étape 5, peu importe le
message qu’il a déchiffré, mais Alice pourrait immédiatement vérifier l’authenticité de
ce message à l’étape 6.
Jouer à pile ou face dans un puits

Il est intéressant de remarquer que dans tous ces protocoles, Alice et Bernard n’ap
prennent pas le résultat du lancer en même temps. Il y a un instant du protocole où un
des participants (Alice dans les deux premiers protocoles et Bernard dans le dernier)
connaît le résultat du lancer mais ne peut pas le changer. Ce participant peut toutefois
retarder la divulgation du résultat à l’autre participant. On dira alors que l’on jo u e à
pile o u face dans un puits. Imaginez un puits. Alice est près du puits et Bernard est
très loin. Bernard lance une pièce, celle-ci atterrit dans le puits. Alice peut maintenant
regarder dans le puits et voir le résultat mais elle ne peut pas atteindre la pièce pour
changer son état. Bernard ne peut pas voir le résultat du lancer jusqu’à ce qu’Alice
l’autorise à s’approcher suffisamment près pour regarder dans le puits.
j .l l Poker à l’aveugle 99
Génération de clef par jeu à pile ou face

Une application concrète de ce protocole est la génération de clef. Les protocoles de
jeu à pile ou face, permettent à Alice et Bernard d’engendrer une clef aléatoire sans
que l’un ou l’autre ne puisse influer sur la clef. Et en faisant l’hypothèse qu’Alice et
Bernard chiffrent tous leurs échanges, cette clef sera à l’abri des oreilles indiscrètes.
4.11 Poker à l’aveugle

Un protocole similaire au troisième protocole de jeu à pile ou face permet à Alice
et Bernard de jouer au poker, chacun étant à une extrémité d’une liaison par courrier
électronique Au lieu de fabriquer et de chiffrer deux messages (un pour pile et un pour
face), Alice fabrique 52 messages, un pour chaque carte du paquet.
Bernard choisit 5 messages au hasard, les chiffre avec sa clef publique et les renvoie à
Alice. Alice déchiffre les messages et envoie le résultat à Bernard qui déchiffre ceux-ci à
son tour pour découvrir sa donne. Il envoie, sans les chiffrer avec sa clef dans ce cas-là,
5 autres messages à Alice, qui les déchiffre pour déterminer sa donne. Durant le jeu,
des cartes supplémentaires peuvent être distribuées en suivant le même protocole. À
la fin du jeu, Alice et Bernard révèlent leurs jeux et leurs paires de clefs ; ainsi chacun
peut être assuré que l’autre n’a pas triché.
Poker à l’aveugle avec trois joueurs

Le jeu de poker est plus amusant avec plus de joueurs. Le protocole de base du poker
à l’aveugle peut être étendu à trois joueurs et plus. Une fois de plus, l’algorithme
cryptographique doit être commutatif.
1° Alice, Bernard, et Christine, chacun, engendrent une clef secrète ou une paire
« clef privée, clef publique ».
2° Alice engendre 52 messages, un pour chaque carte à jouer. Ces messages
doivent contenir une chaîne aléatoire unique de manière qu’elle puisse véri
fier leur authenticité plus tard dans le protocole. Alice chiffre tous les messages
avec sa clef et les envoie à Bernard.
E A ( M n)
3° Bernard, qui ne peut lire aucun des messages, en choisit 5 au hasard. R les
chiffre avec sa clef et les renvoie à Alice.
E B(EA( M n))
4° Bernard envoie les 47 autres messages à Christine.
E A( M n)
5° Christine, qui ne peut lire aucun des messages, en choisit 5 au hasard. Elle les
chiffre avec sa clef et les renvoie à Alice.
E c (EA( M n))
6° Alice, qui ne peut lire aucun des messages qui lui sont renvoyés, déchiffre ceux-
ci avec sa clef et envoie les résultats à Bernard ou Christine (en fonction de
leur provenance).
D A(EB(EA( M n))) = E B( M n)
D A(Ec (EA( M n))) = E c ( M n)
7° Bernard et Christine déchiffrent les messages avec leurs clefs respectives pour
découvrir leurs donnes.
D B(EB ( M n)) — M n
Dc {Ec { M n)) = M n
8° Christine choisit 5 autres messages parmi les 42 restant. Elle les envoie à Alice.
E A( M n)
9° Alice déchiffre les messages pour découvrir sa donne.
D A(EA( M n)) = AAn
10° A la fin du jeu, Alice, Bernard et Christine dévoilent leurs jeux et leur clefs
afin que chacun puisse vérifier qu’il n’y a pas eu tricherie.
Des cartes supplémentaires peuvent être distribuées de la même manière. Si soit

Bernard, soit Christine veut une carte, il ou elle prend le talon chiffré et exécute le
protocole avec Alice. Si Alice veut une carte, celui ou celle qui a le talon à ce moment-là
lui envoie une carte au hasard.
Idéalement, l’étape 10 ne devrait pas être nécessaire. Les joueurs ne devraient pas être
obligés de révéler leur jeu en fin de partie : seuls les joueurs qui n’ont pas suivi devraient
le faire. Puisque l’étape 10 ne fait partie du protocole que pour détecter les tricheurs,
on peut y remédier.
Au poker, il est seulement intéressant de savoir si le gagnant a triché ou non. Tous
les autres peuvent tricher tant qu’ils veulent du moment qu’ils ne gagnent pas. Voyons
donc des cas où différents joueurs gagnent.
Si Alice gagne, elle dévoile son jeu et ses clefs. Bernard peut utiliser la clef privée d ’Alice
pour confirmer qu’elle a honnêtement exécuté l’étape 2 (en d ’autres termes que les 52
messages correspondent bien aux 52 cartes à jouer). Christine peut confirmer qu’Alice
ne ment pas concernant la composition de son jeu en chiffrant les cartes d ’Alice avec
la clef d’Alice et en vérifiant que les messages obtenus correspondent bien à ceux que
Christine lui a envoyés à l’étape 8.
Si soit Bernard, soit Christine gagne, il ou elle révèle son jeu et ses clefs. Alice peut
confirmer que les cartes sont authentiques en comparant avec sa chaîne aléatoire. Elle
peut confirmer que le jeu est composé des cartes distribuées en les chiffrant avec la clef
du gagnant, et en comparant avec ce qu’elle a envoyé à l’étape 3 ou 5.
Ce protocole ne protège pas contre la complicité de plusieurs joueurs malfaisants. Alice
et un autre joueur peuvent effectivement se liguer contre le troisième et plumer celui-ci
sans éveiller le moindre soupçon. Il est donc important de vérifier les chaînes aléatoires
et les clefs chaque fois que les joueurs révèlent leur jeu. Et si vous êtes assis à cette
4-11 Poker à l’aveugle 101
table virtuelle avec deux autres joueurs qui ne révèlent jamais leur main quand l’un
des deux est le donneur (Alice, dans le protocole ci-dessus), arrêtez de jouer.
Il faut noter que si cela constitue une théorie intéressante, le réaliser sur un ordinateur
est une tâche ardue. Une réalisation sur des stations de travail Sparc avec trois joueurs
(un par station) prend huit heures pour mélanger les cartes [515].
Attaques contre les protocoles de poker à l’aveugle

Les cryptographes ont montré qu’il y a des petites fuites d’information dans ces pro
tocoles de poker à l’aveugle quand l’algorithme RSA est utilisé [456, 575]. Plus préci
sément, si la représentation binaire de la carte est un résidu quadratique (voir § 11.3),
alors la carte chiffrée est aussi un résidu quadratique. Cette propriété peut être utilisée
pour marquer certaines cartes — tous les as par exemple. Cela ne révèle pas grand
chose sur les jeux des joueurs, mais dans un jeu comme le poker, la moindre parcelle
d’information peut être un avantage à long terme.
Shafî G o l d w a s s e r et Silvio M i c a l i [626] ont développé un protocole de poker à
l’aveugle à deux joueurs qui ne souffre pas de ce défaut. Mais sa complexité le rend
bien plus théorique que pratique. Un protocole général de poker à l’aveugle à n joueurs
qui élimine le problème de fuite d ’information a été développé dans [393].
Le compte rendu d’autres recherches sur les protocoles de poker sont donnés dans
[575, 1636, 393]. Un protocole compliqué qui évite aux joueurs de devoir révéler leur
jeu est décrit dans [394]. Don COPPERSMITH décrit deux moyens de tricher au poker
à l’aveugle si celui-ci utilise l’algorithme R S A [374].
Distribution anonyme de clefs

Bien qu’il soit improbable que quiconque utilise ce protocole pour jouer au poker par
modem, Charles P f l e e g e r décrit une situation où ce protocole serait bien utile [1254],
Considérez le problème de la distribution des clefs. Si nous émettons l’hypothèse que
les utilisateurs ne peuvent pas engendrer leurs clefs eux-mêmes (elles doivent avoir une
certaine forme, ou elles doivent être signées par un organisme, ou quelque chose de
similaire), alors nous devons mettre en place un serveur centralisé pour engendrer et
distribuer les clefs. Le problème est de trouver un moyen pour distribuer les clefs de
manière que personne, même pas le serveur lui-même, puisse déterminer qui a quelle
clef.
Le protocole suivant résout le problème :
1° Alice engendre une paire « clef privée, clef publique ». Pour ce protocole, elle
garde les deux clefs secrètes.
2° Le C D C engendre une suite continue de clefs.

3° Le C D C chiffre les clefs une à une avec sa propre clefpublique.
4° Le C D C transmet les clefs une à une sur le réseau.
5° Alice choisit une clef au hasard.
6° Alice chiffre la clef choisie avec sa clef publique.
7° Alice attend un peu (suffisamment longtemps pour que le serveur ne puisse pas
deviner quelle clef elle a choisie) et envoie la clef doublement chiffrée au CDC.
8° Le C D C déchiffre la clef doublement chiffrée avec sa clef privée, donnant une

clef chiffrée avec la clef publique d’Alice.
9° Le serveur envoie cette clef chiffrée à Alice.

10° Alice déchiffre la clef avec sa clef privée.
Estelle, qui écoute tout, n’a pas la moindre idée de la clef choisie par Alice. Elle voit un
flot continu de clefs passer à l’étape 4. Quand Alice renvoie sa clef au serveur à l’étape
7, elle est chiffrée avec sa clef publique, qui est également secrète. Estelle n’a aucun
moyen de corréler celle-ci avec le flot de clefs du serveur. Quand le serveur renvoie la
clef à Alice à l’étape 9, elle est aussi chiffrée avec la clef publique d ’Alice. Ce n’est qu’à
l’étape 10, quand Alice déchiffre sa clef, que celle-ci est dévoilée.
Si vous utilisez l’algorithme R S A , il y a des fuites d’information dans ce protocole,
au rythme d ’un bit par message. C ’est lié aux résidus quadratiques une fois de plus.
Si vous envisagez de distribuer des clefs ainsi, veillez à ce que la fuite d’information
soit suffisamment faible. Bien sûr, si Alice ne peut pas faire confiance au C D C, la
fuite d ’information est inévitable. Un C D C malveillant garderait un enregistrement
de toutes les clefs qu’il engendre. Il pourrait ensuite parcourir cet enregistrement pour
déterminer quelle est la clef d’Alice.
Ce protocole présume qu’Alice agit honnêtement. Si l’algorithme R SA est utilisé, elle
peut agir pour obtenir plus d’information qu’elle ne devrait en avoir. Ce n ’est pas un
problème dans notre scénario, mais peut le devenir dans d ’autres circonstances.
4.12 Accumulateurs à sens unique

Alice fait partie de la société Clique d’import export. Il lui arrive de rencontrer les
autres membres dans des restaurants mal éclairés et de chuchoter des secrets à droite
à gauche. Le problème est que le restaurant est si mal éclairé qu’elle a du mal à voir si
la personne à l’autre bout de la table est aussi membre.
La société Clique peut opter pour plusieurs solutions. Chaque membre peut porter
une liste des membres. Cela pose deux problèmes. Premièrement, tout le monde doit
transporter une importante base de données, et deuxièmement, ils doivent surveiller
de prés leurs listes des membres. D ’un autre côté, un secrétaire.de confiance pourrait
distribuer des cartes d’identité signées numériquement. Ceci présente l’avantage sup
plémentaire de permettre aux étranger de vérifier l’appartenance d ’un membre (pour
des remises chez l’épicier par exemple), mais cela requiert un secrétaire de confiance.
Aucun membre de la société Clique ne mérite une telle confiance.
Une solution originale consiste à utiliser quelque chose du nom de a ccu m u lateu r à
sens unique [126]. C ’est, une sorte de fonction de hachage à sens unique, à la différence
près que c ’est, commutatif. C ’est à dire qu’il est, possible d ’appliquer cette fonction à
la liste des membres dans n’importe quel ordre en obtenant toujours la même valeur.
On peut même rajouter des membres toujours sans se soucier de l’ordre.
Aussi, voici ce qu’Alïce fait. Elle calcule l’accumulation de tous les noms des membres
excepté le sien. Ensuite, elle stocke le résultat avec son nom. Bernard, ainsi que tous
les autres membres, font de même. Maintenant, quand Alice et Bernard se rencontrent
dans le restaurant, mal éclairé, ils échangent simplement leurs valeurs d ’accumulation et
leurs noms. Alice vérifie alors que l’ajout du nom de Bernard à sa valeur d’accumulation
4-13 Divulgation tout ou rien de secrets 103
produit le même résultat que l’ajout du nom d’ Alice à sa propre valeur d’accumulation.
Bernard fait de même. Chacun sait alors que l’autre est bien un membre. De plus, aucun
des deux n’a la moindre idée des identités des autres membres.
Encore mieux, on peut donner toutes les valeurs d’accumulation à des personnes exté
rieures. Alice peut alors prouver son appartenance à la société à une personne extérieure
(peut-être pour obtenir une remise au magasin local de contre espionnage) sans que la
personne extérieure puisse deviner la liste entière des membres.
Pour ajouter de nouveaux membres, il suffit d’envoyer leurs noms aux autres.
Malheureusement, le seul moyen d ’effacer un membre et d ’envoyer à tout le monde
une nouvelle liste et de recalculer les valeurs d’accumulation. Mais la société Clique
n’a besoin de faire cela que si un membre démissionne; les membres morts peuvent
rester sur la liste. (Aussi étrange que cela puisse paraître, cela n’a jamais posé de
problème).
C’est une idée intelligente qui entre en application chaque fois que vous désirez les
mêmes effets que les signatures numérique sans avoir recourt à un signeur centralisé.
4.13 Divulgation tout ou rien de secrets

Imaginez qu’Alice soit un ex-agent, secret de l’ex-Union soviétique, aujourd’hui sans
emploi. Pour se faire de l’argent, elle vend des secrets. Toute personne prête à en
payer le prix peut acheter un secret. Elle a même un catalogue. Tous les secrets sont
mentionnés avec un numéro et avec des titres alléchants : « Où est Jimmy Hoffa? »,
« Qui contrôle secrètement la Commission Trilatérale? », « Pourquoi Boris Yeltsin
paraît-il toujours avoir avalé une couleuvre? », etc.
Alice ne donnera pas deux secrets pour le prix d ’un, ni la moindre information concer
nant n’importe quel secret. Bernard, un acheteur potentiel, ne veut pas acheter des
secrets au hasard, ni dire à Alice quel secret il veut lui acheter. Cela ne regarde pas
Alice, sinon, elle pourrait ajouter à la fin de son catalogue : « Quels sont les secrets qui
intéressent Bernard? »
Un protocole de poker ne marchera pas dans ce cas-là car, à la fin du protocole, Alice
et Bernard doivent mutuellement révéler leur jeu. B y aussi des astuces que Bernard
peut utiliser pour apprendre plus d ’un secret.
La solution s’appelle les protocoles à divulgation tout ou rien de secrets (aussi
connus sous le nom de A N D O S : « all-or-nothing disclosure of secrets ») [249], car dès
que Bernard a obtenu l’information sur un quelconque secret d’Alice, il a perdu toute
chance d’apprendre quoi que ce soit concernant les autres secrets.
Il y a plusieurs protocoles A N D O S décrits dans la littérature cryptographique. Certains
d’entre eux seront décrits dans le paragraphe 23.9.
4.14 Dépôt de clefs

Voici comment Silvio M lC A U introduit ce sujet [1091] :
« Les écoutes téléphoniques, autorisées par les autorités judiciaires, consti

tuent le moyen le plus efficace de la société pour prévenir le crime et pour
confondre les criminels. Il y a donc une crainte légitime quant à la large
diffusion de la cryptographie à clef publique, qui pourrait être un outil

puissant dans les mains des organisations criminelles et terroristes. De fait,
plusieurs projets de loi proposent qu’une agence gouvernementale puisse,
dans certaines circonstances définies par la loi, être capable d ’obtenir le
texte en clair de toute communication sur un réseau public. Actuellement,
cette demande se traduirait en une obligation pour tous les citoyens de:
1°) utiliser un cryptosystème faible — c ’est-à-dire, un cryptosystème que
les autorités (mais aussi n’importe qui d ’autre !) pourrait casser sans grand
effort; 2°) remettre, a priori, leur clef secrète à cette autorité. Il n’est pas
étonnant qu’une telle alternative ait provoqué un tollé général. La plupart
des citoyens concernés estiment que le secret de la vie privée doit passer
avant la sécurité nationale et la mise en application de la loi. »
Le dépôt de clefs est au coeur du programme gouvernemental américain C L IP P E R et

de son standard de chiffrement par clefs sous dépôt « Escrowed. Encryption Standard ».
Il s’ agit ici de développer un cryptosystème qui permetrait, à la fois de protéger la vie
privée de chacun et de faire des écoutes sous autorisation judiciaire.
Ce standard tire sa fiabilité de puces résistante à l’investigation. Chaque puce de chif
frement aurait un numéro d ’identification unique et une clef secrète. Cette clef est
divisée en deux morceaux et fichée avec son numéro dans deux organismes distincts de
dépôt. Chaque fois que la puce chiffre un fichier de données, elle commence par chiffrer
la clef de session avec cette clef secrète unique. La clef de session chiffrée et le numéro
d’identification de la puce sont transmis lors de la communication. Quand un organisme
de répression veut déchiffrer le traffique chiffré avec une de ces puces, elle se procure
les clefs appropriées au prés des organismes de dépôt grâce au numéro d ’identification,
ensuite elle combine les deux clefs au moyen de l’opération X O R , elle déchiffre la clef
de session, qu’elle peut utiliser pour déchiffrer le trafique de messages. U y a quelques
complications pour faire fonctionner cela au nez et à la barbe des tricheurs; les détails
seront abordés au paragraphe 24.16. On peut faire la même chose avec des logiciels en
utilisant la cryptographie à clef publique [84, 1581, 1582, 1583].
M i c a l l i appelle son idée les c r y p t o s y s t è m e s é q u i t a b l e s [1091, 1090]6. Dans ces
cryptosystèmes, la clef privée est morcellée et chaque morceau est confié à une autorité
différente. Comme pour un schéma de secret réparti, les autorités peuvent se mettre
ensemble pour reconstruire la clef privée. De plus, les morceaux ont la propriété de
pouvoir être validés individuellement, sans reconstruire la clef privée.
Alice peut créer sa propre clef privée, la diviser en n morceaux et donner chacun des n
morceaux à un dépositaire7. Aucun de ces dépositaires ne peut reconstruire individuel
lement la clef privée d’Alice. Toutefois, chacun des dépositaires peut vérifier la validité
du morceau de clef qui lui a été confié ; Alice ne peut pas envoyer à un des dépositaires
une chaîne de bits aléatoire et espérer s’en tirer ainsi. Si l’autorité judiciaire autorise
une écoute, les autorités compétentes pour faire respecter la loi peuvent réquisitionner
les n morceaux auprès des n dépositaires. Avec les n morceaux, les autorités peuvent
reconstruire la clef privée et peuvent placer une écoute sur les lignes d ’Alice. En outre,
Martin, doit corrompre tous les n dépositaires pour être capable de reconstruire la clef
privée d’Alice et ainsi violer sa vie privée.
6 . Le gouvernem ent am ércain aurait payé un m illion de dollars à M i c a l l i pou r l’ utilisation de son
brevet [1092, 1093]; des com pagnies de banques ont ensuite acheté le brevet de M i c a l l i .
7. N ote du traducteur : en français, on parle également de « fidéicom missaire ».
4-If Dépôt de clefs 105
Voici comment le protocole est défini :
1° Alice crée sa paire « clef privée, clef publique ». Elle partage sa clef privée en
plusieurs morceaux publics et privés.
2° Alice envoie un morceau public et le morceau privé correspondant à chaque

dépositaire. Ces messages doivent être chiffrés. Elle envoie aussi la clef publique
au C D C .
3° Chaque dépositaire effectue un calcul pour vérifier que le morceau public et

le morceau privé dont il dispose sont corrects. Chaque dépositaire stocke le
morceau privé quelque part en sécurité et envoie le morceau public au C D C.
4° Le C D C effectue un autre calcul sur les morceaux publics et la clef publique. Si

tout est correct, il signe la clef publique d’Alice et soit il la renvoie à celle-ci,
soit il l’affiche dans une base de données quelque part.
Si une autorité judiciaire autorise une écoute, alors chaque dépositaire remet son mor
ceau au C D C . Le C D C reconstruit alors la clef privée. Avant cela, ni le C D C , ni
aucun des dépositaires ne pouvait reconstruire individuellement la clef privée : tous les
dépositaires sont requis pour reconstruire la clef.
Tout algorithme à clef publique peut être rendu équitable de cette manière. Certains
algorithmes particuliers sont décrits dans le paragraphe 23.10. L’article de M lC A L i
[1091, 1090] présente des méthodes pour combiner cela avec un schéma à seuil, de
manière qu’un sous-ensemble des dépositaires (par exemple, 3 parmi 5) soit nécessaire
pour reconstruire la clef privée. Il montre aussi comment combiner cela avec un transfert
inconscient (voir § 5.5) afin que les dépositaires ne puissent pas connaître l’identité du
propriétaire de la clef privée reconstruite.
Les cryptosystèmes équitables ne sont pas parfaits. Un criminel peut exploiter le sys
tème en utilisant un canal subliminal (voir § 4.2) pour insérer une autre clef secrète
dans son morceau. De cette manière, il peut communiquer de façon sûre avec quelqu’un
d’autre en utilisant cette clef subliminale sans avoir à se soucier d’une mise sur écoute
judiciaire. Un autre protocole appelé d é p ô t d e clefs à sû reté in tégrée résoud ce
problème [957, 834]. L’algorithme et le protocole seront décrits au paragraphe 23.10.
La politique du dépôt de clefs

Mis à part les plans gouvernementaux de dépôts de clefs, il existe plusieurs propositions.
Ceci nous amène à nous poser la question suivante: quels sont les avantages pour
l’utilisateur de mettre sa clef sous dépôt?
En fait, il n’y en a aucun. L ’utilisateur n’en retire rien qu’il ne puisse se procurer lui-
même. Il peut sauvegarder ses clefs si il veut (voir § 8.8). Le dépôt de clef garanti que
la police peut écouter ses conversations ou lire ses dossiers même s’ils sont chiffrés. Il
garanti que la NSA peut écouter ses appels internationaux sans autorisation, même
s’ils sont chiffrés. Peut-être sera-t-il autorisé à utiliser la cryptographie dans des pays
qui maintenant l’ont bannie, mais ça semble être le seul avantage.
Le dépôt de clef a de considérables désavantages. L’utilisateur doit faire confiance à
l’agent de sécurité des dépôts, ainsi qu’à l’intégrité des personnes impliquées dans la
procédure. Il doit croire que les agents de dépôts ne changeront pas leur politique,
que le gouvernement ne changera pas ses lois et que ceux qui ont toute autorité pour
obtenir ses clefs le fasse dans le cadre de la loi et avec responsabilité. Imaginez une
attaque terroriste massive à New York; quelles seraient les limites dépassées par la
police en répercussion?
Il est dur d ’imaginer des plans de dépôts de chiffrement fonctionnant tels que ses parti
sans le voudraient, c ’est-à-dire sans aucune sorte de pression légale. La prochaine étape
évidente est de bannir l’utilisation des chiffrements non déposés. C ’est probablement la
seule manière de rendre un système commercial lucratif, et c’est certainement la seule
manière de les faire utiliser par des criminels et terroristes techniquement très équipés.
Il n’est pas facile de dire s’il sera aisé de faire disparaître la cryptographie non dépo
sée, ou si cela affectera la cryptographie en tant que discipline académique. Comment
puis-je rechercher des programmes d’algorithmes cryptographiques sans avoir en ma
possession du matériel de chiffrement non déposé; aurai-je besoin d ’une autorisation
spéciale ?
Il y a des questions légales. Les dépôts de clefs engageront-ils la responsabilité des uti
lisateurs s’il y avait une fuite de données chiffrées? Si le gouvernement américain essaie
de protéger les agences de dépôts, cela ne voudrait-il pas dire que c ’est l’utilisateur qui
sera systématiquement en faute si le secret devait être compromis soit par l’utilisateur
soit par l’agence de dépôts?
Que se passerait-il si une grande entreprise de dépôts de clefs, gouvernementale ou
civile, se faisait voler toutes ses clefs mises en dépôt? Que se passerait-il si le gou
vernement américain essayait d ’étouffer l’affaire? Cela aurait un indéniable effet sur la
volonté des utilisateurs à continuer à utiliser le dépôt de clefs. Si ce n’est pas volontaire,
quelques scandales de ce genre auraient pour effet d ’augmenter la pression politique
pour soit le rendre volontaire, soit rajouter des règles complexes à cette industrie.
Ce qui serait encore plus dangereux serait un scandale rendu publique où un membre
de l’opposition à l’administration en place, ou un vif opposant aux agences de ren
seignement ou de police, aurait été sous surveillance pendant plusieurs années. Ceci
pourrait faire monter un sentiment hostile au chiffrement mis sous dépôt.
Si les signatures de clefs sont comme les chiffrement de clefs mises sous dépôt, il y a
alors d ’autres débouchés. Peut-on accepter des autorités qu’elles utilisent des signatures
de clefs pour mener des opérations contre des criminels? Est-ce-que l’authenticité des
signatures basées sur des clefs déposées sera reconnue en cour de justice? Quels recours
auront les utilisateurs si les autorités utilisent leurs signatures de clefs pour signer des
contrats défavorables, pour aider une industrie étatisée, ou pour voler de l’argent?
La globalisation de la cryptographie amène toute une série de questions. Est-ce-que les
politiques de dépôts de clefs seront compatibles entre différentes nations? Est-ce-que les
entreprises multi-nationales devront déposer leurs clefs séparément dans chaque pays
afin de respecter les différentes législations? Sans un minimum de compatibilité, un
des avantages supposés des dépôts de clefs (utilisation internationale de chiffrement)
disparaît.
Que se passerait-il si des pays ne faisaient pas confiance en la sécurité des agences
de dépôts de clefs? Comment les utilisateurs feraient-ils des affaires? Leurs contrats
digitaux seront-ils confirmés par la cour, ou est-ce-que le fait que leur signature de
clef soit sous dépôt aux Etats-Unis leur permet de dire qu’en Suisse quelqu’un d ’autre
aurait pu signer ce contrat électronique ? Y aura-t-il des dispositions spéciales pour les
personnes faisant des affaires dans de tels pays?
Et à propos de l’espionnage industriel, il n’y a aucune raison de croire que les pays
4-14 Dépôt de clefs 107
faisant de l’espionnage industriel pour leurs grandes entreprises ou leurs entreprises

nationalisées ralentiront leurs actions sur les systèmes de chiffrement des dépôts de
clefs. En effet, puisqu’aucun pays ne va autoriser les autres à surveiller ses opérations de
renseignement, l’utilisation étendue de chiffrements déposés augmentera probablement
la pose d’écoutes téléphoniques.
Même si les pays respectueux du droit civil utilisent le dépôt de clefs pour la seule
poursuite légitime des criminels et des terroristes, on peut être certain qu’il sera aussi
utilisé pour traquer des dissidents, faire chanter des opposants politiques, etc... Les
communications digitales offrent aujourd’hui, à la différence des technniques analo
giques, la possibilité de surveiller de manière bien plus poussée les mouvements des
citoyens, les opinions, les achats et les associations.
Il n’est pas facile de dire si cela affectera les dépôts de clefs commerciaux, excepté que
dans 20 ans, vendre à la Turquie ou à la Chine un système de dépôt de clefs prêt à
l’emploi ressemblera fortement à vendre des matraques en Afrique du Sud dans les
années 1970, ou construire une usine chimique en Iraq en 1980. Pire, des enregistre
ments faciles et indétectables de communications pourront inciter des gouvernements à
surveiller les communications de nombreux de leurs citoyens, même ceux qui n’avaient
jamais essayé auparavant. Il n’y a pas de garantie que les démocraties libérales seront
insensibles à cette tentation.
Chapitre 5
Protocoles avancés
5.1 Preuves à divulgation nulle

Alice : « Je connais le mot de passe de l’ordinateur de la Réserve Fédérale
Américaine, la recette secrète de la sauce de McDonald et le contenu du
volume 4 de l’ouvrage de K n u t h . »
Bernard : « Non, tu ne les connais pas. »
Alice : « Si, je les connais. »
Bernard : « Que non ! »
Alice : « Mais si ! »
Bernard: « Prouve-le! »
Alice : « Bon, je vais tout te dire. » (Elle murmure à l’oreille de Bernard.)
Bernard: « C ’est intéressant. Maintenant, je sais aussi. Et je vais tout
raconter au Washington Post. »
Alice: « Aïe! »
Malheureusement, le moyen le plus simple pour Alice de prouver à Bernard qu’elle

connaît un secret est de lui dévoiler celui-ci. Mais alors, partageant le secret Bernard
peut ensuite le raconter à qui veut bien l’entendre et Alice n’y peut rien. (Dans la
littérature, d ’autres acteurs montent sur les planches pour ce genre de protocoles.
Patricia joue généralement le rôle du plaideur et Victor le rôle du vérificateur. Ces
noms sont utilisés dans les exemples à venir.)
En utilisant les fonctions à sens unique, Patricia peut effectuer une p reu v e à d iv u l
gation nulle [628]. Ce protocole démontre à Victor que Patricia a une information
mais il ne donne aucun moyen à Victor de déterminer quelle est cette information.
Ces preuves prennent la forme de protocoles interactifs. Victor pose à Patricia une série
de questions. Si Patricia connaît l’information, elle peut répondre à toutes les questions
correctement. Si elle ne la connaît pas, elle a 50 % de chances de répondre correctement.
Après une dizaine de questions ou plus, Victor sera convaincu que Patricia connaît
l’information. De plus, aucune des questions ou réponses ne donne à Victor le moindre
indice concernant l’information de Patricia — excepté le fait que Patricia la connaît.
110 Chapitre 5 Protocoles avancés
Preuve à divulgation nulle de base

Jean-Jacques Q u i s q u a t e r et Louis G u il l o u [1292] illustrent les preuves à divulgation
nulle à l’aide de l’histoire d ’une grotte. La grotte, illustrée à la figure 5.1, a un secret.
Celui qui connaît la formule magique peut ouvrir la porte entre C et D. Pour toute
autre personne, les deux tunnels mènent à un cul-de-sac.
F lG . 5.1 - Grotte à divulgation nulle
Patricia connaît le secret de la grotte. Elle veut le prouver à Victor mais elle ne veut
pas lui révéler la formule magique. Voici comment elle le convainc :
1° Victor se place au point A.

2° Patricia entre dans la grotte jusqu’au point C ou jusqu’au point D.
3° Après que Patricia a disparu dans la grotte, Victor va jusqu’au point B .
4° Victor crie à Patricia en lui demandant :
(a) soit de sortir par le tunnel de gauche ;

(b) soit de sortir par le tunnel de droite.
5° Patricia s ’exécute, en utilisant la formule magiquesi nécessaire.

6° Patricia et Victor répètent les étapes 1 à 5 unnombre n de fois.
Supposons que Victor filme tout ce qu’il voit avec une caméra. Il enregistre disparais
sant dans la cave, il enregistre le moment où il crie à Patricia par quel tunnel elle doit
sortir et il filme Patricia sortant. Il enregistre les n essais. En voyant ce film, Christine
serait-elle convaincue que Patricia connaît la formule magique? Non Victor et Patricia
auraient pu s’entendre à l’avance ce que Victor crierait et Patricia n’aurait eu qu’à
aller dans le bon tunnel. Elle serait ainsi toujours sortie du bon côté sans connaître
la formule magique. Us pourraient encore procéder autrement. Patricia va dans un des
5.1 Preuves à divulgation nulle 111
passages et Victor lui fait une requête aléatoire. Si Victor a demandé le bon passage,
tout va bien; sinon, ils coupent cette séquence du film final. De quelque manière que
ce soit, Victor peut obtenir un film avec exactement la même séquence d ’événements
que dans une preuve réelle où Patricia connaît la formule magique.
Cela prouve deux choses. Premièrement, Victor ne peut pas convaincre un troisième
parti de ta validité de la preuve. Deuxièmement, le protocole a une divulgation nulle.
Dans le cas où Patricia ne connaissait pas la formule magique, Victor n’apprendra
évidemment rien en regardant le film. Mais comme il n’y a pas de moyen de distinguer
un enregistrement réel d ’un faux, Victor ne peut rien apprendre de la preuve réelle,
elle a forcément une divulgation nulle.
La technique utilisée dans ce protocole est appelée « couper-et -choisir » à cause de sa
similitude avec le protocole classique pour diviser quelque chose équitablement :
1° Alice coupe en deux.

2° Bernard choisit une des moitiés pour lui-même.
3° Alice prend la moitié restante.
Il est dans l’intérêt d ’Alice de partager honnêtement à l’étape 1, car Bernard peut
choisir sa part à l’étape 2. Michael R a b i n est le premier à avoir utilisé la technique
« couper-et-choisir » en cryptographie [1293]. Les concepts de p r o to c o le in te ra ctif
et de divulgation nulle furent formalisés par la suite [628, 629].
La technique couper-et~choisir marche parce que Patricia ne peut pas deviner à coup
sûr le côté par lequel Victor lui demandera de sortir. Si elle ne connaît pas le secret,
elle ne peut ressortir que par où elle est entrée. Elle a 50 % de chance de deviner le
côté par lequel Victor lui demandera de sortir au tour suivant, elle a donc 50 % de
chance de pouvoir le duper. Les chances de pouvoir le duper en deux tours sont de
25 % et les chances de pouvoir le duper en n tours n fois sont de une sur 2n . Après
16 tours, Patricia a une chance sur 65 536 de duper Victor à chaque fois. Victor peut
raisonnablement conclure que si les 16 preuves de Patricia sont toutes valables, alors
elle doit connaître la formule magique pour ouvrir la porte entre C et D. (L’analogie
avec la grotte n’est pas parfaite. Patricia peut simplement prendre un des tunnels et
ressortir par l’autre ; la technique couper-et-choisir n ’est pas nécessaire. Toutefois, la
preuve mathématique en a besoin.)
Faites l’hypothèse que Patricia connaît une information et que cette information est la
solution d ’un problème très difficile. Le protocole de base consiste en plusieurs tours :
1° Patricia utilise son information et un nombre aléatoire pour transformer son

problème en un autre problème très difficile qui est isomorphe à la fonction
initiale. Elle utilise alors son information et le nombre aléatoire pour résoudre
le nouveau problème difficile.
2° Patricia met en gage la solution de ce nouveau problème à l’aide d’un protocole
de mise en gage quelconque.
3° Patricia dévoile à Victor le nouveau problème très difficile. Victor ne peut pas
utiliser ce nouveau problème pour déduire la moindre information concernant,
le problème initial ou sa solution.
4° Victor demande à Patricia :
(sl) soit de prouver que l ’ancien et le nouveau problèmes sont isomorphes,

(b) soitde dévoiler la solution mise en gage à l’étape 2, et de prouver que c ’est
bien une solution du nouveau problème.
5° Patricia s ’exécute.
6° Patricia et Victor effectuent les étapes 1 à 5 un nombre n de fois.
Vous souvenez-vous de la caméra dans l’épisode de la cave? On peut faire la même

chose ici. Victor peut transcrire tous ses échanges entre lui et Patricia. Il ne peut pas
utiliser la transcription pour convaincre Christine, car il peut s’entendre avec Patricia
pour construire une simulation qui maquille le savoir de Patricia. Cet argument prouve
que le protocole est à divulgation nulle.
Les mathématiques sous-jacentes à ce type de preuve sont compliquées. Les problèmes
et les transformations aléatoires doivent être choisis judicieusement de manière que
Victor n’obtienne pas la moindre information concernant la solution du problème ini
tial, même après plusieurs itérations du protocole. Tous les problèmes difficiles ne
peuvent pas être utilisés pour des preuves à divulgation nulle mais c ’est, le cas pour
nombre d ’entre eux.
Isomorphisme de graphes
Un exemple permettra de mieux illustrer ce concept. Celui-ci vient de la théorie des
graphes [621, 624]. Un graphe est un réseau de lignes connectant des points. Si deux
graphes sont identiques mis à part les noms des étiquettes, on dit qu’ils sont iso
m orph es. Pour des graphes extrêmements grands, il peut falloir des siècles de calcul
pour vérifier s’ils sont isomorphes; c ’est l’un des problèmes difficiles abordés au para
graphe 11.1.
Faites l’hypothèse que Patricia connaît l’isomorphisme entre deux graphes G i et GV
Le protocole suivant convainc Victor que Patricia connaît bien cet isomorphisme :
1° Patricia permute aléatoirement les nœuds de G\ pour obtenir un autre graphe.

H qui est isomorphe à G i. Comme Patricia connaît l’isomorphisme entre G\ et
H , elle connaît aussi l’isom.orphisme entre H et G'2 ■ Pour toute autre personne,
trouver l ’isomorphisme entre G'i et H ou entre G'2 et H , est aussi difficile que
de trouver l’isomorphisme entre G\ et G 2 -
2° Patricia envoie H à Victor.

3° Victor demande à Patricia:
{a) soit de lui prouver que G\ et H sont isomorphes ;

(b) soit de lui prouver que G 2 et H sont isomorphes.
4° Patricia s ’exécute :
{a) soit elle prouve que Gi et H sont isomorphes sans prouver que G 2 et H
sont isomorphes ;
( b ) soit elle prouve que G 2 et H sont isomorphes sans prouver que G i et H
sont isomorphes.
5° Patricia et Victor répètent les étapes 1 à f un nombre n de fois.

5.1 Preuves à divulgation nulle 11S
Si Patricia ne connaît pas l’isomorphisme entre G\ et G 2 , elle ne peut pas créer un

graphe H qui soit isomorphe aux deux autres. Elle peut alors uniquement créer un
graphe qui est isomorphe soit à G \, soit à G’2 mais pas aux deux. Comme dans l’exemple
précédent, elle n’a que 50 % de chance de deviner quelle épreuve Victor lui fera subir
à l’étape 4.
Le protocole ne donne aucune information utile à Victor pour l’aider à découvrir l’iso
morphisme entre G’i et G’2 . Comme Patricia engendre un nouveau graphe H à chaque
tour du protocole, il n’y a aucune information pour Victor, même après plusieurs
tours. 1 1 ne pourra pas découvrir l’isomorphisme entre Gi et G’2 à partir des réponses
de Patricia.
Victor reçoit une nouvelle permutation de H h chaque tour, ainsi que l’isomorphisme
entre H et G\ ou bien Gi- Victor pourrait aussi bien générer cela lui-même. Le fait
que Victor peut créer une simulation prouve que le protocole est à divulgation nulle.
Circuit hamiltonien
Une variante de cet exemple fut présentée pour la première fois par Manuel B l u m [133].
Patricia connaît un chemin fermé continu, suivant les lignes, et qui passe par tous les
points une fois et une seule. Un tel chemin est appelé circu it ham iltonien .
Trouver un tel chemin est un autre problème difficile. Patricia dispose de cette
information— qu’elle a certainement obtenue en construisant le graphe à partir d ’un
certain circuit hamiltonien— et elle veut convaincre Victor qu’elle connaît un tel che
min.
Patricia connaît le circuit hamiltonien du graphe G. Victor connaît G mais pas le
circuit hamiltonien. Patricia veut prouver qu’elle connaît ce circuit hamiltonien sans
le dévoiler. Voici comment le protocole se déroule :
1° Patricia permute aléatoirement le graphe G. Elle déplace les points et change

leurs étiquettes pour former un nouveau graphe, H . Comme G et H sont to-
pologiquement isomorphes (c’est-à-dire, des graphes identiques), si elle connaît
un circuit hamiltonien de G, elle peut alors facilement trouver un circuit hamil
tonien de H . Si elle n’avait pas créé H elle-même, déterminer l’isomorphisme
entre les deux graphes aurait été un problème autrement plus difficile ; cela peut
prendre des années de temps de calcul. Elle chiffre ensuite H et obtient H ' 1.
2° Patricia donne une copie de H ' à Victor.
3° Victor demande à Patricia :
(sl) soit de lui prouver que H ’ est le chiffrement d’un graphe isomorphe à G ;
(b ) soit de lui montrer un circuit hamiltonien de H .
4° Patricia s ’exécute :
(a) soit elle prouve que H ’ est le chiffrement d’un graphe isomorphe à G en
révélant la permutation et en déchiffrant tout, sans montrer un circuit
hamiltonien de G ou H ;
1. Cela doit être un chiffrement probabiliste de chaque ligne connectant deu x points de H , c ’est à
dire un 0 chiffré ou un 1 chiffré pou r chaque ligne dans H .
U4 Chapitre 5 Protocoles avancés
(b ) soit elle montre un cycle hamiltonien de H en ne déchiffrant que les lignes

constituant le circuit hamiltonien, sans prouver que G et H sont topolo-
giquement isomorphes.
5° Patricia et Victor effectuent les étapes 1 à 4 un nombre n de fois.
Si Patricia est honnête, elle peut produire la preuve à l’étape 3 à Victor. Toutefois, si
elle ne connaît pas un circuit hamiltonien de G, elle ne peut pas créer un graphe H qui
lui permette de relever les deux défis. Le mieux qu’elle puisse alors faire est soit de créer
un graphe isomorphe à G, soit de créer un graphe qui ait le même nombre de lignes et
de points avec un circuit hamiltonien correct. Comme elle a 50 % de chance de deviner
quelle épreuve Victor lui fera passer à l’étape 3, Victor peut répéter le protocole assez
de fois pour se convaincre que Patricia connaît un circuit hamiltonien de G.
Preuves à divulgation nulle en parallèle

Le protocole de base de preuve à divulgation nulle nécessite n échanges entre Patricia
et Victor. Pourquoi ne pas les faire tous en parallèle :
1° Patricia utilise son information et n nombres aléatoires pour transformer le

problème difficile en n problèmes isomorphes différents. Elle utilise ensuite son
information et les nombres aléatoires pour résoudre les n nouveaux problèmes
difficiles.
2° Patricia met en gage la solution aux n nouveaux problèmes.
3° Patricia dévoile les n nouveaux problèmes à Victor. Victor ne peut pas utili
ser ceux-ci pour obtenir de l’information concernant le problème initial ou sa
solution.
4° Pour chacun des nouveaux problèmes difficiles, Victor demande à Patricia :
(a ) soit de lui prouver que les nouveau et ancien problèmes sont isomorphes ;
(b) soitde lui montrer la solution qu’elle a mise en gage à l ’étape 2 et lui
prouver que c ’est une solution du nouveau problème.
5° Patricia s ’exécute pour chacun des nouveaux problèmes difficiles.
Malheureusement, ce n’est pas si simple. Ce protocole ne remplit pas les mêmes pro
priétés de divulgation nulle que le protocole précédent. A l’étape (4), Victor peut choisir
comme requêtes le résultat d ’une fonction de hachage à sens unique appliquée aux va
leurs mises en gages à la première étape, rendant ainsi la transcription non simulable.
Le protocole est toujours à divulgation nulle, mais d’une manière différente. Il a l’air
sût en pratique, mais personne ne sait comment le prouver. Nous savons que dans cer
taines circonstances, certains protocoles pour certains problèmes peuvent marcher en
parallèle en restant à divulgation nulle [251, 112, 548, 618].
Preuves à divulgation nulle non interactives

Christine ne peut pas être convaincue parce que le protocole est interactif et elle n’est
pas partie prenante du protocole. Pour convaincre Christine, et toute autre personne
qui serait intéressée, on a besoin d’un protocole non interactif.
5.1 Preuves à divulgation nulle 115
Des protocoles ont été inventés pour des preuves à divulgation nulle non interactives
[1380, 204, 1381, 207]. Ces protocoles ne nécessitent aucune interaction; Patricia peut
les publier et ainsi apporter la preuve à quiconque se donne la peine de la vérifier.
Le protocole de base est similaire à celui des preuves à divulgation nulle en parallèle,
mais une fonction à sens unique prend la place de Victor:
1° Patricia utilise son information et n nombres aléatoires pour transformer son

problème difficile en n problèmes isomorphes différents. Elle utilise ensuite son
information et les nombres aléatoires pour résoudre les n nouveaux problèmes
difficiles.
2° Patricia met en gage les solutions aux n nouveaux problèmes difficiles.
3° Patricia utilise toutes ces mises en gage comme entrée à une fonction de ha
chage à sens unique. Après tout, les mises en gage ne sont rien d’autre que des
suites de bits. Elle sauve alors les n premiers bits du résultat de sa fonction de
hachage à sens unique.
4° Patricia prend les n bits engendrés à l’étape S. Pour chaque ie nouveau pro
blème difficile — suivant que le ie bit vaut 0 ou 1 — elle exécutera l’une des
deux étapes suivantes :
(a.)s’il vaut 0 , elle prouve que l’ancien et le nouveau problèmes sont iso
morphes ;
(b ) s ’il vaut 1, elle dévoile la solution qu’elle a mise en gage à l’étape 2 et
prouve que c ’est une solution du nouveau problème.
5° Patricia publie toutes les mises en gage de l’étape 2 ainsi que les réponses de
l’étape 4-
6° Victor, Christine, ou toute autre personne intéressée, vérifie que les étapes 1 à
5 ont été exécutées correctement.
C’est étonnant : Patricia publie des données qui ne contiennent pas la moindre infor
mation sur son secret et pourtant ces données peuvent être utilisées pour convaincre
n’importe qui de l’existence du secret. On peut aussi utiliser le protocole pour des
schémas de signature numérique en appliquant la fonction de hachage à sens unique à
la fois aux messages initiaux et au message à signer.
Cela marche parce que la fonction de hachage à sens unique se comporte comme un
générateur aléatoire non biaisé de bits. Pour que Patricia puisse tricher, elle devrait
être capable de prédire le résultat de la fonction de hachage à sens unique. Rappelez-
vous que si elle ne connaît pas la solution du problème difficile, elle ne peut répondre
qu’à un des défis de l’étape 4 mais pas aux deux. Si elle arrivait à savoir d ’avance
ce que la fonction de hachage à sens unique donnera, elle pourrait tricher. Toutefois,
Patricia ne dispose d’aucun moyen pour forcer la fonction de hachage à sens unique
à produire certains bits, ou pour deviner ceux qui seront produits. La fonction à sens
unique remplace en fait Victor dans le protocole, en choisissant au hasard un des deux
défis à l’étape 4.
Pour un protocole non interactif, il doit y avoir bien plus d’itérations « défi-réponse ».
Patricia, et non Victor, choisit les problèmes difficiles à l’aide de nombres aléatoires.
Elle peut prendre différents problèmes, donc différents vecteurs de bits de mise en gage,
jusqu’à ce que le résultat de la fonction de hachage à sens unique lui convienne. Pour
le protocole interactif, 1 0 itérations sont suffisantes (cela donne une probabilité de 1
chance sur 2 10 = 1024 que Patricia puisse tricher). Pour le protocole non interactif ce
n’est pas suffisant. Rappelons que Martin peut toujours relever un des deux défis à
l’étape 4. Il peut essayer de deviner les défis qu’il devra relever à l’étape 4, effectuer
les étapes 1 à 3, et regarder s’il a bien deviné. Dans le cas contraire, il peut répéter
l’opération jusqu’à un coup de chance. Un ordinateur permet aisément de faire 1024
tentatives. Pour se prémunir de cette attaque exhaustive, les protocoles non interactifs
requièrent 64 itérations, ou même 128, pour être valables.
C ’est là tout l’intérêt d’utiliser une fonction de hachage à sens unique: Patricia ne peut
pas prédire la sortie de la fonction car elle ne peut pas prédire son entrée. Les mises en
gage utilisées en entrée ne sont connues qu’après avoir résolu les nouveaux problèmes.
Généralités
B l u m a prouvé que tout théorème mathématique peut être converti en un graphe tel
que la preuve du théorème est équivalente à un circuit hamiltonien. On trouvera dans
[623] une preuve du cas général statuant que tout problème NP admet une preuve à
divulgation nulle si l’on admet l’existence des fonctions de hachage à sens unique et donc
de bons algorithmes de chiffrement. De cette façon toute preuve mathématique peut
être convertie en une preuve à divulgation nulle. Grâce à cette technique, les chercheurs
peuvent prouver au monde entier qu’ils connaissent la preuve d’un théorème particulier
sans rien révéler de celle-ci. En effect, B l u m aurait pu publier ses résultats sans les
dévoiler.
On distingue aussi les preu ves à d iv u lg a tion m inim ale. Dans une preuve à divul
gation minimale, les propriétés suivantes sont vérifiés :
- Patricia ne peut pas tromper V ictor: si Patricia ne connaît pas la preuve, ses
chances de convaincre Victor sont négligeables.
Victor ne peut pas tromper Patricia. Il n’a pas le moindre indice concernant la
preuve, à part le fait que Patricia connaît la preuve. En particulier, Victor ne peut
faire la démonstration à personne sans d ’abord en faire la preuve par lui-même
à partir de zéro.
Pour les protocoles de preuve à divulgation nulle, une propriété supplémentaire doit
être vérifiée :
- Victor n’apprend rien de Patricia qu’il ne puisse apprendre par lui-même mis à
part le fait que Patricia connaît le secret.
Il y a une différence notable entre les preuves à divulgation minimale et les preuves à
divulgation nulle2. Ces concepts ont été présentés dans [628, 621, 624]. Des théories
plus poussées, basées sur des concepts mathématiques différents ont été développées
indépendamment dans [244, 323, 243].
2. C e sujet dépasse le cadre de ce livre mais le lecteur intéressé pou rra faire b o n usage de la
bibliographie à la fin de cet ouvrage.
5.2 Identification par preuve à divulgation nulle 117
Il y a de plus différentes sortes de preuves à divulgation nulle :
- P arfaite. Il existe un simulateur qui donne des transcriptions ayant la même

distribution que les transcriptions réelles3.
- P ro b a b iliste . Il existe un simulateur qui donne des transcriptions ayant la même

distribution que les transcriptions réelles, mis à part un nombre constant d ’ex
ceptions.
- C alcu la toire. Il existe un simulateur qui donne des transcriptions que l’on ne
peut distinguer des transcriptions réelles.
Un simulateur n’existe peut-être pas, mais on peut prouver que Victor

- In u tile .
n’apprendra jamais de la preuve une quantité polynomiale d ’information4.
Au fil des années, pas mal de recherches ont été effectuées, tant sur le plan théorique
que sur le plan pratique, sur les preuves à divulgation minimale et à divulgation nulle.
Mike B u r m e s t e r et Yvo D e s m e d t ont inventé les p r e u v e s i n t e r a c t i v e s d i f f u s é e s ,
où un plaideur peut diffuser une preuve interactive à divulgation nulle à un grand
groupe de vérificateurs [284]. Une horde de cryptographes a prouvé que tout ce qui
peut être prouvé par une preuve interactive peut l’être aussi à l’aide d ’une preuve
interactive à divulgation nulle [755, 122].
Un bon article général sur le sujet est [550]. Pour des détails mathématiques supplé
mentaires, des variantes, des protocoles et des applications consultez [592, 621, 244,
323, 623, 123, 245, 1536, 1561, 242, 593, 619, 511, 594, 217, 113, 219, 833, 104, 950,
624, 480, 617, 620, 218, 1379, 76]. On a écrit énormément sur le sujet.
5.2 Identification par preuve à divulgation

nulle
Dans le monde réel, nous utilisons des objets physiques pour prouver notre identité :
carte d’identité, passeport, permis de conduire, cartes de crédits, etc. Les documents
contiennent quelque chose qui les rattache à une personne : une photo, généralement,
mais ce pourrait tout aussi bien être une empreinte digitale, une empreinte rétinienne
ou une radiographie dentaire. Ne serait-ce pas intéressant de fane la même chose nu
mériquement?
L’utilisation des preuves à divulgation nulle comme preuve d ’identité fut proposée pour
la première fois par Uriel F e i g e , Amos F i a t et Adi S h a m i r [568, 569]. La clef privée
d’Alice devient fonction de son « identité ». Grâce à une preuve à divulgation nulle, elle
prouve qu’elle connaît sa clef privée et ainsi par la même occasion prouve son identité.
On trouvera des algorithmes dédiés à cela au paragraphe 23.11.
Cette idée est vraiment efficace. Elle permet aux gens de prouver leur identité sans
aucune évidence matérielle. Toutefois, ce n’est pas achevé. Voici quelques exemples
d’abus.
3. C ’est le cas des problèm es du circuit ham iltonien et de l’ isom orphism e de graphes.
4. C ’est le cas de la preuve en parallèle.
Le problème du grand maître aux échecs

Voici comment Alice, qui ne connaît même pas les règles du jeu d’échecs, peut vaincre
un grand maître. Elle décide d ’affronter Gary K A S P A R O V et Anatoly K a r p o v , en
même temps et au même endroit mais dans des pièces séparées. Elle joue les blancs
contre K a s p a r o v et les noirs contre K a r p o v Chaque grand maître ignore la présence
de l’autre.
K a r p o v , avec les blancs, joue son premier coup. Alice note le coup et va dans la
pièce o ù se trouve K a s p a r o v . Elle joue alors avec les blancs exactement ce coup-là.
K a s p a r o v joue ensuite son premier coup avec les noirs. Alice note le coup et va dans
la pièce où se trouve K a r p o v et joue le coup de K a s p a r o v contre K a r p o v . Cela
continue ainsi jusqu’à ce qu’elle gagne la partie contre l’un et perde contre l’autre (ou
encore qu’elle termine les deux parties sur un match nul).
En fait, K a s p a r o v joue contre K a r p o v , et Alice joue simplement le rôle d ’intermé
diaire entre les joueurs, imitant les coups d ’un grand maître sur l’échiquier de l’autre.
Toutefois si ni K a s p a r o v , ni K a r p o v n’est au courant de la présence de l’autre,
chacun sera bien surpris par la qualité de jeu d’Alice.
Ce type de supercherie peut être utilisé contre les identifications par preuve à divul
gation nulle [483, 130]. Pendant qu’Alice prouve son identité à Martin, celui-ci peut
prouver en même temps à Bernard qu’il est Alice.
La supercherie des mafiosi

Lors d ’une présentation des techniques d ’identification par preuve à divulgation nulle,
Adi S h a m i r dit [1419] : « Je pourrais aller à un magasin géré par la mafia un million
de fois et ils ne seraient toujours pas capables de se faire passer pour moi. »
Voici comment la mafia peut le faire. Alice mange au « Petit Bernard », un restaurant
géré par la mafia. Christine fait ses emplettes chez « David Dior », une bijouterie de
luxe. Bernard et Christine sont tous deux membres de la mafia et ils communiquent
par une liaison radio secrète. Alice et David ne sont au courant de rien.
A la fin du repas d ’Alice, quand elle s’apprête à payer et à prouver son identité à
Bernard, celui-ci signale à Christine que la supercherie peut commencer. Christine
achète quelques diamants très chers et s’apprête à prouver son identité à David. Ensuite,
pendant qu’Alice prouve son identité à Bernard, celui-ci transmet par radio l’informa
tion à Christine et Christine effectue le même protocole avec David. Quand David
pose une question lors du protocole, Christine transmet la question à Bernard qui de
mande à Alice. Quand Alice répond, Bernard transmet la bonne réponse à Christine.
De fait, Alice ne fait que prouver son identité à David. Bernard et Christine ne font que
s’interposer dans le protocole et font transiter les messages de l’un à l’autre. Quand
le protocole se termine, Alice a prétendument acheté des diamants très chers (avec
lesquels Christine disparaît dans la nature).
La supercherie des terroristes

Si Alice est prête à collaborer avec Christine, elles peuvent aussi duper David. Dans
ce protocole, Christine est une terroriste réputée. Alice l’aide à entrer dans le pays.
David est l’officier d ’immigration. Alice et Christine sont connectées par une liaison
radio secrète.
5.2 Identification par preuve à divulgation nulle 119
Quand David pose des questions à Christine dans le cadre du protocole de preuve
à divulgation nulle, Christine les relaie par radio à Alice, qui y répond elle-même.
Christine donne ces réponses-là à David. En réalité, Alice prouve son identité à David,
avec Christine faisant l’office de voie de communication. Quand le protocole se termine,
David pense que Christine est Alice et la laisse entrer dans le pays. Trois jours plus
tard, Christine commet un acte terroriste.
Propositions de solutions
Les supercheries des mafiosi et des terroristes sont toutes deux réalisables parce que
les conspirateurs communiquent par une liaison radio secrète. Un moyen d’éviter ces
fraudes consisterait à exiger que toutes les identifications aient lieu dans une cage
de Faraday, qui bloque toutes les émissions électromagnétiques. Dans l’exemple des
terroristes, cela garantirait à David que Christine ne reçoit pas ses réponses d’Alice.
Dans l’exemple des mafiosi, Bernard pourrait construire une fausse cage de Faraday
dans son restaurant mais le bijoutier David en aurait une vraie : Bernard et Christine ne
pourraient pas communiquer. Pour résoudre le problème du grand maître aux échecs,
il faudrait, obliger Alice à reter assise jusqu’à la fin de la partie.
Thomas B e t h et Y vo D e s m e d t proposent une autre solution qui utilise des horloges
précises [155]. Si chaque étape du protocole doit se dérouler à un instant donné précis,
les conspirateurs n’auront pas de temps pour communiquer. Dans le cas de l’histoire des
grands maîtres aux échecs, si chaque coup doit être joué quand l’aiguille des secondes
passe par 0, alors Alice n’aura pas le temps de courir d ’une pièce à l’autre. Bernard et
Christine n’auront pas le temps de se passer les questions et les réponses.
La supercherie aux identités multiples
Il existe d’autres moyens de violer les preuves à divulgation nulle, décrits également
dans [483, 130]. Dans certaines réalisations, l’identité de ceux qui enregistrent une clef
publique n’est pas contrôlée. Ainsi, Alice peut avoir plusieurs clefs privées et donc
plusieurs identités. Cela peut être très utile si elle a l’intention de frauder le fisc. Alice
peut aussi commettre un crime et disparaître. Tout d ’abord, elle crée et publie plusieurs
identités. Elle n’utilise pas l’une d ’entre elles. Ensuite, elle se sert de cette identité-là
une fois et commet un crime de manière que celui qui l’a identifiée soit le témoin. Le
témoin connaît l’identité de la personne qui a commis le crime, mais Alice ne se sert
plus jamais de cette identité — on ne pourra pas retrouver sa trace.
Pour éviter cela, il devrait exister une technique qui empêche chaque personne d’avoir
plus d’une identité. Dans [130], les auteurs suggèrent l’idée « terrifiante » de bébés
« infalsifiables » qui ne peuvent pas être clonés et qui ont un numéro unique gravé dans
leur code génétique. Ils suggèrent aussi que chaque bébé devrait requérir une identité à
sa naissance (de fait, ce serait les parents qui devraient faire les démarches car les bébés
ont d’autres préoccupations). Il est facile de tricher dans ce cas : les parents pourraient
requérir plusieurs identités à la naissance de l’enfant. A la fin, le caractère unique d ’un
individu serait basé sur la confiance.
Le prêt de passeports
Alice veut aller en Argentine, mais le Gouvernement refuse de lui donner un visa.
Christine propose de louer son identité à Alice (Bernard s’était proposé en premier
mais cela posait des problèmes évidents). Christine vend sa clef privée à Alice et Alice
part en Argentine prétendant être Christine.
Non seulement Christine a été payée pour son identité mais encore elle dispose main
tenant d ’un alibi parfait. Elle commet un crime pendant qu’Alice est en Argentine.
« Christine » a prouvé son identité en Argentine : comment pourrait-elle commettre un
crime chez elle?
Bien sûr, Alice est libre de commettre des crimes également. Elle les commet avant son
départ ou après son retour, de préférence près du domicile de Christine. D ’abord, elle
s’identifie comme Christine (elle a la clef privée de Christine, c ’est donc facile pour elle),
ensuite elle commet un crime et s’enfuit. La police vient alors appréhender Christine.
Christine prétendra qu’elle a loué son identité à Alice mais qui pourrait croire une
histoire aussi insensée?
Le problème est qu’Alice ne prouve pas effectivement son identité, elle prouve qu’elle
possède une information secrète. C ’est le lien entre cette information et la personne
qui est faussé. La solution des bébés « infalsifiables » éviterait ce genre de fraudes, de
même qu’un état policier dans lequel chaque citoyen devrait très fréquemment prouver
son identité (à la fin de chaque jour, à chaque coin de rue, etc.). Les méthodes de
biométrie— empreintes digitales, images rétiniennes, empreintes vocales, et ainsi de
suite—peuvent aider à résoudre le problème.
Preuve d’appartenance à un groupe

Alice veut prouver à Bernard qu’elle est membre d’une organisation super secrète, mais
elle ne veut pas révéler son identité. Ce problème est proche de celui de prouver son
identité et a été étudié [887, 907, 908, 1210, 1451]. Certaines solutions sont reliées au
problème des signal;ures collectives (voir § 4.6).
5.3 Signatures en aveugle

Une caractéristique essentielle des protocoles de signature numérique est que le signa
taire d ’un document sait toujours ce qu’il signe. C ’est très bien, sauf que nous voulons
l’inverse.
Il y a des situations où nous voulons que des gens signent un document sans jamais
en voir le contenu. Ce n ’est pas un protocole très utile en tant que tel, mais nous
l’utiliserons plus tard pour réaliser des protocoles de vote et de paiement numérique. Il
y a moyen pour le signataire de « presque » savoir ce qu’il signe, sans savoir exactement.
Mais commençons par le début.
Signatures en aveugle total

Bernard est notaire. Alice veut qu’il signe un document mais elle ne veut pas qu’il ait
la moindre idée de ce qu’il signe. Bernard ne s’intéresse pas au contenu du document,,
5.3 Signatures en aveugle 121
il ne fait que certifier que le document a été enregistré devant notaire à une certaine
date. Voilà ce à quoi il consent :
1° Alice prend le document et le multiplie par une valeur aléatoire. Cette valeur
aléatoire est appelée f a c t e u r d e c a m o u f l a g e .
2° Alice envoie le document camouflé à Bernard.
3° Bernard signe le document camouflé.
4° Alice divise par le facteur de camouflage, retrouvant ainsi le document original
signé par Bernard.
Ce protocole ne marche que si la fonction de signature et la fonction de multiplication

sont commutatives. Si ce n’est pas le cas, il y a moyen de modifier le document au
trement qu’en utilisant la multiplication. Les algorithmes mathématiques utiles sont
présentés dans le paragraphe 23.12. Pour le moment, faites l’hypothèse que c’est une
multiplication et que les mathématiques sont au point.
Bernard peut-il tricher? Peut-il acquérir de l’information concernant le document qu’il
signe? Si le facteur de camouflage est vraiment, aléatoire, il ne peut pas. Le document
camouflé que Bernard signe à l’étape 2 ne ressemble en rien au document original
d’Alice. Le document camouflé avec la signature de Bernard à l’étape 3 ne ressemble
en rien au document signé à la fin de l’étape 4. Même si Bernard met la main sur le do
cument avec sa signature après l’accomplissement du protocole, il ne peut pas prouver
(à lui-même ou à toute autre personne) qu’il l’a signé dans le cadre de ce protocole-là.
Il sait que sa signature est valide. Il sait qu’il (ou quelqu’un d ’autre avec sa clef pri
vée) a signé ce document ; il peut, comme n’importe qui d’autre, vérifier la signature.
Toutefois, il ne dispose d ’aucun moyen de corréler la moindre information qu’il a reçue
durant le protocole avec le document signé. S’il signe un million de documents avec ce
protocole, il n’a toujours pas de moyen de savoir dans quel cas il a signé tel document.
Les propriétés des signatures en aveugle total sont :
- La signature de Bernard sur le document est valide. La signature sert de preuve

que Bernard a signé le document. Bernard sera convaincu qu’il a signé le docu
ment. quand on le lui montrera. Les propriétés des signatures numériques présen
tées au paragraphe 2 . 6 sont aussi valables.
- Bernard ne peut pas faire le lien entre un document signé et l’acte de signature
du document Même s’il garde une trace de toutes les signatures en aveugle qu’il
a effectuées, il ne peut pas déterminer quand il a signé un document donné.
Estelle, assise entre les deux, qui écoute tout le protocole, en sait, encore moins que
Bernard.
Signatures en aveugle
Avec le protocole de signature en aveugle total, Alice peut faire signer n’importe quoi
par Bernard : « Bernard doit un million de francs à Alice », « Bernard est le père du
premier-né d’Alice », « Bernard doit un sachet de dragées à Alice ». Les possibilités
sont infinies. Nul besoin d’insister, ce protocole n’est pas particulièrement utile.
Il existe toutefois un moyen pour Bernard de savoir ce qu’il signe, tout en maintenant
les propriétés intéressantes de la signature en aveugle. Le cœur de ce protocole est la
technique du « couper-et-choisir ». Considérons un exemple. De nombreuses personnes

entrent dans le pays chaque jour et les services des douanes veulent s’assurer qu’elles
ne font pas la contrebande de cocaïne. Les officiels peuvent fouiller tout le monde
mais ils utilisent plutôt une solution probabiliste. Ils fouillent une personne sur dix
qui entrent. Une personne sur dix voit ses effets personnels fouillés ; les neuf autres
personnes passent sans autre formalité. Les contrebandiers chroniques échapperont au
contrôle la plupart du temps mais ils ont 10 % de chance d’être attrapés. Et si le
système pénal est efficace, la sanction pour avoir été pris une fois dépassera largement
le gain des neuf autres fois.
Si le service des douanes veut augmenter ses chances d ’attraper les contrebandiers, ils
doivent fouiller plus de personnes. S’ils veulent diminuer leur chance, ils diminuent le
nombre de personnes fouillées. En manipulant les probabilités, ils contrôlent l’efficadté
du protocole pour attraper les contrebandiers.
Le protocole de signature en aveugle utilise une méthode similaire. Bernard reçoit une
grande pile de documents reliés. Il les o u v r e (i.e. les examine) tous sauf un et signe ce
dernier.
Imaginez que les documents camouflés sont dans des enveloppes. Le procédé de ca
mouflage consiste à mettre le document dans une enveloppe. Le procédé de retrait du
facteur de camouflage consiste à ouvrir l’enveloppe. Quand le document est dans l’en
veloppe, personne ne peut le lire. Le document est signé grâce à une feuille de carbone
dans l’enveloppe. Quand les signataires signent l’enveloppe, leurs signatures passent à
travers la feuille de carbone et sont ainsi transférées sur le document.
Le scénario suivant implique un groupe d’agents du contre-espionnage. Leur identité
est secrète : même l’agence de contre-espionnage ne sait pas qui ils sont. Le directeur
de l’agence veut donner à chaque agent un document signé attestant : « Le porteur de
la présente signée (insérer le nom d’emprunt, de l’agent ici) bénéficie de l’immunité
diplomatique totale. » Chaque agent a sa propre liste de noms d’emprunt donc l’agence
ne peut pas simplement distribuer des documents signés. Les agents ne veulent pas
envoyer leur nom d ’emprunt à l’agence: l’ennemi peut avoir investi l’ordinateur de
l’agence. En outre, l’agence ne veut pas signer en aveugle n’importe quel document que
lui donne l’agent Un agent malin pourrait soumettre un message tel que: « L ’agent
(nom) est retraité et a droit à une pension d’un million de francs par an. Signé:
Monsieur le Président. » Dans ce cas un protocole de signature en aveugle est utile.
Faisons l’hypothèse que chaque agent a n noms d ’emprunt possibles, qu’il a choisi lui-
même et que personne d ’autre ne connaît. Supposons également qu’il importe peu aux
agents sous quel nom d’emprunt ils obtiennent l’immunité diplomatique. Enfin admet
tons que l’ordinateur de l’agence s’appelle « Ordinateur Secret Central de l ’Agence de
Renseignements » (O S C A R en d’autres termes).
1° L ’agent Bernard prépare n documents, chacun utilisant un nom d’emprunt dif

férent, garantissant à cet agent l’immunité diplomatique.
2° Bernard camoufle chacun des documents avec un facteur de camouflage diffé

rent.
3° Bernard envoie les n documents camouflés à OSCAR.
4° OSCAR choisit n — 1 documents au hasard et demande à Bernard le facteur

de camouflage pour chacun de ces neuf messages.
5-4 Cryptographie à clef publique à base d’identification 123
5° Bernard envoie les bons facteurs de camouflage à OSCAR.
6° OSCAR retire le facteur de camouflage des n — 1 documents et s ’assure qu’ils

sont corrects.
7° OSCAR signe le n e document et l’envoie à Bernard.
8° Bernard retire le facteur de camouflage et lit son nouveau nom d’emprunt:

« Le Grand Blond avec une Chaussure Noire. » Le document signé lui procure
l’immunité diplomatique totale sous ce nom.
Ce protocole résiste aux tricheries éventuelles de Bernard. Pour tricher, il devrait pré
dire de façon sûre quel document OSCAR n’examinera pas. Ses chances sont de 1
sur n : pas très bonnes. OSCAR sait cela aussi et il est confiant quand il signe le ne
document : celui qu’il n’a pas pu examiner. Avec ce document-là, le protocole est le
même que le protocole précédent de signature en aveugle total, et il préserve toutes les
propriétés d ’anonymat.
Il est possible de rendre les chances pour Bernard de tricher avec succès aussi petites
que nécessaires. A l’étape 4, OSCAR choisit au hasard n /2 documents et Bernard lui
envoie les bons facteurs de camouflage correspondants à l’étape 5. À l’étape 7, OSCAR
multiplie ensembles les documents restants et signe le tout. À l’étape 8 , Bernard re
tire les facteurs de camouflage. La signature d’ OSCAR n’est valable que si les n /2
documents signés étaient identiques. Pour tricher, Bernard doit deviner quel est le
sous-ensemble qu’OSCAR va choisir; ses chances de réussite sont bien moindre que
lorsqu’il essaye de deviner le document qu’OSCAR n’examinera pas.
Il y a un autre moyen pour Bernard de tricher. Il peut engendrer deux documents
différents: un qu’OSCAR serait prêt à signer et un autre non. Ensuite, il trouve deux
facteurs de camouflage tels que l’un appliqué au premier document et l’autre au se
cond donnent le même document camouflé. De cette façon, si OSCAR demande à
examiner le document, Bernard lui donne le facteur de camouflage qui le transforme
en un document anodin. Si OSCAR ne demande pas à voir le document et le signe,
Bernard utilise le facteur de camouflage qui transforme le document camouflé en do
cument malveillant. Bien que cela soit théoriquement possible, les mathématiques des
algorithmes particuliers utilisés pour ce protocole, rendent les chances de Bernard de
trouver une telle paire de facteurs infiniment faibles. Nous en reparlons plus en détail
dans le paragraphe 23.12.
Brevets
C h a u m a posé des brevets sur différents types de signatures en aveugle (voir le ta
bleau 5.1).
5.4 Cryptographie à clef publique à base

d’identification
Alice veut envoyer un message confidentiel à Bernard. Elle ne veut se procurer sa clef
publique dans un serveur de clefs; elle ne veut pas avoir à vérifier la signature d ’un
troisième parti de confiance avec le certificat de sa clef publique; et elle ne veut même
T ab . 5.1 - Les brevets de signature numérique posés par Chaum
Numéro Date Titre

4 759 063 19/7/88 Systèmes de signature en aveugle [324]
4 759 064 19/7/88 Systèmes de signature en aveugle sans anticipation [325]
4 914 698 3 /3 /9 0 Systèmes de signature en aveugle avec aperçu [329]
4 949 380 14/8/90 Systèmes de signature en aveugle avec retour de valeur [331]
4 991 210 5/2/91 Systèmes de signature en aveugle imprévisible [334]
pas enregistrer la clef publique de Bernard sur son propre ordinateur. Elle veut juste
lui envoyer un message confidentiel.
Les c r y p t o s y s t è m e s à b a s e d ’ i d e n t i f i c a t i o n 5 permettent de résoudre ce problème
[1429]. La clef publique de Bernard est basée sur son nom et son addresse électronique
(ou encore son numéro de téléphone, ou son addresse en ville, ou quoi que ce soit
d’autre). Avec la cryptographie à clef publique classique, Alice a besoin d ’un certificat
signé numériquement qui lie l’identité de Bernard à sa clef publique. Avec la cryptogra
phie à clef publique à base d ’identification, la clef publique de Bernard est son identité.
C ’est une idée vraiment séduisante, l’idée idéale dont on peut rêver pour un système
de courrier électronique: si Alice connaît l’addresse de Bernard, elle peut lui envoyer
du courrier en toute sécurité. Cela rend la cryptographie aussi transparente qu’il est
possible.
Le sytème est fondé sur Ivan qui fournit des clefs privées basées sur l’identité. Si jamais
la clef d’Alice est compromise, elle doit changer un aspect de son identité pour avoir
une autre clef. Le problème le plus sérieux est d ’élaborer un système qui ne laisse pas
la possibilité à des utilisateurs malhonnêtes de s’unir pour créer une clef.
Une grande part de travail a été faite sur les mathématiques sous-jacentes— la plupart
au Japon— qui s’avèrent affreusement compliquées quand il s’agit de rendre le sytème
sûr. De nombreuses solutions parmi celles proposées impliquent que Ivan choisisse un
nombre aléatoire pour chaque utilisateur— ce qui à mon avis vient à l’encontre de l’idée
même du système. Certains algorithmes décrits aux chapitres 19 et 20 peuvent s’utiliser
à base d ’identification. Pour les détails algorithmiques et cryptographiques, se reporter
à [198, 1429, 891, 1030, 1519, 1224, 1205, 909, 693, 675, 1138, 1031, 1520, 1544, 1552,
6 8 , 1218, 318, 319, 1553, 1547, 1551, 944, 1521, 750, 1238]. On trouvera un algorithme
qui ne repose pas sur des nombres aléatoires dans [1043]. Le système introduit dans
[1554, 1555, 1511] résiste aux attaques à clefs publiques choisies, de même que celui
présenté dans [1550, 1548, 1549, 1003, 378, 1546]. Honnêtement, rien de ce qui a été
proposé jusqu’à présent n’est à la fois réalisable et sûr.
5.5 Transfert inconscient

Le cryptographe Bernard essaie désespérément de factoriser un nombre n de 500 bits.
Il sait que celui-ci est le produit de 5 nombres de 100 bits mais il n’en sait pas plus.
(C ’est un problème sérieux pour Bernard. S’il ne peut pas retrouver la clef, il devra
5. Ces cryptosystèm es sont aussi qualifiés de systèmes sans partage interactif de clef.
5.5 Transfert inconscient 125
faire des heures supplémentaires et il va rater son poker à l’aveugle hebdomadaire avec
Alice.)
Alice passe alors par là :
« Il se trouve que je connais un facteur du nombre » dit Alice, « et je te le

donnerai pour cent francs. Cela fait un franc le bit. » Pour montrer qu’elle
est sérieuse, elle utilise un schéma de mise en gage de bits et met en gage
chaque bit individuellement.
Bernard est intéressé, mais il n’a que 50 francs. Alice n’est pas prête à
abaisser son prix et elle propose de vendre à Bernard la moitié des bits
pour la moitié du prix. « Cela t ’évitera pas mal de boulot », dit-elle.
« Mais comment puis-je être sûr que ton nombre est bien un facteur de
n ? Si tu me montres le nombre et que tu me laisses vérifier que c ’est un
facteur, alors je serai d’accord avec tes conditions », dit Bernard.
Alice n’a pas l’intention de le suivre dans cette voie, ils sont donc dans
une impasse. Alice ne peut pas convaincre Bernard que son nombre est un
facteur de n sans le révéler et Bernard n’est pas prêt à payer 50 bits d’un
nombre qui pourrait bien lui être inutile.
Cette histoire empruntée à Joe K i l i a n [832], introduit le concept de t r a n s f e r t i n

Alice transmet un groupe de messages à Bernard. Bernard reçoit un sous-
c o n s c ie n t .
ensemble de ces messages, mais Alice ignore quels sont ceux qu’il reçoit. Cependant,
cela ne résout pas tout à fait le problème précédent. Après que Bernard a reçu une
moitié aléatoire des bits, Alice doit encore le convaincre que les bits qu’elle envoie
constituent un facteur de n en utilisant une preuve à divulgation nulle.
Dans le protocole suivant, Alice va envoyer à Bernard un des deux messages. Bernard
en recevra un et Alice ne saura pas lequel.
1 ° Alice engendre deux paires « clef publique clef privée », soit 4 clefs au total.
Elle envoie les deux clefs publiques à Bernard.
2° Bernard choisit une clef pour un algorithme à clef secrète (le DES par
exemple). Il choisit une des clefs publiques d’Alice aléatoirement et chiffre sa
clef DES avec cette dernière. Il envoie la clef chiffrée à Alice sans lui dire
quelle clef publique il a utilisée pour la chiffrer.
3° Alice déchiffre la clef de Bernard avec ses deux clefs privées. Dans un des cas
elle utilise la bonne clef et déchiffre avec succès la clef DES de Bernard. Dans
l’autre cas, elle utilise la mauvaise clef et n’engendre rien d’autre qu’une suite
de bits sans sens qui néanmoins n’en ressemble pas moins à une clef DES
quelconque. Comme elle ne connaît pas le texte en clair correct, elle ignore
quoi est quoi.
4° Alice chiffre ses deux messages chacun avec une des deux clefs DES qu’elle a
engendré à l’étape précédente (une vraie et une sans sens) et envoie les deux
résultats à Bernard.
5° Bernard reçoit l’un des messages d’Alice chiffré avec la bonne clef DES et
l’autre message avec une clef factice. Bernard utilise sa clef DES pour déchiffrer
les deux messages d’Alice mais il ne peut lire avec succès que l’un d’entre eux.
À ce point, le transfert inconscient est terminé. Bernard a pu lire un des deux messages
(celui chiffré avec sa clef DES) et Alice n’a aucun moyen de savoir lequel. Une étape
supplémentaire est nécessaire pour qu’Alice ne puisse pas tricher.
1 ° Après avoir terminé le protocole et quand les deux résultats possibles du trans
fert sont connus, Alice doit donner à Bernard ses clefs privées afin qu ’il puisse
vérifier qu’elle n’a pas triché. Après tout, elle pourrait avoir chiffré le même
message avec les deux clefs à l’étape 4-
Dès lors, Bernard peut resconstituer le second message.

Ce protocole résiste à une attaque d ’Alice car elle n ’a aucun moyen de savoir quelle est
la bonne clef DES parmi les deux qu’elle a calculées. Le protocole résiste à une attaque
de Bernard, car avant que le protocole ne soit terminé, il n’a aucun moyen d ’avoir les
clefs privées d’Alice donc il ne peut pas calculer l’autre clef DES qui a été utilisée pour
chiffrer l’autre message (celui des deux qu’il n’a pas pu lire). On pourrait penser que
ce n’est qu’une méthode plus compliquée pour tirer à pile ou face par modem, mais ce
protocole a des implications profondes quand il est utilisé au sein de protocoles plus
compliqués.
Bien sûr, rien n ’empêche Alice d ’envoyer deux messages totalement dénués de senr :
« Gna, Gna » et « Cornichon ». Ce protocole garantit qu’Alice envoie à Bernard un des
deux messages; il ne fait rien pour garantir que Bernard désire recevoir l’un d’entre
eux.
Il existe d ’autres protocoles de transfert inconscient décrits dans la littérature. Certains
d ’entre eux sont non interactifs, ce qui signifie qu’Alice peut publier ses deux messages
et que Bernard ne peut comprendre qu’un des deux. Il peut le faire lui-même, il n’a
pas besoin de communiquer avec Alice pour cela [111]. Nombre de protocoles de ce
chapitre utilisent le protocole de transfert inconscient.
Personne n’a besoin de transfert inconscient en pratique, mais la notion est une brique
élémentaire importante pour construire des protocoles plus compliqués. Cependant il y
a plusieurs sortes de transfert inconscient: j ’ai deux secrets et vous en obtenez un, j ’ai
n secret et vous en obtenez un, j ’ai un secret et vous l’obtenez qvec probabilité 1 / 2 , et
ainsi de suite. Toutes les variantes sont équivalentes [250, 395, 399].
5.6 Signatures inconscientes

Honnêtement, je ne connais pas d’application pour cela, il en existe deux variantes
[350] :
1 . Alice possède n messages différents. Bernard peut choisir un des n messages pour
qu’Alice le signe, et Alice n ’aura aucun moyen de savoir quel message elle a signé.
2 . Alice possède un message. Bernard peut choisir une clef parmi n avec laquelle Alice
va signer le message, et Alice ne pourra pas déterminer la clef elle aura utilisé.
C ’est une idée intéressante, je suis sûr qu’elle a son utilité quelque part.
5.7 Signature simultanée de contrat 127
5.7 Signature simultanée de contrat

Signature de contrat avec un arbitre
Alice et Bernard veulent conclure un contrat. Ils se sont mis d’accord sur les termes du
contrat mais aucun des deux ne veut signer sans que l’autre signe aussi. Face à face,
c’est facile : ils signent ensemble. A distance, ils peuvent utiliser un arbitre.
1 ° Alice signe mie copie du contrat et envoie le résultat à Ivan.

2° Bernard signe une copie du contrat et envoie le résultat à Ivan.
3° Ivan envoie un message à Alice et à Bernard indiquant à chacun que l’autre a
signé le contrat.
4° Alice signe deux copies du contrat et les envoie à Bernard.
5° Bernard signe les deux copies du contrat et envoie une copie à Alice et en garde
une pour lui-même.
6° Alice et Bernard informent Ivan qu’ils ont chacun une copie du contrat signée
par eux deux.
7° Ivan déchire les deux copies de contrat chacun avec une seule signature.
Le protocole marche parce qu’Ivan empêche les deux parties de tricher. Si Bernard
refusait de signer le contrat à l’étape 5, Alice pourrait demander à Ivan la copie du
contrat déjà signée par Bernard. Si Alice refusait de signer à l’étape 4, Bernard pourrait
faire de même. Quand Ivan indique qu’il a reçu les deux contrats à l’étape 3, Alice et
Bernard savent tous deux qu’ils sont liés par le contrat. Si Ivan ne reçoit pas les deux
contrats, il déchiffre celui qu’il a reçu et aucune partie n’est liée.
Signature simultanée de contrat sans arbitre (face à face)

Si Alice et Bernard étaient assis face à face, ils pourraient signer le contrat de la manière
suivante [1254] :
1° Alice signe avec la première lettre de son nom et passe le contrat à Bernard.
2° Bernard signe avec la première lettre de son nom et passe le contrat à Alice.
3° Alice signe avec la deuxième lettre de son nom et passe le contrat à Bernard.
4° Bernard signe avec la deuxième lettre de son nom et passe le contrat à Alice.
5° Cela continue ainsi jusqu’à ce qu’Alice et Bernard aient tous deux signé avec
leurs noms en entier.
Si vous ignorez le défaut évident de ce protocole (Bernard a un nom plus long qu’Alice),
cela marchera. Après avoir signé avec une seule lettre, Alice sait qu’aucun juge ne la
considérera comme liée par les termes du contrat. Mais cette lettre est un acte de bonne
volonté et Bernard répond avec un acte similaire de bonne volonté.
Après que chaque participant a signé avec quelques lettres, un juge sera certainement
convaincu que les deux parties ont signé le contrat. Toutefois, les détails sont obscurs.
Sûrement qu’ils ne sont pas liés après la première lettre ; mais ils le sont certainement
dès qu’ils ont signé leur nom entier. A quel point du protocole deviennent-ils liés?
Après avoir signé avec la moitié de leurs noms? Les deux tiers de leurs noms? Les trois
quarts?
Comme ni Alice ni Bernard ne sont certains de l’instant à partir duquel ils sont liés,
ils craignent un peu, à chaque instant, d ’être liés. Cela n’a pas de sens pour Bernard
de dire : « Tu as signé avec quatre lettres et moi je n’ai signé qu’avec trois lettres. Tu
es liée et moi pas. » Il n’y a pas de raison que Bernard ne continue pas le protocole.
Plus longtemps ils continuent, plus grande est la probabilité qu’un juge les considèrent
comme liés. Une fois de plus, il n ’y a aucune raison de ne pas continuer le protocole.
Après tout, ils voulaient tous deux signer le contrat ; ils ne voulaient simplement pas
signer l’un avant l’autre.
Signature simultanée de contrat sans arbitre ( à distance)

Ce protocole exploite le même type d’incertitude [120]. Alice et Bernard alternent les
petits pas vers un contrat signé jusqu’à ce qu’ils aient tous deux signé.
Dans ce protocole, Alice et Bernard échangent une série de messages signés de la forme :
« J’accepte de me considérer comme lié(e) au contrat avec une probabilité p. »
Celui qui reçoit un tel message peut le montrer à un juge et, avec une probabilité p, le
juge considérera le contrat comme signé.
1 ° Alice et Bernard conviennent d’une date à laquelle le protocole de signature

devra être terminé.
2° Alice et Bernard décident d’une différence de probabilités à utiliser. Par

exemple, Alice peut décider qu’elle ne veut pas être liée avec une probabilité
de 2 % supérieure à la probabilité de Bernard. Appelons A la différence de
probabilité d’Alice et B celle de Bernard.
3° Alice envoie un message à Bernard avec p = A.

4° Bernard envoie un message à Alice avec p = A + B .
5° Soit p' la probabilité du message qu’Alice a reçu de Bernard à l’étape précédente.
Alice envoie à Bernard un message signé avec le minimum de p = p' + A ou
p =l.
6 ° Soit p' la probabilité du message que Bernard a reçu d ’Alice à l’étape précédente.
Bernard envoie à Alice un message signé avec le minimum de p = p' + B ou
p= 1.
7° Alice et Bernard continuent à alterner les étapes 5 et 6 jusqu’àce qu’ilsaient

tous deux reçu le message avec p = 1 , ou jusqu’à ce queladate convenue à
l’étape 1 soit dépassée.
Tout au long du déroulement du protocole, Alice et Bernard consentent à être liés par
le contrat avec une probabilité de plus en plus grande. Par exemple, le premier message
d’Alice pourrait indiquer qu’elle se considère comme liée avec une probabilité de 2 %.
Bernard pourrait répondre qu’il est lié avec une probabilité de 3 %. Le message suivant
d’Alice pourrait indiquer qu’elle est liée avec une probabilité de 4 %, et ainsi de suite
jusqu’à ce qu’ils soient liés avec une probabilité de 1 0 0 %.
Si Alice et Bernard terminent tous deux le protocole, tout va bien. Si la date d’échéance
du protocole arrive, chaque participant peut montrer le contrat à un juge avec le dernier
5.7 Signature simultanée de contrat 129
message signé de l’autre participant. Le juge choisit simplement une valeur aléatoire
entre 0 et 1. Si la valeur est inférieure à la probabilité que l’autre participant a signé,
alors les parties sont liées. Si la valeur est plus grande que la probabilité, alors les
parties ne sont pas liées6. C ’est cela que l’on entend par être lié au contrat avec une
probabilité p.
C’est le protocole de base, mais il peut y avoir d ’autres complications. Si Alice com
mence à signer des messages avec des incréments de plus en plus faibles de probabilité,
Bernard peut répondre dans le même sens. Le juge peut trancher en l’absence d’un
des participants. La décision du juge lie soit les deux parties, soit aucune ; il n’y a pas
de situations où l’une des parties est liée et l’autre pas. Aussi longtemps que l’une des
parties est disposée à avoir une probabilité légèrement supérieure d ’être liée à l’autre
(peut importe la petitesse de l’écart), le protocole se terminera.
Signature simultanée de contrat sans arbitre (en utilisant la

cryptographie)
Ce protocole cryptographique utilise la même approche des petits pas [531]. Le DES
est utilisé pour la description du protocole bien que tout algorithme à clef secrète
conviendrait.
1 ° Alice et Bernard choisissent chacun aléatoirement 200 clefs DES groupées par
paires. Il n’y a rien de spécial à propos de ces paires ; elles sont juste appariées
pour les besoins du protocole.
2° Alice et Bernard engendrent chacun n paires de messages, Gi et Di : « Ceci

est la moitié gauche de ma ie signature. » et « Ceci est la moitié droite de
ma ie signature. », par exemple. L ’identificateur i va de 1 à n. Les messages
comprendront aussi probablement une signature numérique du contrat comme
définie précédemment, et une datation. Le contrat est considéré comme signé
si l’autre participant peut produire les deux moitiés Gi et Di d’une paire de
signatures.
3° Alice et Bernard chiffrent tous deux leurs paires de messages avec chaque paire
de clefs D ES, le message gauche avec la clef gauche de la paire, et le message
droit avec la clef droit de la paire.
4° Alice et Bernard s ’envoient réciproquement leur paquet de 2n messages chiffrés,

en s ’assurant que l’autre sait que tel message appartient à telle moitié de telle
paire.
5° Alice et Bernard s ’envoient réciproquement toutes les paires de clefs en utilisant

le protocole de transfert inconscient pour chaque j>aire. C ’est-à-dire qu’Alice
envoie à Bernard soit la clef utilisée pour chiffrer la moitié gauche, soit la clef
utilisée pour chiffrer la moitié droite, indépendamment, pour chacune des n
paires. Bernard fait de même. Ils peuvent alterner l’envoi des moitiés, ou l’un
peut envoyer les n et puis l’autre faire de même — peu importe. Maintenant,
Alice et Bernard ont tous deux une clef de chaque paire mats chacun ignore
quelles sont les clefs en possession de l’autre.
6. Le ju ge enregistre la valeur au cas où il y aurait d ’autres litiges liés à ce contrat-

6° Alice et Bernard déchiffrent tous deux les moitiés de messages comme ils
peuvent, en utilisant les clefs qu’ils ont reçues. Ils s ’assurent que les messages
déchiffrés sont corrects.
7° Alice et Bernard s ’envoient réciproquement les premiers bits des 2n clefs DES.
8° Alice et Bernard répètent l’étape 7 pour les deuxièmes bits des 2n clefs DES,
les troisièmes bits, et ainsi de suite, jusqu’à ce que toutes les clefs DES aient
été transférées.
9° Alice et Bernard déchiffrent les moitiés restantes des paires de messages et le
contrat est signé.
Pourquoi Alice et Bernard doivent-ils faire tout cela? Supposons qu’Alice veuille tricher
et voyons ce qui se passe. Aux étapes 4 et 5, Alice peut perturber le protocole en
envoyant à Bernard des chaînes de bits sans sens. Bernard découvrirait cela à l’étape
6 , quand il essaierait de déchiffrer la moitié qu’il a reçue, quelle que soit cette moitié.
Bernard peut alors arrêter sans dommage, puisqu’Alice ne peut déchiffrer aucune des
paires de messages de Bernard.
Si Alice était très maligne, elle pourrait ne perturber que la moitié du protocole. Elle
pourrait envoyer la moitié gauche de chaque paire correctement et envoyer du charabia
comme moitié droite. Bernard n’a que 50 % de chance de recevoir la moitié droite et
donc Alice peut tricher la moitié du temps. Toutefois, cela ne marche que s’il n’y a
qu’une paire de clefs. S’il n’y avait que deux paires, ce type de supercherie pourrait
réussir dans 25 % des cas. C ’est pour cela que n doit être grand. Alice doit anticiper
correctement le résultat de n protocoles de transfert inconscient; Alice n’a que 1 chance
sur 2” de réussir cela. Si n = 10, Alice a une chance sur 1024 de rouler Bernard.
Alice peut aussi envoyer des bits aléatoires à Bernard à l’étape 8 . Peut-être que Bernard
ne saura pas qu’elle lui a envoyé des bits aléatoires jusqu’à ce qu’il reçoive la clef
complète et qu’il essaie de déchiffrer les moitiés de messages. Mais une fois de plus, les
probabilités sont du côté de Bernard. Il a déjà reçu la moitié des clefs et Alice ne sait
pas quelles sont ces moitiés. Alice est sûre de lui envoyer un bit erroné pour une des
clefs qu’il a déjà reçues, et lui, il saura immédiatement qu’Alice essaie de le rouler.
Peut-être qu’ Alice va continuer l’étape 8 jusqu’à ce qu’elle ait suffisamment de bits des
clefs pour casser les messages DES et ensuite arrêter de transmettre les bits. Le DES
a une longueur de clef de 56 bits. Si elle reçoit 40 des 56 bits, elle ne doit essayer que
2 16 (65 536) clefs pour pouvoir lire le message une tâche qui est certainement à la
portée d ’un ordinateur. Mais Bernard aura exactement le même nombre de bits des
clefs d ’Alice (ou un bit de moins tout au plus) et donc il pourra faire la même chose.
Alice n’a pas d’autre choix que de poursuivre le protocole.
Le point principal est qu’Alice doit jouer le jeu honnêtement, car les chances de rouler
Bernard sont bien trop minces. A la fin du protocole, les deux parties ont n paires de
messages signés, chacune d ’elles suffit pour une signature valable.
Alice a néanmoins la possibilité de tricher; elle peut envoyer des messages identiques
à Bernard durant l’étape 5. Bernard ne pourra s’en rendre compte qu’à la fin du
protocole, mais il peut utiliser une transcription du protocole pour convaincre un juge
de la duplicité d ’Alice.
Il y a deux faiblesses dans les protocoles de ce type [120] :
Premièrement, il y a un problème si l’une des parties a nettement plus de puissance de
calcul que l’autre. Si, par exemple, Aüce peut casser l’algorithme plus rapidement que
5.8 Courrier électronique certifié 131
Bernard, alors elle peut arrêter plus tôt de transmettre des bits à l’étape 8 et calculer
elle-même les clefs de Bernard. Bernard qui ne peut pas faire la même chose en un
temps raisonnable ne sera pas content.
Deuxièmement, il y a un problème si une des parties arrête le protocole plus tôt. Si
Alice arrête abruptement le protocole, tous deux devront faire le même effort pour
faire les calculs, mais Bernard n’a pas de réel recours légal. Si, par exemple, le contrat
spécifie qu’il doit faire quelque chose dans une semaine, et qu’ Alice arrête le protocole
en un point où Bernard devrait consacrer un an à calculer pour qu’ Alice soit vrai
ment engagée, il y aurait alors un problème. La vraie difficulté ici est qu’il n’y a pas
d’échéance à court terme à laquelle le processus doit se terminer comme il se doit : soit
les deux parties liées, soit aucune.
On retrouve ces problèmes avec les protocoles décrits aux paragraphes 5.8 et 5.9.
5.8 Courrier électronique certifié

Le même protocole de transfert inconscient simultané - utilisé pour la signature de
contrats — peut être utilisé pour certifier du courrier électronique [531]. Faites l’hy
pothèse qu’Alice veut envoyer un message à Bernard mais elle ne veut pas qu’il le lise
sans avoir envoyé un accusé de réception signé. Les postiers le font couramment mais
la même chose peut être faite avec la cryptographie. Whitfield D i f f i e aborde pour la
première fois ce problème dans [488].
A première vue, le protocole de signature simultanée de contrats peut faire cela. Alice
simplement chiffre son message avec une clef DES. Sa moitié du protocole peut être
quelque chose comme : « Ceci est la moitié gauche de la clef DES : 32F5. » La moitié
du protocole pour Bernard serait quelque chose comme : « Ceci est la moitié gauche
de mon accusé de réception. » Tout le reste serait de même.
Pour voir pourquoi cela ne marche pas, rappelez-vous que le protocole dépend du
fait que le transfert inconscient de l’étape 5 maintient l’honnêteté des deux parties.
Chacun des participants sait qu’il envoie à l’autre une moitié valide mais personne
ne sait laquelle. Ils ne trichent pas à l’étape 8 parce que les chances de réussite sont
ridicules. Si Alice envoie non pas un message mais une moitié de clef DES, Bernard
n’a aucun moyen de vérifier la validité de la clef DES à l’étape 6 . Alice peut toujours
vérifier la validité de l’accusé de réception de Bernard donc celui-ci est obligé d’être
honnête. Alice peut en toute impunité envoyer à Bernard une fausse clef DES et celui-
ci ne s’en rendra pas compte avant qu’Alice en reçoive l’accusé de réception. Bonne
chance Bernard !
Eviter cela nécessite quelques aménagements du protocole :
1° Alice chiffre son message en utilisant une clef DES aléatoire et envoie le ré
sultat à Bernard.
2° Alice engendre n paires de clefs DES. La première clef de chaque paire est
engendrée aléatoirement; la seconde clef de chaque paire est le ou exclusif de
1a. première clef et de la clef de chiffrement du message.
3° Alice chiffre un message factice avec chacune de ses 2n clefs.
4° Alice envoie à Bernard tous les messages chiffrés en s ’assurant qu’il sache que
tel message est telle moitié de telle paire.
5° Bernard, engendre n paires de clefs DES aléatoires.

6° Bernard engendre une paire de messages qui forment un accusé de réception
valide. « Ceci est la moitié gauche de mon accusé de réception » et « Ceci est
la moitié droite de mon accusé de réception » sont de bons candidats avec l'ad
jonction d’un certain type de validation. Il fait n paires d’accusés de réception,
chacune numérotée. Comme dans le protocole précédent, l’accusé de réception
est considéré comme valide si Alice peut produire les deux moitiés d’un accusé
de réception (avec le même numéro) et toutes ses clefs de chiffrement.
7° Bernard chiffre chacune de ses paires de messages avec les paires de clef DES,
la i e paire de messages avec la ie paire de clefs, le message gauche avec la clef
gauche de la paire et le message droit avec la clef droite de la paire.
8° Bernard envoie son paquet de messages à Alice en s ’assurant qu’Alice sait que
tel message est telle moitié de telle paire.
9° Alice et Bernard s ’envoient réciproquement chaque paire de clefs en utilisant le
protocole de transfert inconscient. En d’autres termes, Alice envoie à Bernard
soit la clef utilisée pour chiffrer le message gauche, soit la clef utilisée pour
chiffrer le message droit, pour chacune des n paires. Bernard fait de même. Ils
peuvent soit alterner les envois de moitiés, soit envoyer les n d’un coup, peu
impoile. Maintenant, Alice et Bernard ont une clef de chaque paire mais ni
l’un ni l ’autre ne sait ce que l’autre a reçu.
10° Alice et Bernard déchiffrent les moitiés comme ils peuvent et s ’assurent de la
validité des messages déchiffrés.
11° Alice et Bernard s ’envoient réciproquement le premier bit des n clefs DES.
(S’ils s ’inquiètent de la présence éventuelle d’Estelle capable de lire le courrier,
alors ils doivent chiffrer la transmission entre eux.)
12° Alice et Bernard répètent l’étape 11 pour le deuxième bit des 2n clefs DES, le
troisième bit, et ainsi de suite jusqu’à ce que tous les bits de toutes les clefs
DES aient été transmis.
13° Alice et Bernard déchiffrent les moitiés restantes des paires de messages. Alice
a un accusé de réception valide de Bernard et celui-ci peut appliquer le ou
exclusif à n’importe quelle paire de clefs pour retrouver la clef de chiffrement
du message d’origine.
Les étapes 5 à 8 pour Bernard et les étapes 9 à 12 pour Alice et Bernard sont les
mêmes que pour le protocole de signature de contrats. La différence se marque par
les messages factices chiffrés d’Alice. Ds donnent à Bernard un moyen de vérifier les
transferts inconscients d’Alice à l’étape 1 0 , qui oblige Alice à être honnête aux étapes
11 à 13. Et tout comme pour le protocole de signature simultanée de contrat, une
moitié gauche et une moitié droite d ’une des paires de messages d’Alice sont toutes
deux nécessaires pour terminer le protocole.
5.9 Echange simultané de secrets

Alice connaît un secret A ; Bernard connaît un secret B . Alice est disposée à dire A à
Bernard si Bernard lui dit B . Bernard est disposé à dire B à Alice si Alice lui dit A. Le
5.9 Échange simultané de secrets 133
protocole suivant peut être observé dans une cours d ’école, il ne marche manifestement
pas:
1° Alice : « Je te le dirai si tu me le dis en premier. »

2° Bernard : « Je te le dirai si tu me le dis en premier. »
3° Alice : « Non, toi en premier. »
4° Bernard: « A h ! bon. » (Bernard chuchote dans l’oreille d’Alice.)
5° Alice : « Ha ! Ha ! Je ne te dis rien. »
6° Bernard : « C ’est pas juste. »
La cryptographie peut le rendre équitable. Les deux protocoles précédentssont des

réalisations d ’un protocole plus général qui permet à Alice et à Bernardd ’échanger
simultanément des secrets [531]. Plutôt que de redonner tout le protocole, voici ce qu’il
faut changer au protocole de courrier numérique certifié :
Alice effectue les étapes 11 à 5 en utilisant A comme message. Bernard fait les mêmes
étapes en utilisant B comme message. Alice et Bernard effectuent le transfert incons
cient de l’étape 1 0 , déchiffrent les moitiés comme ils peuvent à l’étape 1 1 , et effectuent
les itérations des étapes 1 2 et 13. S’ils sont inquiets d’une présence éventuelle d ’Estelle,
ils peuvent chiffrer leurs messages. Finalement, Alice et Bernard déchiffrent tous deux
les moitiés restantes des paires de messages et effectuent le ou exclusif de n’importe
quelle paire de clefs pour retrouver la clef de chiffrement du message initial.
Ce protocole permet à Alice et Bernard d’échanger simultanément des secrets, mais il
ne dit rien du tout de la qualité des secrets échangés. Alice peut promettre à Bernard
la solution du labyrinthe du Minotaure mais lui envoyer la carte du métro de Boston.
Bernard recevra le secret d ’Alice peu importe la nature de celui-ci. On trouvera d’autres
protocoles dans [1298, 202, 1001, 1528, 706, 755, 263, 362, 418].
Chapitre 6
Protocoles ésotériques
6.1 Elections sûres

À moins qu’il n’y ait un protocole qui évite la tricherie et qui garantisse la confiden
tialité, le vote informatique ne sera jamais utilisé pour des élections grandeur nature.
Le protocole idéal a au minimum les 6 caractéristiques suivantes :
1. Seules les personnes autorisées à voter peuvent voter.
2. Personne ne peut voter plus d’une fois.
3. Personne ne peut déterminer pour qui quelqu’un d ’autre a voté.
4. Personne ne peut dupliquer le vote de quelqu’un d ’autre. (Il s’avère que cette
exigence est la plus difficile à remplir.)
5. Personne ne peut modifier le vote de quelqu’un d ’autre sans être découvert.
6. Tous les votants peuvent vérifier que leur vote a bien été pris en compte dans le
décompte final.
De plus, certains schémas de vote pourraient ajouter l’exigence :
7. Tout le monde sait qui a voté et qui n’a pas voté.
Avant d’aborder les protocoles compliqués qui ont ces caractéristiques, voyons quelques
protocoles simplistes qui ne les ont pas.
Protocole de vote simpliste n° 1

1° Tous les votants chiffrent leur vote avec la clef publique de l’Autorité Centrale
de Décompte (Â C D ).
2° Tous les votants envoient leur vote à Z’A C D .
3° L ’A C D déchiffre les votes, les compte et rend les résultats publics.

136 Chapitre 6 Protocoles ésotériques
Ce protocole a des défauts à chaque point. L’A C D n’a aucune idée d ’où viennent les
votes, et donc elle ne sait pas si les votes sont émis par des votants autorisés ou pas.
Elle n’a pas la moindre possibilité de détecter si les votants votent plus d ’une fois.
Du côté des avantages, personne ne peut modifier le vote de quelqu’un d ’autre, mais
personne n’essaierait de le faire quand c’est tellement plus facile de voter un nombre
infini de fois pour forcer le résultat de son choix.
Protocole de vote simpliste n° 2

1° Tous lesvotants signent leur vote avec leur clef privée.
2° Tous lesvotants chiffrent leur vote signé avec laclef publique de Z’A C D .
3° Tous lesvotants envoient leur vote à Z’A C D .
4° L ’A C D déchiffre les votes, vérifie les signatures,décompte les votes et rend les
résultats publics.
Ce protocole satisfait les propriétés ( 1 ) et ( 2 ) : seuls les votants autorisés peuvent voter
et personne ne peut voter plus d ’une fois. Pour cela, l’A C D doit garder une trace des
votes reçus à l’étape 3. Les votes sont signés avec la clef privée des votants donc l’ACD
sait qui a voté, qui n’a pas voté et combien de fois chaque votant a voté. Si un vote
signé par un votant non autorisé arrive — ou un vote signé par un votant qui a déjà
voté — l’A C D l’ignore. De plus, personne ne peut modifier le vote d’autrui même s’il
l’intercepte à l’étape 2 grâce à la signature numérique.
Le défaut de ce protocole est que la signature est attachée au vote et qu’ainsi l’ACD
sait qui a voté pour qui. Le chiffrement des votes avec la clef publique de l’ACD
empêche quiconque écoute le protocole de déterminer qui vote pour qui, mais ce n’est
pas suffisant. C ’est comme si un assesseur de bureau de vote regardait par-dessus votre
épaule dans l’isoloir.
Les deux exemples suivants montrent à quel point il est difficile de remplir ne serait-ce
que les trois premières exigences d ’un protocole de vote sûr.
Vote avec signatures en aveugle

Ce que nous devons faire c ’est d ’une certaine façon dissocier le vote du votant tout en
maintenant l’authentification. C ’est exactement ce que réalise le protocole de signature
en aveugle.
1° Tous les votants engendrent dix ensembles de messages, chaque ensemble

contient un vote valide pour chaque vote possible (par exemple, si le vote est
une question optionnelle : « oui » ou « non », chaque ensemble contient deux
votes, un pour « oui » et l’autre pour « non »). Chaque message contient éga
lement un numéro de série engendré aléatoirement suffisamment grand pour
éviter les collisions avec les autres votants.
2° Tous les votants camouflent individuellement tous les messages (voir § 5.3) et
envoient le résultat à Z’A C D .
3° L ’A C D vérifie dans sa base de données pour être sûre que des votants n’ont
pas déjà auparavant soumis des votes camouflés pour leur signature. Elle ouvre
neuf des dix ensembles de messages et vérifie qu ’ils ont été faits dans les règles.
6.1 Élections sûres 137
Ensuite, elle signe individuellement chaque message dans le dixième ensemble.

Enfin, elle les renvoie aux votants et enregistre les noms des votants dans sa
base de données.
4° Les votants dévoilent les messages pour donner un ensemble de votes signés
par TA C D . (Ces votes sont signés mais non chiffrés, donc les votants peuvent
aisément voir quel vote est « oui » et quel vote est « non ».)
5° Les votants choisissent l’un des votes ( O Démocratie !) et chiffrent celui-ci avec
la clef publique de l’A C D .
6° Les votants envoient leur vote.
7° L ’A C D déchiffre les votes, vérifie les signatures, vérifie dans sa base de don
nées pour des numéros de série redondants, enregistre le numéro de série, et
décompte les voix. Elle publie les résultats du vote avec tous les numéros de
série et leur vote associé.
Un votant malveillant, appelons-le Martin, ne peut pas tricher dans ce système. Le

protocole de signature en aveugle garantit que son vote est unique. S’il essaie d ’envoyer
le même vote deux fois, l’A C D détectera le numéro de série redondant à l’étape 7 et
rejettera le second vote. S’il essaie d ’obtenir plusieurs votes signés à l’étape 2, l’A C D
découvrira cela à l’étape 3. Martin ne peut pas engendrer des votes factices car il ne
connaît pas la clef privée de l’autorité. Il ne peut pas intercepter et modifier les votes
d’autres votants pour les mêmes raisons.
La technique « couper et -chosir » utilisée à l’étape 3 sert à assurer l'unicité des votes.
Sans cette étape, Martin pourrait créer un ensemble de votes identiques en tout point
sauf le numéro de série, et réussir à les faire tous valider.
Une A C D malintentionnée ne peut pas déterminer la façon de voter des individus.
Comme le protocole de signature en aveugle empêche l’autorité de voir les numéros de
série avant qu’ils soient émis, l’A C D ne peut pas faire le lien entre un vote camouflé
qu’elle signe et le vote finalement émis. La publication de la liste des numéros de série
et de leur vote associé permet à tous les votants de vérifier que leur vote a bien été
pris en compte.
Il y a encore des défauts. Si l’étape 6 n’est pas anonyme et si l’A C D peut enregistrer
qui a envoyé tel vote, alors elle peut déterminer qui a voté pour qui. Toutefois, si elle
reçoit les votes dans une urne scellée et qu’elle les décompte plus tard, elle ne peut pas.
De plus, bien que l’A C D ne puisse pas relier les votes aux individus, elle peut engendrer
un grand nombre de votes valides signés et tricher en les soumettant elle même. Et si
Alice se rend compte que l’ A C D a changé son vote, elle n’a pas les moyens d ’en faire la
preuve. Il existe un protocole de ce type qui tente de corriger ces défauts [1204, 1372].
Vote avec deux autorités centrales

Une solution est de répartir le pouvoir de l’A C D en deux parties. Aucune des deux
parties n’a assez de pouvoir pour tricher de son propre chef.
Le protocole suivant utilise une Autorité Centrale de Légitimation (A C L ) pour au
thentifier les votants et une A C D séparée pour compter les votes [1375].
1° Tous les votants envoient un message à l’A CL demandant un numéro de vali

dation.
2° L 'ACL renvoie aux votants un numéro de validation aléatoire. L 'ACL main

tient une liste des numéros de validation. L A C L maintient également une liste
des destinataires des numéros de validation, au cas où ils essaieraient de voter
à nouveau.
3° L A C L envoie la liste des numéros de validation à Z’A C D .
4° Tous les votants choisissent un numéro d’identification individuel aléatoire. Ils

créent un message avec leur numéro d’identification, le numéro de validation
qu’ils ont reçu et leur vote v. Ils envoient le message à l’A C D .
5° L 'A C D compare le numéro de validation avec la liste qu’elle a reçue de Z'ACL

à l’étape 3. Si le numéro de validation y figure, Z'ACD le biffe (pour empêcher
quiconque de voter deux fois). L ’A C D ajoute le numéro d’identification à la
liste des gens qui ont voté pour un candidat donné et ajoute un au décompte.
6° Après que tous les votes ont été reçus, Z’A C D publie le résultat ainsi que les
listes des numéros d’identification et pour qui leur propriétaire a voté.
Un avantage de ce système est que tous les votants peuvent regarder la liste des nu
méros d ’identification et trouver le leur. Cela leur prouve que leur vote a été pris en
compte. Bien sûr, tous les messages circulant entre les différents participants du pro
tocole doivent être chiffrés et signés pour éviter que quelqu’un puisse se faire passer
pour quelqu’un d ’autre et pour éviter les interceptions.
L’A C D ne peut pas modifier les votes parce que tous les votants vont rechercher leur
numéro d ’identification. Si un votant ne le trouve pas ou le trouve dans une autre liste
que celle pour laquelle il a voté, il saura immédiatement qu’il y a eu tricherie. L’ACD
ne peut pas trafiquer l’urne parce que l’A C L surveille. L ’A C L sait combien de votants
ont été validés ainsi que leurs numéros de validation. Toute modification de l’un ou
l’autre est immédiatement détectée.
Martin qui n’est pas un votant autorisé, peut essayer de tricher en devinant un numéro
de validation valide. La probabilité de succès de cette attaque peut être minimisée
en rendant le nombre de numéros de validation possibles nettement plus grand que
le nombre de numéros de validation effectivement émis : un million de nombres de
100 chiffres par exemple. Bien sûr, les numéros de validation doivent être engendrés
aléatoirement.
Malgré cela, l’A C L fait, en quelque sorte, toujours autorité. Elle peut valider des
votants non autorisés. Elle peut valider des votants légitimes plusieurs fois. Le risque
peut être minimisé en obligeant l’A C L à publier la liste des votants validés (mais pas
leur numéro de vaüdation). Si le nombre de votants sur cette liste est inférieur au
nombre de votes comptés, il y a anguille sous roche. S’il y a plus de votants validés
que de votes, cela signifie probablement que des votants validés ne se sont pas donnés
la peine de voter. De nombreuses personnes sont enregistrées pour voter choisissent de
ne pas participer aux ballottages.
Ce protocole est aussi vulnérable à une collusion entre l’A C D et l’ACL. Si les deux
se mettent ensemble, elles peuvent corréler leurs bases de données et déterminer qui a
voté pour qui.
Vote avec une seule autorité centrale

Un protocole plus complexe peut être utilisé pour éviter le danger de collusion entre
l’ACL et l’A C D [1375]. Ce protocole est identique au précédent excepté les deux
modifications suivantes :
- l’A C L et l’A C D sont une seule et même organisation ;
- A N D O S (voir § 4.13) est utilisé pour distribuer des numéros de validation ano
nymes à l’étape 2 .
Comme le protocole de distribution anonyme de clefs empêche l’A C D de savoir quel

votant a eu quel numéro de validation, l’A C D ne peut pas corréler les numéros de
validation avec les votes reçus. Il faut toutefois toujours être sûr que l’A C D n’attribuera
pas des numéros de validation à des votants non légitimes. On peut aussi résoudre le
problème avec des signatures en aveugle.
Vote amélioré avec une seule autorité centrale

Ce protocole utilise aussi le protocole A N D O S [1181]. C ’est un excellent protocole et il
satisfait les 6 propriétés d’un bon protocole de vote. Il ne satisfait pas la 7e contrainte,
mais il a deux propriétés supplémentaires par rapport à celles mentionnées au début
de ce paragraphe :
7. Les votants peuvent changer d’avis (c’est-à-dire, retirer leur vote et voter à nou
veau) pendant une période de temps donnée.
8. Si les votants découvrent que leur vote a été mal comptabilisé, ils peuvent iden
tifier et corriger le problème sans compromettre la confidentialité de leur vote.
Voici le protocole :
1° L ’A C D publie la liste de tous les votants légitimes.

2° Pendant un laps de temps spécifié, toute personne peut indiquer son intention
de voter auprès de Z’A C D .
3° L ’A C D publie la liste des votants participant à l ’élection.
4° Tous les votants reçoivent un numéro d’identification, I, en utilisant le proto
cole A N D O S.
5° Tous les votants engendrent une paire clef publique clef privée : k,d. Si v est le
vote, ils engendrent le message suivant et l’envoient à Z’A C D :
I ,E k(I,v)
6° L ’A C D confirme les votes en publiant :
E k(I,v)
7° Tous les votants envoient à Z'ACD :
I,d
Chapitre 6 Protocoles ésotériques
8° L ’A C D utilise d pour déchiffrer les votes. A la fin de l’élection, elle publie les
résultats de l’élection et pour chaque vote possible, la liste de tous les E k(I,v)
contenant ce vote-là.
9° Si un votant constate qu ’un vote n’est pas comptabilisé correctement, il proteste

en envoyant:
I ,E k{I,v),d
10 ° Si un votant veut changer son vote (c ’est possible dans certains types d’élec
tions) de v à v', il peut envoyer à l ’A C D :
I ,E k(i,v'),d
Un autre protocole de vote [587] utilise des signatures en aveugle à la place d ’ANDOS,
mais il est essentiellement le même. Les étapes 1 à 3 sont des préliminaires au vote
lui-même. Leur but est de déterminer et de publier le nombre total de votants. Bien
que certains d ’entre eux ne participeront probablement pas, cela réduit la possibilité
pour l’A C D d ’ajouter des votes frauduleux.
A l’étape 4, il est possible que deux votants reçoivent le même numéro d ’identification.
Cette éventualité peut être évitée en ayant bien plus de numéros d ’identification qu’il
n’y a de votants. Si deux votants soumettent des votes avec le même identificateur,
l’A C D engendre un nouveau numéro d’identification i', choisit l’un des deux votes et
publie :
r , E k(i,v)
L’émetteur de ce vote le reconnaît et envoie un deuxième vote en répétant l’étape 5

avec le nouveau numéro d ’identification.
L’étape 6 donne la possibilité à tous les votants de vérifier que l’A C D a reçu leur vote
correctement. Et si leur vote est mal comptabilisé, ils peuvent le prouver à l’étape 9.
En faisant l’hypothèse que tous les votes sont corrects à l’étape 6 , le message qu’ils
envoient à l’étape 9 constitue une preuve que leur vote a été mal comptabilisé.
Le défaut principal de ce protocole est que l’A C D peut allouer des votes pour des gens
qui répondent à l’étape 2 mais qui ne votent pas. Un autre défaut est la complexité
du protocole A N D O S. Les auteurs recommandent de diviser une grande population
de votants en groupes plus petits, comme des districts électoraux.
Il reste un problème plus sérieux : l’A C D peut négliger de compter un vote. Ce problème
ne peut être résolu : Alice prétend que l’A C D a sciemment oublié de compter son vote,
mais l’A C D prétend qu’Alice n’a jamais voté.
Vote sans une autorité centrale de comptabilisation

Ce protocole permet de se passer complètement de l’A C D , les votants se surveiellent
les uns les autres. Conçu par Michael M e r r i t t [266, 597, 267], il est si difficile à
manier que seule une poignée de participants peut le mettre en pratique, il est malgré
tout intéressant à étudier.
Alice, Bernard, Christine et David votent oui ou non (0 ou 1) à propos d ’un sujet
particulier. Faites l’hypothèse que chaque participant a une clef publique et une clef
privée, que tout le monde connaît la clef publique de chacun.
1° Tous les votants choisissent un vote et effectuent ce qui suit:
(a) ajouter une chaîne aléatoire à leur vote;

( b ) chiffrer le résultat de l’étape (a) avec la clef publique de David;
( c ) chiffrer le résultat de l’étape (b) avec la clef publique de Christine;
(d ) chiffrer le résultat de l’étape (c) avec la clef publique de Bernard;
( e ) chiffrer le résultat de l’étape (d) avec la clef publique d’Alice;
( f ) ajouter une nouvelle chaîne aléatoire au résultat de l’étape (e) et chiffrer
le tout avec la clef publique de David. Ils enregistrent la valeur de cette
chaîne aléatoire;
(g) ajouter une nouvelle chaîne aléatoire au résultat de l’étape (f) et chiffrer le
tout avec la clef publique de Christine. Ils enregistrent la valeur de cette
chaîne aléatoire;
(h ) ajouter une nouvelle chaîne aléatoire au résultat de l’étape (g) et chiffrer
le tout avec la clef publique de Bernard. Ils enregistrent la valeur de cette
chaîne aléatoire ;
(i) ajouter une nouvelle chaîne aléatoire au résultat de l’étape (h) et chiffrer le
tout avec la clef publique d’Alice. Ils enregistrent la valeur de cette chaîne
aléatoire.
Si E est la fonction de chiffrement, R est une chaîne aléatoire et V est un vote,

le vote ressemble à ceci:
EA(Rb,E B(Ri>E c (R 3,ED(R2,EA(E B(Ec (ED(V1R 1))))))))
Tous les votants sauvegardent les résultats intermédiaires à chaque point du

calcul. Ces résultats seront utilisés plus tard dans le protocole pour confirmer
que leur vote est parmi ceux qui ont été comptabilisés.
2° Tous les votants envoient leur vote à Alice.
3° Alice déchiffre tous les votes avec sa clef privée, vérifie que son vote est bien
parmi l’ensemble des votes (en cherchant sa chaîne aléatoire parmi les votes),
et ensuite elle retire toutes les chaînes aléatoires à ce niveau.
4° Alice mélange l’ordre de tous les votes et envoie le résultat à Bernard.
Chaque vote ressemble à ceci maintenant :
E B{Ri ,E c {R 3 ,E D(R 2 ,E A{E B(Ec {ED{V,R1)))))))
5° Bernard déchiffre tous les votes avec sa clef publique, vérifie que son vote est
bien parmi l’ensemble des votes, retire toutes les chaînes aléatoires à ce niveau,
mélange tous les votes et envoie le résultat à Christine.
Chaque vote ressemble à ceci maintenant:
E c ( R 3 ,E d ( R 2,E a ( E b ( E c ( E d ( V ,R 1 ) ) ) ) ) )
6° Christine déchiffre tous les votes avec sa clef publique, vérifie que son vote est
bien parmi l’ensemble des votes, retire toutes les chaînes aléatoires à ce niveau,
mélange tous les votes et envoie le résultat à David.
E d (R 2 ,E a (E b (E c (E d (V A ) ) ) ) )
7° David déchiffre tous les votes avec sa clef publique, vérifie que son vote est
bien parmi l ’ensemble des votes, retire toutes les chaînes aléatoires à ce niveau,
mélange tous les votes et envoie le résultat à Alice.
E a (E b (E c (E d (V,R i))))
8° Alice déchiffre tous les votes avec sa clef publique, vérifie que son vote est bien
parmi l’ensemble des votes, signe l’ensemble des votes, et envoie le résultat à
Bernard, Christine et David.
S a (E b (E c (E d (V ,/Zi))))
9° Bernard vérifie et retire la signature d’Alice. Il déchiffre tous les votes avec sa
clef publique, vérifie que son vote est bien parmi l’ensemble des votes, signe
l’ensemble des votes, et envoie le résultat à Alice, Christine et David.
S B {E c{E D{V,Ry)))
10 ° Christine vérifie et retire la signature de Bernard. Elle déchiffre tous les votes
avec sa clef publique, vérifie que son vote est bien parmi l’ensemble des votes,
signe l ’ensemble des votes, et envoie le résultat à Alice, Bernard et David.
SC{E D{V,Ry))
1 1 ° David vérifie et retire la signature de Christine. Il déchiffre tous les votes avec
sa clef publique, vérifie que son vote est bien parmi l ’ensemble des votes, signe
l’ensemble des votes, et envoie le résultat à Alice, Bernard et Christine.
S d {V,R i)
12° Tous vérifient et retirent la signature de David. Ils s ’assurent que leur vote est
bien parmi l’ensemble des votes (en cherchant leur chaîne aléatoire parmi les
votes).
13° Chacun retire les chaînes aléatoires de chaque vote et compte les voix.
6.1 Élections sûres
Non seulement ce protocole marche mais il est auto-arbitré. Alice, Bernard, Chris
tine et David sauront immédiatement si quelqu’un triche. Aucune A C D ou A C L n’est
nécessaire. Pour voir comment cela marche, essayons de tricher.
Si quelqu’un essaie de rajouter des voix, Alice le détectera à l’étape 3 quand elle
recevra plus de votes que de participants. Si Alice essaie de rajouter des voix, Bernard
le détectera à l’étape 4.
Un moyen plus détourné de tricher est de remplacer un vote par un autre. Comme les
votes sont chiffrés avec plusieurs clefs publiques, n’importe qui peut créer autant de
votes valides que nécessaire. Il y a deux rondes au protocole de déchiffrement : la ronde
1 est constituée des étapes 3 à 7, et la ronde 2 est constituée des étapes 8 à 11. Le
remplacement de votes est détecté de façon différente dans les deux rondes.
Si quelqu’un remplace un vote par un autre dans la ronde 2 , ces actions sont découvertes
immédiatement. A chaque étape les votes sont signés et envoyés à tous les votants. Si
un (ou plusieurs) votant constate que son vote n ’est plus dans l’ensemble des votes, il
peut immédiatement arrêter le protocole. Comme les votes sont signés à chaque étape,
et que tout le monde peut remonter la ronde 2 du protocole, il est aisé de déterminer
qui a remplacé des votes.
Remplacer un vote par un autre pendant la ronde 1 du protocole est plus subtil. Alice ne
peut pas le faire à l’étape 3, car Bernard, Christine ou David le détecteraient à l’étape
5, 6 ou 7. Bernard pourrait essayer à l’étape 5. S’il remplace le vote de Christine ou de
David (rappelez-vous qu’il ne sait pas à qui tel vote correspond). Christine ou David
s’en rendront compte à l’étape 6 ou 7. Ils ignoreront qui a modifié leur vote (bien
que cela ne puisse être que quelqu’un ayant déjà manipulé leur vote) mais ils sauront
que leur vote a été falsifié. Si Bernard est chanceux et choisit le vote d’Alice pour la
substitution, elle ne s’en rendra compte qu’à la deuxième ronde. A ce moment-là, elle
détectera à l’étape 8 que son vote manque. Toutefois, elle ne saura pas qui a modifié
son vote. Durant la première ronde, les votes sont mélangés d ’une étape à l’autre et
non signés: il est impossible pour qui que ce soit de remonter le protocole afin de
déterminer qui a truqué les votes.
Un autre moyen de tricher est d ’essayer de deviner qui a voté pour qui. A cause du
mélange durant la première ronde, il est impossible de remonter le protocole pour
associer les votants aux votes. Le retrait des chaînes aléatoires pendant la première
ronde est également crucial pour préserver l’anonymat. Si elles ne sont pas retirées, le
mélange des votes peut être défait en rechiffrant les votes avec la clef publique de celui
qui a mélangé. Tant que le protocole tient, la confidentialité des votes est sûre.
Plus fort encore, à cause de la chaîne aléatoire initiale R i , même des votes identiques
sont chiffrés différemment à chaque étape du protocole. Personne ne connaît le résultat
du vote avant l’étape 1 1 .
Quels sont les défauts de ce protocole? Premièrement, le protocole nécessite un grand
nombre de calculs. L’exemple décrit ici n’implique que 4 votants et c ’était compliqué.
Cela ne marcherait jamais pour de vraies élections avec des dizaines de milliers de
votants. Deuxièmement, David apprend les résultats de l’élection avant tout le monde.
Bien qu’il ne puisse plus en modifier le résultat, cela lui donne un pouvoir que les
autres n’ont pas. Pour en finir, tout cela s’applique aux protocoles de vote avec autorité
centrale.
Le troisième problème est qu’Alice peut faire le même vote que n’importe quel autre
votant. Pour comprendre pourquoi cela peut être un problème, considérons une élection
à trois personnes Alice, Bernard et Estelle. Estelle ne soucie pas du résultat de l’élection,
mais elle veut connaître le vote d ’Alice. Pour cela, elle copie le vote d’Alice et le résultat
de l’élection sera forcément égal au vote d ’Alice.
Autres schémas de vote

De nombreux protocoles sûrs d’élection ont été proposés. On peut les cataloguer en
deux tendances de base. Il y les protocoles de mélange, comme le « vote sans autorité
centrale de tabulation » où les votes sont mélangés de sorte que personne ne peut
associer un vote avec un votant.
Il y a aussi des protocoles de division où les votes indiciduels sont répartis entre diffé
rentes autorités de comptabilisation de sorte qu’aucune ne puisse tromper les votants
à elle seule [364, 363, 128, 125]. Ces protocoles ne protègent la vie privée des votants
que dans la mesure où les « parties » du Gouvernement (ou quiconque gère l’élection)
ne conspirent pas contre le votant1.
Un protocole de division est donné dans [1373]. L’idée de départ est que chaque votant
partage son vote en plusieurs parties. Par exemple, s’il s’agit de voter « oui » ou « non »,
un 1 pourrait signifier « oui » et un 0 pourrait signifier « non »; le votant produirait
alors plusieurs nombres dont la somme ferait soit 0, soit 1. Ces parties sont chiffrées et
envoyées aux autorités de comptabilisation, une par autorité. Chaque centre totalise les
parts qu’il reçoit 2 et le vote final est la somme de tous les totaux. Il y a des protocoles
qui certifient que la somme des parts de chaque votant vaut bien 1 ou 0 .
Un autre protocole, dû à David C h a u m [328], permet de retrouver les votants qui
essaient de perturber les élections. Toutefois, dans ce cas, le vote doit être recommencé
sans le votant trublion; cette approche n’est pas pratique pour des votes à grande
échelle.
Un autre protocole de vote plus complexe qui pallie certains des défauts est décrit
dans [770, 771]. Il y a même un protocole de vote qui utilise le surchiffrement [222], Un
autre protocole de vote, qui prétend être pratique pour des élections à grande échelle,
est décrit dans [587]. Et [351] permet aux votants de s’abstenir.
Les protocoles de vote marchent, mais ils facilitent le commerce des votes. Le risque
devient d ’autant plus grand que l’acheteur peut s’assurer que le vendeur a voté comme
promis. Certains protocoles sont conçus pour qu’un votant ne puisse pas prouver à
autrui qu’il a voté d’un côté donné [127, 4, 1374].
6.2 Calcul réparti sûr

Le calcu l rép arti sûr est un protocole par lequel un groupe de personnes peuvent
se rasssembler pour calculer la valeur d ’une fonction à plusieurs arguments. Chaque
participant fournit un seul argument de la fonction. Chacun dans le groupe connaîtra
le résultat de l’évaluation de la fonction mais personne n’apprend rien qui ne puisse se
déduire du résultat concernant les valeurs d ’arguments fournies par les autres membres.
Voici quelques exemples :
X. C ette idée de scinder une autorité centrale en plusieurs parties, en qui l’ on n ’a confiance que si
elles sont réunies vient de [320].
2. Il y a des protocoles qui perm ettent de vérifier l’exactitude des totaux.
Protocole n° 1
Comment un groupe de personnes peuvent-elles calculer la moyenne de leurs salaires
sans que personne n’apprenne le montant du salaire d ’un autre?
1° Alice ajoute un nombre aléatoire secret à son salaire, chiffre le résultat avec la
clef publique de Bernard et l’envoie à Bernard.
2° Bernard déchiffre le résultat d ’Alice avec sa clef privée. Il ajoute son salaire à
ce qu’il a reçu d’Alice, chiffre le résultat avec la clef publique de Christine et
l’envoie à Christine.
3° Christine déchiffre le résultat de Bernard avec sa clef privée. Elle ajoute son
salaire à ce qu’elle a reçu de Bernard, chiffre le résultat avec la clef publique
de David et l’envoie à David.
4° David déchiffre le résultat de Christine avec sa clef privée. Il ajoute son salaire
à ce qu’il a reçu de Christine, chiffre le résultat avec la clef publique d’Alice et
l’envoie à Alice.
5° Alice déchiffre le résultat de David avec sa clef privée. Elle retire le nombre
aléatoire de l’étape 1 pour retrouver la somme des salaires de tout le monde.
6° Alice divise le résultat par le nombre de personnes (4 dans ce cas-ci) et annonce

le résultat.
Ce protocole fait l’hypothèse que tout le monde est honnête. Si les participants mentent
à propos de leur salaire, la moyenne sera fausse. Un défaut plus sérieux est qu’Alice
peut truquer le résultat présenté aux autres. Elle peut retirer le nombre qu’elle veut
du résultat à l’étape 5 et personne ne s’en rendrait compte. Alice pourrait en être
empêchée en l’obligeant à mettre en gage son nombre aléatoire en utilisant n’importe
quel schéma de mise en gage de le paragraphe 4.9 mais quand elle révèle son nombre
aléatoire à la fin du protocole, Bernard peut connaître le montant du salaire d ’Alice.
Protocole n° 2
Alice et Bernard sont ensemble au restaurant et discutent de leur âge respectif. Ni l’un
ni l’autre ne veut dire son âge à l’autre mais ils sont tous les deux curieux de savoir
qui est le plus âgé. Ils pourraient chacun murmurer leur âge à l’oreille d’un tiers de
confiance (le serveur, par exemple), qui calculera de tête et qui annoncera le résultat
à Alice et Bernard.
Il y a deux défauts au protocole ci-dessus. Premièrement, le serveur ordinaire n’a pas
de capacité de calcul pour traiter des problèmes plus complexes que la comparaison
entre deux nombres. Deuxièmement, si Alice et Bernard étaient vraiment soucieux du
caractère secret de leurs informations, ils devraient noyer le serveur dans un verre d’eau
de Vichy sinon celui-ci pourrait tout raconter au sommelier.
La cryptographie à clef publique offre une solution bien moins violente. U existe un
protocole grâce auquel Alice qui connaît la valeur a, et Bernard qui connaît la va
leur b, peuvent ensemble calculer f(a,b) de manière qu’ Alice n’ait aucune information
concernant b et que Bernard n’ait aucune information concernant a. Ainsi, Alice et
Bernard sont tous deux convaincus de la validité des calculs. Comme l’algorithme
cryptographique utilisé est partie intégrante du protocole, les détails seront donnés
dans le paragraphe 23.14.
Bien sûr, ce protocole ne protège pas contre les tricheurs actifs. Il n’y a rien qui empêche
Alice (ou Bernard par la même occasion) de tricher sur son âge. Si Bernard était
un programme informatique qui exécutait aveuglément le protocole, Alice pourrait
apprendre son âge (est-ce que l’âge d ’un programme informatique est compté à partir
du temps où il a été écrit ou à partir du temps où il a commencé à être exécuté?) par
applications répétées du protocole. Alice peut exécuter le protocole en donnant comme
âge 60 ans. Après avoir appris qu’elle est plus âgée, elle exécute le protocole à nouveau
en prétendant être âgée de 30 ans. Après avoir appris que Bernard est plus âgé, elle
exécute le protocole à nouveau avec 45 et ainsi de suite jusqu’à que ce qu’elle connaisse
l’âge de Bernard avec une précision aussi grande que souhaitée.
En faisant l’hypothèse que les participants ne trichent pas activement, il est aisé
d ’étendre ce protocole à plus de deux participants. N’importe quel nombre de personnes
peuvent déterminer l’ordre de leurs âges par des applications honnêtes et répétées du
protocole ; et aucun participant n’apprendra l’âge d’un autre participant.
Protocole n° 3
Alice aime faire des choses un peu perverses avec des ours en peluche. Bernard a des
fantasmes érotiques à propos des tables en marbre. Chacun est gêné d ’évoquer ses
fétiches particuliers mais aimerait bien trouver le compagnon qui partage leur ... hum
... style de vie.
Au « Service Informatique Sécurisé de Rencontres de Groupetm » nous avons conçu
un protocole pour de telles personnes. Nous avons numéroté une liste étonnante de
fétiches depuis « a » jusqu’à « z ». Discrètement, séparés par un modem, Alice et
Bernard peuvent participer à un protocole multi-participants sûr. Ensemble, ils peuvent
déterminer s’ils partagent ou non un fétiche particulier. Si oui, ils peuvent envisager
une heureuse relation. Si non, ils peuvent se dire au revoir, assurés de la confidentialité
de leurs secrets. Personne, même pas la « Secure Multiparty Computation Dating
Servicetm » ne saura jamais.
Voilà comment ça marche.
1 ° Alice applique une fonction de hachage a sens unique au nom de son fétiche et
obtient une suite de huit chiffres.
2° Alice se sert de cette suite de chiffres comme d’un numéro de téléphone au quel
elle appelle et laisse un message pour Bernard. Si personne ne répond ou si le
numéro n’est pas en service, Alice applique autant de fois qu’il est nécessaire
la fonction de hachage au numéro de téléphone pour avoir en ligne quelqu’un
qui puisse participer au protocole.
3° Alice dit à Bernard combien de fois elle a du appliquer la fonction de hachage
au nom de son fétiche.
4° Bernard applique la fonction de hachage au nom de son fétiche le même nombre
de fois. Il téléphone au numéro que forme le résultat et demande si personne
n’a laissé de message pour lui.
Bernard peut faire une attaque à texte en clair choisi. Il peut appliquer la fonction de
hachage à des noms de fétiches usuels et appeller aux numéros de téléphones résultants
6.2 Calcul réparti sûr 147
à la recherche de messages pour lui. Ce protocole ne marche vraiment que s’il y a assez
de textes en clair possibles pour rendre cette attaque infaisable.
Il existe aussi un protocole mathématique similaire au protocole n° 2. Alice connaît a,
Bernard connaît b et ensemble ils vont déterminer si a = b de telle manière que Bernard
n’apprenne rien sur a et Alice n’apprenne rien sur b. Les détails sont donnés dans le
paragraphe 23.14.
Protocole n° 4
Voici un autre problème pour le calcul réparti sûr [1375]. Un comité se réunit réguliè
rement pour voter secrètement sur certains sujets. (Oui, ils gouvernent secrètement le
monde, ne dites à personne que je vous l’ai dit.) Tous les membres du comité peuvent
voter par « oui » ou « non ». En plus, deux participants ont le droit d’émettre des
« super-votes » : « S—oui » et « S non ». Ils ne sont pas obligés d’émettre des super
votes, ils peuvent émettre des votes normaux s’ils préfèrent. Si personne n’émet de
super-vote, alors la majorité des voix décide de l’issue du scrutin. Dans le cas où il n’y
a qu’un seul super-vote, ou deux super-votes équivalents, tous les votes normaux sont
ignorés. Dans le cas de deux super-votes contradictoires, la majorité des votes normaux
l’emporte. Nous voulons un protocole qui réalise de façon sûre ce type de vote.
Deux exemples illustreront le processus de vote. Faites l’hypothèse qu’il y a 5 votants
normaux, Nj à IV5 et deux super-votants Si et S2. Voici le résultat du vote n° 1
Si S-2 Ni N2 N3 N4 N5
S -oui non non non non oui oui
Dans ce cas-là,seul compte le vote de Si et lerésultat est « oui ».

Voici le résultat du vote surle sujet suivant n° 2 :
Si S2 Ni N2 N3 N4 N5
S -oui S- non non non non oui oui
Ici les deux super-votes s’annulent et la majorité des « non » l’emporte.

S’il n’est pas nécessaire de cacher comment le vote a été tranché : par un super-vote ou
par une majorité de votes réguliers, c ’est une simple application du protocole de vote
sûr. S’il est par contre important de garder cette information secrète, un protocole de
calcul réparti sûr plus compliqué est nécessaire.
Ce type de vote peut exister dans la vie courante. Cela peut faire partie de la structure
d’une société où certaines personnes ont plus de pouvoir que d ’autres. Ou cela peut
faire partie des procédures de l’ONU où certaines nations ont plus de pouvoir que
d’autres.
Protocoles répartis inconditionnellement sûr

Il s’agit simplement d’un cas particulier d ’un théorème plus général: un ensemble de n
participants peut calculer évaluer n’importe quelle fonction à n arguments de sorte que
chacun connaîtra le résultat sans qu’un sous-ensemble de moins de n / 2 participants ne
puisse obtenir d’autre information que leurs arguments et l’information inhérente au
résultat. Pour les détails, voir [121, 339, 1299, 622].
Evaluation répartie sûre de circuits

Alice a sa donnée a, Bernard a sa donnée b. Ensemble, ils désirent calculer une certaine
fonction f{a,b) de manière qu’Alice n’apprenne rien sur la donnée de Bernard et que
Bernard n’apprenne rien sur la donnée d ’Alice. Le problème générique de calcul réparti
sûr est aussi appelé évalu a tion rép a rtie sûre d e circu its. Ici Alice et Bernard
peuvent créer un circuit booléen arbitraire. Ce circuit accepte les entrées d ’Alice et
de Bernard et produit une sortie. L’évaluation sûre de circuits est un protocole qui
accomplit trois choses :
1 . Alice peut entrer sa donnée sans que Bernard ne puisse la connaître.
2. Bernard peut entrer sa donnée sans qu’Alice ne puisse la connaître.
3. Alice et Bernard peuvent tous deux calculer la sortie en étant tous deux convain
cus que la sortie est correcte et que personne n ’a triché.
Les détails concernant les évaluations sûres de circuits peuvent être trouvés dans [832].
6.3 Diffusion de messages anonymes

Vous ne pouvez pas aller dîner avec un groupe de cryptographes sans qu’il y ait du
chahut. Dans [327], David C h a u m introduit le Problème du Dîner des Cryptographes:
« Trois cryptographes sont en train de dîner dans leur restaurant trois

étoiles favori. Leur serveur les informe que des arrangements ont été pris
avec le maître d’hôtel pour que la note soit payée anonymement. L ’un des
cryptographes peut avoir payé le dîner, ou cela peut être la NSA. Les
trois cryptographes respectent leur droit respectif d ’effectuer un paiement
anonyme mais ils aimeraient bien savoir quand c ’est la NSA qui paie. »
Comment les cryptographes, appelés Alice, Bernard et Christine, déterminent-ils si l’un

d’entre eux paie le repas tout en préservant l’anonymat du payeur?
C h a u m continue ainsi pour résoudre le problème :
« Chaque cryptographe lance une pièce non biaisée derrière son menu, entre
lui et le cryptographe à sa droite, de telle façon qu’eux deux seuls voient le
résultat du lancer. Chaque cryptographe annonce alors à haute voix si les
deux pièces qu’il peut voir — celle qu’il a lancée et celle que son voisin de
gauche a lancée — sont tombées sur la même face ou sur des faces opposées.
Si l’un des cryptographes est le payeur, il annonce le contraire de ce qu’il
voit. Un nombre impair de différences annoncé autour de la table indique
que l’un des cryptographes paie l’addition ; un nombre pair de différences
indique que la NSA paie (en faisant l’hypothèse que le repas n ’est payé
qu’une seule fois). Ainsi, si un cryptographe paie, aucun des deux autres
n’apprend quoi que ce soit concernant l’identité du payeur à partir des
annonces. »
Pour voir si cela marche, imaginez qu’Alice essaie de deviner quel autre cryptographe a
payé le dîner (en faisant l’hypothèse que ni elle ni la NSA n’ont payé). Si elle voit deux
6.3 Diffusion de messages anonymes 149
faces différentes, alors les deux autres cryptographes, Bernard et Christine, ont tous
deux annoncé « identiques », ou ils ont tous deux annoncé « différentes ». (Rappelez-
vous qu’un nombre impair de cryptographes annonçant « différentes » indique que
l’un d’entre eux paie.) Si tous les deux ont dit « différentes » alors le payeur est le
cryptographe le plus proche de la pièce qui est identique à la pièce cachée (celle qui
a été lancée entre Bernard et Christine). Si tous les deux ont dit « identiques » alors
le payeur est le cryptographe le plus proche de la pièce différente de la pièce cachée.
De même, si Alice voit deux faces identiques, alors soit Bernard a dit « identiques » et
Christine « différentes » ou inversément. Si la pièce cachée est la même que les deux
pièces qu’elle voit, alors le cryptographe qui a dit « différentes » est le payeur. Si la
pièce cachée est différente des deux pièces qu’elle voit, alors le cryptographe qui a dit
« identiques » est le payeur. Dans tous les cas, Alice doit connaître le résultat du lancer
entre Bernard et Christine pour déterminer qui a payé.
Ce protocole peut être généralisé pour n’importe quel nombre de cryptographes : ils sont
tous assis en rond et lancent des pièces entre eux. Même deux cryptographes peuvent
effectuer le protocole: bien sûr ils savent qui a payé mais quelqu’un qui observe le
protocole peut seulement dire si un des cryptographes a payé ou si la NSA a payé. Il
ne peut pas dire quel cryptographe a payé.
Les applications de ce protocole dépassent largement le cadre du restaurant. C ’est un
exemple d ’ a b s e n c e i n c o n d i t i o n n e l l e d e m o y e n d e r e t r o u v e r l ’ e x p é d i t e u r e t
le d e s t i n a t a i r e . Un groupe d ’utilisateurs d ’un réseau disposent du protocole suivant
pour échanger des messages anonymes.
1° Les utilisateurs s ’organisent sous forme d’un anneau logique.

2° A intervalles réguliers les paires d’utilisateurs adjacents lancent une pièce entre
eux, en utilisant un protocole équitable de jeu à pile ou face. Ils veillent à ce que
tous leurs messages soient chiffrés de manière qu ’ils soient les seuls à connaître
le résultat du lancer.
3° A intervalles réguliers chaque utilisateur annonce soit « identiques », soit « dif
férentes ».
Si les utilisateurs veulent diffuser cm message individuellement, ils commencent sim

plement à inverser les annonces dans les rondes correspondant à des 1 dans la repré
sentation binaire du message. Par exemple, si le message est « 1001 », ils inversent
leur réponse, disent la vérité, disent la vérité et finalement inversent leur réponse.
En faisant l’hypothèse que les résultats des lancers sont « différentes », « identiques »,
« identiques », « identiques », ils annoncent « identiques », « identiques », « identiques »,
« différentes ».
Si les utilisateurs détectent que le résultat du protocole ne correspond pas au mes
sage qu’ils essaient d’envoyer, ils savent que quelqu’un d’autre est également en train
d’essayer d’envoyer un message. Ils arrêtent alors de transmettre durant un nombre
aléatoire de rondes avant d’essayer à nouveau. Les paramètres exacts doivent être ba
sés sur le volume de messages circulant sur le réseau mais l’idée est claire.
Pour rendre les choses encore plus intéressantes, les messages peuvent être chiffrés par
les clefs publiques des uns et des autres. Alors, quand tout le monde reçoit le message
(une réalisation concrète de cela ajouterait des en-têtes et des conclusions de messages
standards), seul le destinataire légitime peut déchiffrer et lire le message. Personne
d’autre ne sait qui l’a envoyé. Personne ne sait qui peut le lire. L ’analyse de trafic, qui
trace et enregistre les motifs de communication entre les gens bien que les messages
soient eux-mêmes chiffrés, est inutile dans ce cas-là.
Une alternative au lancer de pièce entre participants adjacents est de partager un
fichier de bits aléatoires. Peut-être pourront-ils le ranger sur un CD-ROM, ou l’un
des membres de la paire pourra engendrer un paquet de bits aléatoires et les envoyer
à l’autre participant (en chiffrant le transfert bien sûr) ? Une autre possibilité est de
convenir de l’utilisation d ’un générateur pseudo-aléatoire de nombres et ils peuvent
alors chacun engendrer la même chaîne de bits pseudo-aléatoires pour le protocole.
Un problème dans ce protocole est le suivant: si un participant malveillant ne peut
lire aucun message, il peut par contre fausser le système sans être pris en mentant
à l’étape 3. Il existe une modification de ce protocole qui permet de détecter les
perturbations [1580, 1253] ; le problème s’appelle le « Dîner des Cryptographes à la
Discothèque ».
6.4 Argent électronique

L ’argent est un problème. C ’est gênant à transporter, cela peut répandre les maladies,
et on peut vous le voler. L ’existence des cartes de crédit a largement réduit la quantité
de monnaie qui circule dans notre société mais l’élimination complète de la monnaie
est virtuellement impossible. Cela n’arrivera jamais : les trafiquants de drogue et les
politiciens ne l’accepteront jamais. Les cartes de crédit et les chèques sont associées à
un relevé : vous ne pouvez pas cacher à qui vous donnez de l’argent.
D ’un autre côté, les chèques et les cartes de crédit autorisent une intrusion dans votre
vie privée à un degré jamais imaginé auparavant. Vous pourriez ne jamais avoir à faire
à la police de toute votre vie, mais la police peut surveiller vos transactions financières.
Ils peuvent voir où vous achetez de l’essence, de la nourriture, qui vous appelez au
téléphone, tout cela sans bouger de leur ordinateur. Les gens ont besoin d ’un moyen
de protéger leur anonymat pour protéger leur vie privée.
Heureusement, il existe un protocole compliqué qui permet des messages authentiques
mais dont on ne peut retrouver l’émetteur. Alice la lobbyiste peut transférer de l’argent
électronique au sénateur Bernard de manière que la journaliste Estelle ne connaisse
pas l’identité d’Alice. Bernard peut alors déposer cet argent électronique sur son compte
en banque, même si la banque n’a pas la moindre idée de qui est Alice. Mais si Alice
essaie de corrompre deux hommes politiques avec le même argent électronique — chose
facile à tenter avec un programme de copies de bits — elle sera repérée par la banque. Et
si Bernard essaie de déposer deux fois le même argent électronique sur deux comptes dif
férents, il sera repéré — mais Alice restera anonyme. On nomme aussi cela de l’argent
électronique anonyme pour le différencier de l’argent élctronique avec relevé comme
les cartes de crédit.
La demande sociale pour ce genre de choses est forte. Avec la montée d’Internet dans
les transactions commerciales, il y a un appel grandissant pour la préservation de la vie
privée dans les réseaux et l’anonymat dans les affaires3. D ’un autre côté, les banques et
les gouvernements ne veulent pas abandonner le contrôle que leur procure les systèmes
actuels de paiement avec relevé. Ils y seront contreints pourtant. Tout ce dont il suffit
3. Les gens ont de bonnes raisons d’être rétissants avant d’envoyer leur numéro de carte de crédit
via Internet.
6.4 Argent électronique 151
pour Lancer l’argent électronique, c ’est une institution de confiance qui changera les
nombres numériques contre de l’argent officiel.
Les protocoles d’argent électronique sont très compliqués. Nous allons en mettre un
sur pied, étape par étape. Pour plus de détails lisez [322, 344, 330, 340, 345]. Rendez
vous bien compte qu’il s’agit là d’un seul protocole d’argent électronique, il en existe
d’autres.
Protocole n° 1
Les quelques premiers protocoles sont des analogies matérielles des protocoles crypto-
graphiques. Le protocole suivant est un protocole matériel pour des ordres de paiement
anonymes :
1° Alice prépare 100 ordres de paiement anonymes de 1000 francs.
2° Alice place chacun d’entre eux avec une feuille de carbone dans 100 enveloppes
différentes. Elle donne le tout à la banque.
3° La banque ouvre 99 enveloppes et confirme que chacune d’entre elles contient

bien un ordre de paiement d’un montant de 1 0 0 0 francs.
4° La banque signe la seule enveloppe non ouverte restante. La signature passe

à travers le carbone sur l’ordre de paiement. La banque rend l’enveloppe non
ouverte à Alice et retire 1 000 francs de son compte.
5° Alice ouvre l’enveloppe et utilise l’ordre de paiement chez un commerçant.
6° Le commerçant vérifie la signature de la banque pour s ’assurer que l’ordre de

paiement est légitime.
7° Le commerçant porte l’ordre de paiement à la banque.
8° La banque vérifie sa signature et crédite le compte du commerçant de

1 0 0 0 francs.
Ce protocole marche. La banque ne voit jamais l’ordre de paiement lors de la signature,

donc quand le commerçant l’apporte à la banque, celle-ci ne sait pas qu’il est d’Alice.
La banque est toutefois convaincue qu’il est valide grâce à sa signature. La banque
est persuadée que le montant de l’ordre de paiement non ouvert est de 1 0 0 0 francs
(et non pas de 1 0 0 0 0 0 francs ou de 1 0 0 0 0 0 0 0 0 francs) grâce à la technique « couper-
et-choisir » (voir § 5.1). Elle vérifie les 99 autres enveloppes, Alice n’a donc que 1 %
de chance de tromper la banque. Bien sûr, en cas de tricherie, la banque infligera une
amende d’un montant tel que cela découragera toute tentative. Si la banque refuse de
signer le dernier chèque (si Alice est prise en flagrant délit de tricherie) sans aucune
punition, Alice pourrait continuer jusqu’à ce qu’elle ait de la chance4.
Protocole n° 2
Le protocole précédent empêche Alice d ’indiquer un montant supérieur à ce qu’elle est
en droit de prétendre sur un ordre de paiement, mais rien ne l’empêche de photocopier
4. Les peines de prison sont de bons moyens de dissuasion.

l’ordre de paiement et de l’utiliser deux fois. Pour éviter cela nous devons compliquer
le protocole :
1° Alice prépare 100 ordres de paiement anonymes de 1000 francs chacun. Sur
chaque ordre de paiement elle ajoute une chaîne aléatoire différente et unique,
suffisamment longue pour que les chances qu’un autre utilisateur utilise la
même chaîne soient négligeables.
3° La banque ouvre 99 enveloppes et confirme qu’il s ’agit bien d’ordres de paiement

pour un montant de 1 0 0 0 francs, et que les chaînes aléatoires uniques sont bien
différentes.
4° La banque signe la dernière enveloppe non ouverte. La signature passe à travers

le carbone sur l’ordre de paiement. La banque rend l’enveloppe non ouverte à
Alice et retire 1000 francs de son compte.

8° La banque vérifie sa signature et contrôle sa base de données pour vérifier qu ’un

ordre de paiement avec la même chaîne aléatoire unique n’a pas déjà été déposé
auparavant. Si tout est en ordre, la banque crédite le compte du commerçant du
montant de 1000 francs. La banque enregistre la chaîne aléatoire unique dans
sa base de données.
9° Si cet ordre de paiement a déjà été déposé auparavant, la banque n’acceptera

pas l’ordre de paiement.
Dès lors, si Alice essaie d ’utiliser une photocopie de l’ordre de paiement, ou si le com
merçant essaie d ’encaisser une photocopie de l’ordre de paiement, la banque le détec
tera.
Protocole n° 3
Le protocole précédent protège la banque de la tricherie mais il ne permet pas l’identifi
cation du tricheur. La banque ne sait pas si la personne qui a acheté l’ordre de paiement
(la banque ne peut pas savoir que c ’est Alice) a essayé de rouler le commerçant ou si
le commerçant a essayé de rouler la banque. Le protocole suivant corrige ce défaut :
1° Alice prépare 100 ordres de paiement anonymes de 1000 francs chacun. Sur
chaque ordre de paiement elle ajoute une chaîne aléatoire différente et unique,
suffisamment longue pour que les chances qu’un autre utilisateur utilise la
même chaîne soient négligeables.
6.4 Argent électronique 15S
3° La banque ouvre 99 enveloppes et confirme qu’il s ’agit bien d’ordres de paiement

pour un montant de 1 0 0 0 francs, et que les chaînes aléatoires uniques sont bien
différentes.
4° La banque signe la dernière enveloppe non ouverte. La signature passe à travers
le carbone sur l’ordre de paiement. La banque rend l’enveloppe non ouverte à
Alice et retire 1 000 francs de son compte.
7° Le commerçant demande à Alice d’écrire une chaîne d’identification aléatoire
sur l’ordre de paiement.
8° Alice s ’exécute.
9° Le commerçant apporte l’ordre de paiement à la banque.
10° La banque vérifie la signature et contrôle sa base de données pour vérifier qu’un
ordre de paiement avec la même chaîne aléatoire unique n’a pas déjà été déposé
auparavant. Si tout est en ordre, la banque crédite le compte du commerçant
du montant de 1000 francs. La banque enregistre la chaîne aléatoire unique et
la chaîne aléatoire d’identification dans sa base de données.
1 1 ° Si la chaîne aléatoire unique est dans sa base de données, la banque refuse
d’accepter l’ordre de paiement. Ensuite, elle compare la chaîne d’identification
avec celle qui est enregistrée dans sa base de données. Si c ’est la même, la
banque sait que c ’est le commerçant qui a fait une photocopie de l’ordre de
paiement. Si elle est différente, la banque sait que c ’est la personne qui a acheté
l’ordre de paiement qui l’a photocopié.
Ce protocole fait l’hypothèse que le commerçant ne peut pas modifier la chaîne d’iden
tification une fois qu’Alice l’a écrite sur l’ordre de paiement. L’ordre de paiement peut
avoir une suite de petites cases que le commerçant demandera à Alice de remplir avec
des X ou des O. L’ordre de paiement serait fait de papier qui se déchire si l’on tente
d’effacer.
Comme l’interaction entre le commerçant et la banque a lieu après qu’Alice a dépensé
l’argent, le commerçant reste avec un mauvais ordre de paiement sur les bras. Des
réalisations pratiques de ce protocole nécessitent qu’Alice attende près de la caisse
pendant l’interaction entre le commerçant et la banque tout comme pour les cartes de
crédit aujourd’hui.
Alice peut essayer de rouler le commerçant. Elle peut essayer d ’utiliser une copie de
l’ordre de paiement une seconde fois en donnant la même chaîne d ’identification à
l’étape 7. A moins que le commerçant n’enregistre les ordres de paiement qu’il reçoit
dans une base de données, le commerçant se fera rouler. Le protocole suivant élimine
ce défaut.
Protocole n° 4
S’il s’avère que la personne qui a acheté l’ordre de paiement a essayé de rouler le
commerçant, il incombe à la banque de déterminer l’identité du tricheur. Pour ce faire
nous devons quitter le monde matériel pour celui de la cryptographie.
La technique du morcellement de secret peut être utilisée pour cacher le nom d’Alice
dans l’ordre de paiement numérique.
1° Alice prépare n ordres de paiement anonymes d’une somme donnée.

Chaque ordre de paiement contient une chaîne aléatoire unique différente, X ,
assez longue pour que la chance d’en avoir deux identiques soit négligeable.
Sur chaque ordre de paiement, il y a aussi n paires de chaînes de bits d ’identifi
cation, I i ,l 2 , . . . ,In- Cela fait n paires différentes sur chaque chèque. Chacune
de ces paires est engendrée de la façon suivante: Alice crée une chaîne qui
contient son nom, son adresse et toute autre information que la banque désire
quant à son identité. Ensuite elle coupe cette chaîne en deux morceaux en utili
sant le protocole de morcellement de secret (voir § 3.6). Enfin elle met en gage
chaque morceau en utilisant un protocole de mise en gage de bits.
Par exemple, I37 est constituée de deux parties : Iz7G et IyjD■ Chaque partie
est un paquet de bits mis en gage dont on peut demander l’ouverture à Alice,
et dont l’ouverture correcte peut être instantanément vérifiée. Toute paire I ^ G
et h rD’ Par exemple, révèle l’identité d’Alice (mais pas l 37G et h%D). Chacun
des ordres de paiement ressemble à ceci :
Montant : . . . francs
Chaîne unique: X
Chaîne d’identification: I\ = (I\G,lyD)
h = { h a J 2 D)
ln (^nci^np)
2° Alice camoufle les n ordres de paiement en utilisant le protocole de signature

aveugle. Elle donne le tout à la banque.
3° La banque demande à Alice de retirer le camouflage de n — 1 ordres de paie
ment et confirme qu’ils sont conformes. La banque vérifie le montant, la chaîne
unique et demande à Alice de révéler toutes les chaînes d’identification.
4° Si la banque constate qu’Alice n’a pas fait de tentative de tricherie, elle signe
Tordre de paiement camouflé restant. La banque rend à Alice l ’ordre de paie
ment camouflé et retire le montant de son compte.
5° Alice retire le camouflage de Tordre de paiement et l’utilise chez un commer
çant.
6° Le commerçant vérifie la signature de la banque pour s ’assurer de la légitimité
de Tordre de paiement.
7° Le commerçant demande à Alice de révéler aléatoirement la moitié gauche ou
la moitié droite de chacune des chaînes d’identité de Tordre de paiement. En
fait, le commerçant donne à Alice une chaîne d e sélection aléatoire de n
bits: bi, b-2 , ..., bn. Alice ouvre soit la partie gauche, soit la partie droite de L
suivant que bi vaut 0 ou 1.
8° Alice s ’exécute.
10° La banque vérifie la signature et contrôle sa base de données ■pour vérifier qu’un
ordre de paiement avec la même chaîne aléatoire unique n’a pas été déposé
auparavant. Si tout est en ordre, la banque crédite le compte du commerçant
du montant de 1000 francs. La banque enregistre la chaîne aléatoire unique et
toutes les informations d’identification dans sa base de données.
11° Si la chaîne aléatoire unique est dans sa base de données, la banque refuse
d’accepter l’ordre de paiement. Ensuite, elle compare la chaîne d’identification
sur l’ordre de paiement avec celle qui est enregistrée dans sa base de données.
5* c 'est la même, la banque sait que c ’est le commerçant qui a fait une photo
copie de l ’ordre de paiement. Si elle est différente, la banque sait que c ’est la
personne qui a acheté l’ordre de paiement qui l’a photocopié. Comme le second
commerçant — qui a accepté l’ordre de paiement d’Alice — lui a donné une
autre chaîne de sélection que le premier commerçant, la banque trouvera une
position de bit où l’un des commerçants a demandé d’ouvrir la moitié gauche
et l’autre commerçant a demandé d’ouvrir la moitié droite. La banque calcule
le ou exclusif des deux moitiés pour retrouver l’identité d’Alice.
C’est un protocole étonnant, aussi regardons-le sous différents angles.

Alice peut-elle tricher? Son ordre de paiement numérique n’est rien d ’autre qu’une
chaîne de bits, donc elle peut la copier. L’utiliser une première fois ne pose pas de
problème : elle exécute tout le protocole et tout va très bien. Le commerçant lui donnera
une chaîne de sélection aléatoire à l’étape 7 et Alice ouvrira soit la partie gauche, soit
la partie droite de chaque I, à l’étape 8 . A l’étapelO, la banque enregistrera toutes ces
données ainsi que la chaîne unique de l’ordre de paiement.
Quand Alice essaie d ’utiliser le même ordre de paiement numérique une seconde fois,
le commerçant (soit le même commerçant soit un autre) lui donnera une autre chaîne
de sélection aléatoire à l’étape 7. Alice doit s’exécuter à l’étape 8 : ne pas le faire
signalerait immédiatement l’anomalie au commerçant. Si le commerçant apporte l’ordre
de paiement à la banque à l’étape 1 0 , la banque remarquera immédiatement qu’un ordre
de paiement avec la même chaîne unique a déjà été déposé. La banque compare alors
les moitiés ouvertes des chaînes d ’identification. Les chances que les deux chaînes de
sélection soient les mêmes sont de 1 pour n ; cela a peu de chance de se produire d’ici
à la prochaine ère glaciaire. La banque trouve alors une paire dont la moitié gauche
a été ouverte la première fois et la moitié droite a été ouverte la deuxième fois. Elle
calcule le ou exclusif des deux moitiés et découvre le nom d’Alice. La banque sait qui
a essayé d’utiliser cet ordre de paiement deux fois.
Le protocole ne nécessite pas la présence d ’Alice tandis que la banque et le commerçant
exécutent leur part du protocole. Ce n’est que si Alice triche que la banque connaît
son identité. Alice ne peut pas empêcher que son identité soit révélée. Elle ne peut pas
modifier la chaîne unique ni les chaînes d’identification car dans ce cas la signature de
la banque ne serait plus valable. Le commerçant s’en rendrait immédiatement compte
à l’étape 6 .
Alice peut essayer subrepticement de faire passer un ordre de paiement aux dépens
de la banque, un ordre sur lequel les chaînes d’identification ne révéleraient pas son
nom ou mieux encore, un ordre dont les chaînes d’identification donneraient le nom
de quelqu’un d’autre. Les chances de réussir cette ruse à l’étape 3 sont de 1 sur n. Ce
n’est pas si improbable que cela mais si la pénalité est assez lourde, Alice n’essaiera
pas. Ou, vous pouvez augmenter le nombre d ’ordres de paiement qu’Alice doit préparer
à l’étape 2 .
Est-ce que le commerçant peut tricher? Ses chances sont encore moins grandes. Il
ne peut pas encaisser l’ordre de paiement deux fois : la banque détecterait la double
utilisation de la chaîne de sélection. Il ne peut pas reporter la faute sur Alice, seule
Alice peut ouvrir les chaînes d ’identification.
Même une collusion entre Alice et le commerçant ne peut pas duper la banque. Comme
la banque signe l’ordre de paiement avec la chaîne unique, elle est sûre de ne payer cet
ordre qu’une fois.
Qu’en est-il de la banque? A-t-elle un moyen de déterminer qu’un ordre de paiement
encaissé a été signé pour Alice? Alice est protégée par le protocole de signature en
aveugle des étapes 2 à 5. La banque ne peut faire le lien, même si elle garde un enre
gistrement complet de toutes les transactions. Bien mieux, la banque et le commerçant
n’ont aucun moyen de se mettre ensemble pour déterminer qui est Alice. Alice peut
entrer dans le magasin et dans le plus complet anonymat faire ses achats.
Estelle peut tricher. Elle peut espionner la communication entre Alice et le commerçant,
et si elle peut aller à la banque avant lui, elle peut porter l’ordre de paiement à la banque
en premier. La banque l’acceptera, et même pire, quand le commerçant viendra porter
son ordre de paiement, il sera suspecté de tricherie. Si Estelle vole et dépense l’argent
électronique d’ Alice avant cell-ci, c’est Alice qui sera suspectée de tricherie. Il n’y a
aucun moyen d ’empêcher cela; c ’est la conséquence directe de l’anonymat procuré par
l’argent électronique. Alice et le commerçant doivent tous les deux protéger leurs bits
comme ils le feraient avec des billets.
Ce protocole se situe quelque part entre les protocoles arbitrés et les protocoles auto-
arbitrés. Alice et le commerçant font confiance à la banque pour qu’elle honore les
ordres de paiement, mais Alice n’a pas confiance dans la banque en ce qui concerne
son identité.
Argent électronique et crime parfait

L’argent électronique a aussi son mauvais côté. Parfois, les gens ne veulent pas autant
d’anonymat. Observons Alice en train de commettre le crime parfait [1577] :
1 ° Alice kidnappe un bébé.

2 ° Alice prépare 10000 ordres de paiement anonymes de 1 000 francs chacun (ou
autant qu ’elle veut pour le montant qu ’elle veut).
3° Alice camoufle les 10 000 ordres de paiement en utilisant un protocole de signa

ture en aveugle. Elle envoie les résultats aux autorités en menaçant de tuer le
bébé si les instructions suivantes ne sont pas suivies à la lettre :
( a ) faites signer les 1 0 0 0 0 ordres de paiement par une banque;

(b) publiez les résultats dans un quotidien.
4° Les autorités s ’exécutent.

5° Alice achète le journal, retire le camouflage des ordres de paiement, et com
mence à les utiliser. Les autorités n’ont aucun moyen de faire le lien entre les
ordres de paiement et Alice.
6° Alice libère le bébé.
Cette situation est autrement dramatique que toute autre impliquant des biens ma
tériels (de l’agent liquide par exemple). Comme il n’y a pas de contact physique, la
police a moins de chances d’appréhender le ravisseur.
En général, cependant, l’argent électronique n’est pas une bonne affaire pour les crimi
nels. Le problème vient du fait que l’anonymat ne marche que dans un sens: l’acheteur
est anonyme, mais pas le vendeur. De plus, le vendeur ne peut pas cacher le fait qu’il a
reçu de l’argent électronique. Avec l’argent électronique, le gouvernement pourra faci
lement déterminer combien d ’argent vous recevez, mais pas comment vous le dépensez.
Argent électronique pratique

Une société néérlandaise, D ig i C a s h , possède la plupart des brevets existants en la
matière, et a réalisé des protocoles d ’argent électronique dans des produits qui fonc
tionnent. Toute personne intéressée doit contacter DigiCash BV, Kruislaan 419,
1098 VA Amsterdam, Pays-Bas.
Autres protocoles d’argent électronique

Il existe d’autres protocoles d’argent électronique; voir [708, 6 6 , 736, 1635, 985].
Certains d’entre eux mettent en jeu des mathématiques assez compliquées. En général,
on peut distinguer diverses catégories de protocoles d ’argent électronique.
Dans les systèmes en ligne, le commerçant doit communiquer la banque à chaque
vente, ce qui ressemble aux protocoles actuels de carte de crédit. S’il y a un problème,
la banque reffuse d’encaisser et Alice ne peut pas tricher.
Dans les systèmes au ton om es, comme le protocole n° 4, aucune communication entre
le commerçant et la banque n’est nécessaire durant la transaction. Ces systèmes n’em
pêchent pas Alice de tricher, mais détectent toute tricherie éventuelle. Alice sait que
cela arrivera, aussi elle ne triche pas.
Une autre solution est de créer une carte à mémoire spéciale (voir § 24.13) contenat
une puce résistante à l’investigation appelée observatrice [336, 346, 391]. La puce
observatrice garde une mini-base de données contenant toutes les dépenses d’argent
électronique faites avec cette carte. Si Alice essaye de copier de l’argent électronique
et de le dépenser deux fois, la puce observatrice détectera la tentative et empêchera la
transaction. Comme la puce résiste à l’investigation, Alice ne peut effacer la mini-base
de données sans endommager la carte. L ’argent peut passer de main en main, et quand
il est finalement déposé, la banque peut déterminer qui a triché, s’il y a lieu.
Les protocoles d’argent électronique peuvent être classés selon un autre critère. Dans
les systèmes de porte monnaie électronique, on utilise des sommes fixes; on a alors
besoin de différentes pièces représentant différents montants. Les chèques électro
niques permettent de régler n’importe quel montant jusqu’à une valeur maximale et
la partie non dépensée est rendue pour se faire rembourser.
Deux excellents et complètement différents protocoles d’argent électronique autonomes
se trouvent dans [227, 228, 229] et [565, 567, 566]. Un système appelé N e t C a s h pré
sente des propriétés d ’anonymat plus restreintes [1057, 1056]. Un autre système récent
est [293].
Dans [1219], Tat.suaki O k a m o t o et Kazuo O h t a donnent la liste de 6 propriétés que

devrait satisfaire un système d’argent, électronique idéal :
1. L ’indépendance. La sécurité de l’argent électronique ne doit dépendre d ’aucune

localisation physique. L’argent peut être transféré par des réseaux informatiques.
2. Sécurité. L ’argent électronique ne peut pas être copié et réutilisé.
3. Anonymat (absence de possibilité d ’identifier l’émetteur). L ’anonymat

des utilisateurs est protégé : personne ne peut retrouver les liens entre les utilisa
teurs et les achats.
4. Paiement hors-ligne. Quand un utilisateur paie un achat avec de l’argent élec

tronique, le protocole entre l’utilisateur et le commerçant est exécuté hors-ligne.
C ’est-à-dire, que le commerce n’a pas à être relié à un ordinateur central pour
traiter le paiement de l’utilisateur.
5. Transférabilité. L’argent électronique peut être transféré à d’autres utilisateurs.
6. Divisibilité. Une pièce d ’argent électronique d ’un certain montant peut être
subdivisée en pièces d ’argent plus petites de montants moins élevés. (Bien sûr,
les totaux doivent être corrects au bout du parcours.)
Les protocoles présentés ici satisfont les propriétés 1, 2, 3 et 4 mais pas 5 et 6 . Il

existe des systèmes d ’argent électronique en-ligne qui satisfont toutes les propriétés
sauf la quatrième [322, 417, 1252]. Le premier système d ’argent électronique hors-ligne
qui satisfait les propriétés 1, 2, 3 et 4, similaire à ceux décrits ci-avant, est décrit
dans [344]. O k a m o t o et O h t a proposent un système qui satisfait les propriétés 1 à
5 [1217] ; ils proposent également un système qui satisfait les propriétés 1 à 6 mais le
volume des données à traiter pour l’achat d ’un seul article est approximativement de
200 méga-octets. Un autre système de porte monnaie électronique est décrit dans [524].
Le schéma d ’argent électronique proposé dans [1219], des mêmes auteurs, satisfait les
propriétés 1 à 6 mais sans la nécessité de cet énorme volume de données. La taille totale
du transfert de données pour un seul achat est d ’environ 2 0 kilo-octets et le protocole
peut être effectué en quelques secondes. Les auteurs considèrent que c ’est le premier
système d ’argent électronique idéal sans possibilité d’identification de l’acheteur.
Cartes de crédit anonymes

Ce protocole [998] utilise plusieurs banques différentes pour préserver l’identité du
consommateur. Chaque consommateur possède un compte dans deux banques diffé
rentes. La première banque connaît l’identité de la personne et lui procure du crédit.
La seconde ne connaît le consommateur que sous un pseudonyme (similaire à un compte
numéroté dans une banque Suisse).
Le consommateur peut retirer des fonds dans la seconde banque en prouvant que le
compte est bien le sien. Cependant la banque ne connaît pas la personne et ne veut pas
lui donner de crédit. La première banque connaît le client et transfert les fonds vers
la seconde banque— sans savoir le pseudonyme. Le consommateur peut alors dépenser
ces fonds de manière anonyme. A la fin du mois, la seconde banque donne une note
à la première banque, dont la solvabilité lui inspire confiance. La première banque
passe la note au consommateur; elle a confiance en sa solvabilité puisqu’elle le connaît.

Quand le consommateur paye, la première banque transfert des fonds additionnels vers
la seconde banque. Toutes les transactions se font par un intermédiaire, qui agit comme
une banque d’Etat électronique: il instaure des comptes entre les banques, fait passer
les messages et créé des relevés.
Les échanges entre le client, le marchant, et les diverses banques sont abordés dans
[998]. A moins que tout le monde ne se ligue contre le client, son anonymat est assuré.
Cependant, ce n’est pas de l’argent électronique, la banque peut facilement tricher. Le
protocole procure aux clients les avantages de la carte de crédit sans dévoiler leur vie
privée.
Deuxième partie
Techniques cryptographiques
Chapitre 7
Longueur des clefs
7.1 Longueur des clefs secrètes

La sécurité d’un cryptosystème à clef secrète dépend de deux choses : la solidité de
l’algorithme et la longueur de la clef. La première caractéristique est plus importante
mais la deuxième est plus facile à illustrer.
Faisons l’hypothèse que la solidité de l’algorithme est parfaite. Cela est très difficile
à réaliser en pratique mais nous supposerons que c’est faisable dans cet exemple. Par
solidité parfaite, je veux dire qu’il n’existe pas de meilleur moyen de casser le crypto
système que d’essayer toutes les clefs possibles : on parlera alors d ’attaque exhaustive.
Pour lancer une telle attaque, un cryptanalyste a besoin d ’un petit bout de texte chiffré
et du texte en clair correspondant; une attaque exhaustive est une attaque à texte en
clair connu. Dans le cas d’un chiffrement par blocs, le cryptanalyste aura besoin d ’un
bloc de texte chiffré et du texte en clair correspondant: en général 64 bits. Obtenir cette
paire de texte chiffré et de texte en clair est plus facile que vous ne pourriez l’imaginer.
Un cryptanalyste peut obtenir une copie d’un message en clair par certains moyens
et intercepter le texte chiffré correspondant. U est possible qu’il connaisse quelque
chose sur le format du texte chiffré; par exemple, c’est un fichier écrit sous W o r d , il
est précédé de l’entête standard des courriers électroniques, c’est un fichier répertoire
UNIX, une image au format T IF F , ou encore une fiche standard dans une base de
donnée. Tous ces formats présentent des octets prédéfinis. Le cryptanalyste n’a pas
besoin de texte en clair pour lancer cette attaque.
Il est facile de calculer la complexité d’une attaque exhaustive. Si la clef a 8 bits, il y a
28 = 256 clefs possibles. Il faudra donc 256 tentatives pour trouver la bonne clef et en
moyenne 128 suffiront. Si la clef a 56 bits, il y a alors 2 56 k 7,2 x 10ie clefs possibles. En
faisant l’hypothèse qu’un super-ordinateur peut essayer un million de clefs par seconde,
il faudra 2 000 ans pour trouver la bonne clef. Si la clef a 64 bits, il faudra alors 600 000
ans à ce même super-ordinateur pour trouver la bonne clef parmi les 2 64 « 1 , 8 x 1 0 19
clefs possibles. Si la clef a 128 bits, il faudra 1025 années. L ’univers est âgé d’environ
1010 ans, et donc 1025 ans est probablement suffisant. Avec une clef de 2 048 bits, un
million de super-ordinateurs hypothétiques travaillant en parallèle passeraient 1 0 597
années pour trouver la clëf. D ’ici là, l’univers peut déjà avoir implosé ou s’être répandu
dans le néant.
164 Chapitre 7 Longueur des clefs
Avant de vous précipiter pour inventer un cryptosystème avec une clef de 8 kilo-octets,
rappelez-vous qu’il y a une autre condition à satisfaire : l’algorithme doit être suffisam
ment solide pour qu’il n’y ait pas d ’autre attaque possible que l’attaque exhaustive. Ce
n’est pas aussi facile qu’il y paraît. La cryptographie est un art subtil. Les cryptosys
tèmes qui semblent parfaits sont souvent mauvais. Des cryptosystèmes solides peuvent
être grandement affaiblis par de toutes petites modifications. Deux cryptosystèmes so
lides utilisés ensemble sans précautions peuvent interagir entre eux et produire des
textes codés faciles à déchiffrer. Le meilleur conseil que l’on puisse donner au cryp
tographe amateur est de suspecter tout nouvel algorithme et ce, même avec un petit
brin de paranoïa. Il vaut mieux avoir confiance en un algorithme parce que des crypto
graphes professionnels l’ont examiné sous toutes ses coutures pendant de nombreuses
années sans trouver de failles, plutôt que parce que les inventeurs d ’un algorithme
clament haut et fort que leur algorithme est inviolable.
Rappelez vous une remarque importante faite au paragraphe 1.1 : la sécurité d’un cryp
tosystème doit résider dans la clef et non pas dans les détails de l’algorithme. Faites
toutes les hypothèses suivantes : 1 - 1 ’attaquant a accès à tous les détails de votre algo
rithme. 2 —il a accès à autant de texte chiffré qu’il le souhaite et il peut attaquer votre
algorithme grâce à des textes chiffrés seulement. 3- il peut monter une attaque à texte
en clair. 4—il peut monter une attaque à texte en clair choisi. Si votre cryptosystème
reste sûr même avec toute cette connaissance dans les mains de l’attaquant, alors vous
avez atteint le niveau de sécurité souhaitable.
Cet avertissement mis à part, il y a suffisamment de marge de manœuvre dans le
domaine de la cryptographie. Dans la vie de tous les jours, il y a des situations où un
tel niveau de sécurité n’est pas vraiment nécessaire. La plupart des attaquants n’ont
pas les connaissances et les ressources de nos Gouvernements, et même ceux qui ont
de tels moyens ne sont pas forcément intéressés à casser votre cryptosystème. Si vous
avez l’intention de comploter pour renverser un Gouvernement, alors tenez-vous en aux
algorithmes éprouvés décrits à la fin de cet ouvrage. Pour les autres : amusez-vous !
Estimation du temps et du coût d’une attaque exhaustive

Rappelez vous qu’une attaque exhaustive est une attaque à texte en clair connu; elle
ne requiert qu’une petite quantité de texte chiffré et de texte en clair correspondant.
Si vous faites l’hypothèse que l’attaque la plus efficace contre un algorithme est une
attaque exhaustive (une hypothèse très forte s’il en est !), quelle doit être la longueur
de la clef pour qu’une telle attaque soit impraticable?
Deux paramètres déterminent la vitesse d’une attaque exhaustive : le nombre de clefs
à tester et la vitesse de chaque test. La plupart des algorithmes à clef secrète acceptent
comme clef n’importe quel motif de bits de longueur fixe. L’algorithme DES a une
clef de 56 bits, il y a donc 256 clefs possibles. Certains algorithmes présentés dans cet
ouvrage ont une clef de 64 bits ; il y a donc 264 clefs possibles pour de tels algorithmes.
D ’autres encore ont une clef de 128 bits.
La vitesse à laquelle on peut tester une clef est un facteur déterminant mais, toutefois, il
est moins important. Dans ce qui suit, je ferai l’hypothèse que le temps mis pour tester
une clef est le même pour tous les algorithmes. Dans la réalité, pour un algorithme
donné, une clef pourrait être testée deux, trois voire même dix fois plus vite que pour
un autre algorithme. Ce petit facteur n ’est pas important car ce que nous regardons
ci-après c ’est ce qui rend une attaque exhaustive impraticable par un facteur « un
7.1 Longueur des clefs secrètes 165
million » ou plus !
La communauté cryptographique s’est surtout concentrée sur l’ attaque exhaustive de
l’algorithme DES. En 1977, Whitfield D i f f i e et Martin H e l l m a n [495] ont décrit
une machine hypothétique. Elle serait composée d’un million de processeurs et chacun
de ces processeurs serait capable de tester un million de clefs par seconde. Une telle
machine pourrait tester 256 clefs en 20 heures. Si une telle machine était construite
pour attaquer une clef de 64 bits, elle testerait les 264 clefs en 214 jours.
L’attaque exhaustive est faite pour les processeurs parallèles. Chaque processeur peut
tester un sous-ensemble des clefs. Les processeurs n’ont pas à communiquer entre eux :
la seule communication nécessaire est un message indiquant la réussite et la clef pour
laquelle elle a été obtenue. U n’y a pas de contraintes de mémoire partagée. Il est facile
de concevoir une telle machine parallèle avec un million de processeurs, chacun d ’entre
eux calculant indépendamment des autres.
Plus récemment, Michael Wiener a décidé de concevoir une machine spécialement dé
diée à la recherche exhaustive [1599, 1600] L II a conçu des puces et des cartes spéciali
sées. Après estimation des prix, il s’est aperçu qu’on pouvait construire pour 1 million
de dollars une machine capable de casser une clef de 56 bits dans un temps moyen
de trois heures et demi (et sept heures au pire). De plus le rapport prix sur vitesse
est linéaire. Le tableau 7.1 donne une généralisation de ces résultats pour différentes
longueurs de clef. Rappelez vous de la loi de M o o r e : la puissance de calcul des or
dinateurs double tous les 18 mois environ. Cela signifie que le coût est divisé par 10
tous les cinq ans; ce qui coûte 1 million de dollars en 1995 sera construit pour 100 000
dollars en l’an 2000. Les ordinateurs systoliques pourraient même faire mieux [726].
Tab. 7.1 - Estimation du temps moyen d’une attaque exhaustive par une machine
dédiée construite en 1995.
Longueur de la clef en bits

Coût 40 56 64 80 112 128
100 K$ 2 sec. 35 heures 1 an 700 siècles 1 0 14 ans 1 0 19 ans
IMS 0 ,2 sec. 3,5 heures 37 jours 70 siècles 1 0 1 3 ans 1 0 18 ans
10 M$ 0 ,0 2 sec. 2 1 min. 4 jours 7 siècles 1 0 1 2 ans 1 0 17 ans
100 M$ 2 millisec. 2 min. 9 heures 70 ans 1 0 1 1 ans 1 0 16 ans
1 G$ 0 , 2 millisec. 13 sec. 1 heure 7 ans 1 0 10 ans 1 0 15 ans
10 G$ 0 ,0 2 millisec. 1 sec. 5,4 min. 245 jours 1 0 9 ans 1 0 14 ans
100 G$ 2 microsec. 0 , 1 sec. 32 sec. 24 jours 1 0 8 ans 1 0 13 ans
1 G$ 0 ,2 microsec. 0 , 0 1 sec. 3 sec. 2,4 jours 1 0 7 ans 1 0 12 ans
10 G$ 0 ,0 2 microsec. 1 millisec. 0,3 sec. 6 heures 1 0 ® ans 10 11 ans
Pour les clefe de 56 bits, c’est à la portée de la plupart des grandes entreprises et
de nombreuses organisations criminelles. Les budgets militaires des nations les plus
industrialisées permettraient de construire une machine à casser les clefs de 64 bits.
Casser une clef de 80 bits est toujours hors de portée, mais si la tendance actuelle
continue, cela changera dans 30 ans seulement.
U est bien sûr ridicule d ’estimer la puissance des ordinateur à venir dans 30 ans.
Une avancée dans quelque technologie de science-fiction pourrait faire de ces chiffres
1. II a conçu la machine pour DES, mais l’analyse tient pout la plupart des algorithmes.
une histoire drôle. À l’opposé, des limitations physiques encore inconnues pourraient
impliquer qu’ils sont exagérément optimistes. En cryptographie, il vaut mieux être
pessimiste. Opter pour un algorithme avec des clefs de 80 bits semble une vue à très
court terme. Il faut des clefs d ’au moins 112 bits.
Si un attaquant veut vraiment trouver une clef, tout ce qui lui reste à faire est de dé
penser le montant nécessaire. En conséquence, il semble prudent d’estimer la « valeur »
minimale d ’une clef: quelle valeur peut être attribuée à une clef avant que cela n’ait
un sens économique de la trouver ? Pour donner un exemple extrême, si un message en
clair vaut 1,39 $, cela n’aurait pas grand sens de dépenser 10 million de dollars pour
trouver la clef. D ’un autre côte, si le message en clair vaut 100 million de dollars, alors
le déchiffrement de ce seul message justifierait la dépense. Notons aussi que la valeur
de certains messages décroît rapidement avec le temps.
Méthodes logicielles de recherche exhaustive

Sans matériel spécialisé et sans machines massivement parallèles, une attaque exhaus
tive est significativement plus difficile. Une attaque exhaustive par logiciel est environ
1 0 0 0 fois plus lente qu’avec une machine dédiée.
L’avantage d’une attaque exhaustive par logiciel n’est pas sa rapidité mais bien le
fait qu’elle est « gratuite ». Cela ne coûte rien de faire chercher des clefs à un micro
ordinateur quand il ne fait rien d’autre. S’il trouve une clef, tant mieux. S’il n’en trouve
pas, rien n’est perdu. Rien n’empêche de mettre un réseau entier de micro-ordinateurs
à la tâche. Une expérience récente avec l’algorithme DES a utilisé le temps libre de
40 stations de travail pour tester 234 clefs en un seul jour [605]. A cette vitesse, cela
prendrait 4 millions de jours pour tester toutes les clefs mais si suffisamment de gens
essaient une attaque telle que celle-là, quelqu’un, quelque part sera peut-être chanceux,
comme il est dit dans [605] :
« Le nœud d’une attaque par logiciel est la pure malchance. Imaginez un ré
seau informatique universitaire avec 512 stations de travail mises en réseau.
Sur certains campus ce serait un réseau de taille moyenne. Elles pourraient
même être répandues de par le monde et elles coordonneraient leur activité
par courrier électronique. Faisons l’hypothèse que chaque station de travail
est capable d’effectuer 15 000 chiffrements par seconde ... En tenant compte
du surcoût pour tester une clef et passer à la clef suivante, ce chiffre est
ramené à 8 192 tests par seconde par machine. Pour essayer toutes les clefs
possibles [de 56 bits] cela prendrait ainsi 545 ans (en faisant l’hypothèse
que le réseau est dédié à cette tâche 24 heures par jour). Notez qu’avec
ces données cela donne à nos étudiants casseurs de code une chance sur
200 000 de trouver une clef en un jour. Sur un long week-end, leurs chances
passent à 1 sur 66000. Plus le matériel est rapide, ou plus il y a d ’ordina
teurs disponibles, plus leurs chances augmentent. Ce ne sont pas de bons
rapports pour gagner au tiercé mais cela n’est cependant pas acceptable.
De tels rapports sont meilleurs que ce que la loterie nationale offre. « Une
chance sur un million? » « Cela ne peut pas se reproduire en mille ans? »
Il n’est plus possible honnêtement de dire de telles choses. Est-ce un risque
acceptable de nos jours ? »
L’utilisation d’un algorithme avec une clef de 64 bits au lieu de 56 bits rend ce type
d’attaque 256 fois plus difficile. Avec une clef de 40 bits, la situation est nettement plus
dramatique. Un réseau de 400 ordinateurs, chacun capable de faire 32 000 chiffrements
par seconde, peut effectuer une attaque exhaustive contre une clef de 40 bits en une
seule journée2.
L’utilisation d’une clef de 128 bits rend une telle attaque ridicule à envisager.
L’industrie estime que d ’ici à 1996, il y aura 200 millions d ’ordinateurs de par le
monde. Cette estimation inclut tout depuis les super-ordinateurs Cray jusqu’aux nano-
ordinateurs. Si tous ces ordinateurs coopéraient à une attaque exhaustive à raison de
1 million de chiffrements par seconde, cela prendrait encore 1 million de fois l’âge de
l’univers pour trouver la clef.
Réseaux neuronaux
Les réseaux neuronaux ne sont pas très utiles pour la cryptanalyse, premièrement à
cause de la forme de l’espace des solutions. Les réseaux neuronaux sont efficaces dans
les problèmes où il y a une continuité des solutions, certains plus que d’autres. Ceci
permet à un réseau neuronal d ’apprendre et de proposer des solutions de plus en plus
adaptées au fur et à mesure. Les opportunités d’apprendre quelque chose quand on
casse un algorithme sont rares: soit on retrouve la clef, soit on ne la retrouve pas3.
Les réseaux neuronaux marchent bien dans les environnements structurés où il y a
quelque chose à apprendre mais pas dans le monde de grande entropie et d ’apparent
chaos qu’est la cryptographie.
Virus
La difficulté majeure dans une attaque de cette ampleur est de convaincre chaque
utilisateur individuel de se prêter à l’expérience. Vous pourriez demander poliment mais
cela prendrait trop de temps. Pire même, ils pourraient refuser. Vous pourriez essayer
d’investir leurs machines la nuit mais ce serait encore plus coûteux en temps. De plus,
vous risqueriez de finir en prison pour violation de domicile. Les virus informatiques
pourraient répandre un programme de recherche exhaustive de clef efficacement sur un
nombre maximum d’ordinateurs.
Cette idée, particulièrement insidieuse, a été présentée pour la première fois dans [1595].
L’attaquant écrit un virus informatique et le lâche dans la nature. Ce virus-là ne refor
mate pas le disque dur, ou ne détruit pas des fichiers ; tout ce qu’il fait c’est travailler
à une attaque exhaustive quand l’ordinateur n’a rien d ’autre à faire. Différentes études
ont montré que les micro-ordinateurs sont inactifs 70 % à 90 % du temps. Ainsi le
virus n’aurait aucune difficulté pour trouver du temps pour accomplir sa tâche. Si par
ailleurs il est bénin, il peut même passer inaperçu en continuant sa tâche.
Éventuellement, une des machines infectées trouvera la bonne clef. A ce point, il y deux
manières de procéder. Premièrement, le virus peut donner naissance à un nouveau virus
différent. Celui-ci ne ferait rien d ’autre que se répandre et détruire toute copie de son
ancêtre, tout en transportant de machine en machine l’information concernant la bonne
2. En 1992, les algorithmes RC2 et RC4 ont été autorisés à l’exportation hors des Etats-Unis pour
autant que leur clef soit restreinte à 40 bits (voir § 13.8).
3. Du moins, c’est vrai quand l’algorithme est bon.
clef. Lors de ses pérégrinations, il finirait par atterrir sur la machine de celui qui a lancé
l’attaque initiale.
Une autre approche plus subtile consisterait à afficher le message suivant sur l’écran
de l’ordinateur infecté qui a trouvé la bonne clef :
Il y a un problème sérieux à cet ordinateur.

Veuillez appeler le numéro de téléphone 1-800-123-4567
et lire le nombre de 64 bits suivant à l ’opérateur:
xxxx xxxx xxxx xxxx
Il y a une prime de 100 $ à la première personne qui

communiquera cette information.
Quelle est l’efficacité d’une telle attaque? Faisons l’hypothèse qu’un ordinateur infecté
essaie 1 000 clefs par seconde. C ’est nettement moins que ce que l’on attendrait comme
vitesse, mais n’oublions pas que cet ordinateur est sensé accomplir d’autres tâches.
Faisons également l’hypothèse qu’un tel virus peut infecter 10 millions d ’ordinateurs.
Le virus pourrait casser une clef de 56 bits en 83 jours et une clef de 64 bits en 58
ans. Vous devrez peut-être corrompre les auteurs de vaccins informatiques mais c’est
votre problème. Toute augmentation de la vitesse des micro-ordinateurs ou du nombre
d’ordinateurs rendrait bien évidemment cette attaque plus efficace.
La loterie chinoise
La « loterie chinoise » est une suggestion originale mais réalisable pour une machine
massivement parallèle pour attaquer l’algorithme DES [1289]. Imaginez que l’on incor
pore une puce de recherche exhaustive de clef, capable de faire un million de tests par
seconde dans chaque radio et dans chaque télévision nouvellement construits. Chaque
puce est programmée pour tester un ensemble différent de clefs et ce automatiquement,
dès qu’elle reçoit une paire « texte en clair, texte chiffré » sur les ondes. Alors chaque
fois que le Gouvernement chinois veut casser une clef, il diffuse les données et toutes
les radios et les télévisions du pays se mettent à la tâche. Eventuellement, la bonne
clef apparaîtra sur l’écran de télévision de quelqu’un, quelque part dans le pays. Le
Gouvernement chinois paie alors un prix à cet heureux gagnant d’une loterie un peu
particulière. Grâce à la promesse d’une récompense, le Gouvernement est sûr que la
bonne clef sera transmise correctement et en prime, cela favorise la vente de radios et
de télévisions contenant cette puce spéciale.
Si chaque homme, femme et enfant en Chine possède une radio ou une télévision,
la bonne clef, pour un algorithme qui utilise 56 bits pour la clef, sera trouvée en 64
secondes. Si seulement un chinois sur dix possède une radio ou une télévision (ce qui
est plus proche de la réalité), alors la bonne clef apparaîtra au bout de 11 minutes. La
bonne clef pour un algorithme à 64 bits apparaîtra au bout de 4 heures et demie (45
heures si seulement un chinois sur dix possède une radio ou une télévision).
Certaines modifications sont nécessaires pour rendre cette attaque praticable. Premiè
rement, il serait plus facile que chaque puce essaie des clefs aléatoires au lieu d’un
ensemble prédéterminé de clefs. Cela ne ralentirait l’attaque que de 39 % (pas grand
chose en comparaison des chiffres que nous manipulons). De plus, le parti commu
niste chinois devrait convaincre chaque personne d ’écouter ou de regarder une certaine
émission à un certain moment de la journée pour être sûr que toutes les radios et télé
visions sont opérationnelles au moment de la diffusion de la paire « texte en clair, texte
chiffré ». Finalement, chacun recevrait comme instruction de contacter le Central-Peu-
Importe-Son-Nom si jamais une clef apparaît à l’écran et de lire les nombres qui y
figurent. Le Parti pourrait même transformer cela en loterie : la personne qui trouve la
clef, reçoit un prix.
Le tableau 7.2 montre l’efficacité de la loterie chinoise pour différents pays et pour
différentes longueurs de clef. La Chine est clairement en bonne position pour conduire
une telle attaque, mais elle devrait équiper chaque homme, femme et enfant de sa
propre radio ou télévision. Les Etats-Unis ont moins d ’habitants mais beaucoup plus
d’équipement par tête d’habitant. L’état du Wyoming pourrait casser une clef de 56
bits rien qu’à lui seul en moins d’un jour.
Tab. 7.2 —Estimations pour une attaque exhaustive pour la loterie chinoise (les données
concernant la population et le nombre de radios et télévisions proviennent de « 1995
World Almanac and Book o f Facts ») _____________________________________________
Nombre de
Population télévisions Temps nécessaire
Contrée (approx.) et radios Clef de 56 bits Clef de 64 bits
Chine 1190431000 257000000 280 secondes 20 heures
Etats-Unis 260 714000 739000000 97 secondes 6,9 heures
Irak 19890000 4730000 4,2 heures 44 jours
Israël 5051000 3 640000 5,5 heures 58 jours
Wyoming (USA) 470 000 1330000 15 heures 160 jours
Morehead, NC (U SA) 6100 17300 48 jours 34 années
Biotechnologie
Si les biopuces sont possibles, il serait alors idiot de ne pas s’en servir pour construire
un outil d’attaque exhaustive répartie. Considérez un animal hypothétique, malencon
treusement appelé « DESosaure » [1289]. Il est constitué de cellules biologiques capables
de tester les clefs possibles. La paire « texte en clair-texte chiffré » est diffusée aux
cellules par un canal optique (ces cellules sont transparentes, vous voyez). Les solutions
sont transmises à l’organe vocal du DESosaure par l’intermédiaire de cellules spéciales
qui se propagent dans le système circulatoire de l’animal.
Un dinosaure typique a 1014 cellules (sans compter les bactéries). Si chacune d’entre
elles est capable d ’effectuer un million de chiffrements par seconde (d’accord, cela est
un grand « si »), retrouver une clef de 56 bits prendrait sept dix millièmes de seconde.
Retrouver une clef de 64 bits prendrait moins de deux dixièmes de seconde. Retrouver
une clef de 128 bits prendrait encore 1 0 1 1 années, malgré tout.
Une autre approche biologique serait d’utiliser des algues modifiées génétiquement pour
la cryptographie et qui seraient capables d’effectuer des attaques exhaustives contre les
algorithmes cryptographiques [1289]. Ces organismes rendraient possible la réalisation
d’une machine distribuée avec plus de processeurs, car ils pourraient couvrir une grande
surface. La paire « texte en clair-texte chiffré » pourrait être diffusée par satellite. Si un
organisme trouve le résultat, il pourrait induire un changement de couleur des cellules
voisines pour communiquer le résultat en retour au satellite.
170 Chapitre 7 Longueur des chefs
Faites l’hypothèse qu’une cellule d ’algue typique a la taille d ’un cube de 10 fi de côté
(cela est probablement une large estimation), alors 1 0 1 5 d’entre elles peuvent remplir
un mètre cube. Déversez-les dans l’océan pour couvrir une superficie de 518 km2, sur
une épaisseur d’eau d ’un mètre (vous vous débrouillez pour savoir comment faire —
moi je suis juste celui qui a les idées), et vous aurez 1 0 23 d ’entre elles flottant sur
l’océan (ce qui représente plus de 380 milliards de litres4). Si chacune d ’entre elles
peut essayer un million de clefs par seconde, elles retrouveront la clef d’un algorithme
avec une clef de 128 bits en juste un peu plus de 100 ans5. Des percées dans la vitesse
de calcul des algues, du diamètre des algues ou même dans la taille de la flaque sur
l’océan pourraient réduire ces nombres de façon significative.
Ne me parlez même pas de la nanotechnologie.
Limitations thermodynamiques
Selon le second principe de la thermodynamique, une certaine quantité d ’énergie est
nécessaire pour représenter de l’information. Enregistrer un simple bit en changeant
l’état d’un sytème requiert une quantité d ’énergie supérieure à kT, où T est la tempé
rature fondamentale du système et A; la constante de B o l t z m a n . (Restez avec moi, la
leçon de physique est presque terminée.)
Etant donné que k = 1,38.10” 16 et que la température ambiante de l’univers est de 3,2,
un ordinateur idéal marchant à 3,2 consommerait 4,4.10 ~ 16 à chaque modification ou
effacement d ’un bit. Faire tourner un ordinateur à une température plus basse que le
rayonnement cosmique environnant demanderait un apport énergétique suplémentaire
pour faire fonctionner une pompe à chaleur.
Maintenant, le soleil dégage chaque année une énergie égale à 1 ,2 1 .1041 environ. C’est
assez pour effectuer 2 ,7 .1 0 56 changements de bit dans notre ordinateur idéal; et assez
pour qu’un compteur de 18 7 bits prenne toutes ses valeurs. En construisant une sphère
de D y s o n autour du soleil et en captant toute son énergie pendant 32 ans, notre
ordinateur pourrait compter jusqu’à 2 192. Bien-sûr il ne resterait pas assez d ’énergie
pour effectuer d’autres opérations utiles avec ce compteur.
Mais il s’agit juste d ’une étoile, pas très douée pour cela. Une supemova moyenne
dégage quelque chose comme 1051. (Environ cent fois plus d ’énergie serait dégagée
sous forme de neutrinos, mais laissons les passer pour l’instant.) Si toute cette énergie
pouvait être canalisée afin d ’effectuer un seul calcul gigantesque, un compteur de 219
bits pourrait passer par tous ses états.
Ces nombres n’ont rien à voir avec la technologie du matériel; ils sont les bornes supé
rieures autorisées par la thermodynamique. Et ils impliquent fortement qu’une attaque
exhaustive contre des clefs de 256 bits restera impossible jusqu’à ce que les ordinateurs
soient construits avec autre chose que de la matière et fonctionnent ailleurs que dans
l’espace.
7.2 Longueur des clefs publiques

Les fonctions à sens unique ont été traitées dans le paragraphe 2.3. Multiplier deux
grands nombres premiers est une fonction à sens unique ; il est facile de multiplier les
4. Par comparaison, la catastrophe de VExxon Valdez a répandu 38 millions de litres de pétrole.
5. L’explosion démographique résultante des algues est votre problème.
7.2 Longueur des clefs publiques 171
nombres pour obtenir un produit, mais difficile de factoriser ce produit et de retrouver

les deux grands nombres premiers (voir § 11.3). La cryptographie à clef publique utilise
l’idée de faire une fonction à sens unique à brèche secrète. En fait, c ’est un mensonge ;
factoriser est supposé être un problème dur (voir § 11.4). Pour chacun d’entre-nous, il
semble l’être. Mais même s’il l’est, personne ne peut prouver que les problèmes durs
le sont vraiment. La plupart d ’entre-nous pensons que factoriser est dur, mais cela n’a
jamais été prouvé mathématiquement, d’une façon ou d’une autre.
Il est intéressant de s’y attarder un peu. Il est facile de s’imaginer dans 50 ans, en train
de se remémorer le bon vieux temps où l’on pensait que la factorisation était dure,
où la cryptographie était basée sur cette factorisation et où des entreprises gagnaient
de l’argent dans ce domaine. Il est facile d ’imaginer que les développements futurs en
théorie des nombres rendront la factorisation plus simple ou que les développements
en théorie de la complexité rendront la factorisation triviale. Il n’y a aucune raison de
croire que ceci arrivera (et la plupart des personnes qui en savent assez pour se faire
leur propre opinion vous diront que c’est peu probable) mais il n’y a non plus pas de
raison de croire que cela n’arrivera pas.
Dans tous les cas, aujourd’hui, les algorithmes dominants de chiffrement à clef pu
blique sont basés sur la difficulté de factoriser des grands nombres qui sont le produit
de deux grands nombres premiers. (D ’autres algorithmes reposent sur une chose ap
pelée problème logarithmique discret mais, pour le moment, supposons que le même
raisonnement s’applique.) Ces algorithmes sont aussi sensibles aux attaques exaustives,
mais d’un type différent. Casser ces algorithmes ne veut pas nécessairement dire es
sayer toutes les clefs possibles ; casser ces algorithmes veut dire essayer de factoriser
un grand nombre (ou de prendre des logarithmes discrets dans un très grand corps
fini — un problème similaire). Si le nombre est trop petit, vous n ’avez aucune sécurité.
Si le nombre est assez grand, vous êtes protégé contre toute la puissance de calcul mon
diale jusqu’à ce que le soleil devienne une nova (étant donnée la connaisance actuelle
des mathématiques). Le paragraphe 11.3 parle de factorisation avec plus de détails
mathématiques ; je me limiterai ici au temps nécessaire pour factoriser des nombres de
longueurs variables.
Factoriser des grands nombres est dur. Hélas pour les concepteurs d ’algorithmes, cela
devient plus facile. Pis encore, cela devient plus facile plus rapidement que les ma
thématiciens l’avaient prévu. En 1976, Richard G u y écrivait : « Je serais surpris que
quiconque puisse factoriser régulièrement des nombres d’une taille de 1 0 80 sans forme
spéciale durant ce siècle. » [681]. En 1977, Ron RlVEST disait que factoriser un nombre à
125 chiffres prendrait 40 quadrillions d’années [602]. En 1994, un nombre à 129 chiffres
a été factorisé [71]. S’il y a là une leçon à retenir, c’est bien que faire des prédictions
est stupide.
Le tableau 7.3 montre les records de factorisation des douzes dernières années.
L’algorithme de factorisation le plus rapide était alors le crible quadratique (voir § 11.3).
Ces chiffres sont assez effrayants. Il est commun aujourd’hui de voir des nombres de
512 bits utilisés dans des systèmes opérationnels. Les factoriser, et par conséquent
compromettre leur sécurité, est tout à fait dans le domaine du possible: l’utilisation
de toutes les machines reliées à l’Internet durant une paire de jours fériés y suffirait.
La puissance de calcul est généralement mesurée en mips-ans : un ordinateur effectuant
un million d’instructions par seconde (mips) pendant une année, soit à peu près 3 *
1013 instructions. Par convention, une machine d ’ 1 mips est équivalente au DEC VAX
T a b . 7.3 - Factorisation utilisant le crible quadratique
Nombre de décimales Combien de fois un nombre de 512 bits

Année des nombres factorisés est plus dur à factoriser
1983 71 > 2 0 millions
1985 80 > 2 millions
1988 90 250000
1989 10 0 30000
1993 12 0 500
1994 129 10 0
11/780. Donc un mips-an est l’équivalent d ’un VAX 11/780 tournant pendant un an.
(Un Pentium 100 MHz est une machine de 50 mips; une machine Paragon d ’Intel à
1800 processeurs est une machine de 50000 mips.)
En 1983, factoriser un nombre à 71 chiffres demandait 0,1 mips-an ; la même opération
en 1994 avec un nombre à 129 chiffres demandait 5000 mips-an. Cette augmentation
insensée de la puissance de calcul est principalement le résultat de l’introduction du
calcul distribué, utilisant le temps d ’inactivité des stations de travail d ’un réseau. Cette
tendance a été initiée par Bob S i l v e r m a n et développée par Arjen L e n s t r a et Mark
M a n a s s e . En 1983, factoriser prenait 95 heures CPU sur un seul Cray X-M P ; en 199A
cela nécessitait 5000 mips-ans et utilisait le temps d’inactivité de 1600 ordinateurs à
travers le monde pendant environ huit mois. Les méthodes modernes de factorisation
se prêtent à ce genre de distribution des tâches.
La situation s’empire encore. Un nouvel algorithme de factorisation a remplacé le crible
quadratique : le crible général sur corps numérique. En 1989, les mathématiciens vous
auraient dit que le crible général sur corps numérique ne serait jamais pratique. En
1992, ils vous auraient dit que c’était pratique, mais seulement plus rapide que le
crible quadratique dans les cas de nombres à plus de 130 à 150 chiffres. Aujourd’hui,
il est reconnu être plus rapide que le crible quadratique pour des nombres compre
nant bien moins de 116 chiffres [504, 637]. Le crible général sur corps numérique peut
factoriser un nombre de 512 bits plus de 10 fois plus rapidement que le crible qua
dratique. L’algorithme tournerait moins d’un an sur un Paragon Intel 1800. Le ta
bleau 7.4 nous donne le nombre de mips-ans nécessaires pour factoriser des nombres de
différentes tailles, en considérant les applications actuelles du crible général sur corps
numérique [1195].
Tab. 7.4 - Factorisation utilisant le crible général sur corps numérique
Nombre de bits Mips-ans nécessaires pour factoriser

512 30000
768 2 * 10 8
1024 3*10n
1280 1 * 1 0 14
1536 3 * 1016
2048 3 * 102°
Le crible général sur corps numérique est de plus en plus rapide. Les mathématiciens
trouvent toujours des nouvelles optimisations, des nouvelles techniques. Il n’y a aucune
raison de penser que cette tendance ne continuera pas. Un algorithme voisin, le crible
spécial sur corps numérique, peut déjà factoriser des nombres d’une forme spécialisée (ce
sont des nombres généralement pas utilisés pour la cryptographie) bien plus rapidement
que le crible général sur corps numérique peut factoriser des nombres généraux de même
taille. Il n’est pas déraisonnable de penser que le crible général sur corps numérique
peut être optimisé pour aller aussi vite [1195] ; il est d ’ailleurs fort possible que la NSA
sache déjà comment faire. Le tableau 7.5 donne le nombre de mips-ans nécessaires
pour que le crible spécial sur corps numérique factorise des nombres de différentes
longueurs [1195].
Tab. 7.5 - Factorisation utilisant le crible spécial sur corps numérique
Nombre de bits Mips-ans nécessaires pour factoriser

512 <200
768 10 0 0 0 0
1024 3 * 107
1280 3 * 109
1536 2 * 1 0 11
2048 4 * 1014
Lors d’un atelier de l’Institut européen pour la sécurité des systèmes en 1991, les
participants ont convenu qu’un module de 1024 bits devrait être suffisant pour des
secrets à long terme jusqu’en 2005 [157]. Néanmoins, ils ajoutèrent: « Bien que les
participants de cet atelier pensent être les plus qualifiés dans leurs domaines respectifs,
cette déclaration [concernant la durabilité de la sécurité] devrait être considérée avec
beaucoup de prudence. » C ’est un bon conseil.
Le cryptographe avisé est très prudent lorsqu’il choisit la longueur de clefs publiques.
Pour déterminer de quelle longueur de clef vous avez besoin, il faut que vous considériez
à la fois le niveau de sécurité désiré et la durée de vie de la clef, ainsi que le nec plus
ultra de la factorisation. Aujourd’hui, vous avez besoin d’un nombre de 1024 bits pour
avoir le niveau de sécurité que vous aviez en 1980 avec un nombre de 512 bits. Si
vous voulez que vos clefs restent sûres pour les 20 prochaines années, 1024 bits sont
probablement insuffisants.
Même si vos secrets ne valent pas l’effort investit pour factoriser votre module, vous
êtes peut-être en danger. Imaginez un système bancaire automatique qui utilise le RSA
pour la sécurité. Martin peut aller devant la justice et déclarer : « Avez-vous lu dans
les journaux qu’en 1994 le RSA-129 a été cassé et que les nombres de 512 bits peuvent
être factorisés par toute organisation prête à dépenser quelques millions de dollars et
à attendre quelques mois? Pour sa sécurité, ma banque utilise des nombres à 512 bits,
et j’en profite pour vous dire que ce n’est pas moi qui ait effectué ces septs retraits. »
Même si Martin ment, il est probable que le juge somme la banque de s’expliquer.
Mais alors, pourquoi ne pas utiliser des clefs de 10000 bits? Vous pouvez, mais sachez
que plus votre clef sera longue, plus vous passerez de temps à la calculer. Vous voulez
une clef assez longue pour qu’elle soit sûre, mais assez courte pour que le calcul soit
faisable.
Un peu plus haut dans ce paragraphe, j ’ai dit que faire des prédictions est stupide. Je
vais maintenant en faire quelques-unes. Le tableau 7.6 regroupe mes recommandations
pour les longueurs de clefs publiques, selon le niveau de sécurité de votre clef que
vous désirez. Il y a trois longueurs de clefs pour chaque année, une pouvant supporter
les attaques individuelles, une sûre pouvant supporter les attaques d’une entreprise
majeure, et une pouvant supporter les attaques d’un gouvernement.
T a b . 7.6 - Longueurs recommandées de clefs publiques (en bits)
Année contre un individu contre une entreprise contre un gouvernement

1995 768 1280 1536
2000 1024 1280 1536
2005 1280 1536 2048
2 0 10 1280 1536 2048
2015 1536 2048 2048
Voici quelques hypothèses de [71] :
« Nous pensons pouvoir acquérir 100 000 machines sans développer d ’efforts
surhumains et en toute probité. En fait, nous ne lâcherions pas un virus sur
Internet pour trouver les ressources pour nous. Beaucoup d’organisations
ont chacune des milliers de machines sur le réseau. Les utiliser demanderait
une grande diplomatie, mais ne devrait pas être impossible. En considérant
la puissance moyenne de 5 mips et une durée d ’un an, il ne semble pas trop
déraisonnable de s’embarquer sur un projet qui exigera un demi-million de
mips-ans. »
Le projet de factorisation d ’un nombre à 129 chiffres a mobilisé à peu près 0,03 pourcent
de la puissance de calcul globale d’Internet [1195], et ils n’ont vraiment pas forcé. Il
est raisonnable de penser qu’un projet ayant fait l’objet d’une bonne campagne de
publicité puisse mobiliser 2 pourcents de la puissance de calcul mondiale pendant une
année.
Supposons qu’un cryptanalyste puisse mettre la main sur 10000 mips-ans, une grande
entreprise peut en avoir 107 et un gouvernement 10°. Supposons également que la
puissance de calcul augmente d’un facteur 10 tous les cinq ans. Enfin, supposons que
les progrès mathématiques en matière de factorisation nous permettent de factoriser
des nombres généraux à la vitesse du crible spécial sur corps numérique. (Ce n’est pas
encore possible, mais cette avancée pourrait survenir à tout moment.) Le tableau 7.6
recommande différentes longueurs de clefs pour la sécurité en différentes années.
N’oubliez pas de prendre la valeur de la clef en considération. Les clefs publiques sont
souvent utilisées pour sécuriser des choses de grande valeur pour une longue durée:
la clef maîtresse d’une banque pour un système d ’argent électronique, la clef qu’un
gouvernement utilise pour certifier ses passeports ou la clef publique d ’une signature
électronique d’un notaire. Cela ne vaut probablement pas la peine de passer des mois
de calcul pour casser la clef privée d’un individu, mais si vous pouvez imprimer votre
propre argent avec une clef que vous avez cassé, l’idée devient plus attrayante. Une clef
de 1024 bits est assez longue pour signer quelque chose qui sera vérifié dans la semaine,
le mois, ou même quelques années. Mais vous ne voulez sûrement pas vous retrouver
devant la justice dans 2 0 ans avec un document signé électroniquement et voir la partie
opposée démontrer comment contrefaire un document avec la même signature.
Faire des prédictions au-delà d ’un future proche est encore plus insensé. Qui connait
les progrès qui vont être effectué en calcul, en matière de réseau et en mathématiques
d’ici à l’an 2020? Néanmoins, si on considère la situation d’un point de vue général,
pour chaque décade, nous pouvons factoriser des nombres deux fois plus longs que la
décade précédente. Ceci nous mène au tableau 7.7.
T ab. 7.7 - Prédictions de factorisation à long terme
Année Longueur de clef (bits)

1995 1024
2005 2048
2015 4096
2025 8192
2035 16384
2045 32 768
D’un autre côté, la technologie de factorisation peut atteindre son apogée bien avant
2045. D’ici vingt ans, nous serons peut-être capable de factoriser n’importe quel
nombre. Je pense néanmoins que ceci est très peu probable.
Tout le monde ne sera pas d ’accord avec mes recommandations. La NSA a mandaté
des clefs de 512 à 1024 bits pour leur standard de signature électronique (voir § 20.1),
ce qui est bien moins que ce que je recommande pour une sécurité à long terme. Pretty
Good Privacy (voir § 24.12) a une longueur de clef RSA maximum de 2047 bits. Arjen
LENSTRA, le plus célèbre « factorisateur » mondial, refuse de faire des prédictions au-
delà de 10 ans [960]. Le tableau 7.8 nous livre les recommandations sur la longueur de
clef de Ron R i v e s t , faites en 1990, que je considère bien trop optimistes [1334]. Bien
que son analyse paraisse correcte sur papier, les événements récents montrent que des
surprises arrivent régulièrement. Il semble logique de choisir ses clefs afin de se protéger
de futures surprises.
T ab . 7.8 - Recommandations optimistes de R iv e s t sur la longueur de clef (en bits)
Année Faible Moyenne Elevée

1990 398 515 1289
1995 405 542 1399
2000 422 572 1512
2005 439 602 1628
2 0 10 455 631 1754
2015 472 661 1884
2020 489 677 2017
Les estimations les plus basses parlent d’un budget de 25 000 dollars, de l’algorithme
du crible quadratique et d ’un progrès technologique de 20 pourcents par an. Les es
timations moyennes parlent d ’un budget de 25 millions de dollars, de l’algorithme du
crible général sur corps numérique et d ’un progrès technologique de 33 pourcents par
an. Enfin, les estimations les plus optimistes avancent un budget de 25 milliards de
dollars, un algorithme du crible général quadratique tournant à la vitesse du crible
spécial sur corps numérique et un progrès technologique de 45 pourcents par an.
Il est toujours possible qu’un progrès en matière de factorisation me surprenne, mais
j ’ai intégré ceci dans mes calculs. Mais pourquoi me faire confiance? Je viens de prouver
ma stupidité en faisant des prédictions.
Calculs biologiques
Maintenant, cela devient étrange. En 1994, Léonard M. A d l e m a n a trouvé une mé
thode pour résoudre un problème N P —complet (voir § 1 1 .2 ) dans un laboratoire de
biochimie, en utilisant des molécules d ’ADN pour représenter les solutions du pro
blème [21]. (Ici, par « solutions », on entend « réponses » et non pas « liquide conte
nant des substances ».) Le problème qu’ A d l e m a n a résolu était un cas particulier
du problème de trouver un chemin orienté Hamiltonien : soit une carte avec des villes
connectées par des routes à sens unique, trouvez un chemin de la ville A à la ville Z qui
ne passe exactement qu’une seule fois par chaque ville de la carte. Chaque ville était
représentée par des chaînes aléatoires distinctes de 20 bases d ’ADN ; avec les techniques
conventionnelles de biologie moléculaire, A d l e m a n a synthétisé 50 picomoles (30 mil
lions de millions de molécules) de la chaîne d’ADN représentant chaque ville. Chaque
route était aussi représentée par une chaîne de 20 bases d ’ADN, mais ces chaînes n’ont
pas été choisies de façon aléatoire : elles ont été choisies judicieusement de manière à ce
que la fin de la chaîne d’ADN représentant la route de la ville P à la ville K (« route
P K ») ait tendance à se rapprocher de la chaîne d’ADN représentant la ville P , et que
la fin de la route P K ait tendance à se rapprocher de la ville K .
A d l e m a n a synthétisé 50 picomoles d’ADN représentant chaque route, les a mixé tous
ensemble avec l’ADN représentant toutes les villes et a ajouté un enzyme ligase qui
noue ensemble les bouts de molécules d ’ADN. La relation judicieuse entre les chaînes
d’ADN de la route et les chaînes d’ADN de la ville fait que la ligase lie les chaînes
d’ADN de la route entre-elles de manière légale. C ’est-à-dire que l’issue de la route
qui va de P à A sera toujours reliée au début d ’une route qui part de la ville K ,
jamais à l’issue d ’une autre route ou au début d’une route qui part d’une ville autre
que K . Après un temps de réaction minutieusement limité, la ligase a construit un
grand nombre de chaînes d ’ADN représentant des chemins multiroutes légaux bien
qu’aléatoires sur la carte.
De cette soupe de chemins aléatoires, A d l e m a n peut retrouver la plus infime trace
(peut-être même une seule molécule) d ’ADN qui représente la réponse au problème. En
utilisant les techniques communes de la biologie moléculaire, il écarte toutes les chaînes
d ’ADN qui représentent des chemins trop longs ou trop courts. (Le nombre de routes
dans le chemin cherché doit être égal au nombre de villes moins un.) Ensuite, il écarte
toutes les chaînes d ’ADN qui ne passent pas par la ville A, puis celles qui ne passent
pas par la ville B, etc... S’il reste un ADN à l’issue de cette série d ’éliminations, la
séquence de routes qu’il décrit est la solution au problème de découverte d ’un chemin
orienté Hamiltonien.
Par définition, toute instance d ’un problème N P —complet peut être transformé, en
temps polynomial, en une instance de tout autre problème N P —complet, et par consé
quent en un problème de découverte d ’un chemin orienté Hamiltonien. Depuis les an
nées 1970, les cryptologues ont essayé d ’utiliser les problèmes N P —c o m p l e t s pour la
crypotographie à clef publique.
Bien que le cas résolu par A d l e m a n fut modeste (sept villes sur sa carte, une énigme
qui peut être résolue en réfléchissant quelques minutes), la technique en est à ses
balbutiements et ne rencontrerait aucun obstacle à être étendue à des problèmes
plus conséquents. C ’est pourquoi, les arguments à propos des protocoles cryptogra-
phiques basés sur des problèmes N P c o m p l e t s , arguments qui jusqu’alors commen
çaient par « Supposons qu’un adversaire possède un million de processeurs, chacun
d’entre-eux pouvant effectuer un million de tests par seconde, » pourraient bientôt de
venir « Supposons qu’un adversaire possède un millier de lieux de fermentation, chacun
ayant une capacité de 2 0 0 0 0 litres. »
Ordinateurs quantiques
Attention, cela devient encore plus étrange. Le principe sous-jacent de l’ordinateur
quantique inclut la dualité onde-particule découverte par Albert E i n s t e i n . Un photon
peut simultanément exister dans un grand nombre d ’états. L ’exemple classique est celui
du photon qui se comporte comme une onde quand il rencontre un mirroir partiellement
argenté ; il est à la fois réfléchi et transmis. C ’est tout comme une vague qui vient se jeter
sur une digue qui comporte une petite ouverture, la vague sera refoulée mais passera
un peu à travers la digue. Néanmoins, quand un photon est mesuré, il se comporte
comme une particule et un seul état peut être détecté.
Dans [1449], Peter S h o r nous montre une conception d e machine à factoriser qui repose
sur les principes de la mécanique quantique. A l’inverse d’un ordinateur classique, qui
en fait est dans un état unique, fixe, à un moment donné, un ordinateur quantique a
une fonction d ’onde interne, qui est une superposition d ’une combinaison des états de
base possibles. Les calculs transforment la fonction d ’ondulation, modifiant ainsi tout
l’ensemble des états en une seule opération. De cette façon, un ordinateur quantique est
une amélioration par rapport à l’automate classique à état fini : il utilise les propriétés
quantiques afin de factoriser en temps polynomial ; ce qui nous permet théoriquement
de casser les cryptosystèmes basés sur la factorisation ou le problème du logarithme
discret.
Le consensus est que les ordinateurs quantiques sont compatibles avec les lois fonda
mentales de la mécanique quantique. Néanmoins, il est peu probable qu’une machine
de factorisation quantique soit construite dans le futur. Un obstacle majeur est le pro
blème de décohérence qui fait que des formes ondulatoires superposées perdent leur
distinction et que l’ordinateur ne marche pas. La décohérence implique qu’un ordi
nateur quantique fonctionnant à 1 Kelvin ne marche pas plus d ’une nanoseconde. De
plus, un très grand nombre de portes serait nécessaire pour construire une machine
de factorisation quantique ; cela peut rendre sa construction impossible. Le concept
de SHOR nécessite un module complet d’exponentiation en arithmétique modulaire.
Aucune horloge interne ne peut être utilisée, alors des millions, voire des milliards de
portes seraient nécessaires pour factoriser des nombres cryptographiquement signifi
catifs. Si n portes quantiques ont une probabilité minimum p d ’échouer, le nombre
moyen d’essais par coup réussi est de (1/(1 — p))n- Le nombre de portes nécessaires
croît polynômialement avec la longueur en bits du nombre, donc le nombre d’essais
nécessaires serait superexponentiel en la longueur des nombres utilisés (ce qui est pire
que factoriser par des divisions).
Ainsi, alors que la factorisation quantique attire de nombreux chercheurs, il est extrê
mement peu probable qu’elle soit jamais mise en pratique. Mais ne dites pas que je ne
vous ai pas prévenu.
7.3 Comparaison de la longueur des clefs

secrètes et des clefs publiques
Un système sera attaqué au niveau de son point faible. Si vous concevez un système qui
utilise à la fois les cryptographies à clef secrète et à clef publique, les longueurs de clefs
pour chaque type de cryptographie devront être choisies de façon à ce qu’il soit aussi
difficile d ’attaquer le système via l’un ou l’autre des mécanismes. Il n’est pas logique
d ’utiliser un algorithme à clef secrète de 128 bits avec un algorithme à clef publique
de 386 bits, de même qu’il n’est pas logique d ’utiliser un algorithme à clef secrète de
56 bits avec un algorithme à clef publique de 1024 bits.
Le tableau 7.9 donne les longueurs des modules des algorithmes à clef publique dont
la difficulté de factorisation égale à peu près la difficulté d’une attaque exaustive pour
les longueurs de clefs secrètes usuelles.
T ab . 7.9 - Longueurs des clefs secrètes et des clefs publiques avec résistances similaires
aux attaques exhaustives_____________________________________________
Longueur de clef secrète Longueur de clef publique
56 bits 384 bits
64 bits 512 bits
80 bits 768 bits
1 1 2 bits 1792 bits
128 bits 2304 bits
Ce tableau nous dit que si vous êtes assez soucieux pour votre sécurité pour choisir
un algorithme à clef secrète avec une clef de 1 1 2 bits, alors vous devriez choisir une
longueur de module d ’au moins 1792 bits pour votre algorithme à clef publique. En
général, vous devriez choisir une longueur de clef publique plus sûre que votre longueur
de clef secrète. Les clefs publiques demeurent généralement plus longtemps et sont
utilisées pour protéger plus d’informations.
7.4 Attaques des anniversaires contre une

fonction de hachage à sens unique
Il y a deux attaques exhaustives pour une fonction de hachage à sens unique. La
première est la plus évidente: soit H (A i), l’empreinte d’un message, un adversaire
aimerait être capable de créer un autre document, A i', tel que II(A i) = II(A i').
La seconde attaque est plus subtile: un adversaire aimerait trouver deux messages
aléatoires, A i et A i ', tel que H (A i) — H (A i'). Cela s’appelle une collision et c’est
une attaque bien plus facile que la première.
7.5 Quelle doit être la longueur de clef? 179
Le paradoxe de l’anniversaire est un problème statistique standard. Combien de per

sonnes doit-il y avoir dans une pièce pour qu’il y ait de bonnes chances qu’au moins l’une
d’entre-elles ait la même date d’anniversaire que vous? La réponse est 253. Maintenant,
combien de personnes doit-il y avoir pour qu’il y ait de bonnes chances qu’au moins
deux d’entre-elles aient la même date d ’anniversaire? La réponse est surprenante: 23.
Avec seulement 23 personnes dans une pièce, il y a tout de même 253 paires différentes
de personnes.
Trouver quelqu’un avec une date d ’anniversaire spécifique est analogue à la première at
taque ; trouver deux personnes avec la même date d’anniversaire aléatoire est analogue
à la seconde attaque. Cette seconde attaque est plus connue sous le nom d’attaque
des anniversaires.
Supposons qu’une fonction de hachage à sens unique est sûre et que la meilleure attaque
est l’attaque exaustive. Elle produit un résultat à m bits. Trouver un message dont l’em
preinte a une valeur donnée exigerait de hacher 2m messages aléatoires. Trouver deux
messages qui ont la même empreinte n’exigerait de hacher que 2 m / 2 messages aléa
toires. Une machine qui hâche un million de messages par seconde mettrait 600 000 ans
pour trouver un second message qui correspondrait à une empreinte donnée de 64 bits.
Cette même machine pourrait trouver une paire de messages de même empreinte en à
peu près une heure.
Comprenez que si les attaques des anniversaires vous inquiètent, vous devriez choisir
une valeur de hachage deux fois plus longue que celle que vous pensez être nécessaire.
Par example, si vous voulez réduire les chances que quelqu’un casse votre système à
moins de 1 pour'2 80, utilisez une fonction de hachage à sens unique à 160 bits.
7.5 Quelle doit être la longueur de clef?

Il n’y a pas de réponse unique à cette question ; cela dépend de la situation. Pour
déterminer le niveau de sécurité dont vous avez besoin, vous devez vous poser quelques
questions. Que valent vos données? Combien de temps doivent-elles rester confiden
tielles? Quelles sont les ressources de vos adversaires?
Une liste client peut bien valoir 1 000 dollars. Les données financières d ’un divorce
houleux doivent bien valoir 10000 dollars. Monter une campagne de publicité et de
marketing d’un produit d’une grande société vaut sûrement 1 million de dollars. Les
clefs maîtresses d ’un système d’argent électronique valent des milliards.
Dans le monde commercial, les secrets doivent seulement être gardés pendant quelques
minutes. Dans l’industrie journalistique, les secrets d ’aujourd’hui font les grands titres
de demain. Les informations concernant le développement de produits doivent sûrement
rester secrètes pendant un an ou deux. Les données du recensement américain sont
légalement gardées secrètes pendant 1 0 0 ans.
La liste des invités pour la fête d’anniversaire de votre sœur n’intéresse que vos proches
curieux. Les secrets commerciaux d ’une compagnie intéressent les compagnies rivales.
Les secrets militaires intéressent des puissances miütaires rivales.
Vous pouvez même spécifier vos desiderata de sécurité en ces termes. Par exemple :
La longueur de clef doit être telle qu’il n’y ait pas une probabilité de plus
de 1 pour 2 32 qu’un attaquant disposé à dépenser 1 0 0 millions de dollars
puisse casser le système en moins d ’un an, même en faisant l’hypothèse
que la technologie progresse à un taux de croissance de 30 % par an sur la

période.
Le tableau 7.10, emprunté partiellement à [157], estime le niveau de sécurité requis

pour plusieurs types d ’informations.
Tab. 7.10 - Niveau de sécurité nécessaire pour différents types d’informations
Type de trafic Longévité Longueur de

clef minimum
Informations militaires tactiques minutes/heures 56-64 bits
Annonces de produits, fusions,
taux d’intérêt j ours/semaines 64 bits
Plans d’affaires à long terme années 64 bits
Secrets commerciaux
(e.g. la recette du Coca-Cola) décades 112 bits
Secrets de la bombe H > 40 ans 128 bits
Identités d ’espions > 50 ans 128 bits
Affaires privées > 50 ans 128 bits
Embarras diplomatiques > 65 ans au moins 128 bits
Données du recensement américain 1 0 0 ans au moins 128 bits
La puissance de calcul future est plus difficile à évaluer, mais à vue de nez : l’efficacité
des équipements de calcul divisée par le prix double tous les 18 mois et augmente d’un
facteur 10 tous les 5 ans [100]. Donc, d ’ici à 50 ans, les ordinateurs les plus rapides seront
10 milliards de fois plus rapides qu’aujourd’hui ! Gardons à l’esprit que ces chiffres ne
prennent en compte que des ordinateurs génériques ; qui sait quel type de système de
recherche cryptographique exhaustive pourra être développé d’ici à 50 ans?
En faisant l’hypothèse qu’un algorithme cryptographique sera utilisé pendant 30 ans,
vous pouvez avoir une idée du niveau de sécurité qu’il doit offrir. Un algorithme conçu
aujourd’hui ne sera probablement pas d’un usage généralisé avant l’an 2 0 0 0 et sera tou
jours utilisé en l’an 2025 pour chiffrer des messages qui devront rester secrets jusqu’en
2075 ou plus tard.
7.6 Avertissement
Ce chapitre entier ne veut absolument rien dire. La notion de prédiction de la puis
sance de calcul dans les 10 années à venir, sans parler des 50 prochaines années, est
absolument ridicule. Ces calculs ne doivent être qu’une indication, rien de plus. Si le
passé est une indication, le futur sera bien différent de tout ce qu’on a pu prévoir.
Soyez prudent. Si vos clefs sont plus longues qu’il vous semble nécessaire, alors moins
de surprises technologiques vous concerneront.
Chapitre 8
Gestion des clefs
Alice et Bernard ont un système de communication sûr. Ils jouent au poker en aveugle,
ils signent simultanément des contrats et échangent même de l’argent électronique.
Leurs protocoles sont sûrs. Leurs algorithmes sont le nec plus ultra. Malheureusement,
ils achètent leurs clefs à la société C l e f s e t c o n f i a n c e d’Estelle dont le slogan est
« Vous pouvez nous faire confiance : la sécurité est le deuxième nom de l’ex-belle-mère
de notre voyageur de commerce. »
Estelle n’a pas à casser les algorithmes. Elle ne compte pas sur les failles subtiles dans
les protocoles. Elle peut utiliser leurs clefs pour lire tous les messages entre Alice et
Bernard sans lever le moindre petit doigt cryptographique.
Dans le monde réel, la gestion des clefs est la partie de la cryptographie la plus difficile.
Concevoir des algorithmes et des protocoles sûrs n’est pas chose aisée mais vous pouvez
compter sur un corps important de recherche académique. Garder les clefs secrètes est
encore plus dur.
Les cryptanalystes attaquent souvent les algorithmes à clef secrète et les algorithmes à
clef publique par leur gestion des clefs. Pourquoi Estelle s’évertuerait-elle à casser un
algorithme cryptographique quand il lui est plus facile de retrouver les clefs à cause d ’un
relâchement dans les procédures de gestion des clefs? Pourquoi devrait-elle dépenser
1 0 millions de dollars pour construire une machine de cryptanalyse alors que 1 0 0 0
dollars suffirait à corrompre un employé? Dépenser 1 million de dollars pour acheter
un employé des communications occupant un poste stratégique au sein d’une ambassade
diplomatique peut se révéler être une vrai affaire. Les W a l k e r s ont vendu pendant des
années aux soviétiques les clefs de chiffrement de la marine américaine. Le directeur du
contre-espionnage de la C IA s’est vendu pour moins de 2 millions de dollars, femme
incluse. C’est beaucoup moins onéreux que de construire de puissantes machines de
cassage de chiffrement et d ’employer de brillants cryptanalystes. Estelle peut voler
les clefs. Elle peut arrêter ou kidnapper quelqu’un qui connaît les clefs. Elle peut
séduire quelqu’un et lui soutirer les clefs de cette façon. (Les M a r i n e s qui gardaient
l’ambassade américaine à Moscou n’étaient pas insensibles à ce type d ’attaque.) Il
est beaucoup plus facile de trouver les points faibles chez une personne que dans un
système cryptographique.
Alice et Bernard doivent protéger leurs clefs au même niveau de sécurité que les données
qu’elles chiffrent. Si une clef n’est pas changée régulièrement, ça pourrait être une
182 Chapitre 8 Gestion des clefs
quantité énorme de données. Malheureusement, beaucoup de produits commerciaux

déclarent tout simplement « Nous utilisons DES » et oublient tout le reste. Les résultats
sont loins d’être concluants.
Par exemple, le programme D i s k l o c k pour M a c i n t o s h (version 2.1), vendu par la
plupart des marchands de logiciels, prétend offrir la sécurité du chiffrement DES. Il
chiffre les fichiers en utiüsant le DES. Sa réalisation de l’algorithme DES est correcte.
Toutefois, D i s k l o c k stocke la clef DES avec le fichier chiffré. Si vous savez où regarder
pour trouver la clef et que vous voulez lire un fichier chiffré avec le DES de D i s k l o c k ,
retrouvez la clef dans le fichier chiffré et ensuite de déchiffrez le fichier à l’aide de la
clef. Cela n’a pas d ’importance que le programme utilise le chiffrement DES — la
réalisation est dénuée de toute sécurité. D ’autres informations concernant la gestion
des clefs peuvent être trouvées dans [463, 105, 1284, 1235, 775, 361]. Les chapitres
suivants s’occupent des résultats et des solutions.
8.1 Génération de clefs

Le niveau de sécurité d’un algorithme dépend de la clef. Si vous utilisez un processus
cryptographiquement faible pour engendrer des clefs, alors tout votre système est faible.
Estelle n’a pas à essayer de cryptanalyser votre algorithme de chiffrement ; elle a juste
à cryptanalyser votre algorithme de génération de clefs.
Espaces de clefs réduits

Le DES a une clef de 56 bits. Dans une réalisation correcte, toute chaîne de 56 bits
peut être la clef: il y a 2 56 ( « 1016) clefs possibles. N o r t o n D i s c r e e t de M S-D O S
(versions 8.0 et antérieures) n’autorisent que des clefs A SC II, forçant le bit de poids fort
de chaque octet à prendre la valeur zéro, le programme convertit aussi les minuscules
en majuscules (ainsi le cinquième bit de chaque octet est toujours l’opposé du sixième)
et ignore le bit de poids faible de chaque octet, ne permettant finalement que 2 40 clefs
possibles. Ces mauvaises procédures de génération de clefs rendent son DES dix mille
fois plus facile à casser qu’une réalisation correcte.
Le tableau 8.1 donne le nombre de clefs possibles, suivant certaines contraintes sur
les chaînes de caractères à l’entrée. Le tableau 8.2 donne le temps requis pour une
recherche exhaustive à travers toutes ces clefs, sur la base d’un million de tentatives
par seconde. Notez qu’il n ’y a pas de différence en temps notable entre une recherche
exhaustive pour des clefs de 8 octets d’emblée, et une recherche progressive où les clefs
de 4 octets sont essayées, puis de 5 octets, ainsi de suite jusqu’à 8 octets.
T a b . 8.1 - Nombre de clefs possibles pour différents espaces de clefs
4 octets 5 octets 6 octets 7 octets 8 octets

Lettres minuscules (26) 460000 1,2 xlO7 3,1x10® 8,0x 10“ 2,1 xlO 11
Lettres minuscules et chiffres (36) 1700000 6,0 xlO 7 2,2 x 109 7,8 xlO10 2,8 xlO 12
Caractères alphanumériques (62) 1,5 xlO7 9,2 x 10® 5,7 xlO 10 3,5 xlO 12 2,2 xlO 14
Caractères affichables (95) 8,1 xlO 7 7,7 xlO9 7,4 xlO11 7,0 xlO13 6,6 xlO 15
Caractères ASCII (128) 2,7x10® 3,4 xlO 10 4,4 x 1012 5,6 xlO 14 7,2 xlO 16
Caractères ASCII 8 bits (256) 4,3 x 109 1,1 xlO 12 2,8 x 1014 7,2 xlO 16 1,8 xlO 19
8.1 Génération de clefs 183
Tab. 8.2 - Recherche exhaustive de différents espaces de clefs (sur la base d’un million
de tentatives par secondes)
4 octets 5 octets 6 octets 7 octets 8 octets
Lettres minuscules (26) 0,5 s 12 s 5 mn 2,2 h 2,4 j
Lettres minuscules et chiffres (36) 1,7 s 1 mn 36 mn 22 h 33 j
Caractères alphanumériques (62) 15,0 s 15 mn 16 h 41 j 6,9 ans
Caractères affichables (95) 1,4 mn 2,1 h 8,5 j 2,2 ans 210 ans
Caractères ASCII (128) 4,5 mn 9,5 h 51 j 18 ans 2 300 ans
Caractères ASCII 8 bits (256) 1,2 h 13 j 8,9 ans 2300 ans 580000 ans
Toute réalisation parallèle et matérielle d ’une attaque exhaustive spécialisée conviendra

ici. En testant un million de clefs par seconde (soit avec une machine, soit avec plusieurs
machines en parallèle), il est envisageable de retrouver une clef de 8 octets faite de
lettres minuscules ou de lettres minuscules et de chiffres, une clef de 7 octets faite
de caractères alphanumériques, une clef de 6 octets de caractères affichables ou de
caractères ASCII, et une clef de 5 octets de caractères ASCII de 8 bits.
Et rappelez-vous, la puissance de calcul double tous les 18 mois. Si vous espérez voir
vos clefs résister à des attaques exhaustives pendant 1 0 ans, vous devriez revoir votre
copie.
Mauvais choix de clefs

Quand les gens choisissent leur clef par eux-mêmes, ils font généralement un mauvais
choix1. Ils choisiront bien plus probablement « Barney » que « 9(hH/A — ». Ce n ’est pas
toujours dû a de mauvaises habitudes de sécurité ; « Barney » est plus facile à retenir que
« 9(hH/A— ». L’algorithme le plus sûr du monde ne sera pas d’une grande utilité pour
les utilisateurs qui choisissent le nom de leur épouse comme clef ou qui écrivent leurs
clefs sur des petits bouts de papier dans leur portefeuille. Un algorithme de recherche
exhaustive intelligent n’essaie pas toutes les clefs dans leur ordre numérique ; il essaie
d’abord les clefs les plus évidentes.
On appelle cela une attaque par dictionnaire, parce que l’attaquant utilise un dic
tionnaire de clefs communes. Daniel K l e i n fut capable de retrouver 40 % des mots de
passe d’un ordinateur moyen en utilisant ce système [848, 849]. Non, il n’a pas essayé
les mots de passe les uns après les autres en tentant de se connecter. Il a copié le dossier
chiffré du mot de passe et mené son attaque dans son coin. Voici ce qu’il a essayé :
1. Le nom de l’utilisateur, les initiales, le nom du compte, et d’autres informations
concernant la personne comme mot de passe possible. L ’un dans l’autre, jusqu’à
130 mots de passe différents furent essayés sur base de ces informations. Pour
un compte désigné par « klone » d ’un utilisateur appelé « D aniel V. K lein »
les mots de passe suivants furent entre autres tentés: klone, kloneO, k lo n e l,
k lo n el23, dvk, dvkdvk, d k le in , DKlein, le in a d , n ie lk , d vk lein , danielk,
DvkkvD, DANIEL-KLEIN, (k lo n e ), KleinD, etc.
2. Des mots de différentes bases de données. Celles-ci comprennent les listes des
noms d’hommes et de femmes (environ 16 0 0 0 au total) ; des noms d ’endroits (y
1 Note du traducteur : l’ inform ation reprise dans cette section est typiquem ent anglo-saxonne mais
elle est également d ’ application, moyennant de légères m odifications, pou r les utilisateurs d ’ expression
francophone.
compris les variantes telles que « sp a m », « spanish », « spaniard » soient tous

considérés) ; des noms de personnages célèbres ; des noms de dessins animés et
de personnages de dessins animés ; des titres, personnages et lieux de films ou
d ’histoires de science-fiction; des noms de créatures mythiques (collectées dans
la mythologie de B u l f i n c h et dans le dictionnaire des bêtes mythiques) ; des
sports (y compris les noms d’équipes, les surnoms et les termes spécialisés) : des
nombres (à la fois écrits en chiffre — « 2001 » et écrits en toute lettre « tw elve ») ;
des chaînes de caractères et de nombres (« a », « aa », « aaa », « aaaa », etc.);
des syllabes chinoises (à partir de la romanisation P i d g i n du chinois, un système
international standard pour écrire du chinois sur un clavier anglais) ; la K m g
James Bible ; les termes de la biologie ; des mots familiers ou vulgaires (tels que
« fuckyou », « ibmsux », « deadhead ») ; des motifs de clefs du clavier (tels que
« qwerty », « asdf », « zxcvbn ») ; des abréviations (telles que « roygb iv », les cou
leurs de l’arc-en-ciel en anglais ou « o o t ta f agvah », un mnémonique pour retenir
les noms des 12 nerfs crâniens en anglais) ; les noms de machines (à partir du fi
chier /etc/hosts) ; des personnages, pièces ou lieux de l’œuvre de SHAKESPEARE;
des mots communs du Yiddish ; des noms d ’astéroïdes ; et une collection de mots
de différents articles techniques publiés par K l e i n lui-même. Tout compris, plus
de 60000 mots différents furent considérés par utilisateur (en ignorant les dou
blons).
3. Des variantes des mots de l’étape 2. Cela inclut : mettre la première lettre en
majuscule, mettre un caractère de contrôle comme première lettre, mettre tout le
mot en majuscule, renverser le mot (avec et sans la mise en majuscule précédente),
remplacer la lettre « o » par le chiffre « 0 » (ainsi le mot « sc h o la r » sera aussi
testé comme « schOlar »), remplacer la lettre « 1 » par le chiffre « 1 » (ainsi le
mot « sch o la r » sera aussi testé comme « sc h o la r »), et faire des remplacements
similaires de la lettre « z » par le chiffre « 2 » et la lettre « s » par le chiffre « 5 ».
Un autre test consistait à mettre le mot au pluriel (peu importe si le mot était
bien un substantif) avec suffisamment de subtilité de telle manière que « d re ss »
devenait « d r e sse s », « house » devenait « houses », et « d a is y » devenait
« d a i s ie s ». Les règles de mise au pluriel ne furent pas seulement prises au pied
de la lettre par K l e in , ainsi « datum » devint « datums » (et non pas « data »),
tandis que « sphynx » devint « sphynxs » (et non pas « sphynges »). De la même
façon, les suffixes « -ed », « -e r » et « -in g » furent ajoutés pour transformer
des mots tels que « phase » en « phased », « phaser » et « phasing ». Ces
tests supplémentaires ajoutèrent 1000 000 de mots à la liste des mots de passe
possibles à tester pour chaque utilisateur.
4. Différentes mises en majuscule des mots de l’étape 2 qui ne furent pas considérées
pour l’étape 3. Cela inclut la mise en majuscule d’une seule lettre à toutes les
positions possibles (ainsi « m ichael » donne « m ichael », « miChael », « micHael »,
« michAel », etc.), la mise en majuscule de deux lettres (« M ichael », « MiChael »,
« MicHael », .. , « mIChael », « mlcHael », etc.), la mise en majuscule de trois
lettres, etc. La mise en majuscule d’une seule lettre rajouta environ 400000 mots
à tester par utilisateur tandis que la mise en majuscule de deux lettres rajouta
1500 000 de mots supplémentaires. La mise en majuscule de trois lettres aurait
rajouté au moins 3000000 de mots par utilisateur s’il y avait eu suffisamment de
temps pour effectuer les tests. Tester les mises en majuscule de quatre, cinq et
six lettres s’avérait infaisable sans beaucoup plus de puissance de calcul.
5. Des mots de langues étrangères pour des utilisateurs étrangers. Le test spécifique
qui fut réalisé était d’essayer des mots de passe chinois pour les utilisateurs chi
nois. La romanisation Pidgin des syllabes chinoises a été utilisée, en combinant
les syllabes par une, deux ou trois pour former des mots. Comme aucun test ne
fut fait pour déterminer si les mots engendrés avaient un sens, une recherche ex
haustive fut entamée. Comme il y a 298 syllabes chinoises dans le système Pidgin,
il y a 158 404 mots de deux syllabes et un peu plus de 16 000 000 de mots de trois
syllabes. Un mode d ’attaque similaire peut être aisément utilisé pour la langue
anglaise en utilisant des règles pour construire des mots prononçables mais sans
aucun sens.
6. Des paires de mots. L ’ordre de grandeur d’un test exhaustif de ce type est stupé
fiant. Pour simplifier le test, seuls les mots de trois et quatre caractères de long
de /usr/dic.t/words furent utilisés. Même ainsi, le nombre de paires est de l’ordre
de dix millions.
Une attaque par dictionnaire est bien plus efficace quand elle est montée contre un
fichier de clefs plutôt que contre une seule clef. Un seul utilisateur peut être assez
malin pour choisir de bonnes clefs. Si un millier de personnes choisissent leur propre
clef comme mot de passe d ’accès à un système informatique, les chances sont élevées que
le mot de passe d ’au moins une personne se trouve dans le dictionnaire de l’attaquant.
Clefs aléatoires
Les bonnes clefs sont des chaînes aléatoires de bits générées par des processus automa
tiques. Si une clef a 64 bits de long, toutes les chaînes possibles de 64 bits devraient
être équiprobables. Engendrez les bits de la clef à partir d’une source aléatoire fiable
(voir § 17.14) ou d ’un générateur pseudo-aléatoire de bits cryptographiquement sûr
(voir chapitres 16 et 17). Si ces dispositifs automatiques ne sont pas disponibles, lancez
une pièce de monnaie ou un dé.
C’est important, mais ne vous laissez pas emporter dans une conversation quant à
savoir si les bruits aléatoires des sources audios sont plus aléatoires que ceux des déchets
radioactifs. Aucun de ces bruits aléatoires sera parfait, mais ils seront probablement
assez bons. Il est important d ’utiliser un bon générateur de nombre aléatoire pour la
génération de clef, mais il est encore plus important d’utiliser de bons algorithmes de
chiffrement et de bonnes procédures de gestion de clefs. Si le fait que vos clefs soient
aléatoires vous ennuie, utilisez la technique du broyage de clef, décrite plus loin.
Certains algorithmes de chiffrement ont des clefs faibles : des clefs spécifiques qui sont
moins sûres que les autres clefs. Je vous conseille de détecter ces clefs et d ’en engendrer
une autre si vous en découvrez une. Le DES n’a que 16 ('lefs faibles sur 256, donc les
chances d’engendrer Lune d ’elles sont incroyablement faibles. Il a été argumenté qu’un
cryptanalyste n’aurait pas la moindre idée qu’une clef faible est utilisée et donc ne
tire pas avantage de leur utilisation accidentelle. Toutefois, détecter les quelques clefs
faibles est tellement facile qu’il semble imprudent de ne pas le faire.
Engendrer des clefs pour les systèmes de cryptographie à clef publique est nettement
plus difficile car souvent les clefs doivent avoir certaines propriétés mathématiques
(elles doivent parfois être un nombre premier, un résidu quadratique, etc.). Des tech
niques pour engendrer des grands nombres premiers aléatoires sont décrites dans le
paragraphe 11.5. La chose importante à se rappeler du point de vue de la gestion des
clefs est que les germes de ces générateurs doivent être complètement aléatoires.
Engendrer une clef aléatoire n ’est pas toujours possible. Parfois, il est nécessaire de
mémoriser votre clef2. Si vous devez engendrer une clef facile à mémoriser, rendez-
la obscure. L’idée est d ’avoir quelque chose de facile à mémoriser mais de difficile à
deviner. Voici quelques suggestions :
- Des paires de mots séparés par un signe de ponctuation,

par exemple: « tu rtle*m oose » ou « z o r c h ls p la t ».
- Des chaînes de caractères qui sont un acronyme de phrases plus longues, par
exemple « Mein Luftkissenfahrzeug ist voiler Aale! » donne la clef « MLivA ! ».
Phrases-mots de passe
Une meilleure solution est d ’utiliser une phrase entière au lieu d’un seul mot et de
convertir cette phrase en une clef. Ces phrases sont appelées phrase clef Une technique
appelée broyage de clef, transforme des phrases faciles à mémoriser en des clefs
aléatoires. Utilisez une fonction de hachage à sens unique pour transformer un texte
de longueur quelconque en une chaîne de bits pseudo-aléatoire.
Par exemple, le texte suivant facile à mémoriser:
Mon nom est Ozymandias, roi des rois. Contemple mon œuvre, O toi le
tout puissant, et désespère.
pourrait être « broyé » pour donner la clef de 64 bits suivante (en hexadécimal) :
E6C1 4398 5AE9 0A9B
Bien sûr, taper une phrase entière dans un ordinateur peut se révéler difficile. Les
bonnes idées pour résoudre ce problème sont les bienvenues.
Si la phrase est assez longue, la clef résultante sera aléatoire. Ce que signifie exactement
« assez longue » est sujet à interprétation. La théorie nous dit que l’anglais standard a
à peu près 1,3 bits d ’information par caractère (voir § 11.1). Pour une clef de 64 bits,
une phrase clef d’à peu près 49 caractères, ou de 10 mots normaux anglais, devrait
être suffisante. A vue de nez, dites-vous que vous avez besoin de 5 mots pour 4 bits de
clef C ’est une hypothèse modérée, sachant que cela ne prend en compte ni les lettres
majuscules ou minuscules, ni l’espacement, ni la ponctuation.
Cette technique peut même être utilisée pour engendrer la clef privée des systèmes
cryptographiques à clef publique : le texte peut être transformé en un germe aléatoire
et ce germe peut être fourni à un système déterministe qui engendre la paire « clef
privée, clef publique ».
Si vous choisissez une phrase clef, choisissez quelque chose d ’unique et de facile à retenir.
Ne choisissez pas des phrases extraites de la littérature, l’exemple de « Ozymandias »
n’est pas bon. Les œuvres complètes de S h a k e s p e a r e et les dialogues de « La guerre
des étoiles (Star Wars) » sont disponibles et peuvent être utilisés pour une attaque
2. Constatez com bien de tem ps il vous faut pou r m ém oriser 25e8 5 6 f2 e8ba c820.
par dictionnaire. Choisissez quelque chose d ’obscur, mais de personnel. Injectez-y de la

ponctuation et des majuscules ; si vous pouvez, ajoutez-y des nombres et des symboles
non alphanumériques. Des mots anglais incorrects, voire des mots étrangers, font que
votre phrase clef est moins sensible à une attaque par dictionnaire. Une suggestion est
d’utiliser une phrase « choquante et dénuée de sens » : quelque chose d ’assez offensif
que vous saurez retenir mais que vous n’écrirez sûrement pas.
Malgré tout ce qui a été écrit ici, l’obscurité ne remplacera pas le vrai hasard. Les
meilleurs clefs sont des clefs aléatoires, difficiles à retenir.
Génération de clefs suivant le standard ANSI X 9.17

Le standard AN SI X 9.17 désigne une méthode de génération de clefs (voir figure
8.1) [57]. Ce processus n ’engendre pas des clefs faciles à mémoriser : il est plus adapté à
la génération de clefs de session ou de nombres pseudo-aléatoires au sein d’un système.
L’algorithme cryptographique utilisé pour engendrer les clefs est le DES triple mais ce
pourrait être aussi bien tout autre algorithme.
F ig. 8 .1 Le standard ANSI X 9 .17 de génération de clefs
Soit E k ( X ) le chiffrement DES de X avec la clef K . C ’est une clef spéciale réservée
à la génération de clefs. Vo est un germe de 64 bits secret. T est une datation. Pour
engendrer la clef aléatoire Ri, calculez :
Ri = Epc(Efi-(7'z) © Vi).
Pour engendrer U f i, calculez:
V%+ 1 — E k ( E k ( Ti ) © R i ) .
Pour transformer Ri en une clef DES, ajustez simplement un bit sur huit pour la
parité. Si vous avez besoin d’une clef de 64 bits, utilisez-la telle quelle. Si vous avez
besoin d’une clef de 128 bits, engendrez une paire de clefs et joignez-les.
Génération de clefs du Département de la Défense américain

Le Département de la Défense américain recommande l’utilisation du DES en mode
OFB (voir § 9.8) pour générer des clefs aléatoires [1151]. Générez une clef DES à partir
de vecteurs d’interruption de système, de registres d’état de système et de compteurs
de système. Générez un vecteur d’initialisation à partir de l’horloge du système, de
l’identification du système, de la date et de l’heure. Pour le texte en clair, utilisez une
quantité de 64 bits générée en externe: huit caractères tapés par un administrateur
système par exemple. Utilisez le résultat comme votre clef.
8.2 Espaces des clefs non linéaires

Imaginez que vous êtes une organisation militaire de cryptographie, fabriquant des
équipements de cryptographie pour vos troupes. Vous voulez utiliser un algorithme sûr,
mais vous avez peur que cet équipement tombe entre des mains ennemies. La dernière
chose que vous voulez est que cet ennemi soit capable d’utiliser cet équipement pour
protéger ses propres secrets.
Si vous pouvez placer votre algorithme dans un module inviolable, voici ce que vous
pouvez faire. Vous pouvez exiger des clefs de forme spéciale et secrète ; toutes les autres
clefs feront que le module chiffrera et déchiffrera en utilisant un algorithme sévèrement
affaibli. Vous pouvez vous arranger pour que les chances de tomber sur une clef correcte
soient de plus en plus faibles quand on ne connaît pas cette forme spéciale.
On appelle cela un espace de clef non linéaire, car toutes les clefs ne sont pas de
force égale, (le contraire est un espace de clef linéaire). Une manière facile de le faire est
de créer la clef en deux parties : la clef elle-même et une chaîne fixe chiffrée avec cette
clef. Le module déchiffre la chaîne avec la clef; si il obtient la chaîne fixe il utilise la
clef normallement, sinon, il utilise un algorithme différent, plus faible. Si l’algorithme a
une clef de 128 bits et une taille de 64 bits, la clef générale est de 192 bits ; ceci donne
à l’algorithme une clef efficace de 2 128 et réduit les chances de trouver par hasard une
bonne clef à un contre 2 64.
Vous pouvez même être encore plus subtil. Vous pouvez créer un algorithme tel que
certaines clefs sont plus fortes que d ’autres. Un algorithme peut ne présenter aucune
clef faible — qui soit vraiment très mauvaise — tout en ayant un espace de clef non
linéaire.
Ceci ne marche que si l’algorithme est secret et si l’ennemi ne peut pas en analyser le
code machine, ou si la différence entre les niveaux de clefs est suffisamment subtile pour
que cela ne se remarque pas. La NSA l’a utilisé avec ses algorithmes secrets dans ses
modules Overtake (voir § 25.1). L ’ont-ils refait avec Skipjack (voir § 13.12)? Personne
ne le sait.
8.3 Transfert de clefs

Alice et Bernard vont utiliser un algorithme cryptographique à clef secrète pour com
muniquer de manière sûre ; ils ont besoin d ’une clef commune. Alice engendre une clef
en utilisant un générateur aléatoire de clefs. Maintenant elle doit la faire parvenir à
Bernard, en toute sécurité. Si Alice peut rencontrer Bernard quelque part (une allée
sombre, une pièce sans fenêtre, ou sur un des satellites de Jupiter), elle peut lui donner
une copie de la clef. Sinon, ils ont un problème. La cryptographie à clef publique résout
ce problème élégamment et avec un minimum de préarrangements, mais ces techniques
ne sont pas toujours disponibles (voir § 3.1). Certains systèmes peuvent utiliser des ca
naux de communication alternatifs réputés pour être sûrs. Alice peut envoyer à Bernard
la clef par un messager de confiance. Elle peut l’envoyer par courrier certifié ou via un
service de livraison express. Elle peut créer un nouveau canal de communication avec
Bernard et espérer que personne n’écoute celui-là.
Alice peut envoyer à Bernard la clef secrète sur le canal de communication, celui qu’ils
vont utiliser. C ’est idiot : si le canal garantit le chiffrement, envoyer la clef de chiffrement
8.3 Transfert de clefs 189
en clair sur le même canal garantit que n’importe qui écoutant le canal peut déchiffrer
toutes les communications.
Le standard X 9 .17 [57] détermine deux types de clefs : les clefs de chiffrement de clefs
et les clefs de données. Les clefs de chiffrement de clefs chiffrent les autres clefs
pour la distribution. Les clefs de données chiffrent le trafic des messages. Ces clefs de
chiffrement de clefs doivent être distribuées manuellement (bien qu’elles puissent être
en sécurité dans un système inviolable, tel qu’une carte à puce), mais seulement très
rarement. Les clefs de données sont distribuées plus souvent. Vous trouverez plus de
détails dans [82]. Ce concept de deux niveaux de clefs est très utilisé dans la distribution
de clefs.
Une autre solution au problème de distribution est de diviser la clef en plusieurs mor
ceaux (voir § 3.6) et d’envoyer chaque morceau par un canal différent. Un morceau
pourrait être envoyé par téléphone, un par courrier, un par courrier express, un par
pigeon voyageur, etc. (voir la figure 8.2). Comme un adversaire arrivant à collecter
tous les morceaux sauf un ne pourra pas reconstruire la clef, cette méthode marchera
dans tous les cas excepté les cas extrêmes. Le paragraphe 3.6 présente des schémas
pour diviser une clef en plusieurs morceaux. Alice pourrait même utiliser un schéma
de partage de secret (voir § 3.7), permettant à Bernard de reconstruire la clef même si
quelques morceaux se sont égarés pendant la transmission.
F ig. 8.2 - Distribution de clef morcelée
Alice envoie à Bernard la clef de chiffrement de clefs de manière sûre, soit en se ren
contrant en chair et en os, soit par la technique de morcellement présentée ci-dessus.
Une fois qu’Alice et Bernard disposent tous deux de la clef de chiffrement de clefs,
Alice peut envoyer à Bernard les clefs de données journalières sur le même canal de
communication. Alice chiffre chaque clef de données journalière avec la clef de chiffre
ment de clefs. Comme le volume chiffré avec la clef de chiffrement de clefs est faible,
elle ne doit pas être changée trop souvent. Toutefois, si la clef de chiffrement de clefs
est compromise alors tous les messages chiffrés avec toutes les clefs journalières sont
compromis, la clef de chiffrement des clefs doit être stockée de manière sûre.
Distribution de clefs dans des grands réseaux

Des clefs de chiffrement de clefs, partagées par des paires d’utilisateurs, conviennent
bien dans des petits réseaux, mais deviennent rapidement incommodes quand le réseau
s’agrandit. Comme chaque paire d’utilisateurs doit échanger des clefs, le nombre total
d’échanges de clefs requis dans un réseau de n personnes est de n(n — l ) / 2 .
Dans un réseau de 6 personnes, 15 échanges de clefs sont nécessaires. Dans un réseau
de 1000 personnes, près de 500 000 échanges de clefs sont nécessaires. Dans ce cas,
la création d ’un serveur central de clefs (ou de plusieurs serveurs) rend 1 opération
beaucoup plus efficace.
Alternativement, tout protocole de cryptographie à clef secrète ou de cryptographie à
clef publique du paragraphe 3.1 fournit un moyen de distribution de clefs sûr.
8.4 Vérification de clefs

Quand Bernard reçoit une clef, comment peut-il savoir que celle-ci vient bien d’Alice
et non pas de quelqu’un qui se fait.passer pour Alice? Si Alice lui a donnée lors d’une
rencontre en chair et en os, c’est facile. Si Alice a envoyé la clef par un porteur de
confiance, alors Bernard doit avoir confiance dans le porteur. Si la clef est chiffrée avec
une clef de chiffrement de clefs, alors Bernard doit avoir confiance dans le fait que seule
Alice a cette clef. Si Alice utilise un protocole de signature numérique pour signer la
clef, Bernard doit avoir confiance dans la base de données de clefs publiques quand il
vérifie la signature (il doit aussi croire qu’ Alice n ’a pas divulgué sa clef). Si le Centre
de Distribution des Clefs (C D C ) signe la clef publique d’Alice, Bernard doit avoir
confiance dans le fait que la clef publique du C D C n’a pas été falsifiée.
En fin de compte, quelqu’un qui contrôle complètement tout le réseau autour de
Bernard peut lui faire croire ce qu’il veut. Martin peut envoyer un message chiffré
et signé en prétendant être Alice. Quand Bernard essaie d’atteindre la base de données
de clefs publiques pour vérifier la signature d’Alice, Martin peut fournir sa propre clef
publique. Martin peut inventer son propre C D C factice et remplacer les vraies clefs
publiques du C D C pour son propre usage. Bernard ne se rendra compte de rien.
Certaines personnes ont utilisé cet argument pour clamer que la cryptographie à clef
publique est inutile. Comme le seul moyen pour Alice et Bernard de s’assurer que leur
clef n’est pas falsifiée est de se rencontrer en chair et en os, la cryptographie à clef
publique n’améliore pas du tout la sécurité.
Cette vision est naïve. C ’est théoriquement vrai, mais la réalité est bien plus compli
quée. La cryptographie à clef publique, utilisée avec des signatures numériques et des
C D C de confiance, rend bien plus difficile la substitution d’une clef par une autre.
Bernard peut ne jamais être tout à fait certain que Martin ne manipule pas son uni
vers, mais Bernard peut être certain que faire cela nécessite bien plus de ressources que
celles dont disposent la plupart des Martin du monde réel.
Bernard peut aussi vérifier la clef d ’Alice par téléphone, il entend alors sa voix. La
reconnaissance de la voix est un très bon moyen d ’identification. Si c ’est une clef
publique, il peut la réciter en toute sécurité en public. Si c ’est une clef secrète, il peut
utiliser une fonction de hachage à sens unique pour vérifier la clef. P G P (voir § 24.12)
et A T & T T SD (voir § 24.18) utilisent tous les deux ce genre de vérification de clef.
Parfois, il peut même être sans importance de vérifier à qui appartient une clef publique.
8.4 Vérification de clefs 191
Il peut être nécessaire de vérifier qu’elle appartient bien à la même personne que celle à
qui elle appartenait l’an dernier. Si quelqu’un envoie un ordre de retrait à une banque, la
banque ne doit pas s’inquiéter de savoir qui retire l’argent, elle doit seulement s’assurer
que c’est la même personne que celle qui a déposé l’argent originellement.
Détection d’erreurs pendant la transmission de clef

Parfois les clefs sont faussées pendant la transmission. Comme une clef faussée peut
signifier des mégaoctets de texte chiffré indéchiffrables, c’est un problème. Toutes les
clefs devraient être transmises avec un certain type de détection d ’erreurs et des bits de
correction d’erreur. De cette façon les erreurs de transmission peuvent être facilement
détectées, et si nécessaire la clef peut être retransmise.
Une des méthodes le plus communément utilisée est de chiffrer une valeur constante
avec la clef et d’envoyer les 2 à 4 premiers octets du texte chiffré en même temps que la
clef. Du côté du récepteur, on fait la même chose. Si les constantes chiffrées concordent,
alors la clef a été transmise sans erreurs. Les chances pour une erreur de ne pas être
détectée vont de 1 pour 2 16 à 1 pour 2 32.
Détection d’erreur de clef pendant le déchiffrement

Parfois, le destinataire veut vérifier si une clef particulière qu’il possède est la clef
secrète de déchiffrement. Si le texte en clair envoyé est du type A SC II, il peut essayer
de déchiffrer et lire le message. Si le texte en clair est aléatoire, il y a d’autres techniques.
L’approche naïve est d ’attacher un b l o c d e v é r i f i c a t i o n : une en-tête connue pré
cédant le texte en clair avant chiffrement. A la réception, Bernard déchiffre l’en-tête et
vérifie qu’elle est correcte. Ca marche, mais cela donne à Estelle un texte en clair connu
pour l’aider à cryptanalyser le système. Cela rend aussi plus faciles les attaques contre
les chiffres à clefs courtes comme le DES et les algorithmes exportables. Précalculez
la somme de contrôle une fois pour chaque clef, puis utilisez cette somme de contrôle
pour déterminer la clef de chaque message que vous interceptez par la suite. C’est une
caractéristique de toute somme de contrôle de clef où ne sont pas incluses des données
aléatoires ou tout du moins différentes. C ’est conceptuellement similaire à l’utilisation
d’un sel pour générer des clefs à partir de phrases-clefs.
Voici une meilleure façon de le faire [822] :
1° Générez un vecteur d’initialisation (différent de celui utilisé pour le message).
2° Utilisez ce vecteur d’initialisation pour générer un grand nombre de bits : par

exemple 512.
3° Hachez le résultat.
4° Utilisez les même bits de l’empreinte, par exemple 32, pour la somme de
contrôle de la clef.
Ceci donne à Estelle des informations, mais très peu. Si elle essaie d’utiliser les 32
bits de la valeur finale du hachage pour entreprendre une attaque massive, elle devra
effectuer de multiples chiffrements ainsi qu’un hachage par clef; une attaque massive
sur la clef elle-même serait plus rapide.
De plus, elle n’aura pas de valeurs de texte en clair connues à essayer, et même si elle
arrive à choisir une valeur aléatoire à notre place, elle ne pourra pas choisir un de nos
textes, puisqu’ils passent au hachage avant qu’elle puisse les voir.
8.5 Utilisation des clefs

Le chiffrement par logiciel est angoissant. Il est loin le temps où les simples micro-
ordinateurs étaient sous le contrôle de programmes isolés. Maintenant, il y a le SYSTEM
7 du M a c i n t o s h , W i n d o w s N T et U NIX. Vous ne pouvez pas prévoir quand le
système va interrompre l’application de chiffrement en cours, écrire le tout sur disque,
et s’occuper d’une tâche urgente. Quand le système redonne finalement la main au
chiffrement de ce qui doit être chiffré, tout a l’air normal. Personne ne réalise que
le système a écrit toute l’application de chiffrement sur disque et qu’il a écrit la clef
en même temps. La clef est maintenant sur le disque, non chiffrée jusqu’à ce que
l’ordinateur réécrive à cet endroit à nouveau. Cela peut prendre des minutes ou des
mois. Cela pourrait même jamais se produire : la clef pourrait encore être là quand
un adversaire passe le disque dur au peigne fin. Dans un environnement multitâche
préemptif, vous pouvez mettre votre application à un niveau de priorité suffisamment
élevé pour qu’elle ne soit pas interrompue. Cela diminuerait le risque. Même ainsi, c ’est
encore trop hasardeux.
Les réalisations matérielles sont plus sûres. De nombreux dispositifs sont conçus pour
effacer la clef si l’on essaie de les décortiquer. Par exemple, la carte de chiffrement de
l’IBM P S /2 a une unité en époxyde qui contient la puce DES, l’alimentation et la
mémoire. Bien sûr, vous devez faire confiance au fabricant pour qu’il ait réalisé cela
correctement.
Quelques applications de communication, tels que les chiffreurs de téléphone, peuvent
utiliser des c l e f s d e s e s s i o n . Une clef de session est une clef qu’on utilise juste pour
une opération de communication — une seule conversation téléphonique — puis dont
on se débarasse. Il n ’y a pas de raison de garder la clef après qu’elle ait été utilisée. Et si
vous utilisez un protocole d’échange de clef pour la transférer, elle n’a pas besoin d ’être
stockée avant d ’être utilisée. De ce fait, la clef est moins susceptible d ’être compromise.
Contrôler l’usage de la clef

Avec certaines applications, il est préférable de contrôler comment une clef de session
est utilisée. Certains utilisateurs en auront besoin seulement pour le chiffrement ou
le déchiffrement. Les clefs de session peuvent être autorisées à l’emploi sur certaines
machines ou à certains moments. Pour gérer ce genre de restrictions, un procédé attache
à la clef un V E C T E U R DE C O N TR Ô L E (V C ) ; le vecteur de contrôle définit les utilisations
et les restrictions de cette clef (voir § 24.1) [1035, 1036]. Ce VC est haché puis combiné
par ou exclusif avec une clef maîtresse ; le résultat est utilisé comme clef de chiffrement
pour chiffrer la clef de session. Cette clef de session ainsi chiffrée est alors stockée avec
le VC. Pour retrouver la clef de session, hachez puis combinez par ou exclusif le VC
avec la clef maîtresse et utilisez le résultat pour déchiffrer la clef de session chiffrée.
Les avantages de ce procédé sont que le VC peut être d’une longueur tout à fait arbi
traire et qu’il est toujours stocké en clair avec la clef chiffrée. Ce procédé est en partie
responsable de l’inviolabilité des matériels et de l’incapacité des utilisateurs d’accéder
8.6 Mise à jour des clefs 193
directement aux clefs. Ce système est abordé plus à fond dans les chapitres 24.1 et
24.8.
8.6 Mise à jour des clefs

Imaginez un lien de données chiffrées où vous voulez changer vos clefs quotidiennement.
Il est souvent fastidieux de distribuer une nouvelle clef chaque jour. Une solution plus
facile est de générer une nouvelle clef à partir de l’ancienne; quelquefois, on appelle
cela une m i s e À j o u r d e s c l e f s .
Il suffit d ’une fonction de hachage à sens unique. Si Alice et Bernard partagent la même
clef et l’utilisent simultanément avec la même fonction à sens unique, ils obtiendront
le même résultat. Puis ils peuvent prendre les bits dont ils ont besoin pour créer la
nouvelle clef.
La mise à jour de clef marche, mais souvenez-vous que la nouvelle clef n’est pas plus
sûre que l’ancienne. Si Estelle a réussi à mettre la main sur l’ancienne clef, elle peut
effectuer l’opération de mise à jour de clef elle-même. Néanmoins, si Estelle n’a pas
l'ancienne clef et lance une attaque seulement à texte de chiffré sur le trafic chiffré,
c’est une bonne manière pour Alice et Bernard de se protéger.
8.7 Stockage des clefs

Le stockage de clefs le moins complexe est pour l’utilisateur isolé, Alice, qui chiffre
ses fichiers pour une utilisation future. Comme elle est la seule concernée, elle est la
seule responsable de sa clef. Certains systèmes prennent une approche facile : la clef
est stockée dans le cerveau d ’Alice et jamais dans le système. Alice doit mémoriser la
clef et l’entrer chaque fois qu’elle a besoin qu’un fichier soit chiffré ou déchiffré.
Un exemple d’un tel système est donné par IPS [881]. Les utilisateurs peuvent soit
entrer directement leur clef de 64 bits, soit entrer la clef sous forme d ’une longue
chaîne de caractères. Le système engendre alors une clef de 64 bits à partir de la chaîne
de caractères, à l’aide d’une technique de broyage de clefs.
Une autre solution est de stocker la clef sur une carte à piste magnétique, une clef en
plastique avec une puce R O M (appelée une clef R O M ), ou sur une carte à puce [558,
559, 461]. Un utilisateur peut alors entrer sa clef dans le système, en insérant sa carte
dans un lecteur spécial de la boîte de chiffrement ou attaché au terminal informatique.
Il peut l’utiliser seulement dans les limites précisées par le vecteur de contrôle.
La clef RO M est une très bonne idée. Les personnes comprennent les clefs physiques,
ce qu’elles représentent et comment les protéger. Mettre une clef cryptographique sous
cette même forme rend le stockage et la protection de cette clef plus intuitive.
Cette technique est rendue encore plus sûre en morcelant la clef en deux moitiés et en
stockant une moitié dans le terminal et l’autre moitié dans la clef R O M . Le procédé
STU-III du gouvernement américain de protection du téléphone fonctionne de cette
manière. Perdre la clef R O M ne compromet pas la clef cryptographique, changez-la
et tout rentre dans l’ordre. Ceci est aussi vrai dans le cas de la perte du terminal. De
cette façon, compromettre soit la clef R O M soit le terminal ne compromet pas la clef
cryptographique — un adversaire doit avoir les deux moitiés.
Des clefs difficiles à mémoriser peuvent être stockées sous forme chiffrée, en utilisant
quelque chose de similaire à une clef de chiffrement de clefs. Par exemple, une clef
privée R SA peut être chiffrée par DES et stockée sur le disque. Pour récupérer la clef
R SA , l'utilisateur doit donner la clef D ES au programme de déchiffrement.
Si les clefs sont engendrées de manière déterministe (avec un générateur pseudo
aléatoire de nombres cryptographiquement sûr) il peut être plus simple de réengendrer
les clefs à partir d ’un mot de passe facile à retenir chaque fois qu’elles sont nécessaires.
L’idéal serait qu’une clef n’apparaisse jamais non-chiffrée hors du module de chiffre
ment. Ce n’est pas toujours possible, mais c’est un but que nous devons atteindre.
8.8 Duplicata des clefs

Alice est le responsable financier de la société « Secrets, S.A. », « Nous ne dévoilons pas
notre devise ». Comme tout employé consciencieux, elle suit les consignes de sécurité de
sa société et chiffre toutes ses données. Malheureusement, elle ignore les consignes de
sécurité routière pour traverser la rue et est renversée par un camion. Que fait Bernard,
le président de la société?
Bernard est bien embarassé, à moins qu’Alice n’ait laissé une copie de sa clef. Le but
du chiffrement est de rendre les fichiers non récupérables sans la clef. Ses fichiers seront
perdus à jamais, à moins qu’Alice soit une débile ou qu’elle utilisait un logiciel de
chiffrement miteux.
Bernard peut éviter cela de plusieurs manières. La plus simple est parfois appelée
d é p ô t d e c l e f (voir § 4.14) : Bernard exige que ses employés mettent leur clef par écrit
et la donnent au responsable de la sécurité de l’entreprise, qui les enfermera en lieu sûr
(ou qui les chiffrera toutes avec une clef maîtresse). Maintenant, si Alice est tuée sur
l’autoroute, Bernard peut demander la clef d’Alice à son responsable de la sécurité.
Bernard devrait aussi s’assurer d ’avoir personnellement la combinaison du coffre, sinon
si le responsable de la sécurité est lui aussi écrasé par un autre camion, Bernard serait
de nouveau frappé par la malchance.
Le problème avec ce système de gestion de clefs est que Bernard doit avoir confiance
dans le responsable de la sécurité pour que celui-ci ne fasse pas un mauvais usage des
clefs dont il a la garde. Plus important encore, tous les employés doivent avoir confiance
dans le responsable de la sécurité pour qu’il ne fasse pas mauvais usage de leur clef.
Une bien meilleure solution est d ’utiliser un protocole de partage de secret (voir § 3.7).
Quand Alice engendre la clef, elle partage également celle-ci en un certain nombre de
morceaux. Elle envoie ensuite chaque morceau — chiffré bien sûr — à un employé
différent de la compagnie suivant en cela les consignes de sécurité de la société. Aucun
des morceaux n’est la clef à lui seul mais quelqu’un peut rassembler les morceaux et
peut ainsi reconstruire la clef. Maintenant, Alice est protégée contre toute personne
malintentionnée et Bernard est protégé de la perte de toutes les données d’Alice en
cas d ’accident. Ou encore, elle peut stocker tous les morceaux, chacun chiffré avec une
clef publique d ’un employé différent de la société, sur son propre disque dur . De cette
façon, personne ne s’occupe de la gestion des clefs tant que ce n’est pas nécessaire.
Un autre schéma de duplication de clef [194] utilise les cartes à puce (voir § 24.13)
pour le dépôt temporaire des clefs. Alice peut mettre sa clef d ’ordinateur sur une carte
à puce et la donner à Bernard pendant qu’elle s’absente. Bernard peut utiliser la carte
pour avoir accès à son ordinateur, mais comme la clef est inscrite dans la carte, Bernard
8.9 Clefs compromises 195
ne peut pas la connaître. Et le système marche à double sens : Bernard peut vérifier
que la clef permet l’accès à l’ordinateur d ’Alice, et quand Alice reviendra, elle pourra
vérifier si Bernard a utilisé la clef et si oui, combien de fois.
Un tel schéma n’est pas applicable aux transmissions de données. Sur un téléphone
protégé, la clef ne devrait exister que le temps de l’appel. Pour le stockage de données,
comme on vient de le dire, le dépôt de clef peut être une bonne idée. J’ai perdu environ
une clef tous les cinq ans, et ma mémoire est supérieure à la moyenne. Si 200 millions
de personnes utilisaient la cryptographie, ce même taux équivaudrait à 40 millions de
clefs perdues annuellement. Je laisse un double des clefs de ma maison à mon voisin,
au cas où je les perde. Si les clefs de la maison étaient des clefs cryptographiques, et si
je les perdais, je ne pourrais plus jamais rentrer chez moi. Au même titre que je garde
à part un duplicata de mes données, il me semble logique de garder une copie de ses
clefs de chiffrement de données.
8.9 Clefs compromises

Tous les protocoles, techniques et algorithmes de ce livre ne sont sûrs que si la clef (la
clef privée dans un système à cryptographie à clef publique) reste secrète. Si la clef
d’Alice est perdue, volée, imprimée dans un quotidien ou compromise d’une façon ou
d’une autre, alors toute sa sécurité s’envole.
Si la clef compromise était celle d ’un système cryptographique à clef secrète, Alice doit
changer sa clef et espérer que le dommage causé est minimum. Si c’était une clef privée,
elle a de plus gros problèmes ; sa clef publique est probablement sur tous les serveurs
du réseau. Et si Estelle a accès à la clef privée d’Alice, elle peut alors se faire passer
pour elle sur le réseau : elle peut lire du courrier chiffré, signer de la correspondance,
conclure des contrats, et ainsi de suite. Estelle peut devenir Alice.
Quand une clef privée est compromise il est vital de diffuser l’information le plus vite
possible à travers le réseau. Toute base de données publique de clefs publiques doit être
immédiatement avertie qu’une clef privée est corrompue, sinon quelqu’un qui n’est pas
au courant pourrait chiffrer un message avec cette clef.
Il faut espérer qu’Alice sait quand sa clef a été compromise. Si un C D C gère les clefs,
Alice doit l’avertir que sa clef a été compromise. S’il n ’y a pas de C D C , elle doit
alors avertir tous ses correspondants. Quelqu’un doit rendre public le fait que tout
message reçu après la perte de la clef est suspect et que personne ne doit envoyer
de message à Alice avec la clef publique associée. L’application devrait utiliser un
système de datation et les utilisateurs peuvent alors différencier les messages suspects
des messages légitimes.
Si Alice ne sait pas exactement quand sa clef a été compromise, les choses sont plus
difficiles. Alice peut vouloir annuler un contrat signé par la personne qui a volé la clef.
Si le système le permet, alors tout un chacun a la possibilité d ’annuler un contrat rien
qu’en prétendant que sa clef a été compromise avant la signature du contrat. Seul le
juge pourra en débattre.
C’est un problème très sérieux qui met en lumière les dangers que prend Alice en liant
son identité à une seule clef. Alice ferait mieux d ’avoir différentes clefs pour différentes
applications — tout comme elle a différentes clefs dans sa poche qui ouvrent différentes
serrures. D ’autres solutions à ce problème sont la biométrie, des limitations d ’utilisation
d’une clef, l’insertion de délais et la contre-signature.
Les procédures et les recommandations sont rarement optimales, mais elles sont ce que
l’on peut faire de mieux. La morale de cette histoire est qu’il faut protéger les clefs, et
les clefs privées par-dessus tout.
8.10 Longévité des clefs

Aucune clef de chiffrement ne doit être utilisée pour une période indéfinie. Elle devrait
expirer automatiquement tout comme un passeport ou une licence. 1 1 y a plusieurs
raisons à cela :
- Plus la clef sera utilisée longtemps, plus elle aura de chances d’être compromise.
Les gens mettent par écrit les clefs, ils les perdent. Les accidents arrivent. Si
vous utilisez la même clef pendant un an, il y a bien plus de chances qu’elle soit
compromise que si vous l’utilisez un jour seulement.
Plus la clef est utilisée longtemps, plus grande est la perte si la clef est compro
mise. Si la clef est utilisée seulement pour chiffrer un seul document de budget
sur un serveur de fichiers, alors la perte de la clef ne compromet que ce document.
Si la même clef est utilisée pour chiffrer tous les budgets sur le serveur de fichiers
alors la perte est nettement plus catastrophique.
- Plus la clef est utilisée longtemps, plus grande est la tentation pour quelqu’un de
fournir l’effort nécessaire pour la retrouver — même si cet effort est une attaque
exhaustive. Retrouver une clef partagée par deux unités militaires pendant un
jour permettrait à quelqu’un de lire et d’engendrer des messages entre ces deux
unités pendant un jour. Retrouver une clef partagée par un état-major de l’armée
pendant un an permettrait à la même personne de lire et d’engendrer des mes
sages à travers le monde entier pendant toute une année. En ayant conscience
du budget, dans notre monde d’après-guerre froide, quelle clef choisiriez-vous
d’attaquer?
- Il est en général plus facile d ’effectuer une cryptanalyse quand on a plus de texte
chiffré avec une même clef.
Pour toute application cryptographique, il doit y avoir une consigne qui détermine la
longévité d’une clef. Des clefs différentes peuvent avoir des longévités différentes. Pour
un système basé sur la connection, tel que le téléphone, il semble logique d’utiliser une
clef pour la durée de l’appel et d ’en utiliser une nouvelle à chaque appel. Les systèmes
dédiés aux canaux de communication ne sont pas si évidents Les clefs devraient avoir
une durée de vie relativement courte, selon la valeur et la quantité de données chiffrées
pendant une période donnée. La clef pour une liaison de communication à 1 gigabit
par seconde doit être changée plus souvent que la clef pour une liaison par modem à
9600 bauds. En faisant l’hypothèse qu’il existe une méthode efficace pour transmettre
des nouvelles clefs à l’aide d ’une clef de chiffrement de clefs, les clefs de session doivent
être changées au minimum chaque jour.
Les clefs de chiffrement de clefs ne doivent pas être changées aussi souvent. Elles sont
utilisées occasionnellement (grosso modo une fois par jour) pour l’échange de clefs. Cela
génère peu de texte chiffré au cryptanalyste, et le texte en clair correspondant n’a pas
8.11 Destruction des clefs 197
de forme particulière. Toutefois, si une clef de chiffrement de clefs est compromise, la

perte potentielle est énorme : toutes les communications chiffrées avec ces clefs. Dans
certaines applications, les clefs de chiffrement de clefs sont changées seulement une fois
par mois ou une fois par an. Vous devez comparer le danger induit par le maintien
d’une clef pour un bon moment à celui induit par la distribution d ’une nouvelle clef.
Les clefs de chiffrement utilisées pour chiffrer des fichiers pour archivage ne doivent
pas être changées souvent. Les fichiers peuvent rester chiffrés sur le disque pendant des
mois ou des années avant qu’on en ait besoin à nouveau. Les déchiffrer et les rechiffrer
avec une nouvelle clef chaque jour n’augmente aucunement la sécurité: cela donne
juste plus de matière première au cryptanalyste. Une solution serait de chiffrer chaque
fichier avec une clef unique par fichier et ensuite de chiffrer toutes ces clefs avec une
clef de chiffrement de clefs. La clef de chiffrement de clefs devrait alors être mémorisée
ou stockée dans un endroit sûr. Bien sûr la perte de cette clef signifierait la perte de
toutes les autres clefs.
Les clefs privées des applications de cryptographie à clef publique ont des durées de
vie variables en fonction de l’application. Les clefs privées utilisées pour les signatures
numériques et les preuves d’identité doivent durer des années (voire même une vie
entière). Les clefs privées utilisées pour jouer à pile ou face peuvent être ignorées
directement après avoir terminé le protocole. Même si la sécurité d’une clef est supposée
durer toute une vie, il peut être prudent de la changer de tant à autre. Les clefs privées
de nombreux réseaux ne sont valables que deux ans ; après cela l’utilisateur doit se
procurer une nouvelle clef privée. L’ancienne clef doit toujours rester secrète au cas où
l’utilisateur doive vérifier une signature numérique pour cette période. Mais la nouvelle
clef devrait être utilisée pour signer de nouveaux documents, réduisant ainsi le nombre
de documents dont disposerait un cryptanalyste pour une attaque.
8.11 Destruction des clefs

Etant donné que les clefs doivent être remplacées régulièrement, les vieilles clefs doivent
être détruites. Les vieilles clefs ont de la valeur, même si elles ne sont plus jamais
utilisées. Avec celles-ci, un adversaire peut lire d ’anciens messages chiffrés [70].
Les clefs doivent être détruites de manière sûre (voir § 10.9). Si la clef est écrite sur un
bout de papier, le papier peut être déchiqueté ou brûlé. Veillez à utiliser une machine
à déchiqueter de très bonne qualité : de nombreux mauvais déchiqueteurs sont sur le
marché. Les algorithmes de ce livre sont protégés des attaques exhaustives qui coûtent
des millions de dollars et qui prennent des millions d ’années. Si un adversaire peut
retrouver votre clef en récupérant la sortie de la machine à déchiqueter dans votre
poubelle, et s’il peut payer 1 0 0 chômeurs dans un pays pauvre 0 , 1 dollar par heure
pendant un an pour recoller les pages déchiquetées, cela ne représenterait que 26 0 0 0 $
bien dépensés.
Si la clef est dans une mémoire E E P R O M , la clef peut être réécrite plusieurs fois. Si la
clef est dans une E P R O M ou une P R O M , la puce doit être broyée en mille morceaux
et disséminée aux quatre vents. Si la clef est stockée sur un disque d ’ordinateur, les bits
utilisés pour son stockage doivent être réécrits plusieurs fois (voir § 10.9) ou le disque
devrait lui-même être déchiqueté.
Un problème potentiel est que, dans un ordinateur, les clefs peuvent être facilement
copiées et stockées en divers endroits. Tout ordinateur qui autogère sa mémoire, en
écrivant et en lisant continuellement la mémoire de travail sur le disque, ne fait qu’aug

menter le problème. Il n’y a aucun moyen de s’assurer que la clef a effectivement
été correctement effacée, plus particulièrement si le système de conduite de l’ordina
teur contrôle le processus d ’effacement lui-même. Les plus paranoïaques d ’entre vous
doivent envisager l’écriture d’un programme d ’effacement spécial qui balaie tous les
disques pour rechercher des copies du motif des bits de la clef dans les blocs non utili
sés et alors effacer ces blocs. N’oubliez pas non plus d’effacer le contenu de tout fichier
temporaire, ou du fichier de pagination (« swap file ») si nécessaire.
8.12 Gestion des clefs

pour la cryptographie à clef publique
La cryptographie à clef publique rend la gestion des clefs plus facile mais elle a ses
propres problèmes. Chaque personne n’a qu’une clef publique, peu importe le nombre
d’utilisateurs du réseau. Si Alice veut envoyer un message à Bernard, elle doit se pro
curer la clef publique de Bernard. Elle peut l’obtenir de plusieurs manières :
Elle peut l’obtenir auprès de Bernard.

Elle peut l’obtenir auprès d’une base de données centrale.
Elle peut l’obtenir à partir de sa propre base de données privée.
Le paragraphe 2.5 présente un certain nombre d’attaques contre la cryptographie à clef

publique, basée sur Martin qui remplace la clef de Bernard par la sienne. Le scénario
est qu’Alice veut envoyer un message à Bernard. Elle demande à la base de données
publique et obtient la clef publique de Bernard. Mais Martin, qui est sournois, remplace
la clef de Bernard par la sienne. (Si Alice demande directement à Bernard, Martin doit
intercepter la communication entre Alice et Bernard et remplacer la clef de Bernard par
la sienne.) Alice chiffre son message avec la clef de Martin et l’envoie à Bernard. Martin
intercepte le message, le déchiffre, le lit. Il le rechiffre alors avec la vraie clef publique
de Bernard et envoie le résultat à Bernard. Ni Alice, ni Bernard ne remarquent quoi
que ce soit.
Certificat de clef publique

Un CE RTIFIC AT DE c l e f p u b l i q u e est constitué de la clef publique de quelqu’un si
gnée par une personne de confiance. Les certificats sont utilisés pour contrecarrer les
remplacements d’une clef par une autre [879]. Le certificat de Bernard dans la base
de données des clefs publiques contient bien plus que sa clef publique. Il contient des
informations concernant Bernard — son nom, son adresse, etc. — et il est signé par
quelqu’un en qui Alice a confiance : Ivan, habituellement connu sous le nom d’autorité
de certification (A C en abrégé). En signant à la fois la clef et les informations concer
nant Bernard, Ivan certifie que ces informations sont correctes et que la clef publique
appartient bien à Bernard. Alice vérifie la signature de Ivan et ensuite utilise la clef
publique en étant sûre que c’est bien celle de Bernard et de personne d ’autre. Les cer
tificats jouent un rôle important dans nombre de protocoles à clef publique tels que le
PE M [827] (voir § 24.10) et le X .509 [309] (voir § 24.9).
8.12 Gestion des clefs pour la cryptographie à clef publique 199
Une caractéristique compliquée non-cryptographique accompagne ce genre de système.

Quelle est la signification de la certification? Ou, pour s’exprimer autrement, qui est
investit du pouvoir de certification, et envers qui? N’importe qui peut signer le certi
ficat d’un autre, mais il faut un moyen de filtrer les certificats suspects : par exemple,
les certificats d’employés d’une compagnie signés par l’ A C pour une autre compagnie.
Normalement, une chaîne de certification transfère la confiance: une seule entité dé
signée certifie des agents, ces agents certifient les A C des entreprises, lesquelles A C
certifient leurs employés.
Voici d’autres questions qui demandent réflexion :
- Quel niveau de confiance en l’identité de quelqu’un est induit par son certificat ?
- Quelles sont les relations entre une personne et l’A C qui certifie sa clef publique,
et comment ces relations peuvent être impliquées par le certificat?
- Qui peut-on désigner comme étant la « seule entité de confiance » au sommet de

la chaîne de certification?
De quelle longueur devrait être une chaîne de certification?
L’idéal serait que Bernard suive une sorte de procédure d ’authentification avant que
l’AC ne signe son certificat. De plus, une datation ou une indication de la période de
validité du certificat est importante pour se protéger des clefs compromises [467].
La datation n’est pas suffisante. Les clefs peuvent être invalidées avant expiration, soit
pour des raisons de compromission ou administratives. C ’est pourquoi il est important
que l’A C garde une liste des certificats invalidés et que les utilisateurs la consulte
régulièrement. Ce problème de révocation de clef est toujours difficile à résoudre.
Une paire « clef publique, clef privée » n ’est pas suffisante. Il est certain qu’une bonne
application de la cryptographie à clef publique requiert des clefs distinctes pour le chif
frement et les signatures digitales. Cette séparation permet d ’avoir différents niveaux
de sécurité, temps d’expiration, procédures de duplication, etc... Quelqu’un pourrait
signer des messages avec une clef de 2048 bits stockée dans une carte à puce et va
lable pour 20 ans, alors qu’ils pourraient utiliser une clef de 768 bits stockée dans un
ordinateur et valable pour six mois pour le chiffrement.
Une paire unique de clefs pour le chiffrement et la signature n’est pas non plus suf
fisante. Une clef privée authentifie une relation ainsi qu’une identité, et les personnes
ont plus d’une relation. Alice pourrait vouloir signer un document en tant qu’Alice,
l’individu, un autre en tant qu’Alice, vice-présidente de la société « Monolith, S.A. », et
un troisième en tant qu’Alice, présidente d ’une organisation communautaire. Certaines
de ces clefs sont plus importantes que d ’autres et demandent à être mieux protégées.
Alice pourrait avoir à stocker un duplicata de sa clef de travail auprès de l’officier de
sécurité de l’entreprise ; elle ne veut pas que l’entreprise ait une copie de la clef avec
laquelle elle a signé un emprunt. Tout comme Alice a plusieurs clefs dans sa poche, elle
aura plusieurs clefs cryptographiques.
Gestion distribuée des clefs

Dans certaines situations, ce genre de gestion des clefs centralisée ne marchera pas.
Peut-être qu’il n’y a pas d ’A C en laquelle Alice et Bernard ont confiance. Peut-être
qu’Alice et Bernard n’ont confiance qu’en leurs amis. Peut-être qu’Alice et Bernard
n’ont confiance en personne.
La gestion distribuée des clefs, utilisée dans le programme « Pretty Good Privacy »
(P G P ) (voir § 24.12) résout ce problème à l’aide de parrains. Les parrains sont
d’autres utilisateurs du système qui peuvent signer les clefs publiques de leurs amis.
Par exemple, quand Bernard engendre sa clef publique, il en donne une copie à ses
amis: Christine et David. Ils connaissent Bernard et donc ils signent chacun la clef
publique de Bernard et lui envoient une copie des clefs signées. Maintenant, Bernard
présente sa clef publique à une étrangère, Alice; il la lui présente avec les signatures
de ses deux parrains. Si Alice connaît et a confiance en Christine, elle a des raisons
de croire que la clef de Bernard est valide. Si elle connaît un peu et a quelque peu
confiance en Christine et David, elle a des raisons de croire que la clef de Bernard est
valide. Si elle ne connaît ni Christine ni David, elle n’a aucune raison de faire confiance
à la clef de Bernard.
Au fil du temps, Bernard rassemblera bien plus de parrains. Si Alice et Bernard gra
vitent dans les mêmes cercles, les chances d ’Alice de connaître un des parrains de
Bernard sont élevées. Pour se prémunir contre Martin qui remplace une clef par une
autre, un parrain doit s’assurer que la clef de Bernard appartient bien à celui-ci avant de
la signer. Le parrain peut demander que la clef soit communiquée lors d ’une rencontre
en chair et en os, ou vérifiée par téléphone.
L ’avantage de ce mécanisme est qu’il n’y a pas d’A C en qui tout le monde doit avoir
confiance. Le défaut est que lorsqu’Alice reçoit la clef publique de Bernard, elle n’a
aucune garantie de connaitre un des parrains, et par conséquent aucune garantie de
pouvoir avoir confiance dans la validité de cette clef.
Chapitre 9
Types et modes d’algorithmes
Il existe deux modèles de base d ’algorithmes à clef secrète : l’algorithme de chiffrement

par blocs et l’algorithme de chiffrement en continu. Les algorithmes de chiffrement
par blocs manipulent des blocs de texte en clair et de texte chiffré — généralement
de 64 bits mais quelquefois plus longs. Les algorithmes de chiffrement en continu
manipulent des flots de textes en clair et de textes chiffrés bit par bit ou octet par
octet (ou même mot de 32 bits par mot de 32 bits). Avec un algorithme de chiffrement
par blocs, le même bloc de texte en clair sera toujours chiffré en un même bloc de
texte cliiffré, en utilisant la même clef. Avec un algorithme de chiffrement en continu,
le même bit ou octet de texte en clair sera chiffré en un bit ou un octet différent à
chaque chiffrement.
Un mode cryptographique combine en général un algorithme cryptographique, une

sorte de rétroaction et des opérations simples. Les opérations sont simples car la sécurité
est une fonction du chiffrement sous-jacent, et non du mode. De plus, le mode de
chiffrement ne devrait pas compromettre la sécurité de l’algorithme dont il découle.
Il y a d’autres motifs de sécurité : les motifs dans un texte en clair doivent être dissimu
lés, l’entrée de l’algorithme cryptographique doit être rendue aléatoire, la manipulation
du texte en clair par insertion d’erreurs dans le texte chiffré doit être difficile et le chif
frement de plus d’un message avec la même clef doit être possible. Nous discuterons
de tout ceci en détails dans les paragraphes suivants.
L’efficacité est aussi à prendre en considération. Le mode ne doit pas être moins efficace,
de manière significative, que l’algorithme cryptographique sous-jacent. Dans certaines
circonstances, il est important que le texte chiffré ait la même taille que le texte en
clair.
Une troisième considération concerne la tolérance aux fautes. Certaines applications

ont besoin de chiffrer ou de déchiffrer en parallèle, alors que d’autres ont besoin de
faire autant de précalculs que possible. Avec encore d ’autres, il est important que le
processus de déchiffrement soit capable de surmonter des erreurs de bits dans le flot
de textes chiffrés, des pertes ou des rajouts de bits. Comme nous allons le voir, les
différents modes ont différents sous-ensembles de ces caractéristiques.
202 Chapitre 9 Types et modes d’algorithmes
9.1 Carnet de codage électronique

Le mode du c a r n e t d e c o d a g e é l e c t r o n i q u e (E C B pour « Electronic CodeBook »)
est la méthode la plus évidente pour utiliser un algorithme de chiffrement par blocs
un bloc de texte en clair se chiffre en un bloc de texte chiffré. Comme un même bloc de
texte en clair sera toujours chiffré en un même bloc de texte chiffré, il est théoriquement
possible de créer un carnet de codage de textes en clair et de leurs textes chiffrés
correspondants. Néanmoins, si la taille du bloc est de 64 bits — le carnet de codage
aura donc 264 entrées — ce qui est bien trop grand pour être précalculé et stocké. Et
rappelez-vous, chaque clef a un carnet différent.
C ’est le mode opératoire le plus simple à utiliser. Chaque bloc de texte en clair est
chiffré indépendamment. Vous n’avez pas à chiffrer un fichier linéairement : vous pouvez
d’abord chiffrer les 1 0 blocs du milieu, ensuite les blocs de la fin puis ceux du début.
C ’est important pour des fichiers chiffrés auxquels on accède aléatoirement, comme une
base de données. Si une base de données est chiffrée par le mode ECB, alors n’importe
quel enregistrement peut être ajouté, effacé, chiffré ou déchiffré indépendamment de
tous les autres — en faisant l’hypothèse que les enregistrements ont un nombre entier de
blocs de chiffrement. Et le processus est dérivable ; si vous avez de multiples processeurs
de chiffrement, ils peuvent chiffrer ou déchiffrer différents blocs qui n’ont aucun rapport
les uns avec les autres.
Le défaut du mode E CB est que si un cryptanalyste a le texte en clair et le texte
chiffré de plusieurs messages, il peut commencer à construire un carnet de codage sans
connaître la clef. Dans la plupart des situations du monde réel, des fragments de mes
sages ont tendance à se répéter. Différents messages peuvent avoir des séquences de bits
en commun Des messages engendrés par ordinateur, tel que le courrier électronique,
peuvent avoir des structures régulières. Les messages peuvent être redondants ou avoir
de longues chaînes de zéros ou d ’espaces.
Si un cryptanalyste apprend que le texte en clair « 5e081bc5 » donne le texte chiffré
« 7ea593a4 », il est capable de déchiffrer ce bloc de texte chiffré dès qu’il apparaît
dans un autre message. Si les messages chiffrés contenant beaucoup de redondances,
et qu’elles ont tendance à apparaître aux mêmes endroits dans différents messages,
un cryptanalyste peut obtenir beaucoup d’informations. Il peut mener des attaques
statistiques contre le texte en clair sous-jacent, sans se soucier du niveau de l’algorithme
de chiffrement par blocs.
Cette vulnérabilité est plus grande au début et à la fin des messages où apparaissent
des en-têtes et des conclusions bien définies qui contiennent des informations concer
nant l’expéditeur, le destinataire, la date, etc. Ce défaut est parfois appelé débuts
stéréotypés et fins stéréotypées et sera évité par les modes décrits ci-après.
Le côté positif est qu’il n’y a pas de risque, au point de vue sécurité, à chiffrer de
multiples messages avec la même clef. En fait, chaque bloc peut être considéré comme
un message à part chiffré avec la même clef. Les erreurs de bits dans le texte chiffré,
quand il est déchiffré, feront que le bloc entier de texte en clair sera incorrectement
déchiffré mais n’affecteront pas le reste du texte en clair. Néanmoins, si un bit du texte
chiffré est accidentellement perdu ou rajouté, le reste du texte chiffré sera incorrecte
ment déchiffré à moins qu’il y ait une sorte de structure d ’encadrement pour réaligner
les limites du bloc.
9.2 Bloc rejoué 203
Remplissage
La plupart des messages ne se divisent pas exactement en un nombre entier de blocs
de 64 bits (ou de toute autre taille) : il y a d ’habitude un bloc court à la fin. L’ECB
traite des blocs de 64 bits. Le rem plissage permet de régler ce problème.
Remplissez le bloc avec un schéma régulier des zéros, des uns, des uns et des zéros en
alternance — pour compléter le bloc. Si vous devez être capable de retirer le remplissage
après le déchiffrement, ajoutez le nombre d ’octets de remplissage comme dernier octet
du dernier bloc. Par exemple, faites l’hypothèse que la taille des blocs est de 64 bits,
et que le dernier bloc contient 3 octets (24 bits). Cinq octets de remplissage sont
nécessaires pour transformer le dernier bloc en un bloc de 64 bits; ajoutez 4 octets
de 0 et un octet final avec le nombre 5. Après déchiffrement, détruisez les 5 derniers
octets du dernier bloc déchiffré. Pour que cette méthode marche correctement, tous les
message doivent être remplis. Même si le texte en clair s’achève à la limite d’un bloc,
vous devez remplir un bloc complet. Sinon, vous pouvez utiliser un caractère marqueur
de fin de fichier pour délimiter la fin du texte en clair, puis remplir à la suite de ce
caractère.
La figure 9.1 propose une alternative appelée vol de texte chiffré [405]. E i n- i est le
dernier bloc en clair plein et M .n est le bloc final en clair court. Cn~j est le dernier bloc
chiffré plein et Cn est le bloc final chiffré court. C' est juste un résultat intermédiaire
et ne fait pas partie du texte chiffré transmis.
Chiffrement Déchiffrement
Mn-1 Mn Cnu Cn C’
«=•
1r 1f 1 r
°k
ir 1r 1r
C„ C’ Mn C’
F ig. 9.1 Vol de texte chiffré en mode ECB
9.2 Bloc rejoué

Un défaut plus dangereux avec le mode E C B est que l’adversaire pourrait modifier les
messages chiffrés sans connaître la clef, ni même l’algorithme, de manière à duper le
destinataire légitime. Ce défaut fut décrit en premier dans [295],
Pour illustrer le problème, considérons un système de transfert de fonds inter-bancaire
qui fait circuler de l’argent entre des comptes dans différentes banques. Pour rendre
la vie plus facile pour le système informatique de la banque, les banques se sont mises
d’accord sur un format de message standard pour les transferts d’argent qui ressemble
à ceci :
Banque A : émettrice 15 blocs

Banque B: bénéficiaire 15 blocs
Nom du déposant 6 blocs
Numéro de compte du déposant 2 blocs
Montant du dépôt 1 bloc
Un bloc correspond à un chiffrement de bloc de 8 octets. Les messages sont chiffrés à

l’aide d’un algorithme de chiffrement par blocs en mode ECB.
Martin, qui écoute les communications entre les deux banques, la banque d ’Alice et
la banque de Bernard, peut utiliser cette information pour s’enrichir. Premièrement,
il programme son ordinateur pour enregistrer tous les messages chiffrés de la banque
d’Alice vers la banque de Bernard. Ensuite, il transfère 100 dollars de la banque d ’Alice
vers son compte à la banque de Bernard. Plus tard, il recommence. En utilisant son
ordinateur, il met les messages enregistrés en corrélation en cherchant une paire de
messages identiques. Ces messages sont ceux qui autorisent le transfert de 100 dollars
vers son compte. S’il y a plus d’une paire de messages identiques (ce qui est très
certainement probable), il fait un autre transfert et enregistre le résultat. Finalement,
il isole le message qui a autorisé la transaction.
Maintenant, il peut insérer à volonté ce message dans la liaison de communication.
Chaque fois qu’il envoie un message à la banque de Bernard, un nouveau montant de
100 dollars est crédité sur son compte. Lorsque les deux banques contrôleront la balance
de leurs transferts (probablement en fin de journée), elles détecteront les autorisations
de transfert fantômes ; mais si Martin est malin, il aura déjà retiré l’argent et sera en
route vers une république exotique où il n’y a pas de loi d ’extradition. Et il a sûrement
commis son forfait avec des montants beaucoup plus élevés que 1 0 0 dollars et avec de
nombreuses autres banques.
A première vue, les banques pourraient aisément éviter cela en rajoutant une datation
à leurs messages.
Datation 1 bloc
Banque A : émettrice 15 blocs
Banque B : bénéficiaire 15 blocs
Nom du déposant 6 blocs
Numéro de compte dudéposant 2 blocs
Montant du dépôt 1 bloc
Deux messages identiques seraient facilement identifiés avec ce système. Mais, en utili
sant une méthode appelée blocs rejoués, Martin peut encore s’enrichir. La figure 9.2
montre que Martin peut extraire les huit blocs chiffrés correspondant à son nom et
son numéro de compte : les blocs 5 à 12. En analysant cette figure, Martin, désormais
armé, ricane dans son coin.
Il intercepte aléatoirement des messages de la banque d ’Alice vers la banque de Bernard
et remplace les blocs 5 à 12 dans le message avec les octets correspondant à son nom et à
son numéro de compte. Ensuite, il les envoie à la banque de Bernard.Il n’a pas à savoir
qui est le déposant légitime ; il n ’a même pas à connaître lemontantdu transfert (bien
9.3 Mode de chiffrement avec chaînage de blocs 205
Numéro de bloc
1 2 3 4 5 6 7 8 9 10 11 12 13
Banque Banque Compte du

Datation émettrice Nom du déposant déposant Montant
bénéficiaire
Cham p
FlG. 9 2 - Exemple d’un dossier à blocs chiffrés
qu’il puisse corréler les messages des différents transferts avec des montants différents
qu’il a effectués vers son compte, et ainsi déterminer les blocs chiffrés correspondant à
certains montants). Simplement, il remplace les noms et les numéros de compte par les
siens et il contemple le solde de son compte augmenter, (il faut que Martin soit prudent
et ne modifie pas le message de retrait, imaginez rien qu’une seconde que chacun ait
une longueur différente.)
Cela prendra plusieurs jours aux banques pour détecter cela. Lorsqu’elles feront la
balance journalière des transferts, tout sera en ordre. Ce ne sera certainement pas
avant que l’un des déposants honnêtes s’aperçoive que l’argent ne lui a pas été crédité,
ou que quelqu’un remarque l’activité inhabituelle du compte de Martin, que les banques
découvriront l’escroquerie. Martin n’est pas stupide, et d’ici là il aura fermé son compte,
changé son nom et acheté une villa en Argentine.
Les banques peuvent minimiser le problème en changeant fréquemment de clef mais
Martin peut aussi travailler plus vite. Néanmoins, rajouter un C A M peut aussi ré
soudre le problème. Pourtant, c ’est un défaut fondamental en mode ECB. Martin peut
retirer, répéter ou échanger des blocs à volonté. La solution est une technique appelée
chaînage.
9.3 Mode de chiffrement avec chaînage de

blocs
Le chaînage utilise une méthode de rétroaction car les résultats du chiffrement du
bloc précédent sont réutilisés comme entrées pour le chiffrement du bloc courant. En
d’autres termes, chaque bloc est utilisé pour modifier le chiffrement du bloc suivant.
Chaque bloc chiffré dépend non seulement du bloc de texte en clair qui l’a engendré
mais aussi de tous les blocs de texte en clair qui précèdent celui-ci.
En mode de chiffrement avec chaînage de blocs (C B C pour « cipher block chai-
ning »), le texte en clair est combiné par ou exclusif avec le bloc chiffré précédent
avant d’être chiffré. La figure 9.3a montre le chiffrement CBC en action. Après qu’un
bloc de texte en clair a été chiffré, le texte chiffré correspondant est aussi stocké dans
un registre de rétroaction. Avant que le bloc suivant de texte en clair soit chiffré, il
est combiné par ou exclusif avec le registre de rétroaction pour devenir la nouvelle
entrée de l’algorithme de chiffrement. Le texte chiffré résultant est à nouveau stocké
dans le registre de rétroaction pour être combiné par ou exclusif avec le bloc de texte
en clair suivant, et ainsi de suite jusqu’à la fin du message. Le chiffrement de chaque
bloc dépend de tous les blocs précédents.
M.
i-l
M.
i M. ,
1+1
Ci-l C:i+1
M i-l M. M.
■VI S i+J ' 'i '" i + l
(a) Chiffrement CBC (b) Déchiffrement CBC
F ig. 9.3 - Mode de chiffrement par chaînage de blocs
Le déchiffrement est aussi facile(voir la figure 9.3b). Un bloc de texte chiffré est déchiffré
normalement, et aussi sauvé dans le registre de rétroaction. Une fois que le bloc suivant
a été déchiffré, il est combiné par ou exclusif avec le contenu du registre de rétroaction.
Ensuite, le bloc suivant de texte chiffré est sauvé dans le registre de rétroaction, et ainsi
de suite jusqu’à la fin du message.
Mathématiquement, on peut écrire :
Ct = E fc i- M t © C j - i )
■Mi = C i-! © D n{Ct).
Vecteur d’initialisation
Le mode C B C ne produit des blocs chiffrés différents pour des mêmes blocs en clair
seulement si un des blocs précédents est différent. Deux messages identiques donneront
toujours le même texte chiffré. Pis encore, deux messages qui commencent de la même
façon donneront le même texte chiffré jusqu’à la première différence. Certains messages
ont un en-tête commun : un en-tête de lettre, une ligne « Frorri » d’un message électro
nique, par exemple. Bien qu’une attaque par blocs rejoués soit toujours impossible, ce
début identique donne encore d’utiles informations au cryptanalyste.
Evitez cela en chiffrant des données aléatoires comme premier bloc. Ce bloc de données
aléatoires est appelé vecteur d’initialisation (IV pour « initialization vector »),
variable d ’initialisation ou valeur initiale de chaînage. L’IV n’a pas de sens : il
est juste là pour rendre chaque message unique. Quand le destinataire déchiffre ce bloc,
il l’utilise pour remplir le registre de rétroaction et l’ignore par ailleurs. Une datation
fait un bon IV. Sinon, utilisez des bits aléatoires.
9.3 Mode de chiffrement avec chaînage de blocs 201
Avec l’addition de l’IV , des messages en clair identiques donneront des messages chiffrés
différents. Il est donc impossible pour un espion de tenter une attaque par blocs rejoués,
et encore plus difficile de constituer un carnet de codage. Bien que l’IV devrait être
unique par message chiffré avec la même clef, ce n’est pas une condition absolue.
L’IV n’a pas besoin d’être tenu secret ; il peut être transmis en clair avec le texte chiffré.
Si vous n’êtes pas persuadé, considérez le raisonnement suivant. Nous possédons un
message de plusieurs blocs: B\, B 2 , ......., B ,. B\ est chiffré avec l’IV. B 2 est chiffré
avec le texte chifré de Bi en tant qu’IV . B 3 est chiffré avec le texte chifré de B 2 en
tant qu’IV , etc. Donc, s’il y a n blocs, il y a n — 1 IV , même si l’IV original est gardé
secret. Il n’y a donc aucune raison de garder l’IV secret ; l’IV est juste un simple bloc
de texte chiffré — un peu comme Bq qui commence la série.
Remplissage
Le remplissage marche exactement comme dans le mode E B C , mais dans certaines
applications le texte chiffré doit avoir exactement la même taille que le texte en clair.
Peut-être qu’un texte en clair doit être chiffré et mis exactement à la même place en
mémoire. Dans ce cas, vous devez chiffrer le dernier bloc court différemment. Faites
l’hypothèse que le dernier bloc a j bits. Après avoir chiffré le dernier bloc complet,
rechiffrez le texte chiffré, sélectionnez les j bits les plus à gauche du texte chiffré deux
fois et combinez le résultat par ou exclusif avec le bloc court pour donner le texte
chiffré. Cela est illustré par la figure 9.4.
M M Pn (j-bits de long)
n-2
-*0
Sélectionne
les j-bits -e
les plus a gauchi
“ n-2 “n 1 C (j-bits de long)
F ig. 9.4 - Méthode de chiffrement pour le dernier bloc
La faiblesse ici est que bien que Martin ne puisse pas retrouver le dernier bloc, il
peut le modifier systématiquement en changeant des bits du texte chiffré. Si les tout
derniers bits du texte chiffré contiennent de l’information vitale, c ’est une faiblesse. Si
les derniers bits contiennent simplement des informations de gestion, ce n’est pas un
problème.
Le vol de texte chiffré est une meilleure méthode (voir la figure 9.5) [405]. M „_ i est le
dernier bloc en clair plein et M n est le bloc final en clair court. Cn^\ est le dernier bloc
chiffré plein et Cn est le bloc final chiffré court. C ' est juste un résultat intermédiaire
et ne fait pas partie du texte chiffré transmis. L’avantage de cette méthode est que
tous les bits d ’un message en clair passent par l’algorithme de chiffrement.
Propagation d’erreurs
Le mode C B C peut être décrit comme une rétroaction du texte chiffré du côté du
chiffrement et une alimentation en texte chiffré du côté du déchiffrement. Ceci a des
conséquences sur les erreurs. Une erreur d ’un seul bit dans un bloc de texte en clair
va affecter le bloc de texte chiffré correspondant et tous les blocs de textes chiffrés qui
suivent. Ce n’est pas de grande portée parce que le déchiffrement va inverser cet effet
et le texte en clair retrouvé aura la même seule erreur.
Les erreurs dans le texte chiffré sont plus fréquentes. Elles peuvent tout simplement
provenir d ’un bruitage de la liaison ou d ’un disfonctionnement du dispositif de stockage.
En mode C B C , une erreur d ’un seul bit dans le texte chiffré affecte un bloc, et un bit
du texte en clair reconstruit. Le bloc contenant l’erreur est complètement brouillé. Le
bloc suivant a une erreur de 1 bit au même endroit que le bit erroné.
Cette transformation d’une petite erreur dans le texte chiffré en une grande erreur
dans le texte en clair est appelée amplification d’erreur. C’est un handicap majeur.
Les blocs après le deuxième ne sont pas affectés par l’erreur, donc le mode C B C est
auto-réparateur. Deux blocs sont affectés par une erreur mais le système récupère
et continue à fonctionner correctement pour tous les blocs suivants. Le C B C est un
exemple d ’algorithme de chiffrement par blocs utilisé d ’une manière auto-synchronisée,
mais seulement au niveau du bloc.
Bien que le mode C B C récupère rapidement les erreurs de bits, il ne récupère pas du
tout les erreurs de synchronisation. Si un bit est ajouté ou perdu dans le flot de texte
chiffré, alors tous les blocs suivants sont décalés d ’un bit et le déchiffrement va produire
du charabia indéfiniment. Tout cryptosystème qui utilise le mode C B C doit s’assurer
que la structure des blocs reste intacte, soit par encadrement soit en stockant les
données dans des paquets de plusieurs blocs.
9-4 Algorithmes de chiffrement en continu 209
Problèmes de sécurité
Des problèmes potentiels sont causés par la structure même du C B C . Primo, du fait
qu’un bloc de texte chiffré affecte les blocs suivants d’une manière simple, Martin peut
ajouter des blocs à la fin d ’un message chiffré sans être détecté. Ce sera à coup sûr
déchiffré en charabia, mais dans certaines situations, ce n’est pas désirable.
Si vous utilisez le C B C , vous devriez structurer votre texte en clair de façon à savoir
où le message s’arrête et de pouvoir détecter les rajouts de blocs supplémentaires.
Secundo, Martin peut altérer un bloc de texte chiffré pour introduire des changements
voulus dans le bloc déchiffré de texte en clair. Par exemple, si Martin change un seul
bit de texte chiffré, le déchiffrement du bloc entier sera incorrect, mais le bloc suivant
comportera une erreur d ’ 1 bit en lieu et place du bit correspondant. Il y a des situations
où ceci est désirable. Le message en clair entier devrait inclure une sorte de contrôle
redondant ou une authentification.
Finalement, bien que les motifs du texte en clair soient dissimulés par le chaînage, les
très longs messages auront encore des motifs. Le paradoxe de l’anniversaire prévoit
qu’il y aura des blocs identiques après 2m / 2 blocs, où m est la taille du bloc. Pour un
bloc d ’une taille de 64 bits, ça représente à peu près 34 giga-octets. Un message doit
être incroyablement long avant que ce ne soit un problème.
9.4 Algorithmes de chiffrement en continu

Les algorithmes de chiffrement en continu convertissent le texte en clair en texte chiffré
1 bit à la fois. La réalisation la plus simple d ’un algorithme de chiffrement en continu
est illustrée par la figure 9.6. Un générateur de codons 1 engendre un flux de bits
(appelons-les codons) : k\, k,2 , k%, ... , fcj. Ce flux est combiné par ou exclusif avec le
flux de bits du texte en clair m j, ?7i2 , m 3 , ..., m ,, pour produire le flux de bits du texte
chiffré.
Ci = mi © h
F ig. 9.6 - Chiffrement en continu
1. Note du traducteur : le term e « c o d o n » a été utilisé pou r alléger la traduction de termes techniques
anglo-saxons qui n ’ont pas d ’équivalents simples en français.
Du côté du déchiffrement, les bits du texte chiffré sont combinés par ou exclusif avec
un flux identique de codons pour retrouver les bits du texte en clair.
rrii = a © kt
Comme :
ml ® k i @ki = ml
tout va bien.
La sécurité du système dépend entièrement des détails internes du générateur de co
dons. Si le générateur de codons engendre un flux continu de zéros, le texte chiffré sera
identique au texte en clair et toute l’opération sera inutile. Si le générateur de codons
engendre un motif répétitif de 16 bits, l’algorithme n’est rien d’autre que le simple
algorithme du ou exclusif qui n’est pas du tout sûr (voir § 1.4). Si le générateur de
codons engendre une suite de bits aléatoires (pas pseudo-aléatoires, vraiment aléatoires
— voir § 2 .8 ), vous avez la technique du masque jetable et une sécurité parfaite.
La sécurité des algorithmes de chiffrement en continu concrets est entre les deux ex
trêmes (ou exclusif et masque jetable) — idéalement, elle est plus proche du masque
jetable. Le générateur de codons engendre un flux de bits qui ont l’air aléatoires, mais
en fait il est déterministe et il peut être reproduit de façon infaillible au moment du
déchiffrement. Plus la sortie du générateur est aléatoire, plus il est difficile pour le
cryptanalyste de le casser.
Si, néanmoins, le générateur de codons engendre le même flot de bits chaque fois qu’on
l’active, le système cryptographique résultant sera facile à casser. Un exemple montrera
mieux pourquoi.
Si Estelle a un texte chiffré et le texte en clair correspondant, elle peut combiner par
ou exclusif le texte en clair avec le texte chiffré pour retrouver le flux de codons. Ou, si
elle dispose de deux textes chiffrés avec le même flux de codons, elle peut les combiner
par ou exclusif pour obtenir le résultat de la combinaison par ou exclusif des deux
textes en clair. C ’est facile à casser et elle peut alors combiner par ou exclusif un des
textes en clair avec le texte chiffré pour retrouver le flux de codons.
Maintenant, chaque fois qu’elle intercepte un message chiffré, elle a les codons néces
saires pour déchiffrer le message. De plus, elle peut déchiffrer et lire tout texte chiffré
qu’elle aurait intercepté avant. Quand Estelle obtient une seule paire « texte en clair,
texte chiffré », elle peut tout lire.
C’est pourquoi tous les algorithmes de chiffrement en continu utilisent des clefs. La sor
tie du générateur de codons est une fonction de la clef.Maintenant, si Estelle a une paire
« texte en clair, texte chiffré », elle peut seulement lire les messages chiffrés avec une
seule clef. Changez la clef et l’adversaire se retrouve à la case départ. Les algorithmes
de chiffrement en continu sont spécifiquement utiles pour chiffrer des communications
continues : un lien T - l entre deux ordinateurs, par exemple.
Un générateur de codons est composé de trois parties de base (voir la figure 9.7). L’état
interne décrit l’état courant du générateur de codons. Deux générateurs de codons, avec
la même clef et le même état interne, produisent le même flux de codons. La fonction
de sortie prend l’état interne et engendre un codon (un bit). La fonction état-suivant
prend l’état interne et engendre un nouvel état interne.
9.5 Chiffrement autosynchrone, en continu 211
F ig. 9.7 A l’intérieur d’un générateur de codons
9.5 Chiffrement autosynchrone en continu

Dans un algorithme de chiffrement autosynchrone en continu, chaque bit du flux
de codons est une fonction d ’un nombre fixe de bits du texte chiffré qui précède [1383].
Les militaires appellent cela un chiffrement à clef automatique (C T A K pour « ci-
phertext auto key »). L ’idée de base a été brevetée en 1946 [6 6 8 ].
La figure 9.8 illustre un chiffrement autosynchrone en continu. L’état interne est une
fonction des n bits précédents du texte chiffré. La complexité cryptographique réside
dans la fonction de sortie qui prend l’état interne et qui engendre un codon.
Comme l’état interne dépend entièrement des n bits précédents du texte chiffré, au
déchiffrement, le générateur de codons se synchronisera automatiquement avec le gé
nérateur de codons du chiffrement après avoir reçu n bits de texte chiffré.
FlG. 9.8 - Un générateur de codons autosynchrone

Dans des réalisations intelligentes de ce mode, chaque message commence avec un

en-tête aléatoire long de n bits. Cet en-tête est chiffré, transmis et déchiffré. Le déchif
frement en sera incorrect, mais après ces n bits les deux générateurs de codons seront
synchronisés.
L’inconvénient du chiffrement autosynchrone en continu est qu’il est sujet à la propa
gation d’erreur. Pour chaque bit de texte chiffré corrompu durant la transmission, le
générateur de codons de déchiffrement produira n codons erronés. Donc, pour chaque
erreur de texte chiffré, il y aura n erreurs correspondantes dans le texte en clair, jusqu’à
ce que le bit corrompu sorte de l’état interne.
Problèmes de sécurité
Les systèmes de chiffrement autosynchrone en continu sont aussi vulnérables aux at
taques par blocs rejoués. D ’abord, Martin enregistre quelques bits de texte chiffré. Puis,
un peu plus tard, il place cet enregistrement dans la communication. Après quelque
charabia initial pendant que le récepteur se resynchronise, le vieux texte chiffré sera
déchiffré normalement comme légitime. Le récepteur n’a aucun moyen de déterminer
que ces données ne sont pas courantes, mais qu’il s’agit de vieilles données rejouées. A
moins qu’un système de datation soit utilisé, Martin peut convaincre une banque de
créditer son compte plusieurs fois en répétant toujours le même message (en suppo
sant que la clef n’ait pas changé, bien sûr). D ’autres faiblesses dans ce type de schéma
pourraient être exploitées dans le cas de fréquentes resynchronisations [412].
9.6 Chiffrement à rétroaction

Un bloc chiffré peut aussi être utilisé en tant que chiffrement autosynchrone en continu ;
cela s’appelle le mode de chiffrement à rétroaction (C F B pour « Cipher Feedback »).
Avec le mode C B C , le chiffrement ne peut pas commencer avant qu’un bloc complet
de données ait été reçu. C ’est un défaut dans certaines applications réseaux. Dans
l’environnement d ’un réseau sûr, par exemple, un terminal doit pouvoir transmettre
chaque caractère à l’ordinateur central dès qu’il est entré. Quand les données à traiter
se présentent sous forme de paquets de la taille de l’octet, le mode C B C ne fonctionnera
pas.
En mode C F B , les données peuvent être chiffrées par unités plus petites que la taille
de bloc. L ’exemple suivant chiffre un caractère ASCII à la fois (on parle alors de CFB
à 8 bits). Mais le chiffre 8 n’est pas sacré, vous pouvez chiffrer les données un bit à
la fois en utilisant un C F B à 1 bit, bien qu’utiliser un chiffrement complet d’un bloc
pour un seul bit représente beaucoup de travail ; un chiffrement en continu serait une
meilleure idée. (Réduire le nombre de rondes d’un chiffrement par blocs pour accélérer
les choses n’est pas recommandé [1280] ) Vous pouvez aussi utiliser un C FB à 64 bits,
ou tout autre C F B à n bit où n est inférieur ou égal à la taille du bloc.
La figure 9.9 illustre un C FB à 8 bits appliqué à un algorithme de chiffrement par
blocs de 64 bits. Un algorithme de chiffrement par blocs en mode C F B manipule une
file d’attente de la taille d’un bloc d’entrée. Initialement, la file d’attente est remplie
avec un IV , comme en mode C B C . La file d ’attente est chiffrée et les huit bits les plus
à gauche du résultat sont combinés par ou exclusif avec le premier caractère de 8 bits
du texte en clair pour devenir les 8 premiers bits du texte chiffré. Ce caractère peut
9.6 Chiffrement à rétroaction 213
maintenant être transmis. Les mêmes huit bits sont placés dans les huit bits les plus à
droite de la file d’attente et tous les autres bits sont décalés de huit positions vers la
gauche. Les huit bits les plus à gauche sont ignorés. Le caractère en clair suivant est
alors chiffré de la même manière. Le déchiffrement est le processus inverse. Des deux
côtés, chiffrement et déchiffrement, l’algorithme de chiffrement par blocs est utilisé
dans son mode de chiffrement.
F ig. 9.9 - Mode de chiffrement à rétroaciion à 8 bits
Si n est la taille du bloc de l’algorithme, alors un C FB à n bit ressemble à ceci (voir

la figure 9.10) :
Ci = A4t © E k {C%- i)
M.i = Ci © EK(Ci~i).
F i g . 9 .1 0 - CFB à n bit avec un algorithme à n bit

Chapitre 9 Types et modes d’algorithmes
Tout comme le mode C B C , le mode C FB lie les caractères du texte en clair entre eux
de manière que le texte chiffré dépende de tout le texte en clair qui précède.
Pour initialiser le processus C FB , l’entrée de l’algorithme de blocs doit être initiée par
un IV. Tout comme l’IV du mode C B C , il n’a pas besoin d’être secret.
Néanmoins, l’IV doit être unique2. Si le l’IV du mode C F B n’est pas unique, un
cryptanalyste peut retrouver le texte en clair correspondant. LTV doit être changé
avec chaque message. Ce peut être un nombre de série, qui augmente après chaque
message et qui ne se répète pas tout au long de la vie de la clef. Pour des données
chiffrées à stocker, cela peut être une fonction de l’index utilisé pour rechercher les
données.
Avec le mode C F B , une erreur dans le texte en clair affecte tous les textes chiffrés
suivants et cette erreur est inversée par le déchiffrement. Une erreur dans le texte
chiffré est plus intéressante à considérer. Le premier effet d ’une erreur d ’un seul bit
dans le texte chiffré est de provoquer une erreur d’un seul bit dans le texte en clair.
Après cela, cette erreur entre dans le registre à décalage, où elle embrouille tout jusqu’à
ce qu’elle ressorte à la fin du registre. En mode C FB à 8 bits, 9 octets de texte en clair
déchiffré sont embrouillés par une erreur d’un seul bit dans le texte chiffré. Après cela,
le système récupère et tous les textes en clair suivants sont déchiffrés correctement.
En général, en mode C F B à n bit, une seule erreur d’un texte chiffré affectera le
déchiffrement du bloc présent et des m /n —1 blocs suivants, où m est la taille du bloc
Un problème subtil avec ce type de propagation d’erreur est que si Martin connaît le
texte en clair de la transmission, il peut changer 1 état de certains bits d’un bloc donné
et ainsi le faire déchiffrer en ce qu’il veut. Le bloc suivant peut être déchiffré comme
du charabia, mais les dégâts peuvent déjà avoir été accomplis. Et il peut changer les
derniers bits d ’un message sans être détecté.
Le mode C F B est aussi autoréparateur pour ce qui est des erreurs de synchronisation.
L’erreur entre dans le registre à décalage, embrouille 8 octets de données, jusqu’à ce
qu’elle ressorte à l’autre bout. Le C FB est un exemple d ’algorithme de chiffrement par
blocs utilisé comme algorithme de chiffrement autosynchrone en continu.
9.7 Chiffrement synchrone en continu

Dans un algorithme de chiffrement synchrone en continu, le flux de codons
est engendré indépendamment du flux du message. Les militaires appellent cela un
chiffrement à clef automatique de clef (K A K pour « Key Auto-Key »). Du côté du
déchiffrement, un autre générateur de codons produit un flux identique de codons, les
uns après les autres. Tout se passe bien tant que les deux générateurs sont synchrones.
Si l’un des deux saute une étape du cycle ou si un bit du texte chiffré est perdu pendant
la transmission, alors chaque caractère du texte chiffré après l’erreur ne pourra plus
être déchiffré correctement.
2. C ’est différent de l’ IV du m od e C B C , qui devrait être unique mais n ’a pas à l’ être.
9.7 Chiffrement synchrone en continu 215
Si cela arrive, l’émetteur et le récepteur doivent resynchroniser leurs générateurs de

codons avant de continuer. Pour compliquer les choses, ils doivent le faire de façon à
ce qu’aucune partie du flux de codons ne soit réutilisée, et donc la solution simpliste
qui consiste à revenir à un état antérieur ne marchera pas.
Un avantage, toutefois, est que les chiffrements synchrones en continu ne propagent
pas les erreurs de transmission. Si un bit est corrompu durant la transmission (ce qui
est nettement plus probable que de perdre un bit) alors seul le bit erroné sera mal
déchiffré. Tous les bits qui précèdent ou qui suivent ne seront pas affectés.
Comme un générateur de codons doit engendrer le même flux au chiffrement et au dé
chiffrement, il doit être déterministe. Comme il est réalisé par une machine à états finis
(c’est-à-dire, un ordinateur), la suite finira par se répéter. Ces générateurs de codons
sont appelés périodiques. Excepté pour les masques jetables, tous les générateurs de
codons sont périodiques.
Un générateur de codons doit avoir une longue période, bien plus longue que le nombre
de bits que le générateur devra produire entre deux changements de clef. Si la période
est plus courte que le texte en clair, alors différentes parties du texte en clair seront
chiffrées de la même manière — un gros défaut. Si un cryptanalyste connaît une partie
du texte en clair, il peut reconstituer une partie du flot de clefs et l’utiliser pour en
savoir plus sur le texte en clair. Même si le cryptanalyste n’a que le texte chiffré, il peut
combiner par ou exclusif les parties chiffrées avec le même flot de clefs et obtenir les
combinaisons par ou exclusif du texte en clair avec ce dernier. C ’est juste un algorithme
de combinaison par ou exclusif avec une très longue clef.
La longueur suffisante d ’une période dépend de l’application. Un générateur de codons
qui chiffre un lien T —1 en continu chiffrera 237 bits par jour. La période du générateur
de codons doit être bien plus grande que cela, même si la clef est changée tous les
jours. Si la période est assez longue, vous n’auriez à devoir changer la clef que chaque
semaine ou chaque mois.
Le chiffrement synchrone en continu protège aussi contre les insertions et les omissions
dans le texte chiffré, car elles causeraient un perte de synchronisation et seraient tout
de suite détectées. En revanche, il ne protège pas tout à fait contre la modification
d’un bit. Tout comme en mode C F B , Martin peut modifier certains bits du flux. S’il
connaît le texte en clair, il peut faire l’opération de façon à imposer le texte déchiffré.
Les bits suivants seront déchiffrés incorrectement (jusqu’à ce que le système récupère),
mais dans certaines applications, Martin peut occasionner beaucoup de dommages.
Attaque par insertion

Les algorithmes de chiffrement synchrone en continu sont vulnérables à une attaque
par insertion [100]. Martin a enregistré un flux de texte chiffré, mais il ne connaît pas
le texte en clair oü le flux de codons utilisé pour chiffrer le texte en clair.
Texte en clair original: mi m2 m3 m4

Flux de codons original: h fe2 k3
Texte chiffré original: Cl Cl c3 c4
Martin insère un seul bit connu, m ', dans le texte en clair après m,\ et s’arrange pour
faire chiffrer ce nouveau texte en clair avec le même flux de codons. Il enregistre le
texte chiffré résultant :
Nouveau texte en clair: mi m' m2 m3 7714

Flux de codons original: ki k2 k3 k§
Texte chiffré mis à jour : Cl C2 c3 C4 4
En faisant l’hypothèse qu’il connaît la valeur de m ', il peut déterminer tout le texte en
clair après ce bit à partir du texte chiffré original et du nouveau texte chiffré :
k2 — c 2 © m 'i et donc rri2 = c2 © k2

k3 = c 3 © rri2 , et donc m 3 = c 3 © A'3
fc3 = C4 © m.3 , et donc 7714 = c4 ©
Martin n’a même pas à connaître la position dans laquelle le bit a été inséré ; il doit
juste comparer le texte chiffré avec le texte chiffré mis à jour et déterminer à partir
de quel endroit ils diffèrent. Pour se protéger contre cette attaque, il ne faut jamais
utiliser le même flux de codons pour chiffrer deux messages différents.
9.8 Mode de rétroaction de sortie

Le mode de ré tr o a c tio n d e so rtie (O F B pour « Output-feedback ») est une méthode
qui consiste à utiliser un algorithme de chiffrement par blocs comme un algorithme de
chiffrement synchrone en continu. Il est similaire au mode C FB , sauf que n bits du bloc
de sortie précédent sont mis dans les positions les plus à droite de la file d ’attente (voir
la figure 9.11). Le déchiffrement est l’inverse de ce processus. Cela s’appelle l’OFB
à n bit. Des deux côtés, chiffrement et déchiffrement, l’algorithme de chiffrement par
blocs est utilisé dans son mode de chiffrement. Cette méthode est parfois appelée
ré tro a ctio n interne, parce que le mécanisme de rétroaction est indépendant à la fois
des flots de texte en clair et de texte chiffré [295].
Si n est la taille du bloc d’un algorithme, alors un O FB à n bits ressemble à ceci (voir
la figure 9.12) :
Ct — A L © St ; St = EK(St- i )
M , = Cr © St ; Sx — Ej((St- i ) .
Si est l’état, qui est indépendant soit du texte en clair soit du texte chiffré.
Une caractéristique intéressante du mode O F B est qu’ une grosse partiedu travail peut
être effectuée séparément, avant mêmeque le message en clair n’existe.Puis,quand
le message arrive, il peut être combiné par ou exclusif avec le produit de l’algorithme
pour produire le texte chiffré.
Le registre à décalage de l’O F B doit aussi être chargé initialement avec un IV. Il
devrait être unique mais n’a pas besoin d ’être secret.
9.8 Mode de rétroaction de sortie 217
F i g . 9.11 - Mode de rétroaction de sortie à 8 bits
Le mode O F B n’a pas d ’amplification d’erreur. Une erreur d ’un seul bit dans le texte
chiffré occasionne une erreur d’un seul bit dans le texte en clair récupéré. Cela peut
être utile dans certaines transmissions analogiques numérisées, comme la voix ou la
vidéo numérisée, où une erreur occasionnelle d’un bit peut être tolérée mais pas l’am
plification d’erreur.
D ’autre part, la perte de synchronisation est fatale. Si les contenus des registres à déca
lage de chiffrement d’une part et de déchiffrement d’autre part ne sont pas identiques,
alors le texte en clair récupéré sera du charabia. Tout système qui utilise le mode OFB
doit avoir un mécanisme de détection de perte de synchronisation, et un mécanisme
F i g . 9 .1 2 - OFB à n bits avec un algorithme à n bits

pour remplir les deux registres à décalage avec un nouveau (ou le même) IV pour
resynchroniser.
Problèmes de sécurité avec le mode OFB

Une analyse du mode O FB [590, 430, 431, 790] démontre que le mode O F B ne peut
être utilisé que si la taille de la rétroaction est égale à la taille des blocs. Par exemple,
vous ne pouvez utiliser qu’un algorithme à 64 bits avec un O FB à 64 bits. Bien que le
Gouvernement américain autorise d ’autres tailles de rétroaction pour le DES [1156],
évitez-les.
Le mode O F B combine par ou exclusif un flot de clefs avec le texte. Ce flot de clefs
se répétera. Il est important qu’il ne se répète pas avec la même clef, sinon, il n’y a
pas de sécurité. Quand la taille de la rétroaction égale celle du bloc, l’algorithme de
chiffrement par blocs agit comme une permutation des valeurs de m bit (où m est la
longueur de bloc) et la longueur moyenne de cycle est 2m — 1. Pour un bloc de 64 bits,
sa longueur est énorme. Quand la taille n de la rétroaction est inférieure à celle du
bloc, la longueur moyenne de cycle tombe à environ 2 " /2. Pour un bloc de 64 bits, ça
ne représente que 2 32, ce n’est pas assez long.
Algorithmes de chiffrement en continu avec le mode OFB

Un algorithme de chiffrement en continu peut aussi fonctionner en mode OFB. Dans
ce cas, la clef affecte la fonction de l’état suivant (voir la figure 9.13). La fonction
résultante ne dépend pas de la clef ; très souvent c ’est quelque chose de simple, comme
un seul bit de l’état interne ou la combinaison par ou exclusif de multiples bits de l’état
interne. La complexité cryptographique se trouve dans la fonction de l’état suivant ;
cette fonction est dépendante de la clef. Cette méthode est aussi appelée rétroaction
interne [295], car le mécanisme de rétroaction est interne à l’algorithme de génération
de clef.
F i g . 9 .1 3 Un générateur de codons en mode de rétroaction de sortie
Dans une variante de ce mode, la clef détermine juste l’état initial du générateur de
9.9 Mode « compteur » 219
codons. Une fois que la clef aura réglé l’état interne du générateur, celui-ci marchera
sans problème.
9.9 Mode « compteur »

Les algorithmes de chiffrements par blocs en mode compteur utilise des suites de
nombres en entrée de l’algorithme [826, 496, 718]. Au lieu d ’utiliser la sortie du chiffre
ment pour remplir le registre à décalage, l’entrée du registre est un compteur. Après
chiffrement d ’un bloc, le compteur est augmenté d’une certaine valeur, typiquement
un. Les propriétés de synchronisation et de propagation d ’erreurs sont les mêmes que
pour le mode O FB . Le mode compteur résoud le problème de sortie de n bit du mode
OFB où n est plus petit que la longueur de bloc.
Rien à propos du compteur n’est sacré ; il ne doit pas compter toutes les entrées pos
sibles dans l’ordre. Vous pouvez utiliser tous les générateurs de suites aléatoires des
chapitres 16 et 17, qu’ils soient cryptographiquement sûrs ou pas, en entrée de l’algo
rithme de blocs.
Algorithmes de chiffrement en continu en mode compteur

Les algorithmes de chiffrement en continu en mode « compteur » ont des fonctions
d’état-suivant simples et des fonctions de sortie compliquées qui dépendent de la clef.
Cette technique, illustrée dans la figure 9.14 a été suggérée dans [496, 718]. La fonction
d’état-suivant peut être aussi simple qu’un compteur qui rajoute une unité à l’état
précédent.
F i g . 9.14 - Un générateur de codons en mode « compteur »
Dans un chiffrement en continu en mode compteur, il est possible d’engendrer le ie bit

de la clef k, sans avoir à engendrer d’abord tous les bits précédents. Il suffit de mettre
le compteur manuellement à la valeur du ie état et d ’engendrer le bit. C ’est utile pour
protéger des fichiers de données à accès aléatoire: vous pouvez déchiffrer un bloc de
données spécifique sans déchiffrer tout le fichier.
9.10 Autres modes

Mode de chaînage de blocs
Pour utiliser un algorithme de chiffrement par blocs en mode de chaînage de b locs
(B C pour « block chaining »), il suffit de combiner par ou exclusif l’entrée du chiffre
ment par bloc avec le ou exclusif de tous les blocs de texte chiffré précédents. Tous
comme pour le mode C B C , un IV démarre le processus.
Mathématiquement cela ressemble à :
Ci = EK (M i ® Ft) ; Fi+i = Fz © C%
M Z= FZ® D k (Cz) ; Fl+1 = Ft ® Ci.
Tout comme pour le mode C B C , le processus de rétroaction du mode B C amplifie les

erreurs dans le texte en clair. Le défaut principal du mode B C vient du fait que le
déchiffrement d’un bloc chiffré dépend de tous les blocs chiffrés précédents, une seule
erreur dans le texte chiffré fausse le déchiffrement de tous les blocs chiffrés suivants.
Mode de chiffrement par chaînage de blocs avec propagation

Le mode dech iffrem en t par chaînage d e b lo c s avec p rop a g a tion (P C B C pour
« Propagating cipher block chaining ») [1084] est similaire au mode C B C , excepté que
le bloc de texte chiffré précédent et le bloc de texte en clair précédent sont tous deux
combinés par ou exclusif avec le bloc de texte en clair courant avant chiffrement (ou
après déchiffrement) (voir la figure 9.15).
C%= E K ( M t ffi Ct- i © M ,- i )
■Adj = © M t- i © D k (Cz)
Le mode P C B C est utilisé dans K e r b e r o s v e r s i o n 4 (voir § 24.5) pour effectuer à la

fois le chiffrement et le contrôle d ’intégrité en une passe. En mode P C B C , une erreur
dans le texte chiffré occasionne un déchiffrement incorrect de tous les blocs qui suivent.
Cela signifie que vérifier un bloc standard à la fin du message permet de s’assurer de
l’intégrité de tout le message.
Malheureusement, il y a un défaut à ce mode [876]. Echanger deux blocs de texte chiffré
occasionne un déchiffrement incorrect des deux blocs de texte en clair correspondants,
mais à cause de la nature de l’opération de ou exclusif avec le texte en clair et le
texte chiffré, ces erreurs se compensent et s’annulent. Donc un système de vérification
d ’intégrité qui ne regarde que les quelques derniers blocs de texte déchiffrés, peut être
amené à accepter un message partiellement embrouillé. Bien que personne n ’ait trouvé
comment exploiter ce défaut, K e r b e r o s VERSION 5, est passé au mode C B C une fois
que le défaut a été découvert.
Mode de chiffrement par chaînage de blocs avec sommes de

contrôle
Le ch iffrem en t par chaînage d e b lo c s avec som m es d e co n trô le (C B C C pour
« Cipher block chaining with checksum ») est une variante du mode C B C [1620]. Gardez
9.10 Autres modes 221
F ig. 9.15 —Mode de chiffrement par chaînage de blocs avec propagation
une combinaison par ou exclusif de tous les blocs de texte en clair, et combinez-la par ou
exclusif avec le dernier bloc de texte en clair avant chiffrement. Le mode C B C C s’assure
que tout changement effectué à un quelconque des blocs chiffrés change le résultat
déchiffré du dernier bloc. Si le dernier bloc contient un type de contrôle d ’intégrité ou
une constante, alors l’intégrité du texte en clair déchiffré peut être vérifiée avec peu de
frais supplémentaires.
Rétroaction de la sortie avec une fonction nonlinéaire

La ré tr o a c tio n d e la sortie avec un e fo n ctio n n on lin éaire (O F B N L F pour
« Output feedback mode with a nonlinear function ») [777] est une variante des deux
modes O F B et E C B où la clef change avec chaque bloc:
Ci = EKl{ M t) ; K i = EK {Ki- 1)
M i = D Kt(Ci) ; K i ~ E K ( K i ^ i)
Une erreur d’un seul bit dans le texte chiffré ne se répercute que dans un seul bloc en
clair. Néanmoins, si un seul bit est perdu ou ajouté, alors il y a une propagation infinie
d’erreurs. Avec un algorithme de chiffrement par blocs qui a un algorithme compliqué
de gestion de clef, comme le DES, ce mode est lent. Je ne connais pas de cryptanalyse
de ce mode.
Encore d’autres modes

D’autres modes sont possibles, bien qu’ils ne soient pas couramment utilisés. Le mode
de chaînage d e te x te en cla ir (P B C pour « plaintext block chaining ») est comme
le mode C B C sauf que le texte en clair précédent est combiné par ou exclusif avec le
bloc de texte en clair au lieu du texte chiffré. Le mode de chiffrem ent à rétroaction
du te x te en clair (P F B pour « plaintext feedback ») est comme le mode C FB , sauf
que c ’est le texte en clair, et non pas le texte chiffré, qui est utilisé pour la rétroaction.
Ces deux modes permettent les attaques à texte en clair choisi afin de résister aux
attaques à texte en clair connu. Il y a aussi le mode de chiffrem ent p a r b lo cs avec
chaînage des différen ces en tre b lo c s d e te x te en clair (C B C P D pour « cipher
block chaining of plaintext différence »). Je suis persuadé que c ’est encore plus étrange.
Si un cryptanalyste a une machine de recherche exaustive de clefs, alors il peut re
trouver la clef s’il peut deviner un des blocs de texte en clair. Certains de ces modes
étranges reviennent à un chiffrement léger avant d ’appliquer l’algorithme de chiffre
ment : par exemple, combiner le texte par ou exclusif avec une chaîne de caractères
secrète ou le permuter. A peu près n’importe quoi d’inhabituel permet d ’éviter ce type
de cryptanalyse.
9.11 Choix d’un mode opératoire de chif

frement
Si la simplicité et la vitesse sont vos critères principaux, le mode ECB est le plus facile
et le plus rapide à utiliser pour un algorithme de chiffrement par blocs. C ’est aussi le
plus faible. Non seulement un algorithme est vulnérable à l’attaque des blocs rejoués,
mais en mode EC B , il est plus facile à cryptanalyser. Je ne recommande donc pas le
mode ECB pour le chiffrement des messages.
Pour le chiffrement de données aléatoires, telles que d ’autres clefs, l’ECB est un bon
mode à utiliser. Comme les données sont courtes et aléatoires, aucun des points faibles
du mode E C B n ’ont d ’importance pour cette application.
Pour du texte en clair normal, utilisez plutôt les modes C B C , C FB , ou O FB . Celui
que vous choisirez dépendra de vos exigences spécifiques. Les deux tableaux 9.1 et 9.2
résument la sécurité et l’efficacité des différents modes.
Le mode C B C convient en général pour chiffrer des fichiers. L ’augmentation du niveau
de sécurité est significative ; et bien qu’il puisse y avoir des erreurs de bit dans les don
nées stockées, il n ’y a presque jamais d ’erreurs de synchronisation. Si votre application
est une réalisation logicielle, le mode C B C est presque toujours le meilleur choix.
Le mode C FB — plus spécifiquement le mode C F B à 8 bits — est généralement le mode
de choix pour chiffrer des flots de caractères quand chaque caractère doit être traité
individuellement, comme c ’est le cas pour le lien entre un terminal et un ordinateur
central. Le mode O FB est généralement utilisé pour les systèmes synchrones à grande
vitesse où la propagation d’erreurs est inacceptable. Le mode O FB est aussi le mode
de choix quand du pré-traitement est requis.
Le mode O F B est le mode de choix dans un environnement où il y a beaucoup d ’erreurs,
car il ne les propage pas.
Restez à l’écart des modes étranges. L ’un des quatre modes de base — E C B , CBC,
OFB et C F B est adéquat pour presque n’importe quelle application. Ces modes ne
sont pas exagérément complexes et probablement ne diminuent pas le niveau de sécurité
du système. Bien qu’il soit possible qu’un mode compliqué puisse augmenter le niveau
de sécurité d ’un système, il est plus probable qu’il n’augmente que sa complexité.
9.12 Intercalation 223
T a b . 9.1 - R é s u m é d e s m o d e s d e c h if f r e m e n t s p a r b l o c s
ECB C BC
Sécurité Sécurité
— Les motifs des textes en clair ne sont + Les motifs des textes en clair sont
pas dissimulés. dissimulés en combinant par o u e x c l u s i f
— L ’entrée de l’algorithme de chiffrement avec le bloc chiffré précédent.
par bloc n’est pas aléatoire ; c ’est comme + L’entrée de l’algorithme de chiffrement
le texte en clair. par bloc est aléatoire en combinant par
+ Plus d ’un seul message peut être chiffré o u e x c l u s i f avec le bloc chiffré précédent.
avec la même clef. + Plus d ’un seul message peut être chiffré
— Le texte en clair est facile à manipuler ; avec la même clef.
des blocs peuvent être retirés, répétés ou + / — Le texte en clair est quelque peu
interchangés. difficile à manipuler; des blocs peuvent
être retirés du début et de la fin du
Efficacité message, des bits du premier bloc peuvent
+ La vitesse est la même que celle de être changés, et la répétition permet des
l’algorithme de chiffrement par blocs. changements contrôlés.
— Le texte chiffré est jusqu’à un bloc
plus long que le texte en clair, du fait du Efficacité
remplissage. + La vitesse est la même que celle de
— Pas de pré-traitement possible. l’algorithme de chiffrement par blocs.
+ Le traitement est parallélisable. — Le texte chiffré est jusqu’à un bloc plus
long que le texte en clair, sans compter
Tolérance aux fautes l’IV.
— Une erreur dans le texte chiffré affecte — Pas de pré-traitement possible.
tout un bloc du texte en clair. + / — Le traitement n’est pas dérivable;
— Une erreur de synchronisation est le déchiffrement est parallélisable et
irrécupérable. supporte l’accès aléatoire.
Tolérance aux fautes

— Une erreur dans le texte chiffré affecte
tout un bloc du texte en clair et le bit
correspondant du bloc suivant.
— Une erreur de synchronisation est
irrécupérable.
Aucun des modes étranges n’a de meilleures propriétés pour la propagation d’erreurs
et pour les mécanismes de récupération d’erreurs.
9.12 Intercalation
Dans la plupart des modes, le chiffrement d’un bit (ou d’un bloc) dépend du chiffre
ment du bit (ou du bloc) précédent. Cela rend souvent impossible la parallélisation du
chiffrement. Prenez par exemple du matériel qui fait du chiffrement en mode CBC.
Même si ce matériel contient quatre puces de chiffrement, une seule peut marcher à la
fois. La puce suivante a besoin du résultat de la puce précédente pour commencer à
T a b . 9.2 - R é s u m é d e s m o d e s d e c h if f r e m e n t s p a r b l o c s
CFB ÔFB/Compteur
Sécurité Sécurité
+ Les motifs des textes en clair sont + Les motifs des textes en clair sont
dissimulés. dissimulés.
+ L’entrée de l’algorithme de chiffrement + L ’entrée de l’algorithme de chiffrement
par bloc est aléatoire. par bloc est aléatoire.
+ Plus d ’un seul message peut être + Plus d’un seul message peut être
chiffré avec la même clef pourvu qu’un IV chiffré avec la même clef pourvu qu’un IV
différent soit utilisé. différent soit utilisé.
+ / — Le texte en clair est quelque peu — Le texte en clair est très facile à
difficile à manipuler; des blocs peuvent manipuler ; tout changement dans le texte
être retirés du début et de la fin du chiffré affecte directement le texte en clair.
message, des bits du premier bloc peuvent
être changés, et la répétition permet des Efficacité
changements contrôlés. + La vitesse est la même que celle de
l’algorithme de chiffrement par blocs.
Efficacité — Le texte chiffré est de la même taille
+ La vitesse est la même que celle de que le texte en clair, sans compter l’IV.
l’algorithme de chiffrement par blocs. — Du pré-traitement est possible avant
— Le texte chiffré est de la même taille l’apparition du message.
que le texte en clair, sans compter l’IV. + / — Le traitement OFB n’est pas pa
+ / — Le chiffrement n ’est pas paralléli rallélisable ; le traitement compteur est
sable; le déchiffrement est dérivable et parallélisable.
supporte l’accès aléatoire.
— Du pré-traitement est possible avant Tolérance aux fautes
l’apparition d ’un b loc; le bloc de texte — Une erreur dans le texte chiffré affecte
chiffré précédent peut être chiffré. seulement le bit correspondant du texte
en clair.
Tolérance aux fautes + Une erreur de synchronisation est
— Une erreur dans le texte chiffré affecte irrécupérable.
le bit correspondant du texte en clair et
le bloc suivant.
-I- Des erreurs de synchronisation de la
taille d ’un bloc sont récupérables. Le
mode C F B à 1 bit peut récupérer après
le rajout ou la perte de bits.
travailler.
La solution est d ’in terca ler les multiples flots de chiffrement. (Ce n’est pas un chiffre
ment multiple, ceci sera abordé dans les paragraphes 15.1 et 15.2). Au lieu d ’utiliser
une seule chaîne en mode C B C , utilisez-en quatre. Les premier, cinquième et un bloc
sur quatre par la suite sont chiffrés en modes C B C avec un IV. Les second, sixième et
un bloc sur quatre par la suite sont chiffrés en modes C B C avec un autre IV , et ainsi
de suite. LTV total est plus long qu’il l’aurait été sans intercalaires.
C’est comme si vous chiffriez quatre messages différents avec la même clef et quatre
différents IV. Ces messages sont tous intercalés.
9.13 Chiffrement par blocs vs chiffrement en continu 225
Cette astuce peut aussi être utilisée pour augmenter la vitesse de matériels de chiffre
ment. Si vous avez trois puces de chiffrement, chacune capable de chiffrer des données à
33 mégabits/seconde, vous pouvez les intercaler pour chiffrer un seul canal de données
à 100 mégabits/seconde.
La figure 9.16 montre trois flots parallèles intercalés en mode C FB . L ’idée peut aussi
marcher en modes C B C et O FB , et avec autant de flots parallèles que désiré. Souvenez-
vous juste que chaque flot a besoin de son propre IV. Il ne doit pas être partagé.
F ig. 9.16 Mode de chiffrement par chaînage de blocs avec propagation
9.13 Chiffrement par blocs vs chiffrement

en continu
Bien que les systèmes de chiffrement par blocs et les systèmes de chiffrement en continu
soient très différents, des systèmes de chiffrement par blocs peuvent être utilisés en
tant que systèmes de chiffrement en continu et des systèmes de chiffrement en continu
peuvent être utilisés en tant que systèmes de chiffrement par blocs. La meilleure défi
nition de la différence que j ’ai trouvée est celle de Ranier R u e p p e l [1364] :
« Les systèmes de chiffrement par blocs agissent sur des données avec une
transformation fixe des grands blocs de données en clair; les systèmes de
chiffrement en continu agissent avec une transformation variant avec le
temps des chiffres en clair individuels. »
Dans le monde réel, les systèmes de chiffrement par blocs sont plus généraux (ils
peuvent être utilisés dans n’importe lequel des quatres modes) et les systèmes de chif
frement en continu sont plus faciles à analyser mathématiquement. Il y a beaucoup
de travail théorique effectué sur l’analyse et la conception des systèmes de. chiffrement
en continu ; la plupart de ces travaux sont effectués en Europe, je ne sais pour quelle
raison. Ils ont été utilisés par les militaires du monde entier depuis l’invention de l’élec
tronique. Cela semble changer dorénavant ; récemment, une grande quantité d’articles
théoriques sur les systèmes de chiffrement par blocs ont été publiés. Il y aura peut-être
que bientôt une théorie sur le modèle des systèmes de chiffrement par blocs aussi riche
que la théorie sur la conception des systèmes de chiffrement en continu.
Ceci mis à part, les différences entre ces deux systèmes se trouvent dans les réalisations.
Les systèmes de chiffrement en continu qui ne chiffrent et ne déchiffrent qu’un bit à
la fois ne sont pas vraiment adaptés à des réalisations logicielles. Les systèmes de
chiffrement par blocs sont nettement plus faciles à réaliser en logiciel, car ils évitent
les manipulations de bits qui sont coûteuses en temps de calcul et ils opèrent sur
des données dans des blocs de taille raisonnable. D ’un autre côté, les systèmes de
chiffrement en continu sont mieux adaptés à des réalisations matérielles car ils peuvent
être réalisés de façon très efficace dans du silicone.
Ce sont des considérations importantes. Il semble logique pour un appareil de chiffre
ment d’un canal digital de communications de chiffrer chaque bit quand il arrive. C ’est
ce que l’appareil voit. D ’un autre côté, il semble illogique pour un logiciel de chiffre
ment de chiffrer chaque bit séparément. Il y a des exemples précis où le chiffrement de
chaque bit et de chaque octet est nécessaire dans un système informatique — chiffrer
le lien entre le clavier et le microprocesseur, par exemple — mais généralement le bloc
de chiffrement devrait au moins être de la largeur du bus de données.
Chapitre 10
Utilisation des algorithmes
Considérez la sécurité (sécurité des données, sécurité des communications, sécurité de

l’information,...) comme une chaîne. La sécurité du système entier n’est pas plus forte
que le plus faible des maillons. Tout doit être sûr: les algorithmes cryptographiques,
les protocoles, la gestion des clefs, et bien plus. Si vos algorithmes sont sophistiqués
mais que votre générateur de nombre aléatoire est mauvais, un cryptanalyste judicieux
attaquera votre système par la génération des nombres aléatoires. Si vous comblez
cette lacune mais oubliez de bien effacer la partie de la mémoire qui contient la clef,
un cryptanalyste cassera votre système par cette voie. Si vous faites tout correctement
mais accidentellement envoyez un courrier électronique de la copie de vos dossiers sûrs
au Wall Street Journal, autant que vous ne fassiez rien du tout.
Ce n’est pas juste. En tant que concepteur de système sûr, vous devez vous proté
ger contre tous les moyens possibles d’attaque, alors qu’il suffit à un cryptanalyste
d’exploiter la moindre faille dans votre système de sécurité !
La cryptographie n’est qu’une partie de la sécurité, et souvent une très petite partie.
C ’est la partie mathématique pour rendre un système sûr, ce qui est différent d ’effec
tivement rendre un système sûr. La cryptographie a ses « grands pontes » : des gens
qui passent tant de temps à discuter à propos de la longueur idéale de clef qu’ils en
oublient tout le reste. Si la police secrète veut savoir ce qu’il y a dans votre ordinateur,
il leur est plus facile de pénétrer chez vous et d’installer une caméra qui enregistre tout
ce qui apparaît sur votre écran que de cryptanalyser votre disque dur.
De plus, la vue traditionnelle de la cryptographie comme étant une technologie « es
pion contre espion » devient de moins en moins appropriée. Plus de 99 pourcents de la
cryptographie utilisée dans le monde ne protège pas de secrets militaires ; c’est dans des
applications telles que les cartes bancaires, les cartes de chaînes de télévision payantes,
les péages autoroutiers, les cartes d’accès aux immeubles et aux ordinateurs, les termi
naux de loterie et les pré-paiements de compteurs électriques [44, 45] qu’elle se trouve.
Dans ces applications, le rôle de la cryptographie est de rendre la petite criminalité
un peu plus difficile ; l’exemple de l’adversaire bien financé avec toute une armée de
cryptanalystes dans une pièce remplie d ’ordinateurs ne s’applique pas ici.
La plupart de ces applications ont utilisé de la cryptographie bas de gamme, mais les
attaques victorieuses menées contre elles n’ont rien à voir avec la cryptanalyse. Elles im
pliquaient des employés véreux, des opérations judicieuses de piratage, des réalisations
228 Chapitre 10 Utilisation des algorithmes
stupides, des ratés d ’intégration et des idioties aléatoires. (Je recommande fortement
le papier de Ross A n d e r s o n « Pourquoi les cryptosystèmes ont échoué » [45] ; il de
vrait être lu par toute personne évoluant dans ce domaine.) Même si la N SA a admis
que la plupart des échecs de sécurité dans sa zone d ’intérêt sont dus à des échecs de
réalisations, et non pas à des échecs au niveau des algorithmes et des protocoles [1125].
Dans ces exemples, peu importe si la cryptographie était bonne ou pas ; les attaques
victorieuses l’ont complètement surpassée.
10.1 Choix d’un algorithme

Quand on en arrive à jauger et à choisir les algorithmes, les gens ont plusieurs choix :
- Ils peuvent utiliser un algorithme publié, croyant que les algorithmes publiés ont
été décortiqués par de nombreux cryptographes ; si personne ne l’a encore cassé,
alors il doit être très bon.
- Ils peuvent faire confiance à un fabricant, croyant qu’un fabricant connu a une
réputation à défendre et qu’il ne risquera pas cette réputation en vendant des
équipements ou des programmes avec des algorithmes de mauvaise qualité.
- Ils peuvent faire confiance à un consultant indépendant, croyant qu’un consul

tant impartial est mieux équipé pour faire une évaluation fiable des différents
algorithmes.
- Ils peuvent faire confiance au Gouvernement, croyant que le Gouvernement est

digne de confiance et qu’il ne tromperait pas ses citoyens.
- Ils peuvent écrire leur propre algorithme, croyant que leurs compétences en cryp
tographie n’ont pas leur pareil et qu’ils ne doivent avoir confiance en personne
d’autre qu’eux-même.
Chacune de ces croyances est problématique, mais la première semble être la plus
sensée. Placer votre confiance dans un seul fabricant, consultant ou gouvernement
revient à chercher des ennuis. La plupart des gens qui portent l’étiquette « consultant
en sécurité » (même des firmes célèbres) ne connaissent en général rien au chiffrement.
La plupart des fabricants en sécurité ne sont pas fiables. Les meilleurs cryptographes
au monde travaillent pour la NSA, mais ils ne disent pas tout ce qu’ils savent. Les
intérêts qu’ils poursuivent ne sont pas conformes à ceux des citoyens. Et même si vous
êtes un génie, écrire votre propre algorithme et ensuite l’utiliser sans l’avoir soumis à
l’examen critique des pairs est de l’inconscience pure.
Les algorithmes de ce livre sont publiques. La plupart ont été divulgués dans la littéra
ture publique et ont été cryptanalysés par des experts dans le domaine. Je mentionne
tous les résultats publiés, positifs et négatifs. Je n’ai pas accès aux cryptanalysés en
treprises par la myriade d ’organisations de sécurité militaire de par le monde (qui sont
probablement meilleures que les institutions académiques — elles le font depuis plus
longtemps et elles sont mieux financées), donc il est possible que ces algorithmes soient
plus faciles à casser qu’ils ne le paraissent. Même ainsi, il est bien plus probable qu’ils
soient plus sûrs qu’un algorithme conçu et réalisé en secret par une société spécialisée
en sécurité.
10.1 Choix d’un algorithme 229
Le point faible de ce raisonnement est que nous ne connaissons pas les capacités des
nombreuses organisations militaires de cryptanalyse.
Quels algorithmes la NSA peut-elle casser? Pour la majorité d’entre nous, il est impos
sible de le dire. Si vous êtes arrêté en possession d’un ordinateur chiffré avec DES, il
est peu probable que le FB I produise le contenu déchiffré comme pièce à conviction ; le
fait qu’ils peuvent casser l’algorithme est souvent un secret bien plus important que les
informations qui sont alors déchiffrées. Pendant la deuxième guerre mondiale, il était
interdit aux Alliés d ’utiliser une information déchiffrée du trafic Ultra des Allemands, à
moins qu’ils aient pu plausiblement obtenir l’information autrement. La seule façon de
pousser la NSA à reconnaître sa capacité à casser un algorithme donné est de chiffrer
une information tellement importante qu’ils ne pourront pas faire autrement que de la
divulguer publiquement. Ou, mieux encore, créez une blague très drôle et envoyez-la
par courrier électronique chiffré à des correspondants ambigus dans des pays suspects.
Les employés de la NSA sont aussi des hommes; je doute qu’il puisse garder une si
bonne blague secrète.
Une bonne hypothèse de travail est que la N SA peut lire chaque message qu’elle choisit,
mais qu’elle ne peut pas lire tous les messages qu’elle choisit. La NSA est limitée par
ses ressources et doit faire un choix dans ses cibles. Une autre bonne hypothèse est
qu’elle préfère casser autre chose que des codes ; cette préférence est si forte qu’elle se
résoudra à casser les codes seulement quand elle voudra préserver le secret qu’elle a lu
le message.
Dans tous les cas, la meilleure chose que la plupart d ’entre-nous peuvent faire est de
choisir parmi des algorithmes publiques qui ont raisonnablement résisté à une obser
vation publique et à des cryptanalysés.
Algorithmes pour l’exportation

Pour exporter un algorithme hors des Etats-Unis, il faut l’autorisation du Gouver
nement américain (plus exactement, de la N SA — voir § 25.1). Il est généralement
admis que ces algorithmes autorisés à l’exportation peuvent être cassés par la NSA.
Bien que personne n’ait admis cela pour la postérité, voici quelques indices de ce que la
NSA est suspectée, en privé, de suggérer aux sociétés qui veulent exporter des produits
cryptographiques :
- Laissez passer un bit de la clef de temps à autre caché dans le texte chiffré ;
- Ramenez la clef effective à quelque chose dans la gamme des 30 bits. Par exemple,
tandis qu’un algorithme pourrait accepter une clef de 100 bits, la plupart de ces
clefs peuvent être équivalentes ;
Utilisez un IV fixé, ou chiffrez un en-tête fixé au début de chaque message chiffré.

Cela facilite une attaque à texte en clair choisi ;
engendrez quelques octets aléatoires, chiffrez-les avec la clef, et placez le texte en

clair et le texte chiffré de ces octets aléatoires au début du message chiffré. Cela
facilite également une attaque à texte en clair connu.
La NSA reçoit une copie du code source, mais les détails de l’algorithme restent cachés
pour les autres. Il est évident que personne ne fait de publicité quant à ces faiblesses,
mais faites attention si vous achetez un produit de chiffrement américain qui a été
approuvé pour Pexport.
10.2 La cryptographie à clef publique vs la

cryptographie à clef secrète
Cryptographie à clef publique ou cryptographie à clef secrète? Quelle est la meilleure?
Cette question n’a aucun sens mais est l’objet d ’un débat depuis que la cryptographie
à clef publique a été inventée. Ce débat suppose que les deux types de cryptographie
peuvent être comparés d ’égal à égal. Ils ne le peuvent pas.
N e e d h a m et S c h r o e d e r [1159] remarquent que le nombre de messages et leur lon
gueur sont bien plus grands dans les algorithmes à clef publique que dans les algo
rithmes à clef secrète. Leur conclusion montre que l’algorithme à clef secrète est plus
efficace que l’algorithme à clef publique. Bien que cela soit vrai, cette analyse oublie le
gain significatif en sécurité de la cryptographie à clef publique.
Whitfield D if f ie écrit [490, 492] :
« En envisageant la cryptographie à clef publique comme une nouvelle forme

de cryptosystème plutôt qu’une nouvelle forme de gestion de clefs, je me
prépare aux critiques tant du point de vue de la sécurité que de la perfor
mance. Les opposants remarquèrent rapidement que le système R S A était
1000 fois plus lent que le DES et nécessitait des clefs presque 10 fois plus
grandes. Bien qu’il fût clair dès le début que l’utilisation des systèmes à
clefs publiques pouvait être limitée à l’échange des clefs pour la cryptogra
phie conventionnelle (à clef secrète), il n’était pas immédiatement clair que
cela fût nécessaire. Dans ce contexte, la proposition de construire des sys
tèmes hybrides [879] fut saluée comme une invention en soi. »
La cryptographie à clef publique et la cryptographie à clef secrète sont deux choses

différentes ; elles résolvent des problèmes de types différents. La cryptographie à clef
secrète est meilleure pour chiffrer des données. Elle est infiniment, plus rapide et n’est
pas prédisposée à des attaques à texte chiffré choisi. La cryptographie à clef publique
peut faire des choses que la cryptographie à clef secrète ne permet pas ; elle est adaptée
pour la gestion des clefs et une myriade de protocoles exposés dans la Partie I.
D ’autres installations ont été exposées dans la Partie I : fonctions de hachage à sens
unique, codes d’authentification de message , etc... Le tableau 10.1 énumère les diffé
rents types d ’algorithmes et leurs propriétés [806].
10.3 Chiffrement des canaux de communi

cation
C’est le problème classique d’Alice et de Bernard: Alice veut envoyer à Bernard un
message sûr. Que fait-elle? Elle chiffre le message.
En théorie, ce chiffrement peut être effectué dans n’importe quelle couche OSI
(Interface de systèmes ouverts, « Open Systems Interface » en Anglais) du modèle
10.3 Chiffrement des canaux de communication 231
T ab . 1 0 .1 - C lasses d ’a l g o r it h m e s
Confidentialité Authentification Intégrité Clef Gestion

Algorithmes de chiffrement à clef secrète Oui Non Non Oui
Algorithmes de chiffrement à clef publique Oui Non Non Oui
Algorithmes de signature digitale Non Oui Oui Non
Algorithmes d ’échange de clef Oui Optionnel Non Oui
Fonctions de hachage à sens unique Non Non Oui Non
Codes d ’authentification de message Non Oui Oui Non
de communication. (Voir le standard d’architecture de sécurité OSI pour plus d’infor

mations [310].) En pratique, le chiffrement a lieu soit dans les basses couches (une et
deux), soit dans les hautes couches. S’il s’effectue dans les basses couches, il est appelé
chiffrement lien par lien; tout ce qui passe par un lien de données particulier est
chiffré. Si le chiffrement s’effectue dans des couches plus élevées, il est appelé chif
frement de bout en bout ; les données sont chiffrées de façon sélective et restent
chiffrées jusqu’à ce qu’elles soient déchiffrées par le destinataire final désigné. Chaque
approche a ses avantages et ses inconvénients.
Chiffrement lien par lien

L’endroit le plus simple pour rajouter le chiffrement se trouve dans la couche physique
(voir la figure 10.1). Cela est appelé chiffrement lien par lien. Les interfaces avec la
couche physique sont généralement standardisées et il est facile de connecter un dispo
sitif de chiffrement à cet endroit. Ces dispositifs chiffrent toutes les données qui passent
par eux, incluant les données elles-mêmes, les informations de routage et les informa
tions du protocole. Ils peuvent être utilisés sur tous les types de liens de communication
numérique. Par ailleurs, tout dispositif de commutation ou de stockage intelligent sur
le parcours entre l’émetteur et le récepteur doit déchiffrer le flux de données avant de
le traiter.
Ce type de chiffrement est très efficace. Comme tout est chiffré, un cryptanalyste ne
peut obtenir aucune information sur la structure de l’information. Il n’a pas la moindre
idée de qui parle à qui, de la longueur des messages envoyés, à quel moment de la journée
ils communiquent, etc. On parle alors de sécurité du flot de trafic : non seulement
l’ennemi n’a pas accès à l’information, mais il ignore aussi la destination et le volume
de cette information.
La sécurité ne dépend d’aucune technique de gestion du trafic. La gestion des clefs est
F ig . 10.1 - Chiffrement au niveau des liens

aussi simple : seules les deux extrémités d ’une ligne doivent partager une clef et elles
peuvent changer leur clef indépendamment du reste du réseau.
Imaginez-vous une ligne de communication synchrone, chiffrée en mode C FB à 1 bit.
Après l’initialisation, cette ligne peut fonctionner indéfiniment, récupérant automati
quement des erreurs de bit ou de synchronisation. La ligne chiffre dès que des messages
sont envoyés à partir d ’une extrémité vers l’autre ; sinon, elle chiffre et déchiffre des
données aléatoires. Estelle n’a aucune idée de la date des messages envoyés ou non;
elle n’a pas d ’idée du début et de la fin des messages. Tout ce qu’elle voit est un flux
continu de bits qui ont l’air aléatoires.
Si la ligne de communication est asynchrone, le même mode C FB à 1 bit peut être
utilisé. La différence est que l’adversaire peut obtenir de l’information sur le taux de
la transmission. Si cette information doit rester secrète, prenez des précautions en
envoyant des messages factices entre les communications utiles.
Le plus gros défaut du chiffrement lien par lien est que chaque lien physique du réseau
doit être chiffré : laisser un seul lien non chiffré compromet la sécurité de tout le réseau.
Si le réseau est grand, le coût peut rapidement devenir prohibitif pour ce type de
chiffrement.
De plus, tous les nœuds du réseau doivent être protégés, car ils véhiculent des données
non chiffrées. Si tous les utilisateurs du réseau se font confiance mutuellement et si tous
les nœuds sont en lieu sûr, cela peut être acceptable. C ’est toutefois improbable. Même
dans une société, l’information doit être gardée secrète au sein d’un département. Si
le réseau se trompe de chemin pour acheminer une information, tout le monde peut la
lire. Le tableau 10.2 résume les avantages et les inconvénients du chiffrement lien par
lien.
Ta b . 10.2 - Chiffrement au niveau physique: avantages et inconvénients
Avantages
Opération plus simple, puisqu’elle est transparente pour l’utilisateur. Tout est chiffré
avant d ’être envoyé sur le lien.
Un seul jeu de clefs par lien est nécessaire.
Fournit une sécurité du flot de traffic, puisque chaque information de routage est
chiffrée.
Le chiffrement est en ligne.
Inconvénients
Les données sont vulnérables dans les nœuds intermédiaires.
Chiffrement de bout en bout

Un autre approche consiste à mettre le dispositif de chiffrement entre la couche réseau
et la couche de transport. Le dispositif de chiffrement doit pouvoir interpréter les
données d ’après les protocoles jusqu’à la couche trois et chiffrer seulement les unités
de données de transport qui sont alors recombinées avec les informations de routage
non chiffrées et envoyées aux couches inférieures du protocole.
10.3 Chiffrement des canaux de communication 233
Cette approche évite le problème du chiffrement/déchiffrement au niveau de la couche

physique. En utilisant le chiffrement de bout en bout, les données restent chiffrées
jusqu’à ce qu’elles atteignent leur destination finale (voir la figure 10.2). Le défaut
principal du chiffrement de bout en bout est que les informations de routage pour les
données ne sont pas chiffrées; un bon cryptanalyste peut pas mal apprendre de qui
parle à qui, à quel moment et pendant combien de temps, sans même connaître le
contenu de ces conversations. La gestion des clefs est également plus difficile car les
utilisateurs doivent s’assurer qu’ils ont bien des clefs communes.
F ig . 10.2 - Chiffrement de bout en bout
Construire un dispositif de chiffrement de bout en bout est difficile. Chaque système

de communication particulier a ses propres protocoles. Parfois, les interfaces entre ces
niveaux ne sont pas bien définies, rendant la tâche plus difficile encore.
Si le chiffrement a lieu dans une couche haute de l’architecture de communication,
comme les couches application et présentation, alors cela peut être indépendant du
type de réseau de communication utilisé. C ’est toujours du chiffrement de bout en
bout, mais la réalisation du chiffrement ne doit pas se préoccuper des codes de ligne,
de la synchronisation entre les modems, des interfaces physiques, etc. Dans les temps hé
roïques de la cryptographie électromécanique, le chiffrement et le déchiffrement avaient
entièrement lieu hors ligne : cela ne fait qu’une étape de moins.
Le chiffrement dans ces hautes couches interagit avec le logiciel de l’utilisateur. Le lo
giciel est différent pour des architectures d’ordinateur différentes et donc le chiffrement
doit être optimisé pour différents systèmes informatiques. Le chiffrement peut être réa
lisé par le logiciel ou par du matériel dédié. Dans ce dernier cas, l’ordinateur enverra
les données au matériel dédié pour les chiffrer, avant de les envoyer vers les couches
inférieures de l’architecture de communication pour être transmises. Ce processus re
quiert quelque intelligence et n’est pas adapté aux terminaux non intelligents. De plus,
il peut y avoir des problèmes de compatibilité entre les différents types d’ordinateurs.
Le plus gros inconvénient du chiffrement de bout en bout est qu’il permet l’analyse
de trafic. C ’est l’analyse de messages chiffrés: d’où ils viennent, où ils vont, de quelle
longueur ils sont, quand ils ont été envoyés, à quelle fréquence, s’ils coïncident avec
des événements extérieurs tels que des rendez-vous, et bien plus. Beaucoup de bonnes
informations sont enterrées dans ces données et un cryptanalyste voudra mettre les
mains dessus. Le tableau 10.3 présente les aspects positifs et négatifs du chiffrement
de bout en bout.
Combinaison des deux

Le tableau 10.4, emprunté à [1254], compare les chiffrements lien par lien et de bout
en bout. Combiner les deux, bien qu’étant très cher, est le moyen le plus efficace de
T a b . 10.3 - Chiffrement lien par lien : avantages et inconvénients
Avantages
Niveau de secret plus élevé.
Inconvénients
Requiert un système de gestion des clefs plus complexe.
L’analyse de trafic est possible, puisque l’information de routage n’est pas chiffrée.
Le chiffrement est hors-ligne.
rendre sûr un réseau. Le chiffrement de tout lien physique rend toute analyse des
informations de routage impossible, tandis que le chiffrement de bout en bout réduit
le danger des données non chiffrées aux différents nœuds du réseau. Les gestions des
clefs des deux schémas peuvent être complètement séparées : les gestionnaires de réseau
peuvent s’occuper du chiffrement au niveau physique, tandis que les individus peuvent
avoir la responsabilité du chiffrement de bout en bout.
Tab. 10.4 Comparaison des chiffrements lien par lien et de bout en bout
C h if f r e m e n t l ie n par l ie n C h if f r e m e n t de bo u t en bout
Sécurité dans les machines hôtes

Message exposé chez l’hôte envoyeur. Message chiffré chez l’hôte envoyeur.
Message exposé dans les nœuds intermé- Message chiffré dans les nœuds intermé
diaires. diaires.
Rôle de l’utilisateur
Effectué par l’hôte envoyeur. Effectué par le processus d’envoi.
Transparent pour l’utilisateur. L’utilisateur effectue le chiffrement.
L ’hôte maintient le chiffrement. L’utilisateur doit trouver l’algorithme.
Un service pour tous les utilisateurs. L’utilisateur sélectionne le chiffrement.
Peut être réalisé en matériel. Plus facilement effectué dans le logiciel.
Tous ou aucun messages chiffrés. L’utilisateur choisit de chiffrer ou pas,
pour chaque message.
Exigences de la réalisation
Nécessite une clef par paire d’hôtes. Nécessite une clef par paire d’utilisa
Nécessite un matériel ou un logiciel de teurs.
chiffrement à chaque hôte. Nécessite un matériel ou un logiciel de
Effectue l’authentification des nœuds. chiffrement à chaque nœud.
Effectue l’authentification des utilisa
teurs.
10. Jf Chiffrement des données à des fins de stockage 2S5
10.4 Chiffrement des données à des fins de

stockage
Chiffrer des données pour les stocker et les récupérer plus tard peut être utilisé dans
le modèle d’Alice et de Bernard. Alice envoie toujours un message à Bernard, mais
dans ce cas « Bernard » est Alice dans un temps futur. Néanmoins, le problème est
fondamentalement différent.
Dans les canaux de communication, les messages en transit n’ont pas de valeur intrin
sèque. Si Bernard ne reçoit pas un message particulier, Alice peut toujours le renvoyer.
Ceci n’est pas vrai pour le stockage des données chiffrées. Si Alice ne peut pas déchiffrer
son propre message, elle ne peut pas remonter le temps et le rechiffrer. Elle l’a perdu à
jamais. Ceci veut dire que les applications de chiffrement pour le stockage des données
devraient avoir des mécanismes pour empêcher des erreurs irrécupérables de s’infiltrer
dans le texte chiffré.
La clef de chiffrement a la même valeur que le message, elle est seulement plus pe
tite. En effet, la cryptographie convertit de gros secrets en petits. Etant plus petites,
elles peuvent facilement être perdues. Les procédures de gestion des clefs devraient
considérer que les mêmes clefs seront utilisées maintes fois et que les données pourront
demeurer sur disque pendant des années avant d ’être déchiffrées.
De plus, les clefs seront présentes pendant une longue période. Une clef utilisée pour
une liaison téléphonique devrait, ce qui serait idéal, exister juste le temps de la commu
nication. Une clef utilisée pour le stockage des données peut servir pendant des années
et doit par conséquent être stockée de manière sûre pendant des années.
D’autres problèmes spécifiques au chiffrement des données informatiques en vue de
stockage sont énumérés dans [361] :
- Les données peuvent aussi exister sous forme de texte en clair, soit sur un autre
disque, dans un autre système informatique ou sur papier. Il y a plus d’occasions
pour des cryptanalystes de monter une attaque à texte en clair connu.
- Dans les applications de bases de données, des parcelles de données peuvent être
plus petites que la taille de blocs de la plupart des algorithmes. Cela donnera un
texte chiffré qui peut être largement plus grand que le texte en clair.
- La vitesse des périphériques d’entrée et sortie nécessite une grande vitesse de

chiffrement et de déchiffrement, et une réalisation matérielle du chiffrement sera
probablement nécessaire. Pour certaines applications, des algorithmes à haute
vitesse pourraient être nécessaires.
- Un stockage sûr et de longue durée pour les clefs est nécessaire.
- La gestion des clefs est nettement plus compliquée, car différentes personnes
doivent accéder à différents fichiers, différentes portions d’un même fichier, etc.
Si les fichiers chiffrés ne sont pas structurés en enregistrements et champs, comme dans
les fichiers de texte, l’accès est facile : tout le fichier est déchiffré avant usage. Si les
fichiers chiffrés sont des fichiers d’une base de données, la solution est problématique.
Déchiffrer toute la base de données pour accéder à un seul enregistrement est inefficace,
2S6 Chapitre 10 Utilisation des algorithmes
mais chiffrer les enregistrements indépendamment peut être sujet à une attaque du type
des blocs rejoués.
De plus, vous devez être sûr que le fichier non chiffré est effacé après le chiffrement
(voir § 10.9). Pour plus de détails et un autre aperçu, consultez [427, 571].
Déréférencer les clefs

Quand vous chiffrez un disque dur volumineux, vous avez deux options. Vous pouvez
chiffrer toutes les données en n’utilisant qu’une seule clef. Cela fournit au cryptana
lyste une grande quantité de texte chiffré à analyser et rend impossible à de multiples
utilisateurs de voir seulement des parties du disque. Ou, vous pouvez chiffrer chaque
fichier avec une clef différente, forçant les utilisateurs à mémoriser une clef différente
pour chaque fichier.
La solution et de chiffrer chaque fichier avec une clef séparée et de chiffrer ces clefs avec
une autre clef connue des utilisateurs. Chaque utilisateur ne doit se souvenir que de
cette clef. Des utilisateurs différents peuvent avoir différents sous-ensembles des clefs
de chiffrement de fichier chiffrés avec leur clef. Il peut même y avoir une clef maîtresse
qui chiffre toutes les clefs de chiffrement de fichier. Ceci est même plus sûr car les
clefs de chiffrement de fichier sont aléatoires et moins vulnérables à une attaque par
dictionnaire.
Chiffrements au niveau du disque vs chiffrements au niveau des

fichiers
Il y a deux manières de chiffrer un disque dur : au niveau des fichiers et au niveau du
disque. Le chiffrement au niveau des fichiers signifie que tous les fichiers sont chiffrés
séparément. Pour utiliser un fichier qui a été chiffré, vous devez d ’abord le déchiffrer,
puis l’utiliser et enfin le rechiffrer.
Le chiffrement au niveau du disque garantit un disque logique dans l’ordinateur de
l’utilisateur où toutes les données y sont chiffrées. Bien effectué, cela fournit une sécurité
qui, au delà du choix d’un bon mot de passe, ne demande pas grand chose de la part
de l’utilisateur. Néanmoins, le disque doit être beaucoup plus complexe qu’un simple
programme de chiffrement de fichier, car il doit s’occuper d ’allouer de nouveaux secteurs
à des fichiers, de recycler de vieux secteurs, de traiter des requêtes de lecture et de mise
à jour des accès aléatoires pour toute donnée sur le disque, etc...
En pratique, le disque demande un mot de passe à l’utilisateur avant de démarrer. Ceci
génère une clef maîtresse de déchiffrement qui peut alors être utilisée pour déchiffrer
les clefs de déchiffrement nécessaires pour les différentes données.
Fournir un accès aléatoire à un disque chiffré

La plupart des systèmes devraient être capable d’accéder aux secteurs d’un disque de
manière aléatoire. Ceci implique des complications quant à l’utilisation de nombreux
algorithmes de chiffrement en continu et d’algorithmes de chiffrement par blocs dans
tout mode de chaînage. Plusieurs solutions sont possibles.
Utilisez l’adresse secteur pour générer un IV unique pour chaque secteur qui est chiffré
ou déchiffré. Le défaut est que chaque secteur sera toujours chiffré avec le même IV.
Assurez-vous que cela ne pose pas de problème de sécurité.
10.5 Chiffrement matériel vs chiffrement logiciel 231
Pour la clef maîtresse, générez un bloc pseudo-aléatoire aussi grand qu’un secteur.
(Vous pouvez le faire en utilisant un algorithme en mode O F B par exemple.) Pour
chiffrer tout secteur, combinez d ’abord par ou exclusif avec ce bloc pseudo-aléatoire,
puis chiffrez normalement avec un algorithme de chiffrement par blocs en mode ECB.
Cela s’appelle E C B + O F B (voir § 15.4).
Comme C B C et C FB sont des modes de récupération d ’erreurs, vous pouvez utilisez
tous les blocs du secteur sauf les premiers et seconds pour générer un IV pour ce
secteur. Par exemple, l’IV du secteur 3 001 peut être le hachage de toutes les données du
secteur, mis à part les premiers 128 bits. Après avoir généré l’IV , chiffrez normalement
en mode C B C . Pour déchiffrer le secteur, vous utilisez les 64 bits du second bloc
du secteur en tant qu’IV puis déchiffrez le reste du secteur. Ensuite, en utilisant les
données déchiffrées, vous régénérez l’IV et déchiffrez les premiers 128 bits.
Vous pouvez utiliser un algorithme de chiffrement par blocs avec une taille de bloc
assez grande pour pouvoir chiffrer tout le secteur d’un coup. C R A B (voir § 14.6) en
est un exemple.
10.5 Chiffrement matériel vs chiffrement

logiciel
Chiffrement matériel
Jusqu’à il y a peu, tous les équipements de chiffrement étaient des réalisations ma
térielles dédiées. Ces boîtes de chiffrement/déchiffrement se branchaient sur les lignes
de communications et chiffraient toutes les données passant sur la ligne. Bien que le
chiffrement en logiciel prenne de l’importance aujourd’hui, le matériel est toujours le
choix qui est fait par les militaires et les applications commerciales sérieuses. La NSA,
par exemple, n’autorise que le chiffrement par le matériel. Il y a plusieurs raisons à
cela.
La première est la vitesse. Comme nous le verrons dans la troisième Partie, les algo
rithmes de chiffrement consistent en de nombreuses opérations compliquées sur des bits
de texte en clair. On ne trouve pas sous le sabot d’un cheval des ordinateurs qui com
prennent ce genre d ’opérations en standard. Les deux algorithmes de chiffrement les
plus courants, le DES et R SA , ne fonctionnent pas bien sur des processeurs généraux.
Bien que certains cryptographes aient essayé de rendre les algorithmes plus facilement
réalisables en logiciel, le matériel dédié gagnera toujours la course de vitesse.
De plus, le chiffrement est souvent une tâche de calcul intensif. Mobiliser le processeur
principal de l’ordinateur pour cela est inefficace. Confier le chiffrement à une autre puce,
même si cette puce n’est qu’un autre processeur, rend tout le système plus rapide.
La deuxième raison est la sécurité. Un algorithme de chiffrement fonctionnant sur
un ordinateur commun n’a pas de protection physique. Martin peut utiliser différents
outils de débogage et subrepticement modifier l’algorithme sans que qui que ce soit s’en
rende compte. Les dispositifs de chiffrement matériels peuvent être bien encapsulés pour
prévenir cela. Des boîtes à l’épreuve de l’investigation peuvent empêcher que quelqu’un
modifie le dispositif de chiffrement matériel. Des puces VLSI dédiées peuvent être
recouvertes d ’un film protecteur chimique spécial tel que toute tentative d’accéder à
l’intérieur provoque la destruction des circuits logiques de l a puce. Les puces C l i p p e r
T ab. 10.5 - Chiffrements au niveau des fichiers vs au niveau du disque
C h if f r e m e n t a u n iv e a u d e s f ic h ie r s C h if f r e m e n t au n iv e a u du d is q u e
Bénéfices
Facilité de réalisation et d’utilisation. Les fichiers temporaires, de travail, et
Flexibilité. autres, peuvent être gardés dans le
Baisse de performance très faible. disque sûr.
Les utilisateurs peuvent transférer des fi- Il est plus difficile d ’oublier de rechiffrer
chiers entre différentes machines sans quelque chose avec ce genre de système,
problèmes.
Les utilisateurs peuvent sauvegarder des
fichiers sans problèmes.
Questions de sécurité
Fuite possible par des programmes non- Beaucoup de choses peuvent mal se pas
sécurisé (un programme peut écrire un ser avec un disque ou un programme
fichier sur le disque pour un stockage résident en mémoire.
temporaire, par exemple). De mauvaises conceptions permettront
Une mauvaise conception peut toujours des attaques à texte en clair, voire à
rechiffrer la même clef pour le même texte chiffré, choisi.
mot de passe. Si tout le système est verrouillé avec un
mot de passe, la perte de ce mot de
passe fait que l’attaquant peut tout ob
tenir.
Un ensemble plus limité d ’algorithmes
de chiffrement peut raisonnablement
être utilisé pour ce genre d ’application.
Par exemple, des algorithmes de chif
frement en continu en mode O F B ne
marcheraient pas.
Problèmes d’ utilisation
L’utilisateur doit savoir ce qu’il doit II y aura une baisse de performance.
faire. Le disque peut réagir de manière inat-
II peut y avoir différents mots de passe tendu
pour différents fichiers. avec W i n d o w s , l’émulation OS2 DOS,
Le chiffrement manuel de fichiers sélec- des gestionnaires de disque, etc...
tionnés
est le seul contrôle d ’accès.
et C a p s t o n e du gouvernement américain (voir § 24.16 et § 24.17) sont conçues pour

résister à toute investigation. Les puces peuvent être conçues pour qu’il soit impossible
à Martin de lire la clef non chiffrée.
IBM a développé un système cryptographique pour chiffrer les données et les commu
nications sur les ordinateurs centraux [517, 1032]. Il comprend des modules spéciaux
résistants à l’investigation pour contenir les clefs. Ce système est décrit dans le para
10.5 Chiffrement matériel vs chiffrement logiciel 239
graphe 24.1.
Le rayonnement électromagnétique peut parfois révéler ce qui se passe dans un équipe
ment électronique. Des boîtes dédiées au chiffrement peuvent être blindées de manière
à ne pas laisser s’échapper d’information. Les ordinateurs multi-usage traditionnels
peuvent être blindés également, mais c’est nettement plus complexe à réaliser. Les mi
litaires américains appellent ceci T E M P E S T ; c ’est un sujet qui dépasse largement le
cadre de ce livre.
La raison finale pour la prédominance des réalisations matérielles est la facilité d’ins
tallation. La plupart des applications de chiffrement n’impliquent pas des ordinateurs
classiques. Les gens peuvent vouloir chiffrer leur conversations téléphoniques, leurs en
vois de fax, ou leurs liens de données. Il est moins cher de mettre du matériel dédié
au chiffrement dans les téléphones, les fax, et les modems que de mettre le chiffrement
dans un microprocesseur et un logiciel.
Même quand les données chiffrées viennent d’un ordinateur, il est plus simple d’installer
un périphérique de chiffrement que de modifier le logiciel système de l’ordinateur. Le
chiffrement doit être invisible et ne doit pas gêner l’utilisateur. Le seul moyen de réaliser
cela en logiciel est de réaliser le chiffrement dans les couches profondes du système de
conduite. Ce n’est pas simple. De plus, même un néophyte de l’informatique peut
brancher une boîte de chiffrement entre son ordinateur et son modem externe.
Aujourd’hui, les trois types principaux de dispositifs matériels de chiffrement sur le
marché sont : des modules de chiffrement autonomes (qui effectuent des fonctions telles
que la vérification de mots de passe et la gestion des clefs pour les banques), des boîtes
dédiées au chiffrement pour les liens de communications et les cartes que l’on enfiche
dans les ordinateurs personnels.
Certaines boîtes de chiffrement sont conçues pour des types spéciaux de liens de com
munication, comme les boîtes de chiffrement pour liens T -1 qui sont conçues pour ne
pas chiffrer les bits de synchronisation. Il existe différentes boîtes pour les lignes de
communications synchrones et asynchrones. De nouvelles boîtes semblent accepter de
plus grandes vitesses (en bits par seconde) et sont plus versatiles.
Malgré cela, nombre de ces périphériques occasionnent des incompatibilités. Les ache
teurs doivent en être avertis et doivent bien connaître leurs besoins particuliers, sinon
ils se retrouvent propriétaires d ’un équipement de chiffrement qui n’arrive pas à effec
tuer la tâche demandée. Faites attention aux restrictions quant au type de matériel,
au système de conduite, aux programmes d ’application, au réseau, etc.
Les cartes chiffreuses P C chiffrent en général tout ce qui est écrit sur le disque dur et
peuvent également être configurées pour chiffrer tout ce qui est écrit sur des disquettes
ou sur les ports séries. Ces cartes ne sont pas blindées contre les rayonnements électro
magnétiques ou les interférences de signaux, puisque cela n’a pas de sens de protéger
les cartes si l’ordinateur ne l’est pas.
De plus en plus de sociétés commencent à mettre du matériel de chiffrement dans leurs
équipements de communication. Des téléphones sûrs, des fax sûrs et des modems sûrs
sont tous disponibles.
La gestion interne des clefs de ces périphériques est en général sûre, bien qu’il existe
autant de schémas que de vendeurs d’équipement. Certains schémas sont mieux adaptés
à une situation qu’à une autre, et les acheteurs doivent savoir d’une part quel type de
gestion des clefs est incorporé dans la boîte de chiffrement et d’autre part ce qu’ils
doivent fournir par eux-mêmes.
Chiffrement logiciel
Tout algorithme de chiffrement peut être réalisé en logiciel. Les désavantages sont la
vitesse, le coût et la facilité de modification (ou de manipulation). Les avantages sont
la flexibilité et la portabilité, la facilité d ’utilisation et la facilité de mise à jour. Les
algorithmes écrits en C à la fin de cet ouvrage peuvent être réalisés, modulo des petites
modifications, sur n’importe quel ordinateur. Ils peuvent être incorporés dans de plus
grandes applications comme les programmes de communications ou les traitements de
texte.
Les logiciels de chiffrement sont populaires et disponibles pour tous les systèmes de
conduites majeurs. Ils sont destinés à protéger des fichiers individuels : l’utilisateur
doit généralement chiffrer et déchiffrer des fichiers spécifiques. Il est important que la
gestion des clefs soit sûre : les clefs ne devraient pas être stockées sur le disque n’importe
où (ou même écrites dans une zone mémoire qui peut être recopiée sur le disque par la
gestion de mémoire virtuelle). Les clefs et les fichiers non chiffrés doivent être effacés
après chiffrement. Nombre de programmes sont négligents à ce propos et l’utilisateur
doit choisir prudemment.
Bien sûr, Martin peut toujours remplacer le logiciel de chiffrement par autre chose. Mais
pour la plupart des utilisateurs, ce n’est pas un problème. Si Martin peut s’introduire
dans nos bureaux et modifier nos programmes de chiffrement, il peut aussi installer une
caméra cachée dans le mur, mettre le téléphone sur écoute, et un détecteur T E M P E S T
dans la rue. Si Martin est aussi puissant, l’utilisateur a alors perdu le jeu avant même
qu’il n’ait commencé.
10.6 Compression, codage et chiffrement

Utiliser un algorithme de compression de données avec un algorithme de chiffrement
est logique pour deux raisons :
- La cryptanalyse s’appuie sur l’exploitation de redondances dans le texte en clair ;

compresser un fichier avant de le chiffrer réduit ces redondances.
- Le chiffrement prend du temps ; compresser un fichier avant de le chiffrer accélère

le processus tout entier.
La chose importante dont il faut se souvenir est de compresser avant de chiffrer. Si

l’algorithme de chiffrement est bon, le texte chiffré ne sera pas compressible ; il ressem
blera à des données aléatoires. (Ceci est un bon test d’un algorithme de chiffrement ;
si le texte chiffré peut être compressé, alors l’algorithme n’est probablement pas très
bon.)
Si vous voulez ajouter tout type de codage de transmission ou de détection d’erreur et
de récupération, n’oubliez pas de l’ajouter après le chiffrement. S’il y a du bruit dans la
voie de communication, les propriétés d ’extension d ’erreur du déchiffrement ne feront
qu’amplifier ce bruit. La figure 10.3 résume ces étapes.
10.7 Détection du chiffrement 241
F ig . 10.3 - Chiffrement avec compression et contrôle d’erreur
10.7 Détection du chiffrement

Comment Estelle peut-elle détecter un fichier chiffré? Elle est dans l’espionnage, alors
c’est une question importante. Imaginez qu’elle espionne un réseau où les messages
fusent de tous les côtés à des vitesses élevées ; elle doit sélectionner les plus intéressants.
Les fichiers chiffrés sont certainement intéressants, mais comment peut-elle savoir qu’ils
sont chiffrés?
En général, elle s’appuie sur le fait que les programmes de chiffrement les plus popu
laires ont des en-têtes bien définies. Les messages de courrier électronique chiffrés avec
soit PE M soit P G P (voir § 24.10 et § 24.12) sont faciles à identifier pour cette raison.
D’autres chiffreurs de fichier produisent juste un fichier de texte chiffré de bits appa
remment aléatoires. Comment peut-elle le distinguer d’un autre fichier avec des bits
apparemment aléatoires? Il n’y a pas de méthode infaillible, mais Estelle peut essayer
un certain nombre de choses :
- Examiner le fichier. Le texte A S C II est facilement décelable. D ’autres formats

de dossier, tels que T IF F , TeX , C, P o s t c r i p t , facsimile G3 ou M i c r o s o f t
E x c e l ont des caractéristiques standards identifiables. Un code exécutable est
aussi détectable. Les fichiers U N IX ont souvent des « nombres magiques » qui
peuvent être détectés.
- Essayer de décompresser le fichier en utilisant les algorithmes de compression les

plus connus. Si le fichier est compressé (et non chiffré), cela devrait donner le
fichier original.
- Essayer de compresser le fichier. Si le fichier est du texte chiffré (et que l’algo
rithme est bon), alors la probabilité que le fichier puisse être compressé à un
degré appréciable par une compression d ’usage général est faible. (Par « à un
degré appréciable », j ’entends plus de 1 ou 2 pourcents.) Si c’est quelque chose
d’autre (une image binaire ou un fichier de données binaires, par exemple) cela
peut probablement être compressé.
Tout fichier qui ne peut être compressé et qui ne l’est pas déjà est probablement du
texte chiffré. (Bien entendu, il est toujours possible de faire un texte chiffré spécifique
qui soit compressible.) Identifier l’algorithme est beaucoup plus dur. Si l’algorithme
est bon, vous ne pourrez pas. S’il a quelques petites altérations, il peut être possible
de reconnaître ces altérations dans le fichier. Néanmoins, les altérations devront être
assez significatives ou le fichier assez gros afin que cela puisse marcher.
10.8 Cacher du texte chiffré dans du texte

chiffré
Alice et Bernard se sont envoyés des messages chiffrés tout au long de l’année. Estelle les
a tous récupérés, mais elle ne peut déchiffrer aucun d ’entre-eux. Finalement, la police
secrète se lasse de tous ces textes chiffrés illisibles et arrête la paire. « Donnez-nous vos
clefs de chiffrement », demandent-ils. Alice et Bernard refusent, puis ils aperçoivent un
appareil de torture. Que peuvent-ils faire?
Ne serait-il pas agréable de pouvoir chiffrer un fichier de manière à ce qu’il y ait deux
déchiffrements possibles, chacun avec une clef différente? Alice pourrait chiffrer un vrai
message vers Bernard avec l’une des clefs et un message banal avec l’autre. Si Alice se
faisait arrêter, elle pourrait livrer la clef du message banal et garder la vrai clef secrète.
La façon la plus simple de faire ceci est avec les masques jetables. Soit Ad le texte en
clair, £ le texte en clair leurre, C le texte chiffré, K la vrai clef et K ' la clef leurre.
Alice chiffre Ad :
Ad © K = C
Alice et Bernard partagent K , Bernard peut donc déchiffrer C :
C@K = M
Si la police secrète les force à leur livrer leur clef, ils ne livrent pas K , mais à la place :
K' = C© £
La police obtient alors le texte en clair leurre :
C© K’ = £
Comme ce sont des masques jetables et que K est totalement aléatoire, il n ’y a pas de
moyen de prouver que K ' n’était pas la bonne clef. Pour rendre les choses encore plus
convaincantes, Alice et Bernard devraient concocter des messages leurres moyennement
compromettants pour les substituer aux messages réels vraiment compromettants. Une
paire d ’espions israéliens l’ont fait une fois.
Alice pourrait prendre Ad et le chiffrer avec son algorithme préféré et sa clef K pour
obtenir C. Puis elle prend C et le combine par ou exclusif avec un bout de texte en clair
mondain (« Ici Pans » par exemple) pour obtenir K '. Elle stocke C et la combinaison
par ou exclusif sur son disque dur. Maintenant, si la police secrète l’interroge, elle
peut expliquer qu’elle est une cryptographe amateur et que K ' est simplement un
masque jetable pour C. La police pourrait suspecter quelque chose, mais à moins qu’elle
connaisse K , elle ne peut pas prouver que l’explication d ’Alice est fausse.
Une autre méthode consiste à chiffrer Ad avec un algorithme à clef secrète K , et £ avec
K '. Intercalez les bits (ou octets) des textes chiffrés pour faire le texte chiffré final. Si
la police secrète demande la clef, Alice lui donne K ' et dit que les bits (ou octets)
alternés sont des bruits aléatoires pour décourager toute cryptanalyse. Le fait est que
cette explication est si peu plausible que la police secrète ne la croira probablement
pas (surtout maintenant qu’elle est suggérée dans ce livre).
10.9 Destruction d’information 243
Une meilleure manière est qu’Alice crée un message leurre, £ , tel que A4 et £ mis bout
à bout et compressés soient à peu près de la taille de £ . Appelez cet enchaînement A i'.
Alice chiffre alors A i' avec tout algorithme qu’elle partage avec Bernard pour obtenir
C. Puis elle envoie C à Bernard. Bernard déchiffre C pour obtenir A i', puis A i et £.
Ensuite, ils calculent tous les deux
C® L — K'
Ce K ' devient le masque jetable leurre qu’ils utiliseront si la police secrète fait irruption.
Alice doit transmettre £ afin que son alibi et celui de Bernard coïncident.
Une autre méthode est qu’Alice prenne un message banal et le passe par un code
correcteur d’erreur. Puis elle peut introduire des erreurs qui correspondent au message
secret chiffré. A la réception, Bernard peut extraire les erreurs pour reconstruire le
message secret et le déchiffrer. Il peut aussi utiliser le code correcteur d’erreur pour
retrouver le message banal. Alice et Bernard auront du mal à expliquer à la police
secrète pourquoi ils obtiennent constamment un taux d ’erreur de bits de 30 pourcents
sur un réseau pourtant sans bruit, mais dans certaines circonstances, ceci peut marcher.
Enfin, Alice et Bernard peuvent utiliser des canaux subliminaux dans leurs algorithmes
de signature digitale (voir § 4.2 et § 23.3). C ’est indétectable, ça marche très bien mais
a le défaut de n’autoriser qu’environ 20 caractères de texte subliminal par l’envoi de
message banal signé. Ce n’est bon que pour l’envoi de clefs.
10.9 Destruction d’information

Quand vous détruisez un fichier sur la plupart des ordinateur, le fichier n’est pas
réellement détruit. La seule chose qui est détruite est l’entrée dans le fichier d’index
du disque, qui indique à la machine où se trouve le fichier. Beaucoup de vendeurs de
logiciel ont fait fortune en vendant des logiciels de récupération de fichiers après qu’ils
furent détruits.
Il y a encore un autre motif d ’inquiétude: la mémoire virtuelle implique que votre
ordinateur peut lire et écrire la mémoire vers le disque à tout instant. Même si vous
ne le sauvez pas, vous ne savez jamais quand un document sensible est envoyé sur le
disque. Ce qui veut dire que même si vous ne sauvegardez jamais vos données en clair,
votre ordinateur pourrait le faire pour vous. Les programmes de compression au niveau
du disque comme « Stacker » et « DoubleSpace » peuvent rendre encore plus difficile la
prévision de la manière avec laquelle, et de l’endroit où, l’information est stockée sur
le disque.
Pour effacer un fichier de manière à ce que ces logiciels ne puissent pas les reconstituer,
vous devez écrire physiquement sur chaque bit du fichier sur le disque. D ’après le
Centre National de Sécurité Informatique américain (« National Computer Security
Center ») [1149] :
« La réécriture est le procédé par lequel des données non secrètes sont
écrites dans des zones de stockage qui contenaient auparavant des données
sensibles ... Pour purger le ... support de stockage, le D o D (le Département
de la Défense américaine) requiert la réécriture avec un motif, puis son
complément et finalement un autre motif ; par exemple réécrivez première
ment avec 0011 0101, suivi de 1100 1010 et ensuite avec 1001 0111. Le
Chapitre 10 Utilisation des algorithmes
nombre de réécritures dépend du type du support de stockage, parfois de

sa sensibilité, et parfois des requis du D oD sur certains composants. Dans
tous les cas, une purge n’est pas complète avant qu’une réécriture finale
soit faite avec des données non secrètes. »
Vous aurez peut-être à effacer des fichiers, voire des disques entiers. Vous devrez aussi
effacer tout l’espace inutilisé de votre disque dur.
La plupart des logiciels qui prétendent réaliser le standard du D oD réécrivent trois fois :
une fois avec uniquement des 1, ensuite avec uniquement des 0 et finalement avec un
motif répétitif de 1-0. Etant donné mon niveau général de paranoïa, je recommande de
réécrire un fichier détruit sept fois : la première fois avec uniquement des 1, la seconde
avec uniquement des 0 et les 5 autres fois avec un générateur de séquence pseudo
aléatoires cryptographiquement sûr. Des développements récents au N IST avec des
microscopes à effet tunnel suggèrent que même cela pourrait ne pas être suffisant.
Honnêtement, si vos données ont tant de valeur, considérez qu’il est « impossible » de
les effacer complètement d ’un support magnétique. Brûlez ou déchiquetez le support ;
il est moins onéreux d’acheter un nouveau support que de perdre vos secrets.
Troisième partie
Algorithmes cryptographiques
Chapitre 11
Rudiments mathématiques
11.1 Théorie de l’information

La théorie moderne de l’information fut définie pour la première fois par Claude
Elmwood S h a n n o n [1437, 1438]. Ces articles ont été réédités récemment par IEEE
Press [1440]. Pour un bon traitement mathématique du sujet, consultez [595]. Dans
cette section, je n’aborderai que quelques sujets importants.
Entropie et incertitude
La théorie de l’information définit la q u a n t i t é d ’ i n f o r m a t i o n d ’un message comme
le nombre minimal de bits nécessaires pour coder toutes les significations possibles de
ce message. Par exemple, le champ « jour de la semaine » dans une base de données
ne contient pas plus de 3 bits d’information, parce que l’information peut être codée
avec 3 bits :
000 = dimanche
001 = lundi
010 = mardi
011 = mercredi
100 = jeudi
101 = vendredi
110 = samedi
Si cette information était représentée par les chaînes de caractères ASCII correspon
dantes, cela prendrait plus de place mémoire mais cela ne contiendrait pas plus d’infor
mation. De façon similaire, le champs « sexe » de la base de données contient seulement
1 bit d’information, bien qu’il donne l’impression de devoir être stocké comme l’une
des deux chaînes de 5 caractères ASCII « homme » ou « femme ».
Formellement, la quantité d’information dans un message M est mesurée par
l’e n t r o p i e d’un message, dénotée H (M ). L ’entropie d’un message indiquant le sexe est
de 1 bit ; l’entropie d’un message indiquant le jour de la semaine est un tout petit peu
moins que 3 bits. En général, l’entropie d ’un message est log2 n, où n est le nombre de
significations possibles. Cela suppose que toutes les significations sont équiprobables.
S48 Chapitre 11 Rudiments mathématiques
L’entropie d’un message mesure également son i n c e r t i t u d e . C ’est le nombre de bits

de texte en clair qui doivent être retrouvés pour retrouver le texte en clair en entier
à partir du texte chiffré. Par exemple, si le bloc de texte chiffré « QHP*5 » a pour
texte en clair soit « homme » soit « femm e », alors l’incertitude du message est de 1. Un
cryptanalyste doit découvrir un seul bit bien choisi pour retrouver le message.
Taux du langage
Pour un langage donné, le t a u x d u l a n g a g e est
r = H ( M ) /N
où N est la longueur des messages. Le taux de l’anglais courant prend plusieurs valeurs
entre 1 bit et 1,5 bit par lettre, pour des grandes valeurs de N . Dans son livre [1439],
S h a n n o n annonce que l’entropie dépend de la longueur du texte. Plus précisément,
il indique un taux de 2,3 bit par lettre pour des bribes de 8 lettres, mais le taux
tombe entre 1,3 et 1,5 bits par lettre pour des bribes de 16 lettres. Thomas C o v e r a
trouvé, avec des techniques de théorie des jeux, une entropie de 1,3 bits par lettre1.
Le t a u x a b s o l u d’un langage est le nombre maximal de bits qui peuvent être codés
par chaque caractère, en faisant l’hypothèse que toutes les séquences de caractères sont
équiprobables. S’il y a L caractères dans le langage, le taux absolu est :
R = log2 L
C ’est l’entropie maximale des caractères isolés.

Pour l’anglais, avec 26 lettres, le taux absolu est log2 26 = 4,7 bits par lettre. Il n’est
pas surprenant que le taux effectif de l’anglais soit nettement inférieur au taux absolu :
l’anglais est une langue fortement redondante.
La r e d o n d a n c e d’un langage, notée D , est définie par :
D — R —r
Étant donné que le taux de l’anglais est de 1,3, la redondance est de 3,5 bits par lettre2.
Cela veut dire que chaque caractère apporte 3,5 bits d ’information redondante.
Un message ASCII qui n’est rien d ’autre que de l’anglais écrit n’a que 1,2 bit d ’infor
mation par 8 bits du message. Cela veut dire qu’il y a alors 6,8 bits de redondance, ce
qui donne une redondance globale de 0,85 bit d ’information par bit de texte ASCII et
une entropie de 0,15 bit d ’information par bit de texte ASCII. Le même message codé
par le système B A U D O T , à 5 bits par caractère, a une redondance de 0,76 bit et une
entropie de 0,34 bit par bit de texte B A U D O T . La prise en compte des blancs, de la
ponctuation, des nombres et de la mise en page modifierait ces résultats.
Sécurité d’un cryptosystème

S h a n n o n a défini un modèle mathématique précis de ce que l’on peut entendre par
un cryptosystème sûr. Le but des cryptanalystes est de déterminer la clef K , le texte
1. J ’utiliserai ce tau x d e 1,3 dans ce livre.

2. N ote du traducteu r: d ’après [240], la redondance d e la langue française est un petit peu plus
élevée.
11.1 Théorie de l’information 249
en clair A4, ou les deux. Toutefois, ils peuvent se contenter de certaines informations
probabilistes concernant A4 si c’est du son numérisé, si c ’est un texte en allemand, si
ce sont des données pour un tableur, ou quelque chose d ’autre.
Pour la plupart des cryptanalysés du monde réel, les cryptanalystes ont quelques in
formations probabilistes concernant A4 avant de commencer. Ils connaissent probable- .
ment le langage du texte en clair. Ce langage a une certaine redondance associée. Si
c’est un message destiné à Bernard, il commence probablement par « C h e r B o b , ».
Certainement, « C h e r B o b , » est plus probable que « e 8 T & g [,m ». Le but de la cryp
tanalyse est, par analyse, de modifier les probabilités associées avec tous les textes en
clair possibles. Finalement un texte en clair considéré comme certain (ou au moins,
très probable) émergera du paquet des textes en clair possibles.
Il existe quelque chose que l’on peut appeler cryptosystème à c o n f i d e n t i a l i t é p a r
f a i t e . C ’est un cryptosystème dans lequel le texte chiffré ne fournit pas la moindre
information concernant le texte en clair (excepté peut-être sa longueur). S h a n n o n
postula que ce n’était possible que si le nombre de clefs possibles est au moins aussi
grand que le nombre de messages possibles. En d ’autres termes, la clef doit être au
moins aussi longue que le message lui-même et aucune clef ne peut être réutilisée. En
d’autres termes encore, le masque jetable (voir § 1.5) est le seul cryptosystème qui
assure une confidentialité parfaite.
La confidentialité parfaite mise à part, le texte chiffré donne quelques informations sur
le texte en clair correspondant. C ’est inévitable. Un bon algorithme cryptographique
minimisera cette information ; un bon cryptanalyste exploite cette information pour
retrouver le texte en clair.
Les cryptanalystes utilisent la redondance naturelle du langage pour réduire le nombre
possible de textes en clair. Plus le langage est redondant, plus simple il est à cryp
tanalyser. C ’est la raison pour laquelle de nombreuses réalisations cryptographiques
concrètes utilisent avant de chiffrer un programme de compression pour réduire la
taille du texte. La compression réduit la redondance du message et aussi le travail à
fournir pour chiffrer et déchiffrer.
L’entropie d’un cryptosystème est une mesure de la taille de l’ensemble des clefs. Elle
est approchée par le logarithme en base 2 du nombre de clefs :
H (K ) = log2(nombre de clefs)
Un cryptosystème avec une clef de 64 bits a une entropie de 64 ; un cryptosystème avec

une clef de 56 bits a une entropie de 56. En général, plus grande est l’entropie, plus
difficile il est de casser le cryptosystème.
Distance d’unicité
Pour un message de longueur n, le nombre de clefs différentes qui traduiront un message
chiffré en un texte en clair intelligible dans un même language est donné par la formule
suivante [714, 102] :
2H ( K ) ~ n D _ ^
S h a n n o n [1438] a défini la d i s t a n c e d ’ u n i c i t é , U, appelée aussi le point d ’unicité,

comme une approximation de la quantité de texte chiffré telle que la somme des infor
mations réelles (entropie) dans le texte en clair correspondant et de l’entropie de la clef
de chiffrement soit égale au nombre de bits de texte chiffré utilisés. Il montra alors que
250 Chapitre 11 Rudiments mathématiques
des textes chiffrés plus longs que cette valeur sont raisonnablement certains de n’avoir
qu’un seul déchiffrement plausible. Des textes chiffrés significativement plus courts
que cela ont des chances d’avoir plusieurs déchiffrements également valables et donc
augmentent la sécurité, car il est difficile à l’attaquant de choisir le bon déchiffrement.
Pour la plupart des cryptosystèmes à clef secrète, la distance d’unicité est définie comme
l’entropie du cryptosystème divisée par la redondance du langage :
U = H (K)/D .
La distance d’unicité, comme toute mesure d ’information statistique ou théorique, ne

fait pas de prédictions déterministes mais donne des résultats probabilistes. La distance
d ’unicité indique le minimum de texte chiffré pour lequel il est probable qu’il n’y ait
qu’un seul texte en clair plausible correspondant quand une attaque exhaustive est
montée. En général, plus grande est la distance d’unicité, meilleur est le cryptosystème.
Pour le DES, avec une clef de 56 bits, et un message en anglais codé en ASCII,
la distance d’unicité est d ’environ 8,2 caractères ASCII, ou 66 bits. Le tableau 11.1
donne les distances d ’unicité pour différentes longueurs de clef. Les distances d’unicité
de quelques cryptosystèmes classiques sont donnés dans [448].
T a b . 11.1 - Distances d’unicité de texte ASC II chiffré avec différentes longueurs de

clef. ______________________________________________
Longueur de la clef Distance d ’unicité
(en bits) (en nombre de lettres)
40 5,9
56 8,2
64 9,4
80 11,8
128 18,8
256 37,6
La distance d’unicité n’est pas une mesure de la quantité de texte chiffré qu’il faut pour
la cryptanalyse mais bien de la quantité de texte chiffré nécessaire pour qu’il n’y ait
qu’une solution raisonnable à la cryptanalyse. Un cryptosystème peut être inviolable
par calcul même si théoriquement il est possible de le casser avec une faible quantité de
texte chiffré3. La distance d ’unicité est inversement proportionnelle à la redondance.
Quand la redondance approche de zéro, même un chiffrement trivial peut être inviolable
par une attaque à texte chiffré seulement.
S h a n n o n définit un cryptosystème dont la distance d ’unicité est infinie comme un
système à c o n f i d e n t i a l i t é i d é a l e . Remarquez qu’un cryptosystème idéal n’est pas
forcément un cryptosystème parfait, bien qu’un cryptosystème parfait soit nécessai
rement un cryptosystème idéal. Si un cryptosystème offre une confidentialité idéale,
même une cryptanalyse réussie laissera une incertitude quant à savoir si le texte dé
codé est le bon texte.
3. La théorie de la c r y p t o g r a p h i e r e la t iv is é e , bien qu ’ésotérique et peu pratique, est appropriée

ici [233, 234, 235, 236, 237, 238].
11.2 Théorie de la complexité 251
Théorie de l’information en pratique

Bien que ces concepts aient une grande valeur théorique, la cryptanalyse réelle se base
rarement là-dessus. Trop petit, la distance d’unicité reste aussi peu sûre que si elle
est grande. Peu d’algorithmes pratiques sont totalement imperméables à l’analyse;
toutes sortes de caractéristiques peuvent servir de bras de levier pour casser certains
messages chiffrés. Toutefois, des considérations sur la théorie de l’information sont
parfois utiles, par exemple pour déterminer l’intervalle de changement de clefs pour
un algorithme déterminé. Les cryptanalystes utilisent une variété de tests statistiques
basés sur la théorie de l’information afin de mener leurs analyses dans les directions les
plus efficaces. Malheureusement, la plupart des publications concernant la théorie de
l’information appliquée à la cryptanalyse demeurent secrètes, comme le compte-rendu
du séminaire de 1940 d ’Alan T u r i n g .
Confusion et diffusion
Les deux techniques de base pour gommer les redondances dans un texte en clair sont
selon S h a n n o n la confusion et la diffusion [1438].
La c o n f u s i o n gomme les relations entre le texte en clair et le texte chiffré. Elle évite
l’analyse du texte chiffré par recherche de redondances et de motifs statistiques. Le
moyen le plus simple de réaliser cela est la substitution. Un chiffre à substitution
simple, tel le système à décalage de Jules César, est un système dans lequel chaque
lettre identique du texte en clair est remplacée par une même autre lettre dans le
texte chiffré. Les chiffres à substitution modernes sont plus compliqués : un long bloc
de texte en clair est remplacé par un autre bloc de texte chiffré et le mécanisme de
substitution change avec chaque bit du texte en clair. Ce type de substitution n’est
pas nécessairement suffisant ; le système allemand E N IG M A est un algorithme de
substitution complexe qui fut cassé durant la Seconde Guerre mondiale.
La d i f f u s i o n disperse la redondance du texte en clair en la répartissant dans le texte
chiffré. Un cryptanalyste qui recherche ces redondances aura plus de difficultés à les
trouver. Le moyen le plus simple de provoquer la diffusion est la transposition (ap
pelée aussi p e r m u t a t i o n ) . Un chiffre à transposition simple, telle la transposition
en colonnes, réarrange simplement les lettres du texte en clair. Les chiffres modernes
réalisent ce type de permutation, mais ils emploient d’autres formes de diffusion qui
peuvent diffuser les parties du message à travers la totalité du message.
Les chiffres en continu se basent sur la confusion seulement. Les algorithmes par blocs
utilisent à la fois la confusion et la diffusion. En règle générale, la diffusion seule est
facile à casser (bien que la double transposition résiste mieux que beaucoup d’autres
méthodes faisables avec un papier et un crayon).
11.2 Théorie de la complexité

La théorie de la complexité fournit une méthodologie pour analyser la complexité
de calcul de différents algorithmes et techniques cryptographiques. Elle compare les
algorithmes et les techniques cryptographiques pour déterminer leur niveau de sécurité.
La théorie de l’information nous apprend que tous les algorithmes cryptographiques
(excepté les masques jetables) peuvent être cassés. La théorie de la complexité nous
apprend s’ils peuvent être cassés avant la fin du monde...
Complexité des algorithmes

La complexité d’un algorithme est déterminée par la puissance de calcul nécessaire
pour l’exécuter. La complexité calculatoire d’un algorithme est mesurée par deux pa
ramètres : T (pour la c o m p l e x i t é e n t e m p s ) et S (pour la c o m p l e x i t é e n e s p a c e ,
ou mémoire nécessaire). En général T et 5 sont tous deux exprimés en fonction de n,
où n est la taille de l’entrée4.
En général, la complexité calculatoire d’un algorithme est exprimée à l’aide de ce que
l’on appelle la notation « grand O » : l’ordre de grandeur de la complexité du calcul
à savoir le terme de la fonction de complexité qui croît le plus vite avec n ; toutes les
constantes et les termes d ’ordre inférieur sont ignorés. Par exemple, si la complexité en
temps d ’un algorithme donné est de 4n2 + 7 n + 12, alors la complexité en calcul sera
de l’ordre de n2, ce qui s’exprime aussi par 0 ( n 2).
De cette façon, la mesure de la complexité en temps est indépendante du système. Vous
n’avez pas à connaître le timing exact des différentes instructions ou le nombre de bits
utilisés pour représenter les différentes variables ou même la vitesse du processeur.
Tel ordinateur peut être une fois et demi plus rapide qu’un autre ou tel autre peut
avoir un chemin de donnée deux fois plus large, l’ordre de grandeur de la complexité
d ’un algorithme reste le même. Ce n’est pas de la triche ; quand vous manipulez des
algorithmes aussi complexes que ceux décrits dans cet ouvrage, les autres informations
sont en général négligeables par rapport à l’ordre de grandeur de la complexité.
Cette notation vous permet de voir la façon dont les besoins en temps et en espace
évoluent avec la taille des entrées. Par exemple, si T = (D(n), alors doubler la taille de
l’entrée double le temps de calcul de l’algorithme. Si T = 0 ( 2 n), alors ajouter 1 bit
à la taille de l’entrée double le temps de calcul de l’algorithme (à un facteur constant
près).
En général, les algorithmes sont classés d’après leur complexité en temps ou en espace.
Un algorithme est c o n s t a n t si sa complexité est indépendante de n : 0 (1 ). Un algo
rithme est l i n é a i r e , 0(n), si sa complexité croît linéairement avec n. Les algorithmes
peuvent être aussi q u a d r a t i q u e s , c u b i q u e s , etc. Tous ces algorithmes sont p o l y n o
m i a u x : leur complexité est 0 ( n ‘ ) où t est une constante. La classe des algorithmes
qui ont une complexité en temps polynomiale sont appelés algorithmes p o l y n o m i a u x
e n te m p s.
Les algorithmes dont la complexité est 0 ( t ^ n^), où t est une constante et f(n) est
une certaine fonction polynomiale de n, sont appelés e x p o n e n t i e l s . Ceux dont la
complexité est 0 { t ^ n^), où t est une constante et /( n ) est plus que constante mais
moins que linéaire, sont appelés s u p e r p o l y n o m i a u x .
Idéalement, les cryptographes voudraient pouvoir dire que tout algorithme de cassage
pour leurs chiffres doivent être exponentiels en temps. En pratique, les affirmations
les plus fortes qui peuvent être faites, étant donné l’état de l’art de la théorie de la
complexité, sont de la forme « tout algorithme de cassage connu pour ce chiffre a
une complexité superpolynomiale en temps ». C ’est-à-dire que, pour les chiffres utili
sés en pratique, les algorithmes de cassage que nous connaissons ont une complexité
4. Il y a d ’ autres mesures de la com plexité : le nom bre de bits aléatoires, le débit de com m unications,
la quantité de données, etc.
superpolynomiale en temps mais qu’il n’est pas encore possible de prouver qu’on ne
pourra jamais découvrir un algorithme de cassage polynomial en temps. Les avancées
en théorie de la complexité permettront peut-être un jour de concevoir des chiffres
pour lesquels l’existence d’algorithmes de cassage polynomiaux en temps pourra être
écartée mathématiquement avec certitude.
Quand n croît, la complexité en temps d’un algorithme peut faire une énorme différence
quant à l’applicabilité de l’algorithme. Le tableau 11.2 montre les temps d ’exécution
de différentes classes d’algorithmes pour lesquels n vaut un million. Le tableau passe
sous silence les constantes et montre pourquoi il est raisonnable de les ignorer.
Tab. 11.2 - Temps de calcul pour différentes classes d’algorithmes
Classe Complexité Nombre d’opérations Temps pour 10

pour n = 106 opérations par seconde
Constants 0 (1 ) 1 1 ps
Linéaires 0 (n ) 106 1s
Quadratiques 0 ( n 2) 1012 11,6 j
Cubiques 0 ( n 3) 1018 32 000 années
Exponentiels 0 ( 2n) JQ301 030 10301 o°6 fois l’âge
de l’univers
En faisant l’hypothèse que l’unité de temps de votre ordinateur est la microseconde,

(lis), l’ordinateur peut effectuer un algorithme constant en une microseconde, un al
gorithme ünéaire en une seconde et un algorithme quadratique en 11,6 jours. Cela
prendrait 32000 ans pour exécuter l’algorithme cubique; ce qui n’est pas très pra
tique, mais dans ce cas-là l’univers existe encore, il serait possible pour un ordinateur
de fournir finalement une solution. Exécuter des algorithmes exponentiels est futile,
peu importe comment vous extrapolez la puissance de calcul, le traitement en parallèle
et l’aide d’extra-terrestres super-intelligents.
Prenez le problème de l’attaque exhaustive contre un cryptosystème. La complexité
en temps de cette attaque est proportionnelle au nombre de clefs possibles, qui est
une fonction exponentielle de la longueur de clef. Si n est la longueur de clef, alors
la complexité d ’une attaque exhaustive est 0 ( 2n). Le paragraphe 10.1 présente la
controverse autour de la clef de 56 bits au lieu de 112 bits pour le DES. La complexité
d’une attaque exhaustive contre une clef de 56 bits est 256 ; alors que contre une clef
de 112 bits la complexité est de 2112. Le premier résultat est à la limite du réalisable,
le deuxième est tout à fait hors de portée.
Complexité de problèmes
La théorie de la complexité classe aussi la complexité inhérente des problèmes, et
pas seulement la complexité d ’algorithmes particuliers utiüsés pour résoudre des pro
blèmes5. La théorie détermine les temps et espace minimaux nécessaires pour résoudre
l’instance la plus difficile du problème sur un ordinateur théorique connu sous le nom
de m a c h i n e d e T u r i n g . Il s’agit d ’une machine à états finis avec une mémoire en
5. Une excellente introduction du sujet est donnée dans [603, 214, 1236] ; voyez également [1102,
31, 741],
écriture et en lecture sous la forme d ’un ruban infini. Il s’avère que la machine de
Turing est un modèle réaliste du calcul.
Les problèmes qui peuvent être résolus avec des algorithmes polynomiaux en temps
sont appelés s o l u b l e s , parce qu’ils peuvent généralement être résolus en un temps
raisonnable pour des entrées de taille raisonnable6. Les problèmes qui ne peuvent
pas être résolus en temps polynomial sont appelés n o n s o l u b l e s , parce que calculer
leur solution devient rapidement impossible. Les problèmes non solubles sont parfois
appelés simplement d i f f i c i l e s . Ils le sont. Les problèmes qui peuvent être résolus par
des algorithmes exponentiels ou superpolynomiaux sont non solubles par calcul, même
pour des valeurs relativement petites de n.
Il y a pire. Alan T u r i n g a prouvé que certains problèmes étaient i n d é c i d a b l e s . Il
est impossible de concevoir un algorithme pour les résoudre, et certainement pas un
algorithme polynomial.
Les problèmes peuvent être rangés dans des classes de complexité qui dépendent de
la complexité de leurs solutions. La figure 11.1 montre les classes de complexité les
plus importantes et leurs liens présumés (malheureusement il n’y a pas beaucoup de
preuves mathématiques à ce propos).
F ig . 1 1 .1 - Classes de complexité
Tout en bas, la classe P contient tous les problèmes qui peuvent être résolus en temps
polynomial. La classe N P contient tous les problèmes qui peuvent être résolus en
temps polynomial sur une machine de Turing non déterministe. C’est une variante de
la machine de Turing normale qui devine les solutions. La machine devine une solution
d ’un problème— soit en faisant par chance une bonne hypothèse, soit en essayant toutes
les possibilités en parallèle— et vérifie son hypothèse en temps polynomial.
6. La définition exacte de « ra iso n n a b le » dépend des circonstances.

L’intérêt cryptographique de la classe N P réside en ceci: de nombreuses classes de

chiffres conventionnels peuvent être cassés en un temps non déterministe polynomial.
Etant donné un texte chiffré C, le cryptanalyste devine simplement un texte en clair X
et une clef k, et en un temps polynomial il exécute l’algorithme de chiffrement sur les
entrées X et k, et enfin vérifie si le résultat est égal à C. C ’est important théoriquement,
car cela donne une borne supérieure de la complexité pour la cryptanalyse des chiffres de
ces classes. Bien sûr, en pratique, c’est un algorithme en temps polynomial déterministe
que le cryptanalyste recherche. De plus, cet argument n’est pas applicable à toutes les
classes de chiffres et en particulier aux masques jetables — pour tout C, il y a de
nombreuses paires X , k qui donnent C quand on utilise l’algorithme de chiffrement
mais la plupart de ces X sont des textes en clair non légitimes sans aucun sens.
La classe N P contient la classe P parce que tout problème soluble en temps polynomial
sur une machine de Turing déterministe est aussi soluble en temps polynomial sur une
machine de Turing non déterministe, car l’étape de devinette peut tout simplement
être supprimée.
Si tous les problèmes N P sont solubles en temps polynomial sur une machine détermi
niste, alors P — N P . Bien qu’il semble évident que certains problèmes N P se montrent
nettement plus difficiles que d ’autres (une attaque exhaustive contre un chiffre vs
le chiffrement d’un bloc quelconque de texte en clair), il n’a jamais été prouvé que
P ^ N P (ou P = N P ). Toutefois, tous ceux qui travaillent en théorie de la complexité
soupçonnent qu’elles ne sont pas égales.
Plus étrange encore, il y a des problèmes spécifiques dans N P qui se révèlent aussi
difficiles que tout autre problème de même catégorie- C O O K [369] a prouvé que le
problème SA T (« étant donné une formule booléenne propositionnelle, y a-t-il un moyen
d’assigner des valeurs de vérité aux variables de telle manière que la formule soit
vraie ? ») est N P —co m p le t. Cela veut dire que, si SA T peut être résolu en temps
polynomial, alors P — N P . Inversement, si l’on peut prouver que tout problème dans
N P n ’a pas un algorithme déterministe polynomial en temps, cela démontrerait que
SAT n’admet pas non plus d’algorithme déterministe polynomial en temps. Il n’y a
donc pas de problème plus difficile que SA T dans N P .
Depuis que l’article de C O O K a été publié, un grand nombre de problèmes ont été
montrés équivalents à SA T ; des centaines d ’entre eux sont cités dans [370] et des
exemples sont donnés ci-dessous. Par extension, j ’appelerai ces problèmes également
N P —co m p le ts : c’est-à-dire, ils sont aussi difficiles que tout autre problème dans N P .
Si leur solvabilité en temps polynomial déterministe était déterminée, alors la question
P vs N P serait tranchée. Est-ce que P est égale à N P ? est la question centrale non
résolue de la théorie de la complexité et personne ne s’attend à avoir une réponse de si
tôt. Si quelqu’un démontrait que P — N P , alors la plus grande partie de cet ouvrage
serait inutile : comme je l’ai expliqué ci-dessus, de nombreuses classes de chiffres sont
trivialement cassables en temps polynomial non déterministe et si P = N P , ils sont
cassables par des algorithmes déterministes utilisables.
Plus haut dans la hiérarchie de la complexité on trouve P S P A C E . Les problèmes dans
P S P A C E peuvent être résolus dans un espace polynomial mais pas nécessairement en
temps polynomial. P S P A C E comprend N P mais il y a dans P S P A C E des problèmes
dont on pense qu’ils sont plus difficiles que N P . Bien sûr, ce n ’est pas non plus prouvé.
Il y a une classe de problèmes, appelés P S P A C E —com p lets, qui ont la propriété
suivante : si n’importe lequel d ’entre eux est dans N P alors P S P A C E = N P et si l’un
d’entre eux est dans P alors P S P A C E = P.

Et enfin, il y a une classe de problèmes appelés E X P T I M E . Ces problèmes sont
solubles en temps exponentiel. Les problèmes E X P T I M E —complets sont ceux qui
ne peuvent pas être résolus en temps déterministe polynomial. Il a été démontré que
P n’est pas égale à E X P T I M E .
Problèmes N P —complets
Michael G a r e y et David J o h n s o n ont rassemblé une liste de plus de 300 problèmes
N P —complets [603]. En voici seulement quelques-uns:
Le Problème du Commis Voyageur. Un commis voyageur doit visiter n villes

différentes et il n’a qu’un plein d ’essence (il ne peut donc parcourir qu’une
distance maximale). Existe-t-il un itinéraire qui lui permettrait de visiter
chaque ville une fois et une seule avec ce plein d ’essence?7
Le Problème du Groupement par trois. Soit n hommes et n femmes dans une
pièce ainsi que n membres du clergé (prêtres, rabbins, etc.) ; soit une liste
des groupements acceptables, qui consistent en un homme, une femme, et
un membre du clergé disposé à officier. Etant donné cette liste des triplets
possibles, est-il possible d ’arranger n groupements de telle manière que
chacun soit épouse quelqu’un, soit officie pour un mariage?
Le Problème 3-SAT. Soit une liste de n propositions logiques, chacune
comportant trois littéraux : (x A y) => z, (x A w) V ( ~ i z ) , ((->« A ->x) V (z A
(u V - æ ) ) ) => ( ( - i z A u ) V x), etc. Existe-t-il une assignation de valeurs de
vérité pour tous les littéraux qui satisfasse toutes les propositions?8
11.3 Théorie des nombres

Ce livre n’est pas un ouvrage sur la théorie des nombres, aussi je me contenterai
d ’ébaucher ici les quelques thèmes nécessaires à la bonne compréhension des chapitres
suivants. Si vous voulez approfondir votre connaissance de la théorie des nombres,
vous consulterez avantageusement les ouvrages suivants: [1436, 79, 1177, 16, 970, 682,
744, 422]. Pour la théorie des corps finis, mes deux livres préférés sont: [981, 1050].
Consultez également [95, 1157, 1158, 1067].
Congruences
Vous avez tous appris l’arithmétique modulo n 9 à l’école ; cela s’appelait Y arithmé
tique de l’horloge. Rappelez-vous les problèmes tels que:
« si Marc dit qu’il sera à la maison pour 10 heures et qu’il rentre 13

heures plus tard, à quelle heure rentre-t-il à la maison et quel est l’âge du
capitaine? »
7. C ’est une généralisation du problèm e d u Circuit H am iltonien — voir § 5.1.
8. C ’est un cas particulier d u problèm e S A T m entionné ci-dessus.
9. Les termes arithm étique des congruences, congruences et arithm étique m od u lo n, désignent tous
la mêm e chose.
11.3 Théorie des nombres 257
C’est de l’arithmétique modulo 12. 23 modulo 12 est égal à 11.
(1 0 + 1 3 ) mod 12 = 11.
Ce qui s’exprime aussi par « 23 et 11 sont équivalents modulo 12 ».
(10 + 13) = 11 (mod 12).
La notation a = b (mod n) indique que a = fe + kn pour un certain entier k. Si a et b

sont positifs et si b est plus petit que n, vous pouvez considérer que b est le reste de la
division de a par n. On a aussi la propriété que a et 6 donnent le même reste quand
ils sont divisés par n. Parfois, b est appelé le résidu de a modulo n. On dit aussi que
a est congru à b modulo n (le symbole s dénote une congruence). Ce ne sont que
différentes manières de dire la même chose.
L’ensemble des entiers de 0 à n — 1 forme ce que l’on appelle l’ensemble de tous
les résidus modulo n. Ce qui signifie que, pour tout entier quelconque a, son résidu
modulo n est un nombre compris entre 0 et n — 1 bornes comprises.
L’opération a mod n dénote le résidu de a. Ce résidu est un nombre entier compris
entre 0 et n — 1. Cette opération est parfois appelée la réduction modulo n. Par
exemple, 5 mod 3 = 2.
Attention, cette définition de « mod » peut être différente de celle qui est utilisée
dans certains langages de programmation. Par exemple, l’opérateur modulo du langage
Pascal fournit parfois un résultat négatif. Dans ce cas, le résultat est compris entre
—n~ 1 et n- 1. Dans le langage C, l’opérateur % fournit le reste de la division du premier
opérande par le deuxième ; ce résultat peut être négatif si l’un des opérandes est négatif.
Lorsque vous réalisez un algorithme de ce livre dans un langage de programmation pour
lequel l’opération modulo peut donner un résultat négatif, n’oubliez pas d’ajouter n
au résultat d ’une opération modulo si celui-ci est négatif.
Tout comme l’arithmétique classique, l’arithmétique modulo n jouit des propriétés de
commutativité, d ’associativité et de distributivité. De plus, lors d ’un calcul, la valeur
finale obtenue sera la même que vous appliquiez la réduction modulo n à chaque étape
intermédiaire ou que vous appliquiez celle-ci au résultat final seulement. Les formules
suivantes expriment formellement certaines de ces propriétés :
(a + b) mod n = ((a mod n) + (b mod n )) mod n

(a — b) mod n = ((a mod n) —(b mod n)) mod n
(a x b) mod n = ((a mod n) x (b mod n )) mod n
(a x (b + c)) mod n = (((a x 6) mod n) + ((a x c) mod n)) mod n.
En cryptographie, on fait un usage intensif de l’arithmétique modulo n. Celle-ci per

met de restreindre la taille de tous les résultats intermédiaires et de la valeur finale.
C’est indispensable, par exemple, pour le calcul de logarithmes discrets ou de racines
carrées qui sont des opérations très coûteuses en ressources de calcul (temps et es
pace mémoire). Pour un module n qui peut être représenté par k bits, le résultat de
toute addition, soustraction ou multiplication peut être représenté par au plus 2k bits.
Comme on peut appliquer la réduction modulo n pour toutes les étapes intermédiaires
d’un calcul, on ne devra jamais manipuler des nombres représentés par plus de 2k bits.
On peut ainsi, par exemple, calculer des exponentielles en arithmétique modulo n sans
engendrer des résultats intermédiaires démesurés.
Elever un nombre à une puissance entière modulo n,
ax mod n
se fait par une série de multiplications et de divisions, mais il existe des techniques pour
effectuer cela efficacement. Une de ces techniques consiste à minimiser le nombre de
multiplications modulo n ; une autre consiste à optimiser le calcul de la multiplication
modulo n. Comme l’arithmétique modulo n est distributive, il est plus efficace d ’entre
lacer les multiplications avec des réductions modulo n à chaque étape intermédiaire.
Pour les exemples qui suivent, cela peut ne pas sembler d ’une grande utilité, mais pour
des nombres de 200 bits c ’est essentiel.
Par exemple, si vous voulez calculer a8 mod n, n’utilisez pas l’approche simpliste qui
consiste à effectuer 7 multiplications suivies d ’une coûteuse réduction modulo n finale :
( a x a x a x a x a x a x a x a ) mod n.
Il est plus avantageux d ’effectuer 3 multiplications plus petites ainsi que 3 réductions
modulo n également plus petites :
((a2 mod n)2 mod n )2 mod n.
La même technique appliquée à une puissance 16e donne :
a16 mod n — ({(a2 mod n )2 mod n )2 mod n)2 mod n.
Calculer ax mod n quand x n ’est pas une puissance de 2 n’est qu’un tout petit peu
plus difficile. Illustrons cela pour x — 25. La première étape consiste à représenter x en
notation binaire (c’est-à-dire, comme une somme de puissances de 2). La représentation
binaire de 25 est 11001 et donc 25 = 24 + 23 + 2°. Ensuite, quelques transformations
élémentaires donnent :
a25 mod n
= (g x a8 x a 16) mod n
= (a x ((a2)2)2 x (((a 2)2)2)2) mod n
= ((((a 2 x a)2)2)2 x a) mod n
Par un arrangement judicieux de la mémorisation des résultats intermédiaires, il y a

moyen de n ’effectuer que 6 multiplications :
(((((((a 2 mod n ) x a) mod n )2 mod n)2 mod n )2 mod n) x a) mod n.
Cette technique de calcul s’appelle la so m m a tion en chaîne [864]. Elle utilise une
suite d’additions simple et évidente qui est basée sur la représentation binaire. Cela
peut être codée en C par la fonction suivante :
unsigned long modexp (unsigned long a, unsigned long x, unsigned long n) ■

ll.S Théorie des nombres 259
unsigned long s;
s = 1;
while(u) -[
if(x&l) /* x est-il impair ? */
s = (s*a)%n;
x»=l;
a = (a*a)%n;
}
return(s);
}
Une autre fonction, récursive, est la suivante :
unsigned long exp_rapide(unsigned long a, unsigned long x,

unsigned long n) {
unsigned long tmp;
if(x==l) return(a°/n) ;
if(l~(a&l)) {
tmp = exp_rapide(a,x»l,n) ;
return((tmp*tmp)%n);
>
else {
tmp = exp_rapide(a, (x-l)»l,n) ;
tmp = (tmp*tmp)%n;
tmp = (tmp*a)%n;
return(tmp);
>
}
Si k est le nombre de bits de l’exposant x, la technique précédente nécessite, en

moyenne, 1,5 x k opérations. Trouver la suite d ’opérations la plus courte possible est un
problème difficile (il a été prouvé qu’une telle suite contient au moins fc —1 opérations),
mais il n’est pas trop difficile de ramener le nombre d’opérations à 1,1 x k ou mieux
encore quand k est grand.
Il est possible de calculer efficacement des réductions modulo n utilisant toujours
le même n avec la méthode de Montgomery [1117]. Une autre méthode est
l’algorithme de Barrett [94]. Les performances de ces deux algorithmes et de celui
donné plus haut sont données dans [2] : l’algorithme que j ’ai présenté plus haut consti
tue le meilleur choix pour une seule réduction modulo n, l’algorithme de B a r r e t t est
le meilleur pour des petits arguments, et la méthode de M o n t g o m e r y est la meilleure
pour le calcul de puissances modulo n en général10.
L’inverse du problème de l’élévation de puissance est le calcul du logarithme discret.
Nous en reparlerons bientôt (voir § 9.6).
10. La m éthode de M o n t g o m e r y peut aussi tirer avantage des petites puissances en utilisant ce qui
s’appelle de l ’arithm étique m ixte.
Nombres premiers
Un nombre premier est un nombre entier, strictement plus grand que 1, dont les seuls
facteurs sont 1 et lui-même : aucun autre nombre ne le divise exactement. Le nombre
2 est un nombre premier, de même que: 73, 2 521, 2 365 3 4 7 7 3 4 3 3 9 , et 2 756839 — 1. Un
nombre qui n’est pas premier est dit composé. Il y a une infinité de nombres premiers.
En cryptographie, on utilise souvent de très grands nombres premiers (de 512 bits ou
plus).
Evengelos K r a n a k i s est l’auteur d ’un excellent livre sur la théorie des nombres, les
nombres premiers, et leur application en cryptographie [896]. Paulo R lB E N B O lM a écrit
deux excellents ouvrages de référence sur les nombres premiers en général [1318, 1319].
Plus grand commun diviseur

Deux nombres sont premiers entre eux quand il n’ont d’autre facteur en commun
que 1. En d’autres termes, si le plus grand commun diviseur (P G C D en abrégé)
de a et n est 1, alors a et n sont dits premiers entre eux, ce qui s’écrit :
pgcd(a,n) = 1.
Les nombres 15 et 28 sont premiers entres eux ainsi que 13 et 500, tandis que 15 et
27 ne le sont pas (3 est un facteur commun plus grand que 1). Un nombre premier est
premier par rapport à tous les autres nombres excepté ses propres multiples.
La méthode la plus simple pour calculer le plus grand commun diviseur de deux
nombres est donnée par l’algorithme d ’Euclide. Cet algorithme est décrit dans les
« Eléments d’Euclide » écrits 300 ans avant J.-C. E u c l i d e ne l’a pas inventé. Les his
toriens pensent que l’algorithme en question pourrait être plus vieux de 200 ans. C ’est
un des plus vieux algorithmes non triviaux connus et nous nous en servons encore de
nos jours. K n u t h décrit cet algorithme et quelques variantes modernes [864].
En C :
/* calcule le plus grand commun diviseur de x et y */
int pgcdfint x, int y)
f
int g;
if (x < 0)
x = -x;
if (y < 0)
y = -y ;
if (x + y == 0)
ERR0R j
g = y;
whilefx > 0) {
g = x;
x = y 7. x;
y = g;
>
return(g);
>
ll.S Théorie des nombres 261
Cet algorithme peut être généralisé pour calculer le PGCD d’un tableau de m nombres :
/ * c a lc u le l e plu s grand commun d iv is e u r de x l , x2, xm * /

in t m u ltip le _ p g cd (in t m, in t *x)
{
s iz e _ t i ;
in t g;
if(m < 1)
re tu r n (O );
g = x [0] ;
f o r ( i = l ; i<m; + + i) {
g = p g cd (g , x [ i ] ) ;
/ * o p tim isa tio n car pour des x [ i ] a lé a t o ir e s , g==l 60% du temps * /
i f (g == 1)
re tu rn (l);
>
r e t u r n (g );
>
Inverses modulo n
Vous vous rappelez les inverses? L ’inverse de 4 est 1/4 car 4 x 1 / 4 = 1. Dans le monde
de l’arithmétique modulo n, c ’est plus compliqué:
4 x i s l (mod 7).
f
Cette équation revient à chercher un x et un k tels que :
4x = 7k + 1
et où x et k sont des entiers.

Le problème général consiste à trouver un x tel que :
1 = (a x x) mod n
ce qui s’écrit aussi :

a-1 = x (mod n).
Le calcul de l’inverse d ’un nombre modulo n est un problème difficile à résoudre.

Parfois, il y a une solution ; parfois, il n’y en a pas. Par exemple, l’inverse de 5 modulo
14 est 3 car 5 x 3 = 15 = 1 (mod 14). D ’autre par, 2 n’a pas d’inverse modulo 14.
En général, a *1 = x (mod n) a une solution x unique si a et n sont premiers entre eux.
Si a et n ne sont pas premiers entre eux, alors cTx = x (mod n) n’a pas de solution.
Si n est un nombre premier, alors chaque nombre compris entre 1 et n —1 est premier
par rapport à n et chacun a exactement un inverse modulo n dans cet intervalle.
Mais comment calcule-t-on l’inverse de a modulo n ? Il y a plusieurs méthodes.
L’algorithme d ’Euclide permet aussi calculer l’inverse d ’un nombre modulo n. Cet
algorithme est parfois appelé a l g o r i t h m e d ’ E u c l i d e é t e n d u .
Voici l’algorithme écrit en C + + :
#define estPair(x) ((x & 0x01) == 0)

#define estlmpair(x) (x & 0x01)
#define intervertir(x.y) (x “= y, y ~= x, x "= y)
void EuclideÉtendu(int *u, int *v, int *ul, int *u2, int *u3) {
// Attention : u et v seront intervertis si u < v
int k, tl, t2, t3;
if(*u < *v) intervertir(*u,*v);

for(k=0; estPair(*u) && estPair(*v); ++k) {
*u » = 1; *v » = 1;
>
*ul = 1; *u2 = 0; *u3 = *u; tl = *v; t2 = *u-l; t3 = *v;
do {
do {
if(estPair(*u3)) {
if (estPairOul) II estPair(*u2) ) {
*ul += *v; *u2 += *u;
>
*ul » = 1; *u2 » = 1; *u3 » = 1;
>
if(estPair(t3) II *u3 < t3) {
intervertir(*ul,tl);
intervertir(*u2,t2);
intervertir(*u3,t3);
>
> while(estPair(*u3) );
while(*ul < tl II *u2 < t2) {
*ul += *v; *u2 += *u;
>
*ul -= tl; *u2 -= t2; *u3 -= t3;
} while(t3 > 0);
while(*ul >= *v && *u2 >= *u) {
*ul -= *v; *u2 -= *u;
>
*u « = k; *u2 « = k; *u3 <<= k;
}
main(int argc, char **argv) {

int a,b,pgcd;
if(argc < 3) {
cerr << "Utilisation : euclide u v" << endl;
return(-l);
>
int u = atoi(argv[l]);
int v = atoi(argv[2]);
if(u <= 0 II v <= 0) {
cerr « "Les arguments doivent être strictement positifs!"
« endl;
return(-2);
>
// Attention, u et v seront échangés si u < v
EuclideÉtendu(&u,& v ,& a ,& b ,fepgcd);
cout « a « " * " « u « " + (
« b « ") * " « v « " = " « pgcd « endl;
if(pgcd == 1)
cout « "L’inverse de " « v « " mod " « u « " est : "
« u - b « endl;
return(O);
>
Je ne vais pas prouver que cela marche, ni donner la théorie sous-jacente. Les détails
se trouvent dans [864], ou dans tout autre texte sur la théorie des nombres cité plus
haut.
L’algorithme est itératif et peut être lent pour des grands nombres. K n u t h a montré
que le nombre moyen de divisions pour cet algorithme est donné par :
0,843 x log2(rt) + 1,47.
Calcul de coefficients
L’algorithme d’EucilDE peut aussi être utilisé pour résoudre la classe de problèmes
suivante. Etant donné un tableau de m variables xi,X 2 ,—,xm, trouver un tableau de m
coefficients Wi,U2 ,...,um, tel que:
m x x xm — 1.
Petit théorème de Fermât

Si m est premier, et a n’est pas un multiple de m, alors le p e t i t t h é o r è m e d e
indique que:
F e r m â t 11
c/m- 1 _ j (mod m).
Fonction d’Euler
Il y a une autre méthode pour calculer l’inverse d ’un nombre modulo n mais il n’est
pas toujours possible de l’appliquer. L ’ e n s e m b l e r e s t r e i n t d e s r é s i d u s modulo n est
l’ensemble des résidus premiers par rapport à n (cet ensemble est un sous-ensemble de
11. Pierre de Fermât, m athém aticien français, a vécu de 1601 à 1665 C e théorèm e n ’ a rien à voir
avec son dernier théorème.
l’ensemble de tous les résidus modulo n défini précédemment). Par exemple, l’ensemble
restreint des résidus modulo 12 est {1,5,7,11}. Si n est premier, alors l’ensemble res
treint des résidus est l’ensemble de tous les nombres entre 1 et n — 1. Le nombre 0 ne
fait jamais partie de l’ensemble restreint des résidus.
La fonction d’Euler12 de n (parfois appelée indicateur d’Euler de n) est le nombre
d’éléments (« le cardinal ») de l’ensemble restreint des résidus modulo n. Cette fonction
est notée : <p(n). En d ’autres termes, <fi(n) est le nombre d ’entiers positifs plus petits
que n et premiers par rapport à n.
Si n est premier, alors <p(n) — n — 1. Si n = p x q et p et q sont premiers, alors
<p(n) = (p — l ) ( ç — 1). Ces nombres apparaîtront souvent lors de la présentation des
algorithmes à clef publique.
D ’après le petit théorème de Fermât généralisé par Euler, si pgcd(a,n) = 1,
alors:
av ^ mod n = 1.
Maintenant, il est facile de calculer a ' 1 mod n :
x = av^ ~ x mod n.
Par exemple, quel est l’inverse de 5 modulo 7? Comme 7 est premier, <p(7) = 7 —1 = 6.
Ainsi, l’inverse de 5 modulo 7 est :
56-1 mod 7 = 55 mod 7 = 3.
Les deux méthodes de calcul d ’inverses peuvent être étendues pour calculer x dans
l’équation (si pgcd(a,n) = 1) :
(a x x) mod n = b.
Par la généralisation d ’ EULER, on a :
x = (b x av^ ~ x) mod n.
Par l’algorithme d ’ E üC LlD E , on a :
x = (b x (a-1 mod n)) mod n.
En général, l’algorithme d ’EucLiDE est une méthode plus rapide pour calculer les
inverses modulo n, plus particulièrement pour des nombres d ’environ 500 bits. Si
pgcd(a,n) / 1, tout n’est pas perdu. Dans le cas général, (a x x) mod n = b peut
avoir des solutions multiples ou pas de solution du tout.
Théorème du reste chinois

Si vous connaissez la décomposition en facteurs premiers de n, alors vous pouvez utiliser
le théorème du reste chinois pour résoudre un système d’équations particulier. La
version de base du théorème a été découverte au premier siècle de notre ère par le
mathématicien chinois S u n T s e .
12. Leonhard E uler est un m athém aticien suisse qui vécu t de 1707 à 1783.
En général, si la décomposition en facteurs premiers de n est n = pi x 'P'2. x ... x r ,

alors le système d ’équations :
( x mod p,) = ai, pour i = l,2,...,t
admet une solution unique x, telle que x soit inférieur à n. Certains nombres premiers
peuvent apparaître plusieurs fois dans le produit. Par exemple, pi peut être égal à p 2 .
Ainsi, pour a et 6 quelconques tels que a < p et b < q (p et q premiers), il existe un
seul x tel que x soit inférieur à p x q et tel que :
x = a (mod p), et x = b (mod q).
Pour calculer ce x, on utilise l’algorithme d’EucLlDE pour calculer u tel que:
u x q= 1 (mod p)
et ensuite on calcule :
x = (((a — b) x u) mod p) x q + b.
Voici le théorème du reste chinois codé en C :
/* r e s t l e nombre d ’ élém ents dans l e s tableau x m e t u;

me s t l e tab lea u des p a ir e s de modules prem iers en tre eux;
u e s t l e tab leau des c o e f f i c i e n t s
l e r é s u lt a t e s t n t e l que
n == u[k] ‘/. m[k] ( k = 0 . . r - l )
e t n < m [0 ]* m [l]* .. .* m [r -l]
*/
/* l a fo n c t io n d ’ Euler e u le r ( ) e s t la is s é e
comme e x e r c ic e au le c t e u r . * /
in t r e s t e _ c h in o is (s iz e _ t r , in t *m, in t *u)
s iz e _ t i ;
in t module;
in t n;
module = 1;
f o r ( i= 0 ; i< r ; ++i)
module *= m [ i ] ;
n = 0;
f o r ( i= 0 ; i< r ; + + i) {
n += u [ i ] * m odexp(m odule/m ti], e u l e r ( m [i ] ) , m [ i ] ) ;
n '/.= module;
}
r e t u r n (n );
}
Un corollaire du théorème du reste chinois peut être utilisé pour résoudre un problème
similaire : si p et q sont premiers et p est inférieur à q, alors il existe un x unique
inférieur à p x q tel que :
a = x (mod p), et b = x (mod q).
Si a > b mod p, alors :
x — (((a — ( b mod p)) x u) mod p) x q + b.
Si a < b mod p, alors :
x — (((a + p — (b mod p)) x u) mod p) x q + b.
Résidus quadratiques
Si p est premier et a est inférieur à p, alors a est un r é s i d u q u a d r a t i q u e modulo p
si :
x 2 = a (mod p), pour un certain x.
Une valeur quelconque de a ne satisfait pas forcément cette propriété. Par exemple, si
p — 7, les résidus quadratiques sont 1, 2 et 4 :
12 = 1 = 1 (mod 7)
22 = 4 ee 4 (mod 7)
32 = 9 = 2 (mod 7)
42 = 16 EE 2 (mod 7)
52 = 2 5 = 4 (mod 7)
62 = 36 = 1 (mod 7).
Remarquez que chaque résidu quadratique apparaît deux fois dans la liste.
Il n’existe pas de valeur de x qui satisfasse une des équations :
x2 = 3 (mod 7)
x2 = 5 (mod 7)
x2 = 6 (mod 7)
Les nombres 3, 5 et 6 ne sont donc pas des résidus quadratiques modulo 7.

Bien que je ne le fasse pas ici, il est aisé de démontrer qu’il y a exactement (p —
l ) /2 résidus quadratiques modulo p et (p - l) /2 nombres qui ne sont pas des résidus
quadratiques modulo p. De même, si a est un résidu quadratique modulo p, alors a a
exactement deux racines carrées: l’une comprise entre 0 et (p — l ) /2 et l’autre entre
(p —l ) /2 et (p —1). L ’une de ces racines carrées est aussi un résidu quadratique modulo
p ; celle-ci est appelée racine carrée prin cip ale.
Si n est le produit de deux nombres premiers, p et q, il y a exactement (p — l)(q — l) /4
résidus quadratiques modulo n. Un résidu quadratique modulo n est un carré parfait
modulo n. Par exemple, il y a 6 résidus quadratiques modulo 35: 1, 4, 9, 11, 16, 29.
Chacun d ’entre eux a exactement 4 racines carrées.
11.3 Théorie des nombres 2t
Symbole de Legendre
Le sy m b o le d e L egen dre, noté13 L(a,p), est défini quand a est un entier quelconqi
et p est un nombre premier plus grand que 2. Il vaut 0, 1 ou —1 :
L(a,p) = 0 si a est divisible par p.

L(a,p) = 1 si a est un résidu quadratique modulo p.
L(a,p) — —1 si a n’est pas un résidu quadratique modulo p.
Un moyen simple de calculer L(a,p) est donné par :
L(a,p) = o ( 2 mod p.
Un autre moyen de le calculer est donné par les formules récursives suivantes :
1. si a = 1, alors L(a,p) = 1 ;
2. si a est pair, alors L(a,p) — L(a/2,p) x ( —1)(p2-1)/8 ;
3. si a est impair, alors L(a,p) = L(p mod a,a) x (—i ) !0- 1)*!?*-1)/4.
Remarquez que c ’est aussi un moyen efficace de déterminer si a est un résidu quadr
tique modulo p (seulement quand p est premier, évidemment).
Symbole de Jacobi
Le s y m b o l e d e J a c o b i , noté J(a,n) est une généralisation du symbole de L e g e n d r
il est défini pour toute paire d’entiers a et n. Cette fonction est utilisée dans les tes
de primalité. Le symbole de JACOBI est une fonction de l’ensemble restreint des résid
des facteurs de n. Il peut être calculé grâce à différentes formules [1418]. En voici u
qui repose sur les définitions suivantes :
1. J(a,n) n’est défini que pour n impair.
2. J(0,n) = 0.
3. Si n est premier, alors J(a,n) = 0 si n divise a.
4. Si n est premier, alors J(a,n) = 1 si a est un résidu quadratique modulo n.
5. Si n est premier, alors J(a,n) — —1 si a n’est pas un résidu quadratique modi

n.
6. Si n est un nombre composé, alors J(a,n) = J(a,p i) x ... x J(a,pm), où pi,...,}

est la décomposition en facteurs premiers de n.
Les règles suivantes permettent de calculer récursivement le symbole de Jacobi :
1. J(l,n) = 1
2. J(a x b,n) = J(a,n) x J(b,n)
13. N ote du traducteur : il est aussi parfois noté

3. J(2,n) — 1 si (n2 — l)/8 est pair, — 1 sinon
4 J(a,n) = J((a mod n),n)
5. J{a,pi x p2) = J(a,pi) x J{a,pv)
6. Si pgcd(a,b) = 1 et a et b sont tous deux impairs (la loi de réciprocité n’est pas
valable pour les entiers pairs) :
6a. J(a,b) = +J(b,a) si (a — 1)(6 — l)/4 est pair

6b. J(a,b) = —J(b,a) si (a — l)(i> — l)/4 est impair.
Voici l’algorithme en C :
/* Cet algorithme calcule le symbole de Jacobi récursivement. */
#define estPair(x) (x & 1 == 0)

#define estlmpair(x) (x & 1)
int Jacobi(int a, int b) {

int d;
assert(estImpair(b));
if (a >= b) a V.= b; /* Règle 4 */

if (a == 0) retum(O); /* Définition 1 */
if(a == 1) return(l); /* Règle 1 */
if (a < 0)
if(estPair((b-1)/2))
re t u m Jacobi(-a,b) ;
else
return -Jacobi(-a,b);
if(estPair(a))
if(estPair((b*b - l)/8>)
return +Jacobi(a/2,b);
else
return -Jacobi(a/2,b); /* Règles 3 et 2 */
d = pgcd(a,b);
assert(estlmpair(a));
/* Ceci est garanti par le test estPair(a) plus haut */
if(d == a) /* a divise b */
return 0; /* Règle 5 */
else if(d != 1)
return Jacobi(d.b) * Jacobi(a/d,b); /* Règle 2 */
else if(estPair((a-l)*(b-l)/4))
return +Jacobi(b,a); /* Règle 6a */
else
return -Jacobi(b,a); /* Règle 6b */
>
Si on sait que n est premier, il suffit de calculer a^n~ 1^ 2 mod n au lieu d’exécuter
l’algorithme précédent; dans ce cas, J(a,n) est équivalent au symbole de Legendre.
Le symbole de Jacobi ne permet pas de déterminer si a est un résidu Si J{a,n) = 1 et
n est un nombre composé, a n’est pas forcément un résidu quadratique modulo n. Par
exemple :
7(7,143) = J ( 7 ,ll) x 7(7,13) = (—1)(—1) = 1.
Toutefois, il n’existe pas de nombre entier tel que x2 = 7 (mod 143).
Entiers de Blum
Si p et ç sont deux nombres premiers et qu’ils sont tous les deux congrus à 3 modulo
4, alors n = pq est appelé e n t i e r d e B l u m . Si n est un entier de B l u m , chaque résidu
quadratique modulo n a exactement 4 racines carrées. L ’une de ces racines carrées
est aussi un carré; c ’est la racine carrée p r i n c i p a l e . Par exemple, la racine carrée
principale de 139 modulo 437 est 24. Les trois autres racines carrées sont 185, 252 et
413
Générateurs
Si p est premier, et g est plus petit que p, alors g est un g é n é r a t e u r modulo p si :
pour chaque b de 1 à p — 1, il existe un certain a tel que ga = 6 (mod p).
On dit aussi de façon équivalente, que g est p r i m i t i f par rapport à n.

Par exemple, si p = 11, 2 est générateur modulo 11 :
210 = 1 024 -- 1 (mod 11)

21 = 2 = 2 (mod 11)
28 = 256 = 3 (mod 11)
22 = 4 s 4 (mod 11)
24 = 16 = 5 (mod 11)
29 = 512 = 6 (mod 11)
27 = 128 - 7 (mod 11)
23 = 8 = 8 (mod 11)
26 = 64 — 9 (mod 11)
25 = 32 :: 10 (mod 11)
Tout nombre de 1 à 10 peut être exprimé comme 2“ (mod p).

Pour p = 11, les générateurs sont 2, 6, 7 et 8. Les autres nombres ne sont pas géné
rateurs. Par exemple, 3 n’est pas un générateur parce qu’il n’y a pas de solution à
l’équation :
3a = 2 (mod 11).
En général, trouver un générateur n’est pas un problème facile, sauf si l’on connaît la
décomposition en facteurs premiers de p — 1. Soit çi,Ç 2 viÇ n les facteurs premiers de
p — 1. Pour déterminer si un nombre, g, est un générateur modulo p, on calcule:
g{p- i)/e (mod p)
pour toutes les valeurs de q = Çi,<72,—,9n-

Si cette expression vaut 1 pour un certain alors g n’est pas un générateur. S’il
n’existe pas de qi tel que cette expression vaille 1, alors g est un générateur modulo p.
Par exemple, pour p — 11, les facteurs premiers de p — 1 = 10 sont 2 et 5. Pour tester
si 2 est un générateur on calcule :
2 ( n - i ) / 5 m od n = 4
2( n - i)/2 mod n _ 1Q
Aucun des résultats n’est égal à 1, donc 2 est un générateur.

Pour tester si 3 est un générateur on calcule :
3 ( n - i ) / 5 m od n = 9
3 ( n - i )/2 m o d n = L
Comme le dernier résultat est égal à 1, 3 n’est pas un générateur.

Si vous avez besoin d ’un générateur modulo p, choisissez tout simplement un nombre
au hasard entre 1 et p — 1 et testez si c ’est un générateur. Il y en a un bon nombre,
aussi vous en trouverez probablement un rapidement.
Corps de Galois
Pas de panique ! Ce titre ne cache rien de terrible. En fait, depuis plusieurs paragraphes,
nous effectuons déjà des calculs dans un corps de G a l o i s . Dans le cadre de l’arithmé
tique modulo n, si n est premier ou une puissance entière d’un nombre premier, alors
nous avons ce que les mathématiciens appellent un co r p s fini. Dans le cas particulier
de n premier, nous utiliserons plutôt la lettre p. Ce type de corps fini est tellement
important que les mathématiciens lui ont donné le nom de son promoteur : on parlera
d’un co rp s d e G a lois et on l’écrira Zjp. Evariste G a l o i s , mathématicien français
qui a vécu au début du XIXe siècle, a beaucoup produit dans le domaine de la théorie
des nombres avant de mourir à l’âge de 20 ans dans un duel.
Dans u n corps de G a l o i s , l’addition, la soustraction, la multiplication et la division
sont bien définies. Il existe un élément neutre pour l’addition : 0 et un élément neutre
pour la multiplication: 1. Chaque nombre non nul a un inverse unique (cela ne serait
pas vrai si p n’était pas premier). Les lois de commutativité, d ’associativité et de
distributivité s’appliquent.
E n cryptographie, on se sert beaucoup de l’arithmétique dans un corps de G a l o i s .
Toute la théorie des nombres s’applique, les nombres gardent une taille finie et il n’y a
pas d’erreur d’arrondi pour la division. Nombre de cryptosystèmes sont basés sur Z /p ,
où p est un nombre premier très grand.
Pour compliquer un peu plus les choses, les spécialistes de cryptographie utilisent aussi
l’arithmétique modulo des polynômes irréductibles de degré u et à coefficients entiers
11-4 Factorisation 271
modulo q (avec q premier). Ces corps sont notés Z jqn. Tous les calculs sont fait modulo
un certain polynôme irréductible de degré n, p(x).
La théorie de ces corps est hors du propos de cet ouvrage: malgré cela, je décrirai
certains cryptosystèmes qui en font usage. Si vous voulez jouer un peu avec ces corps,
Z / 23 a pour éléments : 0 , 1 , x, x + 1 , x2, x 2 + 1 , x2+ x , x 2 + X + 1 . Ï I existe un algorithme
pour calculer des inverses dans Z /2 n dont on peut faire mie réalisation sur machine
parallèle [423].
Quand on parle de polynômes, le terme « premier » est souvent replacé par le terme
« irréductible » . Un polynôme est dit irréductible s’il ne peut pas être exprimé comme le
produit de deux autres polynômes (différents de 1 et de lui-même). Le polynôme x 2 + 1
est irréductible sur les entiers. Par contre, le polynôme x z + 2x2 -f x est réductible : il
est équivalent au produit x(x + l)(a: + 1).
On appelle primitif un polynôme qui est générateur dans un corps donné; tous ses co
efficients sont premiers entre eux. Nous reparlerons de polynômes primitifs à l’occasion
des générateurs de nombres pseudo-aléatoires (voir § 16.2).
Les calculs dans 2 /2 ” peuvent être rapidement réalisés matériellement grâce à des
registres à décalage linéaire à rétroaction. Pour cette raison, les calculs dans Z j2 n sont
souvent plus rapides que dans 2 /p . Tout comme l’exponentiation peut être réalisée de
manière très efficace dans Z j 2” , il en est de même du logarithme discret [187, 188, 372,
383]. Si vous voulez en apprendre plus consultez [147].
Pour le corps de G a lo is 2 /2 ” , les spécialistes de cryptographie aiment utiliser le
trinôme p(x) = x n + x + 1 comme module car la longue série de coefficients nuls entre
xn et x rendent la réalisation de la multiplication très efficace [190], Le trinôme doit
être primitif, sinon cela ne fonctionne pas. Pour n inférieur à 1000, le trinôme x n + x + 1
est primitif [1651, 1650] si n vaut :
1,3,4,6,9,15,22,28,30,46,60,63,127,153,172,303,471,532,865,900.
Il existe une réalisation matérielle de Z /2 127 avec p(x) — x ’ 27 + x + 1 [1633,1634,1136].

L’article [154] décrit des architectures matérielles efficaces pour réaliser l’exponentia
tion dans 2 /2 ” .
11.4 Factorisation
Factoriser un nombre signifie trouver ses facteurs premiers :
10 = 2 x 5
60 = 2 x 2 x 3 x 5
252 601 = 41 x 61 x 101
2113 - 1 = 3 391 x 23 279 x 65 993 x 1868 569 x 1066 818132 868 207
Le problème de la factorisation est l’un des plus vieux de la théorie des nombres. Il
est facile de factoriser un nombre mais c ’est coûteux en temps. Toutefois, il y a eu des
avancées dans l’état de l’art.
Actuellement, le meilleur algorithme de factorisation est :
Le c r i b l e s u r c o r p s n u m é r i q u e (NFS pour « Number Field Sieve ») [962]

(voir aussi [964, 20, 283]). Le c r i b l e g é n é r a l s u r c o r p s n u m é r i q u e est
272 Chapitre tl Rudiments mathématiques
la méthode de factorisation la plus rapide connue pour des nombres de plus

de 110 chiffres environ [504, 637). Elle n’était pas efficace au moment où
elle a été proposée pour la première fois, mais cela a changé depuis grâce
à une série d ’améliorations survenues ces dernières années. Le crible sur
corps numérique est encore trop nouveau pour avoir permis d ’établir des
records de factorisation, mais cela viendra bientôt. Le NFS a été utilisé
pour factoriser le neuvième nombre de F E R M A T : 2512 + 1 [966, 965].
Il existe d ’autres algorithmes de factorisation, mais ils ont été supplantés par le crible
sur corps numérique :
Le crib le q u a d ra tiqu e [1267, 1619,1269]. C ’est l’algorithme le plus rapide

connu pour des nombres de moins de 110 chiffres et il a été très utilisé [442].
Une version plus rapide de cet algorithme est appelée crible quadratique
multipolynomial [1459, 304]. La version la plus rapide de cet algorithme
est appelée variante à deux grands facteurs premiers du crible quadratique
multipolynomial.
M é th o d e des co u r b e s ellip tiq u es (E C M pour « Elliptic Curve
Method ») [968, 1118, 1119]. Cette méthode a été utilisée pour trouver
des facteurs de 43 chiffres décimaux mais rien de plus grand.
A lg o rith m e M o n te -C a r lo d e P o lla rd [1264, 252]. Cet algorithme ap
paraît également dans le volume 2, page 370 de l’ouvrage de K n u th [864],
A lg o rith m e des fra ction s continues. Voyez [1129, 1262, 864]. Cet algo
rithme n’est même pas dans la course.
T en tativ e d e division . C ’est le plus vieil algorithme de factorisation:
il consiste à tester tous les nombres premiers jusqu’à la racine carrée du
nombre à factoriser.
Voyez [255] pour une bonne introduction à ces différents algorithmes de factorisation,
excepté pour le crible sur corps numérique. La meilleur présentation du crible sur corps
numérique se trouve dans [962]. Des références plus anciennes sont [502, 1604, 1268].
Des informations sur la factorisation parallèle peuvent être trouvées dans [253].
Si n est le nombre à factoriser, la variante la plus rapide du crible quadratique nécessite
un nombre d’opérations équivalent à :
e (l+ 0 (l))(ln «)*(ln (ln n ))i
Le crible sur corps numérique est plus rapide avec un temps heuristique asymptotique
estimé de :
(l,9 2 3 + 0 (l))(ln n )4 (ln (ln n ))§
En 1970, la factorisation d ’un nombre « difficile » de 41 chiffres était à la une des jour
naux [1129] 14. Dix ans après, factoriser des nombres difficiles de taille double prenait
quelques heures de calcul sur un ordinateur CRAY [442].
En 1988, Cari P o M E R A N C E a conçu une machine à factoriser modulaire en utilisant des
puces VLSI sur mesure [1269]. La taille du nombre que vous pouvez factoriser dépend
14. Un nom bre « difficile » est un nom bre qui n ’a pas de petits facteurs et qui n ’ a pas une forme
spéciale qui perm et de le factoriser plus facilement.
11.4 Factorisation 273
de la taille de la machine que vous pouvez vous permettre de construire. Il ne l’a jamais
construite.
En 1993, un nombre difficile de 120 chiffres a été factorié grâce au crible quadratique;
le calcul a demandé l’équivalent de 825 millions d ’instructions par seconde pendant un
an (mips-an en abrégé) et fut mené en trois mois de temps réel [469] D ’autres résultats
se trouvent dans [501].
Aujourd’hui, la factorisation tend à utiliser les réseaux d ’ordinateurs [304, 966]. En
factorisant un nombre de 116 chiffres, Arjen L E N S T R A et Mark M A N A S S E utilisèrent
400 mips-an, le temps d ’inaction d ’une batterie d ’ordinateurs tout autour du monde
pendant quelques mois.
En mars 1994, une équipe de mathématiciens menée par L e n s t r a a factorisé un
nombre de 129 chiffres (428 bits) grâce à la variante du crible quadratique multi
polynomial [71]. Des volontaires sur Internet ont mené à bien le calcul: 600 personnes
et 1600 machines durant huit mois, probablement le plus grand multi-processeur ad
hoc jamais assemblé. Le calcul a demandé l’équivalent de 4000 à 6000 mips-an. Les ma
chines communiquaient par courrier électronique, envoyant leurs résultats individuels
à un central qui s’est occupé de l’étape finale de l’analyse. Ce calcul était basé sur le
crible quadratique et des théories vieilles de cinq sms; un dixième du temps de calcul
aurait suffit avec le crible sur corps numérique [960]. Selon [71] : « Nous en concluons
que les nombres de 512 bits courament utilisés pour R SA sont vulnérables face à n’im
porte quelle organisation prête à dépenser quelques millions de dollars et à attendre
quelques mois. » Ils estiment que factoriser un nombre de 512 bits demande 100 fois
plus de travail avec les mêmes moyens et 10 fois plus en utilisant le crible sur corps
numérique et la technologie actuelle [960].
Pour rester au courant de l’art de factoriser, R SA D a t a S e c u r i t y a instauré en mars
1991 un concours de factorisation ( le « RSA Factoring Challenge * ) [534]. Il s’agit
d’une liste de nombres difficiles, chacun étant le produit de deux nombres premiers
de tailles comparables. Chaque nombre premier est congru à 2 modulo 3. Il y a 42
nombres dans le concours; leur taille va croissante de 100 chiffres à 500 chiffres de
10 en 10 (plus un nombre de 129 chiffres). Au moment d ’écrire ces lignes, RSA-100,
RSA-110, RSA-120 et RSA-129 ont étés factorisés, tous grâce au crible quadratique.
RSA-130 pourrait être le prochain (en utilisant le crible sur corps numérique), ou les
champions de factorisation pourraient bien sauter directement à RSA-140
C’est un domaine qui évolue vite. Il est difficile d ’extrapoler les progrès de la technologie
de la factorisation car personne ne peut prédire les avancées mathématiques. Avant que
le crible sur corps numérique ne soit découvert, de nombreuses personnes ont conjecturé
que le crible quadratique était asymptotiquement aussi rapide que toute autre méthode
de factorisation pourrait l’être. Ils avaient tort.
Des progrès à court terme dans le crible sur corps numérique pourraient aller dans le
sens d’abaisser la constante : 1.923. Pour certains nombres de forme spéciale, comme
les nombres de F e r m â t, la constante avoisine plutôt 1.5 [966, 965]. Si c ’était le cas
pour les nombres difficiles utilisés en cryptographie à clef publique, les nombres de 1024
bits pourraient être factorisés aujourd’hui. Une façcon d ’abaisser la constante consiste
à trouver de meilleurs moyens de représenter les nombres par des polynômes à petits
coefficients. Le problème n’a pas encore été étudié en profondeur, mais des avancées
vont probablement arriver [960].
Chapitre 11 Rudiments mathématiques
Pour obtenir les résultats les plus récents du concours de factorisation, envoyez un
courrier électronique à ch a lle n g e -in fo @ rsa .com .
Racines carrées modulo n

Si n est le produit de deux nombres premiers, alors la possibilité de calculer des racines
modulo n demande une puissance de calcul équivalente à celle nécessaire pour factoriser
n [1294, 36, 37, 200]. En d’autres termes, celui qui connaît les facteurs premiers de n
peut facilement calculer les racines carrées d ’un nombre modulo n, mais pour tous les
autres le calcul est prouvé être aussi difficile que pour calculer les facteurs premiers de
n.
11.5 Génération de nombres premiers

La cryptographie à clef publique a besoin de nombres premiers. Tout réseau de taille
raisonnable en demande un grand nombre. Avant de présenter les mathématiques sous-
jacentes à la génération de nombre premiers, je vais répondre à quelques questions
évidentes :
1. Si tous le monde a besoin d’un nombre premier différent, ne va-t-on pas tomber
à court? Non, le père Noël ne tombera jamais à court de nombres premiers
pour tous les petits garçons et toutes les petites filles sages. En fait, il y a plus
de 10151 nombres premiers de 512 bits de long ou m oins15. Il y a 1084 d ’atomes
dans l’univers. Si chaque atome de l’univers avait besoin d ’un milliard de nombres
premiers chaque microseconde depuis l’origine des temps jusqu’à maintenant, il
faudrait 10116 nombres premiers; il en resterait encore approximativement 10151.
2. Que se passe-t-il si deux personnes choisissent par accident le même nombre

premier? Avec un choix de plus de 10151 nombres premiers, les chances que cela
arrive sont inférieures aux chances que l’ordinateur se consume spontanément
au moment précis où vous gagnez à la loterie. Cela ne vaut pas la peine de s’en
préoccuper.
3. Si quelqu’un créé une base de donnée contenant tous les nombres premiers,
pourra-t-il s’en servir pour casser les algorithmes à clef publique? Oui, mais
il ne peut pas la créer. Si vous disposiez de disques de un gigaoctets pesant un
gramme, alors la liste des nombres premiers de 512 bits serait si lourde qu’elle
dépasserait la limite de Chandrasar et imploserait pour se transformer en trou
noir... ainsi, vous ne pourriez pas en retirer de données de toute manière.
Si la factorisation d ’un nombre est si difficile, comment peut-il être facile de générer un
nombre premier? L’astuce vient de ce que répondre par oui ou par non à la question
« Est-ce que n est premier? » est bien plus facile que de répondre à la question plus
compliquée « Quels sont les facteurs premiers de n ? »
Générer des nombres aléatoires, puis essayer de les factoriser est une mauvaise méthode
de génération de nombres premiers. La méthode appropriée consiste à générer des
15. Pour des nom bres de taille N , la probabilité q u ’un nom bre aléatoire soit premier est approxim a
tivement de 1 pou r ln 2 .IV-
11.5 Génération de nombres premiers 275
nombres aléatoires et tester s’ils sont premiers. Il existe plusieurs tests probabilistes
de primalité, ce sont des tests qui permettent de déterminer si un nombre est premier
avec un certain niveau de confiance. En supposant que ce « niveau de confiance » est
suffisant, ce type de tests est assez bon. J’ai entendu appeler les nombres ainsi produits
« nombres premiers de type industriel » : ce sont des nombres probablement premiers
avec une faible chance d’erreur contrôlable.
Supposons qu’un test soit mis au point pour échouer une fois sur 250. Cela veut dire
qu’il y a une chance sur 1015 pour que le test affirme à tort qu’un nombre composé
est premier16. Si pour certaines raisons vous avez besoin de plus de certitude dans
la primalité du nombre, vous pouvez faire descendre le taux d ’erreur plus bas encore.
Par contre, si vous considérez que les chances d ’obtenir un nombre composé sont 300
millions de fois plus faibles que celles de gagner à la loterie nationale, peut-être que
vous ne vous inquiéterez pas trop.
Une présentation générale des développements dans le sujet se trouve dans [1266, 210].
D’autres articles importants sont [1497, 388, 15, 23, 628, 654, 912].
Solovay—Strassen
S o l o v a y et S t r a s s e n ont développé un algorithme probabiliste de test de prima
lité [1497]. Cet algorithme utilise le symbole de JACOBI pour tester si p est premier:
1. Choisissez un nombre aléatoire a inférieur à p.
2. Si le pgcd(a,p) ^ 1; alors p échoue au test et il est composé.
3. Calculez j — a^p~ 1^ 2 mod p.
4. Ca lcu lez le sym bole de JACO BI J(a,p).
5. Si j ^ J(a,p), alors p n’est certainement pas premier.
6. Si j — J(a,p), alors la probabilité que p ne soit pas premier est au plus de 50 %.
Un nombre a qui permet d ’affirmer que p n’est certainement pas premier s’appelle un
tém oin. Si p est composé, il y a au moins 50 % de chances pour qu’un nombre a
aléatoire soit un témoin. Répétez ce test t fois avec t valeurs différentes aléatoires pour
a. Un nombre composé à une chance sur 2* de passer les t tests.
Lehmann
Un autre test, plus simple, a été développé indépendamment par L e h m a n n [956]. Voici
l’algorithme pour tester si t est premier :
2. Calculez a^p_1^ 2 mod p.
3. Si a^p 'U /2 lou — 1 (mod p) pour tous les i, alors p n’est pas premier.
4. Si a(p-1) / 2 = 1 ou —1 (mod p) alors la probabilité que p soit composé est de 50 %

au plus.
16. Le test n’ indiquera jam ais à tort qu ’ un n om bre est com posé.
À nouveau, un nombre aléatoire a a au moins 50 % de chances d ’être un témoin. Répétez

le test t fois. Si le calcul vaut 1 ou —1, mais pas toujours 1, alors p est probablement
premier avec un taux d ’erreur de 1 sur 2e.
Rabin—Miller
L’algorithme que tout le monde utilise— il est facile— a été développé par R a b i n , en
partie à partir des idées de M i l l e r [1099, 1295]. En fait, c ’est une version simplifiée
de l’algorithme recommandé par la proposition pour le DSS du N IST [1176, 1174].
Choisissez d ’abord un nombre aléatoire p à tester. Calculez b, où b est le nombre de
fois que 2 divise p — 1 (c’est-à-dire que 2b est la plus grande puissance de 2 qui divise
p — 1). Ensuite calculez m tel que p = 1 + 2bm.
2. Posez j = 0 et z = am mod p.
3. Si z = 1 ou si z = p — 1, alors p passe le test et peut être premier.
4. Si j > 0 et z = 1, alors p n’est pas premier.
5. Posez j ~ j + 1. Si j < b et z ^ p — 1, posez z = z2 mod p

et retournez à l’étape (4). Si z = p — 1, alors p passe le test et peut être premier.
6. Si j = b et z ^ p — 1, alors p n’est pas premier.
Les chances d ’un nombre composé de passer ce test décroissent plus vite qu’avec les
algorithmes précédents. Trois quarts des valeurs possibles de a sont à coup sûr des
témoins. Cela veut dire qu’un nombre composé passera le test moins d ’une fois sur 4f,
où t est le nombre d’itérations. En réalités, ces estimations sont très pessimistes. Pour
la plupart des nombres aléatoires, environ 99,9 % des valeurs possibles de a sont des
témoins [103].
Il existe même de meilleures estimations [420]. Pour des candidats de n bits (où n est
supérieur à 100), les chances d ’erreur sur un test sont de 1 sur A n 2 ' ^ 2. Et pour un
candidat de 256 bits, les chances d ’erreurs après six tests sont inférieures à une sur 251.
Vous trouverez plus de théorie dans [421],
Considérations pratiques
Dans les réalisations du monde courant, la génération de nombres premiers est rapide.
1. Générez un nombre aléatoire p de n bits.
2. Mettez le bit de poids fort et le bit de poids faible à 1 17.
3. Vérifiez par prudence que p n’est pas divisible par les petits nombres premiers :
3, 5, 7, 11, etc. De nombreuses réalisations testent la divisibilité de p par tous les
nombres premiers inférieurs à 256. Le plus efficace est de tester la divisibilité par
tous les nombres premiers inférieurs à 2000. Vous pouvez faire cela efficacement
avec une roue [864].
17. Le bit de poids fort assure que p a la longueur requise et le bit d e poids faible assure que p est
impair.
11.5 Génération de nombres premiers 277
4. Effectuez le test de R a b i n —M i l l e r pour un a aléatoire. Si p réussit le test,

générez un autre a aléatoire et faites le test à nouveau. Choisissez une valeur
petite de a pour rendre les calculs plus rapides. Faites cinq tests [654]18. Si p
échoue à l’un des tests, générez un autre p et essayez encore.
Une autre option consiste à ne pas générer p au hasard mais à essayer les uns après
les autres tous les nombres à partir d ’un point aléatoire jusqu’à trouver un nombre
premier.
L’étape 3 est optionnelle, mais c ’est une bonne idée. Tester si un nombre p impair
aléatoire est divisible par 3, 5 et 7 permet d’éliminer 54 % des nombres impairs avant
d’arriver à l’étape 4. Tester avec tous les nombres premiers inférieurs à 100 permet
d’éliminer 76 % des nombres impairs; tester avec tous les nombres premiers inférieurs
à 256 permet d’éliminer 80 % des nombres impairs. En général, la part de nombre
impairs qui ne sont multiples d’aucun nombre premier inférieur à n est de 1.12/ km .
Plus vous prenez n grand, plus cela requiert de pré-calcul avant d ’arriver au test de
R a b in -M il l e r .
Une réalisation de cette méthode sur une Sparc II était capable de trouver des nombres
premiers de 256 bits en un temps moyen de 2,8 secondes, des nombres premiers de 512
bits en un temps moyen de 24,0 secondes, des nombres premiers de 768 bits en un
temps moyen de 2 minutes, des nombres premiers de 1024 bits en un temps moyen de
5,1 minutes [929].
Nombres premiers forts

Si n est le produit de deux nombres premiers p et q, il peut être désirable d’utiliser
des n om b res p rem iers forts pour p et q. Ce sont des nombres qui ont certaines
propriétés qui rendent leur produit n difficile à factoriser par des méthodes spécifiques.
Voici quelques propriétés parmi celles qui ont été suggérées [1339, 654] :
Le plus grand commun diviseur de p — 1 et q — 1 doit être petit.

p — 1 et q — 1 doivent tous deux avoir des grands facteurs premiers, respec
tivement p' et q1.
p' — 1 et 4 — 1 doivent tous deux avoir des grands facteurs premiers.
(p — l ) /2 et (q — l ) /2 doivent tous deux être premiers [189]. (Notez que si
cette condition est vérifiée, alors les deux premières le sont aussi.)
La question de savoir si des nombres premiers forts sont nécessaires est sujette à débat.
Ces propriétés ont été développées pour empêcher certains algorithmes de factorisation.
Toutefois, les algorithmes de factorisation les plus rapides ont autant de chances de
factoriser des nombres qui satisfont ces critères que ceux qui ne les satisfont pas [832].
Je recommande de ne pas générer spécifiquement des nombres premiers forts. La taille
des nombres premiers est bien plus importante que leur structure. De plus les exigences
de structure peuvent être néfastes car elles vont à l’encontre du caractère aléatoire.
Cela peut changer. De nouveaux algorithmes de factorisation peuvent être découverts
qui marchent mieux avec des nombres ayant certaines propriétés qu’avec ceux qui n’en
jouissent pas. S’il en est ainsi, des nombres premiers forts seront peut-être à nouveau
18. Un suffit peut-être mais faites en cinq.

nécessaires. Vérifiez votre journal de mathématiques théoriques local pour les dernières
nouvelles.
11.6 Logarithmes discrets dans un corps

fini
L ’exponentiation modulaire est une autre fonction à sens unique fréquemment utilisée
en cryptographie. Evaluer l’expression suivante est facile :
ax mod n.
Le problème inverse de l’exponentiation modulaire est celui de la recherche du loga

rithme discret d ’un nombre. C ’est un problème difficile.
Trouver un x tel que ax = b (mod n).
Par exemple :
Si 3X mod 17 = 15, alors x = 6.
Les logarithmes discrets n’ont pas tous des solutions (rappelez-vous que les seules
solutions valides sont entières). Il est facile de voir qu’il n’y a pas de solution x pour
l’équation :
3X mod 13 = 7.
Il est encore plus difficile de résoudre ces problèmes pour des nombres de 1024 bits.
Calcul de logarithmes discrets dans un groupe fini

Il y a trois groupes principaux dont les logarithmes discrets sont intéressants pour les
cryptographes :
- le groupe multiplicatif des corps premiers: Z /p ;
- le groupe multiplicatif des corps finis de caractéristique 2: Z / 2" ;
- le groupe des courbes elliptiques sur des corps finis F : E C (F ).
La sécurité de nombreux algorithmes à clef publique est basée sur le problème de la

détermination des logarithmes discrets, et donc le problème est étudié intensivement.
Un bon aperçu condensé du problème et des meilleures solutions à l’époque peut être
trouvé dans [1194, 1047]. Le meilleur article à jour sur le sujet est [945].
Si p, lemodule, est premier, alors la complexité du calcul des logarithmes discrets
dans Z /p est essentiellement la même que celle de la factorisation d ’unnombre n
d’à peu près la même taille où n est le produit de deux nombres premiers de tailles
comparables [1383, 945]. C ’est-à-dire :
e ( l + 0(l))(ln n ) i (ln(ln n) ) i
11.6 Logarithmes discrets dans un corps fini 279
Le crible sur corps numérique est plus rapide avec son estimation asymptotique heu
ristique du temps de calcul :
e (l,9 2 3 + 0 (l))(ln n)3 (ln(ln n ))§
Stephen POHLtG et Martin H e llm a n ont trouvé un moyen rapide de calculer des
logarithmes discrets dans Z j p si p - 1 n’a que des petits facteurs premiers [1263]. Pour
cette raison, seuls les corps tels que p — 1 a au moins un grand facteur premier sont
utilisés en cryptographie. Un autre algorithme [18] calcule les logarithmes discrets à une
vitesse comparable à la factorisation ; il a été ensuite étendu aux corps de la formes
Z / p n [716]. Cet algorithme a été critiqué [729] car il a certains défauts théoriques.
D’autres articles [1590] montrent combien le problème est effectivement difficile.
Le calcul de logarithme discret est intimement lié à la factorisation. Si vous savez
calculer le logarithme discret, alors vous savez factoriser19. Actuellement, il y a trois
méthodes de calcul de logarithmes discrets dans un corps premier [374, 945, 650] : le
crible linéaire, le schéma d ’entiers de Gauss et le crible sur corps numérique.
Le plus gros des calculs préliminaires ne doit être effectué qu’une fois pour chaque corps.
Après cela, des logarithmes donnés peuvent être rapidement calculés. C’est un défaut de
sécurité pour les systèmes basés sur ces corps. Il est important que différents utilisateurs
utilisent des corps premiers différents. Des utilisateurs de la même application peuvent
cependant utiliser le même corps premier.
Le monde des corps polynomiaux, Z j 2", n’a pas été ignoré par les chercheurs. Un
algorithme heuristique a été proposé dans [729]. L’algorithme de C O P P E R S M IT H rend
raisonnable la recherche des logarithmes discrets dans des corps tels que Z j 2127 et
possible la recherche dans Z j 2400 [372], Cela est basé sur les travaux de [187]. L’étape
de précalcul est énorme, mais sinon c’est élégant et efficace. Une réalisation pratique
avec une version nettement moins efficace du même algorithme, après une période de
précalcul de 7 heures, trouve des logarithmes discrets dans Z j 2127 en quelques secondes
chacun [1137, 794]20.
Plus récemment, les précalculs pour Z j 2227, Z / 2 313 et Z j 2401 ont été terminés et
des progrès significatifs ont été faits pour Z j 2503. Ces calculs sont exécutés sur un
ordinateur massivement parallèle n C u b e -2 avec 1024 processeurs [651, 652], Calculer
des logarithmes discrets dans Z j 2593 est encore hors de portée.
Tout comme pour les logarithmes discrets dans un corps premier, les précalculs néces
saires pour calculer des logarithmes discrets dans un corps polynomial ne doivent être
faits qu’une fois. E l G a m a l [522] donne un algorithme pour calculer des logarithmes
discrets dans le corps Z j p 2 .
19. L’inverse n’ a jam ais été prouvé.

20. C e corps particulier fut utilisé dans quelques cryptosystèm es [146, 1633, 1634], il n ’est pas sûr.
Chapitre 12
Le DES
12.1 Historique
Le DES (pour « Data Encryption Standard »), aussi connu sous le nom D E A pour la
norme ANSI (pour « Data Encryption Algorithm ») et D E A -1 pour la norme ISO, est
un standard mondial depuis plus de 20 ans. Bien qu’il montre des signes de vieillesse,
il a remarquablement bien résisté à des années de cryptanalyse et il est toujours sur
contre tous les adversaires, excepté peut-être contre les plus puissants.
Développement du standard
Au début des années 70, la recherche cryptographique non militaire était faite au
petit bonheur. Il n’y avait quasiment aucune publication dans le domaine. Beaucoup
de gens savaient que les militaires utilisaient des équipements de codages spéciaux
pour communiquer, mais peu d’entre eux comprenaient la science de la cryptographie.
L’Agence nationale de sécurité américaine (N SA pour « National Security Agency »)
avait une expérience considérable mais son existence n’était même pas publiquement
admise.
Les acheteurs ignoraient ce qu’ils achetaient. Quelques petites compagnies concevaient
et vendaient des équipements cryptographiques, principalement pour les gouverne
ments hors Etats-Unis. Ils étaient tous différents ; aucun de ces dispositifs ne pouvait
communiquer avec un autre. Et personne ne savait s’ils étaient vraiment sûrs ou pas ;
il n’existait pas d’instance indépendante pour certifier leur niveau de sécurité, et ceux
qui achetaient des équipements cryptographiques ne savaient pas vraiment ce qu’ils
achetaient. Un rapport gouvernemental rapporta [443] :
« Les implications profondes du lien entre les différentes variantes de méca

nismes de clefs, ainsi que les principes de fonctionnement et la force réelle
des équipements de chiffrement et déchiffrement étaient, et sont encore,
virtuellement inconnus de presque tous les acheteurs, et il est très difficile
de faire des choix bien informés quant au type d’équipement — en-ligne,
hors-ligne, génération de clef, etc. —- qui satisfassent les besoins en sécurité
des acheteurs. »
282 Chapitre 12 Le D E S
En 1972, le Bureau national des standards américain (NBS pour « National Bureau of
Standards »), maintenant dénommé l’Institut national des standards et de la technologie
(N IST pour « National Instïtute of Standards and Technology »), a lancé un programme
pour protéger les ordinateurs et les communications de données. Un des objectifs ce
programme consistait à développer un algorithme standard de cryptographie unique
qui puisse protéger les données numériques durant leur transmission et leur stockage.
Cet algorithme unique serait testé et certifié, et il permettrait à différents équipements
cryptographiques d’interagir. Il serait moins cher à réaliser et aisément disponible
Dans le numéro du 15 mai 1973 du « Fédéral Register », le NBS faisait un appel d’offres
public pour un algorithme standard de cryptographie, qui spécifiait un ensemble de
critères de conception de l’algorithme :
- il devait fournir un niveau de sécurité élevé ;
- il devait être complètement spécifié et facilement compréhensible ;
- sa sécurité devait être liée à la clef ; et ne devait pas dépendre de la confidentialité

de l’algorithme ;
- il devait être disponible à tous les utilisateurs ;
- il devait être adaptable à diverses applications ;
- il devait pouvoir être réalisé de façon économiquement rentable dans des dispo
sitifs électroniques ;
- il devait être efficace ;
- il devait pouvoir être validé ;
- il devait être exportable.
La réponse du public indiqua qu’il existait une demande très forte pour un standard
de cryptographie, mais qu’il y avait très peu d’expertise dans ce domaine. Certains
mathématiciens ont envoyé des squelettes d ’algorithmes assez sommaires. Aucune des
soumissions ne satisfaisait les critères énumérés ci-dessus.
Le NBS émit un deuxième appel d ’offres dans le numéro du 27 août 1974 du « Fédéral
Register » . Finalement, ils obtinrent un candidat prometteur basé sur un algorithme
développé par IBM au début des années 70, appelé L u c i f e r (voir § 13.1). Une équipe
d’IBM travaillait sur la cryptographie à la fois à Kinston et à Yorktown Heights; elle
était constituée entre autres de Roy A d l e r , Don C o p p e r s m i t h , Horst F E IS T E L , Edna
G r o s s m a n , Alan K o n h e i m , Cari M e y e r , Bill N o t z , Lynn S m i t h , Walt T u c h m a n
et Bryant T u c k e r m a n .
L’algorithme, bien que complexe, était sans détours. Il n’utilisait que des opérations
logiques simples sur des petits groupes de bits et pouvait être réalisé de manière rela
tivement efficace en matériel et en logiciel.
Le NBS demanda le concours de la NSA pour évaluer le niveau de sécurité de cet al
gorithme et pour déterminer son adéquation comme standard fédéral. IBM avait déjà
déposé un brevet pour cet algorithme [516], mais était prêt à céder la propriété intellec
tuelle en vue de sa fabrication, de sa réalisation et de son utilisation. Le NBS travailla
12.1 Historique 283
sur les termes de cet accord avec IBM et obtint finalement une licence non exclusive
et gratuite de fabriquer, utiliser et vendre des dispositifs appliquant cet algorithme.
Finalement, dans le numéro du 17 mars 1975 du « Fédéral Register », le NBS publiait
à la fois les détails de l’algorithme et la déclaration d’IB M d’octroi d ’une licence non
exclusive et gratuite [538]. Un autre avis publié dans le numéro du 1er août 1975 du
« Fédéral Register » faisait appel aux commentaires des agences nationales et du public
en général.
Et il y eut de nombreux commentaires [722, 495, 1126]. De nombreux cryptographes
voyaient d’un mauvais œil la « main invisible de la N SA dans le développement de cet
algorithme. Ils craignaient que la N SA ait pu modifier l’algorithme pour y introduire
une brèche secrète. Ils protestèrent contre le fait que la NSA avait réduit à 56 bits
la longueur de clef qui était de 128 bits originellement (voir § 13.1). Le raisonnement
sous-jacent aux choix faits dans la conception du DES devint clair au début des années
90, mais dans les années 70 cela semblait mystérieux et inquiétant.
En 1976, le NBS organisa deux ateliers pour évaluer la proposition de standard. Le
premier atelier s’intéressa aux mathématiques de l’algorithme et à l’existence possible
d’une brèche secrète [1199]. Le second atelier s’intéressa à la possibilité d ’augmenter la
longueur de clef [232]. Les concepteurs, les évaluateurs, les réalisateurs, les vendeurs,
les utilisateurs et les critiques furent invités. A tout point de vue, les ateliers furent
animés [1124].
En dépit des critiques, le DES fut adopté au niveau fédéral le 23 novembre 1976 [232]
et son utilisation autorisée pour les communications gouvernementales non classées
secrètes. La description officielle du standard, FIPS PU B 46, « Data Encryption
Standard » [1153] fut publiée le 15 janvier 1977 et entra en vigueur un mois plus
tard. Le FIPS PU B 81, « DES Modes of opération » [1156] en 1980, et le FIPS PU B
74, « Guidelines for Implementing and Using the NBS Data Encryption Standard »
[1155] parut en 1981. Le NBS publia également le document FIPS PU B 112 qui
spécifie l’utilisation du DES pour le chiffrement de mots de passe [1151] et le FIPS
PUB 113, qui spécifie l’utilisation du DES pour l’authentification de données informa
tiques [1152]. (FIPS vient de « Fédéral Information Processing Standard », standard
fédéral pour le maniement d’informations.)
Adoption du standard
L’Institut national américain de standardisation (AN SI pour « American National
Standards Institute ») homologua le DES comme standard pour le secteur privé
sous la référence ANSI X 3.92 [56]. Us l’appelèrent D E A (pour « Data Encryption
Algorithm »). AN SI publia un standard pour les modes d ’opération du D E A sous la
référence AN SI X 3.106 [55], qui correspondait au document NBS, et un standard
pour le chiffrement avec le DES en réseau AN SI X 3.105 [54].
Deux autres groupes au sein de l’AN SI, représentant respectivement le monde ban
caire des opérations aux particuliers et le monde bancaire des grands comptes, ont
développé des standards basés sur le DES. Les opérations bancaires aux particuliers
concernent les transactions entre les institutions financières et les particuliers, tan
dis que les opérations bancaires des grands comptes concernent les transactions entre
institutions bancaires.
Le groupe de travail « Financial Institution Wholesale Retail Working Group» de
l’ANSI a développé un standard pour la gestion et la sécurité des PIN (ANSI
Chapitre 12 Le D ES
X 9.8) [64], ainsi qu’un autre standard basé sur le DES pour l’authentification de
messages dans le commerce de détail (A N SI X 9.19) [58]. Le groupe a une ébauche de
standard pour la distribution sûre de clefs (AN SI X 9.24) [60].
Le groupe de travail « Financial Institution Wholesale Security Working Group » de
l’AN SI a développé ses propres standards pour l’authentification de messages (ANSI
X 9 .9) [65], pour la gestion des clefs (A N SI X 9.17) [57, 1171], pour le chiffrement
(ANSI X 9.23) [59], et pour l’authentification sûre de personne ou de nœud (ANSI
X 9.26) [61].
L ’ « American Bankers Association » développe des standards optionnels pour le monde
financier. Ils ont publié un standard recommandant l’utilisation du D ES chaque fois que
le chiffrement est nécessaire [5] et un autre pour la gestion des clefs cryptographiques [6].
Avant le « Computer Security Act » de 1987, les services généraux de l’administration
américaine (G S A pour « General Services of Administration ») avaient la responsabi
lité de la définition des standards de communication fédéraux. Depuis le « Computer
Security Act », cette responsabilité a été transférée au NIST. Les G SA publièrent
trois standards qui utilisaient le DES : deux concernant les exigences en matière de
sécurité en général et de l’interfonctionnement des équipements (F E D E R A L STAN D ARD
1026 [663] et F é d é r a l S t a n d a r d 1027 [664]), et un pour les équipements de télécopie
suivant la norme « Groupe 3 » ( F é d é r a l S t a n d a r d 1028 [665]).
Le Département du Trésor (« Department of Treasury») a émit une directive afin
que tous les messages de transferts de fonds électroniques soient authentifiés par le
DES [474, 476] ; il décrivit également les critères que devaient satisfaire tous les équi
pements d’authentification [475].
L’Organisation internationale de normalisation (ISO pour « International Organiza-
tionfor Standardization ») décida dans un premier temps de soutenir le DES (rebaptisé
pour l’occasion D E A -1) comme norme internationale; mais l’ISO décida ensuite de
ne pas se mêler de la cryptographie. Toutefois, le groupe de travail « International
Wholesale Financial Standards » de l’ISO utilisa le DES dans une norme d ’authen
tification internationale [762] et pour la gestion des clefs [765]. DES est aussi spécifié
dans un standard financier australien [1197].
Validation et réception d’équipement DES
Dans le cadre du DES, le N IST valide les réalisations du DES. Cette validation
confirme que la réalisation est conforme au standard. Jusqu’en 1994, le N IST n’a validé
que les réalisations en matériel ou en microprogrammation; jusqu’alors, les réalisations
logicielles ont été exclues du standard. En mars 95, 73 réalisations différentes avaient
été validées.
Le N IST a aussi développé un programme certifiant les équipements conformes
aux AN SI X 9.9 et FIPS 113. En mars 1995, 33 produits avaient été validés. Le
Département du Trésor a une procédure supplémentaire de validation. Le N IST a
aussi un programme certifiant qu’un équipement est conforme à AN SI X 9.17 pour la
gestion des clefs dans les grands comptes [1171]; en mars 1995, quatre produits avaient
été validés.
12.1 Historique 285
1987
Les termes du standard prévoient qu’il peut être revu tous les cinq ans. Dans le numéro
du 6 mars 1987 du « Fédéral Register », le NBS faisait un appel aux commentaires
concernant l’évaluation de la deuxième tranche de cinq ans. Le NBS soumettait trois
choix à l’examen [1487, 1488] : reconduire le standard pour trois ans, le supprimer ou
revoir son domaine d ’application.
Le NBS et la NSA évaluèrent le standard. La NSA était plus impliquée cette fois-ci.
Grâce à une directive de l’exécutif signée par Ronald R e a g a n , appelée N SDD-145, la
NSA avait un droit de veto sur le NBS en matière de cryptographie. Tout d ’abord, la
NSA annonça qu’elle ne reconduirait pas le standard. Le problème n’était pas que le
DES ait été cassé ou même qu’il pût être suspecté d ’avoir été cassé. Il était simplement
de plus en plus probable qu’il serait bientôt cassé.
A sa place, la NSA proposait le programme « Commercial COMSEC Endorse-
ment » (C C E P ), qui aurait finalement offert une série d ’algorithmes pour remplacer
le DES [92]. Ces algorithmes conçus par la N SA ne seraient pas divulgués; une couche
protectrice dans les puces VLSI aurait empêché la reconstruction de l’algorithme (voir
§ 25.1).
Cette annonce ne fut pas très bien accueillie. De nombreuses personnes indiquèrent que
le DES était très répandu dans le monde des affaires (plus particulièrement le monde
financier) et qu’aucune alternative valable n’était disponible. Le retrait du standard
aurait laissé de nombreuses organisations sans protection pour leurs données. Après pas
mal de débats, le DES fut reconduit comme standard gouvernemental américain jus
qu’en 1992 [1154]. D ’après le NBS, le DES ne serait plus reconduit par la suite [1487].
1993
Ne dites jamais « jamais plus ». En 1992, il n’y avait toujours pas d ’alternative au
DES. Le NBS, maintenant appelé N IST, sollicita une fois de plus les commentaires
dans le « Fédéral Register » [543] :
« Le but de cet avis est d’annoncer l’évaluation du bien-fondé de la pour

suite de l’utilisation du standard pour protéger des données informatiques.
Les commentaires de l’industrie et du public sont souhaités sur les alterna
tives suivantes pour le FIPS 46—1. Les coûts (impacts) et les bénéfices de
ces alternatives doivent être inclus dans les commentaires :
« — Reconduire le standard pour une nouvelle période de cinq (5) ans.

L ’Institut national des standards et de la technologie continuerait à
valider les équipements qui réalisent le standard. FIPS 4 6 -1 conti
nuerait à être la seule méthode approuvée pour protéger des données
informatiques non secrètes.
« - Retrait du standard. L’Institut national des standards et de la tech
nologie ne continuerait pas à valider les équipements qui supportent
le standard. Les organisations pourraient continuer à utiliser les équi
pements existants qui réalisent le standard. D’autres standards pour
raient être émis par le N IST en remplacement du DES.
« - Revoir les clauses d’application et/ou de réalisation du standard. Cette

révision impliquerait toute modification du standard permettant l’uti
lisation de réalisations logicielles du DES aussi bien que matérielles ;
permettant l’utilisation répétée (itérative) du DES dans certaines ap
plications ; permettant l’utilisation d ’autres algorithmes approuvés et
enregistrés par le NIST. »
La période de commentaire se clôtura le 10 décembre 1992. D ’après une déclaration de

Raymond K a m m e r , directeur par intérim du N IST à l’époque [802] :
« L ’année dernière, le N IST sollicita formellement les commentaires sur la

reconduite du DES. Après analyse de ces commentaires, et d ’autres infor
mations techniques que j ’ai reçues, j ’envisage de recommander au Secrétaire
du Commerce qu’il reconduise le DES pour une nouvelle période de cinq
ans. J’envisage également de suggérer au Secrétaire que, lors de l’annonce
de la reconduction, nous affirmions notre intention de lui trouver des alter
natives durant les cinq années qui viennent. En mettant cette déclaration
sur la table, nous espérons donner aux individus la chance de donner leur
opinion sur une transition technique méthodique. En attendant, nous de
vons prendre en compte le très grand nombre de systèmes qui utilisent ce
standard éprouvé. »
Bien que l’Office d ’évaluation technologique américain (« Office of Technology
Assesment ») citât les dires de Dennis B r a n s t a d affirmant que la période utile d ’ex
ploitation du DES devrait se terminer à la fin des années 90 [1200], l’algorithme fut
reconduit pour cinq années supplémentaires [1175]. Les réalisations logicielles de DES
furent finalement admises pour être validées.
Quelqu’un veut-il essayer de deviner ce qui arrivera en 1998?
12.2 Description du DES

Le DES est un système de chiffrement par blocs; il chiffre les données par blocs de
64 bits. Un bloc de 64 bits du texte en clair entre par un côté de l’algorithme et un
bloc de 64 bits du texte chiffré sort de l’autre côté. Le chiffrement et le déchiffrement
utilisent tous deux le même algorithme (avec des différences uniquement dans le plan
de génération des clefs).
La longueur de la clef est de 56 bits. Généralement, la clef est exprimée comme un
nombre de 64 bits mais un bit sur huit utilisé comme bit de contrôle de parité est
ignoré1. La clef peut être n’importe quel nombre de 56 bits et peut être changée à tout
moment. Une poignée de nombres sont des clefs fragiles mais ils peuvent aisément être
évités. Toute la sécurité réside dans la clef.
Au niveau le plus simple, l’algorithme n ’est rien d ’autre que la combinaison de deux
techniques de base du chiffrement : confusion et diffusion. L ’élément constitutif du DES
est une seule combinaison de ces techniques (une substitution suivie d ’une permutation)
appliquée au texte, basée sur la clef. On parlera alors de ron d e. Le DES a 16 rondes,
c ’est-à-dire qu’il applique 16 fois la même combinaison de techniques au bloc de texte
en clair (voir la figure 12.1).
1. Ces bits de parité sont les bits de poids faible des octets de la clef.
12.2 Description du DES 287
Texte en clair
çjp
k2
F ig . 12.1 - DES
L’algorithme n’utilisant que des opérations arithmétiques et logiques standard sur des
nombres d’au maximum 64 bits, il était facile de le réaliser avec la technologie de la
fin des années 70. La nature répétitive de l’algorithme le rend idéal pour l’utilisation
de puces spécialisées. Les premières réalisations logicielles étaient inélégantes mais les
réalisations actuelles sont nettement meilleures.
Plan général de l’algorithme

Le DES manipule le texte en clair par blocs de 64 bits. Après une permutation initiale,
le bloc est coupé en une partie droite et une partie gauche, chacune d’une longueur
de 32 bits. Après cela, il y a 16 rondes d ’opérations identiques, appelées « fonction
/ », lors desquelles les données sont combinées avec la clef. Après la 16e ronde, les
parties droite et gauche sont réassemblées et une permutation finale (l’inverse de la
permutation initiale) termine l’algorithme.
À chaque ronde (voir figure 12.2), les bits de la clef sont décalés et 48 bits sont alors
sélectionnés parmi les 56 bits de la clef. La partie droite des données est étendue à 48
bits par une permutation expansive, combinée avec 48 bits de la clef décalée et permutée
par ou exclusif, remplacée par 32 nouveaux bits par un algorithme de substitution et
permutée une fois de plus. La « fonction / » est constituée de ces quatre opérations. La
sortie de la « fonction / » est alors combinée avec la moitié gauche par un ou exclusif.
Le résultat de ces opérations devient la nouvelle moitié gauche ; l’ancienne moitié de
gauche devient la nouvelle moitié droite. Ces opérations sont répétées 16 fois, donnant
le DES à 16 rondes.
F ig . 12.2 - Une ronde du DES
Si B %est le résultat de la ie itération, Li et Ri sont respectivement les moitiés gauche

et droite de £?,, est la clef de 48 bits pour la ie ronde, et / est la fonction qui fait
toute les substitutions, permutations et ou exclusif avec la clef, alors une ronde est
décrite par :
l'î — R %—i
R% — i © f ( R i - i , K t ).
La permutation initiale
Le tableau 12.1 décrit la permutation initiale qui transpose le bloc d’entrée avant la
première ronde. Ce tableau, ainsi que les autres tableaux de ce chapitre, doit être lu
de gauche à droite et de haut en bas. Par exemple, la permutation initiale déplace le
bit 58 jusqu’à la position 1, le bit 50 jusqu’à la position 2, le bit 42 jusqu’à la position
3, etc.
Tab. 12.1 - Permutation initiale
~ 58 50 42 34 26 18 ÏÔ 2 60 52 44 36 28 20 12 T
62 54 46 38 30 22 14 6 64 56 48 40 32 24 16 8
57 49 41 33 25 17 9 1 59 51 43 35 27 19 11 3
61 53 45 37 29 21 13 5 63 55 47 39 31 23 15 7
La permutation initiale et la permutation finale correspondante n’affectent pas la sécu

rité du DES. (Tout ce qu’on peut dire est que son but premier est de rendre plus facile
le chargement du texte en clair ou du texte chiffré dans une puce DES en morceaux de
taille un octet. Rappelez vous que le DES est arrivé avant les microprocesseurs 16 ou
32 bits.) Comme cette permutation bit à bit est difficile à réaliser en logiciel (bien que
ce soit banal en matériel), de nombreuses réalisations logicielles du DES n’incluent pas
les permutations initiale et finale. Bien que ce nouvel algorithme ne soit pas moins sûr
que le DES, il n’est pas conforme au standard DES et ne doit pas être appelé DES.
Le plan de génération des clefs
Initialement, les 64 bits de la clef DES sont réduits à 56 bits en ignorant un bit sur
huit. Ceci est décrit par le tableau 12.2. Ces bits peuvent être utilisés comme bits de
contrôle de parité pour vérifier qu’il n’y a pas eu d’erreur lors de la saisie de la clef.
T ab . 12.2 - Permutation de clef
~ 57 49 41 33 25 Ï7 9 ï 58 50 42 34 26 Ï 8~
10 2 59 51 43 35 27 19 11 3 60 52 44 36
63 55 47 39 31 23 15 7 62 54 46 38 30 22
14 6 61 53 45 37 29 21 13 5 28 20 12 4
Après que la clef de 56 bits a été extraite, une clef de 48 bits différente est engendrée
pour chaque ronde du DES. Ces clefs K i, sont déterminées de la manière suivante :
Tout d ’abord, la clef de 56 bits est divisée en deux moitiés de 28 bits. Ensuite les
moitiés sont décalées vers la gauche d’une ou deux positions, en fonction de la ronde.
Le nombre de bits de décalage est donné par le tableau 12.3.
T ab . 12.3 - Décalage de clef par ronde
Ronde \ 2 3~4 5 6 7 8 9 ÏÔ ÏÏ 12 13 Ï4 Ï5 lfT

Nombre de
décalages 1 1 2 2 2 2 2 2 1 2 2 2 2 2 2 1
Après avoir été décalés, 48 bits parmi les 56 sont sélectionnés. Comme cette opération
combine une permutation des bits avec une sélection d ’un sous-ensemble des bits, elle
est appelée permutation compressive, ou encore choix permuté. Cette opération
fournit un sous-ensemble de bits qui a la même taille que la sortie de la permutation
expansive. Le tableau 12.4 définit la permutation compressive. Par exemple, le bit en
position 33 de la clef décalée va en position 35 de la sortie, et le bit en position 18 de
la clef décalée est ignoré.
Les décalages ont pour effet de rendre différents les sous-ensembles de bits utilisés dans
chaque sous-clef. Chaque bit est utilisé dans approximativement 14 des 16 sous-clefs,
bien que tous les bits ne soient pas utilisés exactement le même nombre de fois.
T ab . 12.4 - Permutation compressive
14 Vf II 24 ï 5 3 28 Ï5 6 21 10
23 19 12 4 26 8 16 7 27 20 13 2
41 52 31 37 47 55 30 40 51 45 33 48
44 49 39 56 34 53 46 42 50 36 29 32
La permutation expansive
Par cette opération, la moitié droite des données, Rl, est étendue de 32 à 48 bits.
Comme cette opération change l’ordre des bits et qu’elle répète certains bits, elle est
appelée permutation expansive. Cette opération a deux buts : le résultat a la même
taille que la clef pour l’opération ou exclusif, et elle fournit un résultat plus long qui
pourra être comprimé pendant l’opération de substitution. Toutefois, aucun de ces
deux buts n’est sa raison d ’être cryptographique. En permettant à un bit d’affecter
deux substitutions, la dépendance entre les bits d’entrée et les bits de sortie se dilue
plus vite. On parlera d’effet d ’avalanche. Le DES est conçu afin de parvenir le plus
vite possible à ce que chaque bit du texte chiffré dépende de chaque bit du texte en
clair et de chaque bit de la clef.
La figure 12.3 illustre la permutation expansive. On l’appelle parfois ta b le T . Pour
chaque bloc de 4 bits d ’entrée, le premier et le quatrième bit, représentent chacun 2
bits du bloc de sortie, tandis que les deuxième et troisième bits, représentent chacun
un bit du bloc de sortie. Le tableau 12.5 indique la correspondance entre les positions
de sortie et les positions d ’entrée. Par exemple, le bit en position 3 du bloc d ’entrée va
en position 4 du bloc de sortie, et le bit en position 21 du bloc d ’entrée va en positions
30 et 32 du bloc de sortie.
Bien que le bloc de sortie soit plus grand que le bloc d ’entrée, il n’existe qu’un bloc
d’entrée possible pour un bloc de sortie donné.
F ig . 12.3 - Permutation expansive

T ab . 12.5 - Permutation expansive
32 1 2 3 4 5 4 5 6 7 8 9
8 9 10 11 12 13 12 13 14 15 16 17
16 17 18 19 20 21 20 21 22 23 24 25
24 25 26 27 28 29 28 29 30 31 32 1
La substitution par tables—S

Après que la clef comprimée a été combinée par ou exclusif avec le bloc expansé, le
résultat de 48 bits est soumis à une opération de substitution. Ces substitutions sont
réalisées à l’aide de huit tables de substitution, ou tables-S. Chaque table-S 1 a
six bits d ’entrée et quatre de sortie, et il y a huit tables-S 1 différentes2. Les 48 bits
sont divisés en blocs de 6 bits. Chaque bloc est manipulé séparément par une table-
S différente: le bloc 1 est manipulé par la table -S 1, le bloc 2 est manipulé par la
table- S 2, etc. Voir la figure 12.4.
Chaque table-S a 4 rangs et 16 colonnes. Chaque cellule dans la table est un nombre
de 4 bits. Les 6 bits du bloc d ’entrée spécifient le rang et la colonne à exploiter pour
obtenir la sortie. Le tableau 12.6 montre les 8 tables -S.
Les bits d’entrée spécifient une cellule de la table-S d’une manière très particulière :
considérez 6 bits d’entrée étiquetés fq, 6 2 , 6 3 , 6 4 , fis, fie ; les bits fi] et fie sont combinés
pour former un nombre de 2 bits, entre 0 et 3, qui correspond à un rang dans la table ;
les 4 bits du milieu, 62 à fis, sont combinés pour former un nombre de 4 bits, entre 0
et 15, qui correspond à une colonne dans la table.
Par exemple, faites l’hypothèse que l’entrée de la sixième table-S (c’est-à-dire les bits
31 à 36 en sortie de la fonction ou exclusif ) soit 1100102. Le premier et le dernier bits,
combinés pour former 102, indiquent qu’il faut prendre le 2 e rang de la table. Les 4 bits
du milieu combiné pour former 10012 indiquent qu’il faut prendre la 9e colonne de la
table. La cellule au 2e rang, 9e colonne de la table-S 6 est 0. Rappelez-vous que l’on
numérote les rangs et les colonnes à partir de 0 et non de 1. La valeur 00002 remplace
110010 2 .
Bien sûr, dans une réalisation logicielle, il est bien plus facile d ’utiliser des tableaux de
64 entrées pour les tables S. Cela demande de réarranger un peu les entrées, mais ce
n’est pas difficile3. Toutefois, décrire ainsi les tables-S aide à visualiser la façon dont
2. L ’espace m ém oire total occu p é par les ta b le s -S du D E S est de 256 octets.

3. Il ne faut pas changer uniquement les indices sans réarranger les entrées. Les ta b le s -S sont
conçues très précisément.
F ig . 12.4 - Table-S de substitution

T ab . 12.6 - Tables-S
Table-5 1:
14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7
0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8
4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0
15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13
Table-S 2 :
15 1 8 14 6 11 3 4 9 7 2 13 12 0 5 10
3 13 4 7 15 2 8 14 12 0 1 10 6 9 11 5
0 14 7 11 10 4 13 1 5 8 12 6 9 3 2 15
13 8 10 1 3 15 4 2 11 6 7 12 0 5 14 9
Table-S 3:
10 0 9 14 6 3 15 5 1 13 12 7 11 4 2 8
13 7 0 9 3 4 6 10 2 8 5 14 12 11 15 1
13 6 4 9 8 15 3 0 11 1 2 12 5 10 14 7
1 10 13 0 6 9 8 7 4 15 14 3 11 5 2 12
Table-S 4:
7 13 14 3 0 6 9 10 1 2 8 5 11 12 4 15
13 8 11 5 6 15 0 3 4 7 2 12 1 10 14 9
10 6 9 0 12 11 7 13 15 1 3 14 5 2 8 4
3 15 0 6 10 1 13 8 9 4 5 11 12 7 2 14
Table S 5:
2 12 4 1 7 10 11 6 8 5 3 15 13 0 14 9
14 11 2 12 4 7 13 1 5 0 15 10 3 9 8 6
4 2 1 11 10 13 7 8 15 9 12 5 6 3 0 14
11 8 12 7 1 14 2 13 6 15 0 9 10 4 5 3
Table-S 6 :
12 1 10 15 9 2 6 8 0 13 3 4 14 7 5 11
10 15 4 2 7 12 9 5 6 1 13 14 0 11 3 8
9 14 15 5 2 8 12 3 7 0 4 10 1 13 11 6
4 3 2 12 9 5 15 10 11 14 1 7 6 0 8 13
Table S 7 :
4 11 2 14 15 0 8 13 3 12 9 7 5 10 6 1
13 0 11 7 4 9 1 10 14 3 5 12 2 15 8 6
1 4 11 13 12 3 7 14 10 15 6 8 0 5 9 2
6 11 13 8 1 4 10 7 9 5 0 15 14 2 3 12
Table-S 8 :
13 2 8 4 6 15 11 1 10 9 3 14 5 0 12 7
1 15 13 8 10 3 7 4 12 5 6 11 0 14 9 2
7 11 4 1 9 12 14 2 0 6 10 13 15 3 5 8
2 1 14 7 4 10 8 13 15 12 9 0 3 5 6 11
elles fonctionnent. On peut voir chaque table-S 1 comme une permutation de quatre de
ses entrées: les bits de £>2 à 65 sont pris en entrée et il en sort un résultat de quatre
bits. Les bits bi et be proviennent des emplacements contigus; ils sont utilisés pour
sélectionner une des quatres permutations possibles de la table-S en question.
Cette étape de substitution par tables-S est cruciale dans le DES. Toutes les autres
opérations sont linéaires et faciles à analyser. Les tables-S sont non linéaires et, par
dessus tout, elles confèrent au DES son niveau de sécurité.
Cette phase de substitution donne 8 blocs de 4 bits qui sont recombinés pour former
un seul bloc de 32 bits. Ce bloc passe alors à l’étape suivante : la permutation-P.
La permutation—P
Les 32 bits de sortie des substitutions par tables .S sont permutés à l’aide d ’une table-
P. Cette table met en correspondance chaque bit de l’entrée avec un bit de sortie;
aucun bit n’est utilisé deux fois et aucun bit n’est ignoré. O 11 parlera de permutation
pure, ou tout simplementde permutation. Le tableau12.7montre à quelle position
migre chaque bit. Par exemple, le bit 21 va en position 4, tandis que le bit 4 va en
position 31.
T ab . 12.7 —Permutation-P
Ï6 7 20 21 29 12 28 Ï7 1 15 23 26 5 Ï 8 31 10
2 8 24 14 32 27 3 9 19 13 30 6 22 11 4 25
Finalement, le résultat de la permutation-P est combiné par ou exclusif avec la moitié

gauche du bloc initial de 64 bits. Ensuite, les parties gauche et droite sont échangées
et une nouvelle ronde commence.
La permutation finale
La permutation finale, qui est l’inverse de la permutation initiale, est décrite par le
tableau 12.8. Notez que les parties gauche et droite ne sont pas échangées après la
dernière ronde du DES ; c ’est le bloc RieLie qui est utilisé comme entrée pour la
permutation finale. Il n’y a rien de bien particulier ici ; échanger les moitiés et décaler
la permutation donnerait exactement le même résultat ; il en est ainsi pour que le même
algorithme puisse être utilisé pour le chiffrement et le déchiffrement.
T ab . 12.8 - Permutation finale
~4Ô 8 48 16 56 24 64 32 39 7 47 15 55 23 63 3F
38 6 46 14 54 22 62 30 37 5 45 13 53 21 61 29
36 4 44 12 52 20 60 28 35 3 43 11 51 19 59 27
34 2 42 10 50 18 58 26 33 1 41 9 49 17 57 25
294 Chapitre 12 Le D ES
Déchiffrement du DES
Après toutes ces substitutions, permutations, ou exclusif et décalages, vous pourriez
penser que l’algorithme de déchiffrement est totalement différent et aussi déroutant que
l’algorithme de chiffrement. Tout au contraire, les différentes opérations ont été choisies
pour offrir une propriété très utile : le même algorithme est utilisé pour le chiffrement
et le déchiffrement.
Avec le DES il est possible d’utiliser la même fonction pour chiffrer un bloc et pour le
déchiffrer. La seule différence est que les clefs doivent être utilisées dans l’ordre inverse.
Si les clefs de chiffrement de chaque ronde sont A i , A 2 , A 3 , ... , A i 6 , alors les clefs de
déchiffrement sont respectivement A 16, A 1 5 , A 1 4 , ... , K\. L’algorithme qui engendre
les clefs pour chaque ronde est également circulaire, et le nombre de décalages (vers la
droite) à effectuer devient 0 ,1 ,2 ,2 ,2 ,2 ,2 ,2 , 1 ,2 ,2 ,2 ,2 ,2 ,2 , 1 .
Modes opératoires du DES

Le document FIPS PU B 81 spécifie quatre modes opératoires: E CB, C B C , OFB,
et C FB (voir le chapitre 9) [1156]. Le standard bancaire de l’AN SI spécifie les modes
E C B et C B C pour le chiffrement, et les modes C B C et CFB à n bits pour l’authen-
tification [55].
Dans le monde du logiciel, la certification n’existe pas. A cause de sa simplicité le
mode E C B est le plus souvent utilisé dans les logiciels commerciaux classiques, bien
qu’il soit le plus vulnérable aux attaques. Le mode de chiffrement avec chaînage de blocs
est utilisé occasionnellement, bien qu’il ne soit guère plus compliqué que le carnet de
codage électronique et qu’il procure un niveau de sécurité nettement plus élevé.
Réalisations matérielles et logicielles du DES

De nombreuses publications décrivent des réalisations efficaces matérielles et logicielles
de l’algorithme [1007, 8 8 , 535, 536, 437, 740, 1575, 183, 275, 1574].
Le détenteur du record de rapidité de la puce DES est un prototype développé par
D i g i t a l E q u ip m e n t C o r p o r a t i o n [513]. Elle offre les modes ECB et C B C et elle
est réalisée avec une matrice de 50000 transistors G a A s . Les données peuvent être
chiffrées et déchiffrées à la vitesse de 1 gigabit par seconde (15,6 millions de blocs DES
par seconde). C ’est impressionnant. La table 12.9 donne les spécificités de certaines des
puces DES du commerce. Les apparentes disparités entre les vitesses d ’horloges et les
taux de donées sont dues au parallélisme incorporé dans certaines puces.
La puce la plus impressionnante est la 6 8 6 8 de VLSI (appelée à ses débuts la « garde
barrière »). Non seulement elle peut appliquer le DES en 8 cycles d’horloge (des pro
totypes peuvent le faire en quatre), mais elle peut aussi appliquer le le triple DES en
25 cycles d ’horloge en mode E C B , et en 35 cycles d ’horloge en mode O FB ou CBC.
Cela me paraît impossible mais je vous assure que ça marche.
Une réalisation logicielle du DES sur un ordinateur central IBM 3090 peut effec
tuer 32 000 chiffrements DES par seconde. La plupart des microprocesseurs sont plus
lents, mais impressionnants malgré tout. Le tableau 12.10 [605, 793] donne des chiffres
concrets et des estimations pour divers microprocesseurs I n t e l et M O T O R O L A .
T ab . 12.9 - Les puces dédiées au DES dans le commerce.
Marque Puce Année Vitesse Taux de Commercialisé

d ’horloge données chiffrées
(en MHz) (en megaoctets
par seconde)
AMD Am9518 1981 3 1,3 non
AMD Am9568 ? 4 1,5 non
AM D AmZ8068 1982 4 1,7 non
AT& T T7000A 1985 ? 1,9 non
C E -I n fo sys SuperCrypt 1992 20 12,5 oui
CE99C003
IscCE-Infosys SuperCrypt 1994 30 20,0 oui
CE99C003
C ryptech Cryl2C102 1989 20 2,8 oui
N e w b r id g e CA20C03A 1991 25 3,85 oui
N e w b r id g e CA20C03W 1992 8 0,64 oui
N e w b r id g e C A 9 5 C 6 8 /18/09 1993 33 14,67 oui
P ij n e n b u r g PCC100 ? ? 2,5 oui
SEM APHORE Roadrunner284 ? 40 35,5 oui
Communications
VLSI T e c c h n o l o g y VM007 1993 32 20,0 oui
VLSI T e c c h n o l o g y VM009 1993 33 14,0 oui
VLSI T e c c h n o l o g y 6868 1995 32 64,0 oui
W e s t e r n D ig it a l W D2001/2002 1984 3 0,23 non
T ab . 12.10 - Vitesse du DES pour différents processeurs
Vitesse Blocs DES

Processeur (en MHz) (par seconde)
8088 4,7 370
68000 7,6 900
80286 6 1100
68020 16 3 500
68030 16 3900
80386 25 5000
68030 50 9600
68040 25 16000
68040 40 23 200
80486 33 40600
Sun ELC 26000
HyperSparc 32000
RS6000-350 53000
Sparc 10/52 84000
DEC Alpha 4000/610 154000
HP 9000/887 125 196000
12.3 Niveau de sécurité du DES

Les gens ont longtemps mis en doute le niveau de sécurité du DES [464]. Il y a eu bon
nombre de spéculations sur la longueur de la clef, le nombre d’itérations et le schéma de
conception des tables-S. Les tables S semblaient tout particulièrement mystérieuses
— toutes ces constantes, sans aucune raison apparente à leur valeurs particulières.
Certaines personnes craignaient que la NSA ait caché une « brèche secrète » dans
l’algorithme, de façon à pouvoir facilement déchiffrer les messages.
Une commission sénatoriale, le « Senate Select Committee on Intelligence », étudia la
question en 1978, avec les autorisations top-secrètes du plus haut niveau. Les résultats
de cette enquête sont restés secrets mais un résumé en a été publié disculpant la NSA
de toute malveillance dans la conception de l’algorithme [1226]. « Il est établi [que la
NSA] a convaincu IBM du bien-fondé du choix d’une clef plus courte, [que la NSA] a
indirectement participé au développement de la structure des tables- S et [que la NSA]
a certifié que l’algorithme final DES était, pour autant que l’on sache, exempt de
toute faiblesse statistique ou mathématique » [435]. Toutefois, comme le gouvernement
ne rendit jamais publics les résultats complets de l’enquête, de nombreuses personnes
restèrent sceptiques.
T U C H M A N et M e y e r , deux des cryptographes d ’IBM qui ont conçu le DES, décla
rèrent que la NSA n’avait, pas altéré le schéma de conception [842] :
« Leur approche de base consistait à chercher des fonctions solides de substi

tution, de permutation et de génération de clefs ... IBM a classé les notes
concernant les critères de conception à la demande de la N SA ... « La
NSA nous a dit que nous avions par inadvertance réinventé certains des se
crets fondamentaux qu’elle utilise pour ses propres algorithmes », expliqua
T uchm an . »
Plus loin dans l’article, T u c h m a n déclara: « Nous avons développé l’algorithme DES
entièrement à l’intérieur d’IBM avec des IBMistes. La NSA n’a pas dicté une seule
ligne! » T U C H M A N confirma ceci lorsqu’il présenta l’histoire du DES à la « National
Computer Security Conférence » en 1992.
D ’un autre côté, C o p p e r s m i t h a écrit [376, 379]: « La NSA a aussi apporté des
conseils techniques à IB M .» Et les propos suivant de K o n h e i m ont été rapportés:
«Nous avons envoyé nos tables S à Washington. Elles nous ont été renvoyées toutes
différentes. Nous leur avons fait subir nos tests et elles ont réussi.» Certaines personnes
ont pris cela comme une preuve que la NSA avait caché une « brèche secrète ».
Quand la NSA fut interrogée quant à toute faiblesse introduite intentionnellement dans
le DES, elle répondit [367] :
« Pour ce qui est du standard de chiffrement de données (D ES), nous

pensons que le compte-rendu public de l’enquête menée par le « Senate
Committee for Intelligence » en 1978 quant au rôle de la NSA dans le dé
veloppement du DES répond à votre question. Le rapport de la commission
indique que la N SA n’a pas faussé la conception du DES en quelque façon
que ce soit, et que le niveau de sécurité offert par le DES était plus que
suffisant pour résister au moins cinq à dix ans sur les données non classées
pour lesquelles il était conçu. En bref, la NSA n’a pas imposé ou tenté
d’imposer la moindre faiblesse au DES. »
12.3 Niveau de sécurité du D E S 297
Pourquoi ont-ils alors modifié les tables-S? Peut-être pour s’assurer qu’IBM n’avait
pas caché une « brèche secrète » dans le DES. La NSA n’avait aucune raison de faire
confiance aux chercheurs d ’IBM , et aurait manqué à son devoir en n ’évitant pas toute
possiblité d ’une « brèche secrète » dans le DES. Donner les tables-S était un moyen
de s’en assurer.
Très récemment, de nouveaux résultats de cryptanalyse ont éclairé cette question sous
un autre jour, mais pendant de nombreuses années elle fut l’objet de multiples spécu
lations.
Clefs faibles
La méthode pour obtenir les sous-clefs pour chaque ronde de l’algorithme à partir
de la clef initiale implique l’existence de certaines clefs faibles [722, 428]. Rappelez-
vous que la valeur initiale est divisée en deux moitiés, chaque moitié étant décalée
indépendamment de l’autre. Si tous les bits de chaque moitié sont soit des 0, soit
des 1, alors la clef utilisée pour n’importe quel cycle de l’algorithme est la même que
pour tous les cycles de l’algorithme. Tel est le cas si la clef est constituée entièrement
de 1 ou entièrement de 0, ou si une moitié est entièrement constituée de 1 et l’autre
entièrement de 0. De plus, deux des clefs faibles ont d ’autres propriétés qui les rendent
moins sûres [428].
Les quatre clefs faibles sont données en notation hexadécimale par le tableau 12.11.
Rappelez-vous qu’un bit sur huit est un bit de contrôle de parité et que la permutation
initiale change légèrement l’ordre des bits de la clef.
Ta b . 12.11 - Clefs DES faibles
Valeur de clef faible

(avec bits de parité) Clef
0101 0101 0101 0101 0000000 0000000
1F1F 1F1F 0E0E 0E0E 0000000 FFFFFFF
EOEO EOEO F1F1 F1F1 FFFFFFF 0000000
FEFE FEFE FEFE FEFE FFFFFFF FFFFFFF
De plus, il existe des paires de clefs qui chiffrent un texte en clair en un même texte
chiffré. En d ’autres termes, une clef de la paire peut être utilisée pour déchiffrer des
messages chiffrés avec l’autre clef de la paire. Ceci est dû à la méthode utilisée pour
engendrer les sous-clefs dans le DES ; au lieu d’engendrer 16 sous-clefs différentes, ces
paires de clefs n’engendrent que 2 sous-clefs différentes. Chacune de ces sous-clefs est
utilisée 8 fois dans l’algorithme. Ces clefs sont appelées clefs sem i-faibles. Elles sont
décrites dans le tableau 12.12.
Il y a aussi des clefs qui ne produisent que 4 sous-clefs différentes, chacune étant utilisée
4 fois dans l’algorithme. Ces clefs sont décrites dans le tableau 12.13.
Avant de condamner le DES parce qu’il a des clefs faibles, notez que cette liste de 64
clefs est minuscule en comparaison du nombre total de clefs possibles, à savoir :
72057594037927936.
Si vous choisissez les clefs aléatoirement, les chances d ’en choisir une parmi ces clefs
T a b . 12.12 - Clefs DES semi-faibles
01FE 01FE 01FE 01FE et FE01 FE01 FE01 FE01

1FE0 1FE0 0EF1 0EF1 et E01F E01F F10E F10E
01E0 01E0 01F1 01F1 et E001 E001 F101 F101
1FFE 1FFE OEFE OEFE et FE1F FE1F FEOE FEOE
011F 011F 010E 010E et 1F01 1F01 0E01 0E01
EOFE EOFE F1FE F1FE et FEEO FEEO FEF1 FEF1
T ab . 12.13 - Clefs DES potentiellement faibles
1F 1F 01 01 OE OE 01 01 EO 01 01 EO FI 01 01 FI
01 1F 1F 01 01 OE OE 01 FE 1F 01 EO FE OE 01 FI
1F 01 01 1F OE 01 01 OE FE 01 1F EO FE 01 OE FI
01 01 1F 1F 01 01 OE OE EO 1F 1F EO FI OE OE FI
FE 01 01 FE FE 01 01 FE
EO EO 01 01 FI FI 01 01 EO 1F 01 FE FI OE 01 FE
FE FE 01 01 FE FE 01 01 EO 01 1F FE FI 01 OE FE
FE EO 1F 01 FE FI OE 01 FE 1F 1F FE FE OE OE FE
EO FE 1F 01 FI FE OE 01
FE EO 01 1F FE FI 01 OE 1F FE 01 EO OE FE 01 FI
EO FE 01 1F FI FE 01 OE 01 FE 1F EO 01 FE OE FI
EO EO 1F 1F FI FI OE OE 1F EO 01 FE OE FI 01 FE
FE FE 1F 1F FE FE OE OE 01 EO 1F FE 01 FI OE FE
FE 1F EO 01 FE OE FI 01 01 01 EO EO 01 01 FI FI
EO 1F FE 01 FI OE FE 01 1F 1F EO EO OE OE FI FI
FE 01 EO 1F FE 01 FI OE 1F 01 FE EO OE 01 FE FI
EO 01 FE 1F FI 01 FE OE 01 1F FE EO 01 OE FE FI
1F 01 EO FE OE 01 FI FE
01 EO EO 01 01 FI FI 01 01 1F EO FE 01 OE FI FE
1F FE EO 01 OE FE FO 01 01 01 FE FE 01 01 FE FE
1F EO FE 01 OE FI FE 01 1F 1F FE FE OE OE FE FE
01 FE FE 01 01 FE FE 01
1F EO EO 1F OE FI FI OE FE FE EO EO FE FE FI FI
01 FE EO 1F 01 FE FI OE EO FE FE EO FI FE FE FI
01 EO FE 1F 01 FI FE OE FE EO EO FE FE FI FI FE
1F FE FE 1F OE FE FE OE EO EO FE FE FI FI FE FE
faibles sont négligeables. Si vous être vraiment paranoïaque, vous pouvez détecter les
ciels faibles lors de la génération de clefs. Certains ne pensent pas que cela en vaille la
peine. D ’autres pensent que c ’est tellement facile qu’il vaut mieux le faire.
Vous trouverez plus de détails concernant les clefs faibles et semi-faibles dans [1122].
D ’autres types de clefs faibles ont été recherchés mais aucun n’a été trouvé.
Clefs complémentaires
Prenez le complément bit à bit d’une clef ; autrement dit, remplacez tous les 0 par des
I et tous les 1 par des 0. Après cela, si la clef originale est utilisée pour chiffrer un bloc
de texte en clair, alors le chiffrement du complément du bloc de texte en clair par la
clef complémentaire donnera le complément du texte chiffré.
Si x' est le complément de x, alors l’identité est donnée comme suit :
E k {M ) = C
E K'( M ') = C'.
Cela n’a rien de mystérieux. Les sous-clefs sont combinées avec la moitiée de droite
après la permutation expansive. Cette propriété de complémentarité provient de
ce fait.
Cela veut dire qu’une attaque à textes en clair choisis contre le DES ne devra tester
que la moitié des clefs possibles : 2 55 clefs au lieu de 2 51 [1084]. B i h a m et S h a m i r
montrent [178] qu’il existe une attaque à textes en clair connus de la même complexité
avec au moins 2 3 3 textes en clair connus.
II est douteux que cela constitue une faiblesse, car la plupart des messages n’ont pas
de blocs complémentaires de texte en clair (dans un texte en clair aléatoire, les chances
sont infimes) et l’on peut conseiller aux utilisateurs de ne pas utiliser de clefs complé
mentaires.
Structure algébrique
Il y a 264! manières de mettre en correspondance tous les textes en clair possibles
de 64 bits avec tous les textes chiffrés possibles. Avec sa clef de 56 bits, l’algorithme
DES donne donc 256 (~ 1016) de ces relations. En utilisant le surchiffrement, il semble
possible d ’obtenir un plus grand nombre de ces relations. Toutefois, ceci n’est vrai que
si le DES n’a pas une certaine structure algébrique.
Si l’opération de chiffrement par le DES était interne, pour tous K\ et K 2, il existerait
A 3 tel que :
E K2 ( EK l(P )) - E K3(P)
En d’autres termes, cette opération formerait un groupe, et chiffrer un bloc de texte

en clair avec K\ puis A 2 serait identique au chiffrement du bloc avec A 3 . Pire encore,
le DES serait vulnérable à une attaque par collisions qui ne nécessite que 228 étapes,
nettement moins que les 256 étapes nécessaires pour une recherche exhaustive [803].
Si l’opération de chiffrement par le DES était pure, pour tous A i , AT2 et Kg, il exis
terait A 4 tel que :
E K3(EK2(EKi (P))) = E k 4(P)
Le DES triple serait alors inutile4.
Don C O P P E R S M IT H a écrit très tôt un article théorique donnant des indices sur la
question, mais cela n’était pas suffisant [381]. Plusieurs mathématiciens se sont attaqués
à cette question [590, 428, 431, 529, 725, 790]. Ces expériences rassemblèrent un « grand
nombre d’indices » indiquant que le DES n’est pas un groupe [803, 375, 804,1122, 805],
4. Rem arquez q u ’un algorithm e de chiffrement interne est nécessairement pur, mais un algorithm e
de chiffrement pur n ’est pas forcém ent interne.
mais il fallut attendre 1992 pour que les cryptographes réussissent à prouver que le DES
n’est pas un groupe [297], C o p p e r s m i t h a affirmé que l’équipe d’IBM le savait depuis
longtemps.
Longueur de clef
La première proposition d ’IBM à la NBS avait une clef de 112 bits. Quand le DES
devint un standard, cette longueur avait été ramenée à 56 bits. De nombreux cryp
tographes préconisaient une clef longue. Leurs arguments tournaient principalement
autour de la possibilité d ’une attaque exhaustive (voir § 7.1).
En 1976 et 1977, D i f f i e et H e l l m a n démontrèrent qu’un ordinateur parallèle dédié
à l’attaque du DES pouvait retrouver la clef en un jour et coûterait 20 millions de
dollars. En 1981, D i f f i e et H e l l m a n révisèrent leurs chiffres à la hausse : deux jours
de recherche par clef et 50 millions de dollars [489]. Ils admettaient que c ’était hors de
portée de quiconque excepté les organisations telles que la NSA, mais considéraient
que d ’ici à 1990, le DES ne serait plus sûr du tout [717].
H e l l m a n [716] présenta un autre argument contre une petite taille de clef : en jouant
sur le compromis mémoire - temps de calcul dans le sens de la mémoire, il serait
possible d ’accélérer le processus de recherche. II suggérait la possibilité de calculer et
de stocker 256 résultats possibles du chiffrement d ’un même bloc de texte en clair avec
toutes les clefs possibles. Alors, pour retrouver une clef, tout ce qui restait à faire au
cryptanalyste était d ’insérer le bloc de texte en clair dans le processus de chiffrement,
de récupérer le texte chiffré et de rechercher la clef par comparaison. H e l l m a n estima
le coût d ’une telle machine à 5 millions de dollars.
Les argumentations pour ou contre l’existence d’un système permettant de casser le
DES quelque part dans les caves du Gouvernement ont continué. Plusieurs personnes
firent remarquer que le temps moyen entre deux pannes des puces DES ne serait jamais
assez grand pour garantir qu’une telle machine puisse marcher. Cette objection est
superflue comme le montre [1289]. D ’autres ont suggéré d ’accélérer encore le processus
et de réduire l’effet de pannes des puces.
Entre-temps, les réalisations matérielles du DES ont lentement approché le million de
chiffrements par seconde nécessaire pour la machine spécialisée de D i f f i e et H e l l m a n .
En 1984, des puces capables d’exécuter 256000 chiffrements par seconde ont été fabri
quées [535, 536]. En 1987, des puces qui effectuaient 512000 chiffrements par seconde
ont été développées, et une version capable de tester plus d ’un million de clefs par
seconde était faisable [740, 1575]. Et en 1993, Michael W i e n e r a conçu une machine
coûtant un million de dollars pouvant accomplir une attaque exhaustive contre le DES
en un temps moyen de 3,5 heures (voir § 7.1).
Jusqu’ici, personne n’a admis publiquement avoir construit une telle machine, bien
qu’il soit raisonnable de penser que quelqu’un en a déjà construit une. Un million de
dollars ne constitue pas une somme importante pour un pays développé.
Ce n’est qu’en 1990 que deux mathématiciens israéliens, B i h a m et S h a m i r , ont dé
couvert la cry p ta n a lyse différentielle, une technique qui écarta la question de la
longueur de clef. Avant que nous ne décrivions cette technique, énumérons quelques
autres critiques à l’encontre de la conception du DES.
Nombre de rondes
Pourquoi 16 rondes? Pourquoi pas 32? Après 5 rondes, chaque bit du texte chiffré
est une fonction de chaque bit du texte en clair et de chaque bit de la clef; et après
8 rondes, le texte chiffré est essentiellement une fonction aléatoire de chaque bit du
texte en clair et de chaque bit de la clef [1088, 1084]5. Alors pourquoi l’algorithme ne
s’arrête-t-il pas alors après 8 rondes?
Au fil des ans, il y a eu des attaques réussies contre des variantes du DES avec un
nombre de rondes réduit. Le DES avec 3 ou 4 rondes fut facilement cassé en 1982 [50].
Le DES avec 6 rondes est tombé quelques années plus tard [341]. C ’est la cryptanalyse
différentielle de B i h a m et S h a m i r qui explique également cela; avec n’importe quel
nombre de rondes inférieur à 16 le DES peut être cassé par une attaque à texte en
clair connu plus efficacement que par recherche exhaustive. L’attaque exhaustive est
certainement plus pratique, mais il est intéressant de constater que l’algorithme a
exactement 16 rondes.
Conception des tables—S

En plus d ’avoir été accusée d ’avoir réduit la longueur de la clef, la NSA fut aussi accusée
d’avoir modifié le contenu des tables-S. Sommée de justifier la conception des tables-S,
la NSA indiqua que les détails de conception de l’algorithme étaient sensibles et qu’ils
ne seraient pas rendus publics. Plusieurs cryptographes s’inquiétaient de la possibilité
que la NSA ait introduit une brèche secrète dans les tables-S, lui permettant ainsi de
cryptanalyser l’algorithme.
Depuis, pas mal d ’effort a été investi dans l’étude de la conception et du fonctionne
ment des tables-S. Au milieu des années 70, L e x a r C o r p o r a t i o n [972, 722] et B e l l
L a b o r a t o r i e s [1126] examinèrent le fonctionnement des tables-S. Leurs analyses ne
révélèrent aucune faiblesse, bien qu’ils trouvèrent tous les deux des caractéristiques
inexplicables. Les tables-S avaient plus de caractéristiques en commun avec des trans
formations linéaires que n’en auraient eu des tables choisies aléatoirement. L’équipe de
B e l l L a b o r a t o r i e s indiqua que les tables-S pouvaient avoir une brèche secrète et
le rapport L E X A R concluait ainsi :
« Certaines structures découvertes dans le DES ont sans doute été in
sérées pour renforcer le système contre certains types d’attaques. D’autres
structures tendent à affaiblir le système. »
D’un autre côté, ce rapport contenait aussi la mise en garde suivante:
« ...le problème [de la recherche de structures dans les tables-,S’] est

rendu plus complexe par la capacité qu’a l’esprit humain de trouver une
structure apparente dans des données aléatoires, mais qui ne constitue pas
vraiment une structure. »
Au second atelier du DES, l’ Agence nationale de sécurité américaine révéla certains

des critères de conception des tables- .S’ [232]. Cela n’atténua pas le moins du monde la
suspicion des gens et le débat continua [231, 424, 717, 1510, 1559].
5. Cela s’appelle l’effet de cascade.

Chapitre 12 Le D ES
Plusieurs excentricités concernant les tables - S ont vu le jour dans la littérature. Les
trois derniers bits de sortie de la quatrième table S 4 peuvent être obtenus de la
même manière que les premiers en prenant le complément de certains bits d ’entrée
[436, 438]. Deux entrées différentes, mais soigneusement choisies, peuvent produire la
même sortie [436]. Il est possible d ’obtenir la même sortie d ’une seule ronde DES en
changeant les bits de trois tables S contigües seulement [485]. S h a m i r a remarqué que
les tables-S1paraissaient déséquilibrées en quelque sorte, mais il était loin de pouvoir
utiliser cela dans une attaque [1430]6. D ’autres chercheurs ont montré que des principes
publiques de conception permettaient de générer des tables-S ayant les caractéristiques
observées [270].
Résultats supplémentaires
Il y a eu d ’autres tentatives de cryptanalyse du DES. Un cryptographe a recherché
l’absence de caractère non aléatoire sur la base de tests spectraux [561]. D ’autres cryp
tographes ont recherché des séquences de facteurs linéaires dans le DES, mais leur
attaque échouait après huit rondes [1308, 341, 533]. En 1987, une attaque non publiée
de Donald D a v ie S exploitait la façon dont la permutation expansive répète les bits
dans des tables S adjacentes ; cette attaque est elle aussi inutilisable à partir de huit
rondes [178, 441].
12.4 Cryptanalyse différentielle et linéaire

Cryptanalyse différentielle
En 1990, Eli B ih a m et Adi S h a m ir ont introduit la notion de cryptanalyse différen
tielle [174, 175, 179, 178]. C ’était une nouvelle méthode de cryptanalyse, inconnue à
ce moment-là du public. En utilisant cette méthode, B ih a m et S h a m ir trouvèrent une
attaque à texte en clair choisi contre le DES plus efficace que la recherche exhaustive.
La cryptanalyse différentielle traite spécifiquement les paires de textes chiffrés :
des paires de textes chiffrés dont les textes en clair présentent certaines différences
particulières. Elle analyse l’évolution de ces différences de textes en clairs à travers les
différentes rondes du DES quand ils sont chifrés avec la même clef.
Choisissez simplement des textes en clair avec une différence fixée. Les deux textes en
clair peuvent être choisis aléatoirement tant qu’ils vérifient des conditions particulières
de sur leur différence ; le cryptanalyste n’a pas même besoin de connaître leurs valeurs7.
En utilisant alors les différences dans les textes chiffrés résultants, assignez différentes
probabilités aux clefs possibles. À force d ’analyser des paires de textes chiffrés, vous
finirez par trouver la clef la plus probable. C ’est la bonne clef.
Les détails sont plus compliqués. La figure 12.5 représente la fonction résultant d’une
ronde de DES. Imaginez qu’elle prenne en entrée la paire X et X de différence
A X . Les sorties Y et Y ' sont connues et par conséquent leur différence A Y aussi. La
permutation expansive et la table-P sont toutes les deux connues, A A et A C le sont
6. Il m entionna aussi une caractéristique de la cinquièm e ta b le -S , mais c ’est seulement après huit
ans que la cryptanalyse pu t exploiter cette caractéristique.
7. Pour le D E S, le term e « différence » est défini par l’opération de « o u e x c lu s if ». Il peut en être
autrement pou r d ’autres algorithm es.
12. J) Cryptanalyse différentielle et linéaire 303
donc aussi. B et B ' ne sont pas connus mais leur différence A B est égale à A / l 8. Voici
l’astuce : pour tous les A A possibles, toutes les valeurs de ÔC ne sont pas équiprobables.
La combinaison de A A et A C donne des indications sur les bits de A © K i et A' © Ki-
Comme A et A! sont connus, cela nous donne de l’information sur Ki.
F ig . 12.5 - La fonction résultant d’une ronde de DES
Examinons la dernière ronde du DES. (La cryptanalyse différentielle ignore les per
mutations initiales et finales. Elles n’ont aucun effet sur l’attaque mis à part celui de
la rendre plus difficile à expliquer.) Si nous pouvons déterminer K ie, alors nous avons
48 bits de la clef9. Les 8 autres bits peuvent être obtenus par recherche exhaustive. La
cryptanalyse différentielle nous donnera /C e-
Certaines différences dans les paires de textes en clair ont de fortes chances de réap
paraître dans les paires de textes chiffrés correspondantes. On les appelle caractéris
tiques. Les caractéristiques s’étendent sur plusieurs rondes et définissent essentielle
ment un chemin à travers ces rondes. Il y a une différence en entrée de chaque ronde
et une différence en sortie avec une certaine probabilité.
Vous pouvez trouver ces caractéristiques en générant un tableau où les lignes corres
pondent aux entrées possibles (les combinaisons par ou exclusif de deux ensembles
8. Q uand on regarde la différence, les deux opérations de o u e x c lu s if de K z sur A et A ! s’ annulent.

9. R appelez-vous que la sous-clef de chaque ronde est constituée de 48 des 56 b its de la clef.
différents de bits d’entrée), les colonnes correspondent aux différences en sorties pos
sibles, et chaque case contient le nombre de fois où une sortie particulière est obtenue
pour une entrée donnée. Vous pouvez générer un tel tableau pour chacune des huit
tables-S 1 du DES.
Par exemple la figure 12.6a donne une caractéristique d’une ronde. La différence en
entrée du côté gauche est L ; cela peut-être n’importe quoi. La différence en entrée du
côté droit est O10. Comme il n’y a pas de différence à l’entrée de la fonction résultant
de la ronde, il n’y en a pas à la sortie. Ainsi, la différence du côté gauche est L ® 0 = L,
et la différence du côté droit est 0. C ’est une caractéristiques triviale, qui est vrai avec
probabilité 1 .
La figure 12.6b donne une caractéristique moins évidente. La différence du côté gauche
est à nouveau arbitraire: L. La différence du côté droit est 0x60000000; les deux
entrées ne différent que par le premier et le troisième bits. Il y a une probabilité de
14/64 pour que la différence en sortie de ronde soit L © 0x00808200. Cela signifie que
la différence en sortie est L © 0x00808200 du côté gauche et 0x60000000 du côté droit
avec probabilité 14/64.
F ig. 12.6 - Des caractéristiques du DES
Des caractéristiques différentes peuvent être combinées. Et en supposant que les rondes
sont indépendantes, on peut multiplier les probabilités. La figure 12.7 combine les
deux caractéristiques décrites ci-dessus. La différence en entrée est 0x00808200 du
côté gauche et 0x60000000 du côté droit. A la fin de la première ronde, la différence
en entrée et la sortie de la fonction résultant de la ronde s’annulent, laissant une
différence en sortie de 0. Cela entre dans la deuxième ronde; la différence finale en
sortie est 0x60000000 du côté gauche et 0 du côté droit. Cette caractéristique sur deux
rondes a probabilité 16/64.
Une paire de textes en clair qui satisfait la caractéristique est une paire juste. Une
paire de textes en clair qui ne la satisfait pas est une paire fausse. Une paire juste
suggérera la bonne clef de ronde (pour la dernière ronde de la caractéristique) ; une
10. Les deux entrées ont mêm e partie droite, ce qui donne une différence égale à 0.
12-4 Cryptanalyse différentielle et linéaire 305
A=Y A=X
▼ T
A=X A =Y
X = 0x60000000
Y = 0x00808200
A vec probabilité —
64
F ig. 12.7 - Une caractéristique du DES à deux rondes
paire fausse suggérera une clef aléatoire. Pour trouver la bonne clef, il suffit rassembler
assez d’essais pour qu’une clef soit suggérée plus souvent que les autres. En effet, la
bonne clef se démarquera des autres alternatives qui sont aléatoires.
Ainsi l’attaque différentielle brute sur le DES à n rondes produira la sous-clef de 48
bits utilisée à la ronde n, et les huit bits restants sont obtenus par recherche exhaustive.
Il reste des problèmes importants. Tout d’abord les chances de réussite sont faibles
avant d’avoir atteind un certain seuil. Avant d’avoir obtenu assez de données, vous ne
pouvez pas distinguer la bonne clef au milieu de tout le bruit. Ensuite, l’attaque est
trop lourde en pratique : il faut utiliser des compteurs pour assigner des probabilité à
2 48 sous-clefs différentes, la somme de données requise est trop importante pour que
cela puisse marcher.
B i i i a m et S h a m i r ont modifié leur attaque. Au lieu d ’utiliser une caractéristique à 15
rondes sur le DES à 16 rondes, ils ont utilisé une caractéristique à 13 rondes et quelques
astuces pour les rondes restantes. Une caractéristique plus courte avec une probabilité
plus grande fonctionnait mieux. Us utilisèrent de plus des mathématiques astucieuses
pour obtenir des clefs candidates de 56 bits qui pouvaient être testées immédiatement,
ce qui permet de se passer des compteurs. Cette attaque réussi dès que la bonne paire
est trouvée ; cela évite le seuil et donne une probabilité linéaire de succès. Si vous avez
1000 fois moins de paires, vous avez mille fois moins de chances de succès. Cela paraît
terrible, mais c ’est beaucoup mieux que le seuil. Il reste toujours une petite chance de
succès immédiat.
Les résultats sont très intéressants. Le tableau 12.14 est un résumé de l’attaque contre
le DES avec différents nombres de rondes [178].
T ab. 12.14 - Attaques par cryptanalyse différentielle contre le DES
Nombre de Textes en Textes en Textes en Complexité de

rondes clair choisis clair connus clair analysés l’analyse
8 2 14 2 38 4 29
9 2 24 2 44 2 2 32*
10 2 24 2 43 2 14 2 15
11 2 31 2 47 2 2 32*
12 2 31 2 47 2 21 2 21
13 2 39 2 52 2 2 32*
14 2 39 2 5ï 2 29 2 29
15 2 47 2 56 27 2 37
2 36
16 2 47 2 55 2 37
La complexité de l’analyse peut être fortement réduite pour ces variantes en
utilisant quatre fois plus de textes en clair avec la méthode de la clique.
La meilleure attaque contre le DES complet à 16 rondes nécessite 247 textes en clair
choisis. Ceci peut être converti en une attaque à texte en clair connu, mais qui néces
site 255 textes en clairs connus. De plus cela requiert 237 opérations du DES durant
l’analyse.
La cryptanalyse différentielle marche contre le DES et d ’autres algorithmes similaires
avec des tables-5 constantes. L’attaque dépend fortement de la structures des tables-
S ; il se trouve que celles du DES sont optimisées contre la cryptanalyse différentielle.
L’attaque marche contre le DES sous tous ses modes opératoires - E C B , C B C , CFB
et O F B - avec la même complexité [178].
La résistance du DES peut être améliorée en augmentant le nombre de rondes. La
cryptanalyse différentielle (à texte en clair choisi) contre le DES avec 17 ou 18 rondes
prend à peu près le même temps que la recherche exhaustive [167]. Avec 19 rondes
ou plus, la cryptanalyse différentielle devient impossible car elle nécessite plus de 2 64
textes en clair choisis : rappelez-vous que le DES utilise des blocs de 64 bits, de sorte
qu’il n’y a que 2 64 textes en clair possibles11.
Voici quelques points importants. Premièrement, l’attaque est largement théorique. Le
temps énorme et les données requises pour monter une attaque cryptanalytique diffé
rentielle mettent celle-ci hors de portée de presque tout le monde: pour collecter les
données nécessaires à cette attaque, il faut chiffrer, au taux de 1,5 mégabit par seconde,
un flot de textes en clair choisis pendant presque trois ans. Deuxièmement, ce doit être
une attaque à texte en clair choisi. La cryptanalyse différentielle marche aussi pour une
attaque à texte en clair connu, mais vous devez parcourir toutes les paires « texte en
clair-texte chiffré » pour trouver celles qui conviennent. Pour un DES complet à 16
11. En général, on prouve q u ’un algorithm e résiste à la cryptanalyse différentielle en prouvant que
le nom bre de textes en clair nécessaires pou r l'attaque est plus grand que le nom bre de textes en clair
possibles.
12. J, Cryptanalyse différentielle et linéaire 307
rondes, cela rend l’attaque légèrement moins efficace que l’attaque exhaustive (l’at
taque cryptanalytique différentielle nécessite 2 5 5 ,1 opérations et l’attaque exhaustive
255 opérations). Tout le monde admet que le DES correctement réalisé est encore sûr
par rapport à la cryptanalyse différentielle.
Pourquoi le DES est-il si résistant à la cryptanalyse différentielle? Pourquoi les tables-
S sont-elles optimisées pour rendre cette attaque aussi difficile que possible? Pourquoi
comporte-t-il le nombre de rondes nécessaires mais ni plus ni moins? Parce que les
concepteurs étaient au courant. Don C o p p e r s m i t h d’IB M a récemment écrit [376,
379] :
« La conception tirait avantage de certaines techniques cryptanalytiques,

plus précisément la technique de « cryptanalyse différentielle » qui n’ap
paraissait pas dans la littérature publiée. Après des pourparlers avec la
NSA, il fut décidé que la divulgation des considérations utilisée pour la
conception révélerait la technique de cryptanalyse différentielle, une tech
nique puissante qui pouvait être utilisée contre de nombreux algorithmes
de chiffrement. Cela aurait altéré l’avantage compétitif sur d’autres pays
dont les Etats-Unis jouissaient dans le domaine de la cryptographie. »
Adi S h a m i r répondit à cela en mettant C o p p e r s m i t h au défi de dire qu’il n’avait pas

trouvé d’attaque plus puissante depuis lors. COPPERSMITH a choisi de rester silencieux
à ce propos [1431].
Cryptanalyse par clefs corrélées
Le tableau 12.3 donne le nombre de bits de décalage de la clef après chaque ronde : 2
bits après chaque ronde, excepté 1 bit après les rondes 1, 2, 9 et 16. Pourquoi?
La c r y p t a n a l y s e p a r c l e f s c o r r é l é e s examine les différences entre des clefs diffé
rentes, comme la cryptanalyse différentielle. Cette attaque est différente de toutes les
attaques déjà présentées : le cryptanalyste choisit une relation entre une paire de clefs,
mais ne choisit pas les clefs elles-mêmes. Les données sont chiffrées avec les deux clefs.
Dans la version à texte en clair connu, le cryptanalyste connaît le texte en clair et le
texte chiffré de données quelconques chiffrées avec la clef. Dans la version à texte en
clair choisi, le cryptanalyste a la possibilité de choisir les textes en clair chiffrés avec
les deux clefs.
Un DES modifié, où la clef est décalée de 2 bits après chaque ronde, est moins sûr.
Eli B i h a m a développé une attaque par clefs corrélées qui casse cette variante en
utilisant 2 1 7 clefs choisies - textes en clair choisis, ou 2 3 3 clefs choisies - textes en clair
connus [165, 169].
Cette attaque n’est pas réalisable, mais elle est intéressante pour trois raisons. Tout
d’abord, c ’est la première attaque contre le système de génération de sous-clefs de
l’algorithme. Deuxièmement, cette attaque est indépendante du nombre de rondes de
l’algorithme ; elle est tout aussi efficace sur le DES à 16, 32 ou 1000 rondes. Et troisiè
mement, le DES résiste à cette attaque. Les variations dans les rotations contrecarrent
la cryptanalyse par clefs corrélées.
Cryptanalyse linéaire
La c r y p t a n a l y s e l i n é a i r e est un autre type d ’attaque cryptanalytique inventée par
Mitsuru M a t s u i [1024, 1026, 1025]. Cette attaque utilise des approximations linéaires
pour décrire l’action d’un algorithme de chiffrement par blocs (en l’occurrence, le DES).
Cela veut dire que si vous combinez par ou exclusif une partie des bits du texte en clair,
une partie des bits du texte chiffré, puis les deux résultats ensembles, vous obtenez un
simple bit qui est la combinaison par ou exclusif de certains bits de la clef. Ceci est une
approximation linéaire qui est valide avec une probabilité p. Si p ^ 1/ 2 , il est possible
d’exploiter ce biais. En rassemblant des textes en clair et leurs textes chiffrés associés,
vous pouvez devinez la valeur des bits de la clef. Plus vous rassemblez de données, plus
votre clef supposée est fiable. Plus le biais est important, plus les chances de succès
sont grandes, pour la même quantité de données.
Comment trouver de bonnes approximations linéaires pour le D E S? Trouvez de bonnes
approximations linéaires sur une ronde, puis et joignez les ensembles12. Regardons les
tables- S. Il y a 6 bits en entrée et 4 en sortie. Les bits en entrée peuvent être combinés
de 63 manière utiles (2 6 — 1), et ceux en sortie peuvent être combinés de 15 manière
utiles. Maintenant, pour chaque table-5, vous pouvez estimez pour une entrée choisie
aléatoirement la probabilté qu’une combinaison par ou exclusif en entrée soit égale à
une combinaison par ou exclusif en sortie. S’il y a une combinaison présentant un biais
assez important, alors la cryptanalyse linéaire peut marcher.
Si les approximations linéaires ne sont pas biaisées, alors elles sont valides pour 32
des 64 entrée possibles. Je vous épargne les pages de tables, mais sachez que la table-
S la plus biaisée est la cinquième. Plus précisément, le deuxième bit est égal à la
combinaison par ou exclusif des 4 bits d ’entrée pour seulement 12 entrées. Ceci se
traduit par une probabilité de 3/16, ou un biais de 5/16, et constitue le biais le plus
extrême de toutes les tables-S1. ( S h a m i r avait remarqué cela [1430], sans trouver de
moyen de l’exploiter.)
La figure 12.8 montre comment faire de cela une attaque contre la fonction résultant
d’une ronde de DES. Le bit en entrée de la cinquième table-S est f>26 13- Les 4 bits
de sortie de la cinquième table-S sont Cn, c 1 g, C19 et c2o •Nous pouvons suivre le bit
f>26 de l’entrée à la table-S. Le bit a 26 est combiné par ou exclusif au bit K z^6 de
la sous-clef pour obtenir f>26. Et le bit X n devient a 2 6 via la permutation expansive.
Après la table-S, les 4 bits de sortie deviennent via la table-P 4 des bits de sortie de la
fonction résultant de la ronde: I 3 , lg , E14 et Y25. Cela signifie que l’équation suivante
est vérifiée avec probabilité 1/2 — 5/16 :
X n © L3 © L3 © 5^8 © E14 © Y25 — R i ,26
Les approximations linéaires de différentes rondes peuvent être combinées d’une ma
nière similaire à celle présentée pour la cryptanalyse différentielle. La figure 12.9 est
une approximation sur 3 rondes avec une probabilité de 1/2 —0,0061. Chaque approxi
mation est de qualité variable : la dernière est très bonne, la première est assez bonne,
et celle du milieu est mauvaise. Mais les trois approximations sur une ronde ensembles
donnent une très bonne approximation sur trois rondes.
12. Vous pouvez à nouveau ignorer les perm utations initiale et finale qui n ’affectent pas l’ attaque.
13. Je num érote les bits de gauche à droite et de 1 à 64. M a t s l 'I n ’ a pas tenu com pte de cette
convention avec le D E S, et il num érote ses bits de droite à gauche et de 0 à 63. C ela suffirait à vous
rendre fou.
12.J, Cryptanalyse différentielle et linéaire 309
F ig . 12.8 - Une approximation linéaire sur une ronde du DES.
L’attaque de base consiste à utiliser la meilleure approximation linéaire du DES à 16

rondes. Cela requiert 247 blocs de textes en clair connus, et donnera un bit de la clef.
Ce n ’est pas très utile. Si vous échangez le rôle du texte en clair et du texte chiffré, et
si vous utilisez le déchiffrement au lieu du chiffrement, vous pouvez obtenir deux bits
de la clef. Ce n ’est toujours pas très utile.
Il est posible d’affiner la technique. Utilisez une approximation linéaire sur 14 rondes
pour les rondes 2 à 15. Devinez les 6 bits de la sous-clef correspondant à la cinquième
table-S pour la première ronde et la dernière (cela fait 12 bits de la clef en tout). En
fait, vous effectuez 2 12 cryptanalysés linéaires en parallèle et vous sélectionnez la bonne
vis à vis des probabilités. Cela donne les 12 bits et 626 en plus, et en inversant texte en
clair et texte chiffré, on obtient 13 autres bits. Pour trouver les 30 bits restant, utilisez
une recherche exhaustive. Il y a d’autres astuces, mais le principe de base est là.
Utilisée contre le DES à 16 rondes, cette attaque permet de trouver la clef avec 243
textes en clair connus en moyenne. Une réalisation logicielle de cette attaque a décou
vert une clef de DES en 50 jours avec 1 2 stations de travail HP9735. C ’est l’attaque
la plus efficace contre le DES au moment d’écrire ces lignes.
La cryptanalyse linéaire dépend fortement de la structure des tables-S 1 et celles du
DES ne sont pas optimisées contre ce type d’attaques. En fait l’ordre des tables-S
choisi pour le DES figure parmi les 9 à 16 % de ceux qui offrent le moins de protection
B 17
A =[3,8,14,25] B = [8 ,14,25]
________ avec probabilité 1/2+6,1_________
F i g . 12.9 - Une approximation linéaire sur trois rondes du DES.
contre la cryptanalyse linéaire [1027]. Selon Don COPPERSMITH [376, 379], la résistence
à la cryptanalyse linéaire « ne faisait pas parti des critères de conception du DES ».
Soit ils n’avaient pas connaissance de la cryptanalyse linéaire, soit ils connaissaient une
autre technique encore plus puissante dont le critère de résistence prenait le dessus.
La cryptanalyse linéaire est plus récente que la cryptanalyse différentielle, et elle peut
connaître plus d ’améliorations de performances durant les prochaines années. Quelques
idées sont proposées dans [1281, 801], mais il n’est pas clair qu’elles puissent être
utilisées contre le DES complet. Cependant, elles fonctionnent très bien contre les
variantes avec moins de rondes.
12.5 Les critères réels de conception 311
Directions futures
Certains travaux ont visé à étendre le concept de cryptanalyse différentielle à un niveau
plus haut de différentielles [703, 168, 938, 858, 861]. Lars K n u d s e n utilise ce qu’il
appelle les différentielles partielles pour attaquer le DES à 6 rondes ; cela nécessite 32
textes en clair choisis et 20000 chiffrement [861]. C ’est encore trop récent pour savoir
si ces extensions faciliteront l’attaque du DES à 16 rondes.
Une autre voie d ’attaque est la c r y p t a n a l y s e d i f f é r e n t i e l l e - l i n é a i r e qui consite à
combiner la cryptanalyse différentielle et la cryptanalyse linéaire. Susan L a n G F O R D
et H e l l m a n ont une attaque contre le DES à 8 rondes qui trouve 10 bits de la clef
avec une probabilité de succès de 80 avec 512 textes en clair choisis et une probabilité
de succès de 95 avec 768 textes en clair choisis [949]. Après l’attaque, une recherche
exhaustive de l’espace des clefs restantes (246 clefs possibles) est nécessaire. Si cette
attaque est comparable en temps aux attaques précédentes, elle nécessite beaucoup
moins de textes en clair. Cependant, elle ne semble pas s’étendre facilement à plus de
rondes.
Mais cette attaque est encore récente et le travail continue. Il est possible qu’il y ait
une percée dans les années à venir. Il est possible que la combinaison de cette attaque
avec la cryptanalyse différentielle de haut niveau puisse porter ses fruits. Qui sait?
12.5 Les critères réels de conception

Une fois la cryptanalyse différentielle devenue publique, IB M publia les critères de
conception des tables-S' et des tables-P [376, 379]. Les critères pour les tables-S' sont:
Chaque table-S 1 prend 6 bits en entrée et 4 en sortie14.
Aucun bit de sortie d’une table-S' ne devrait s’approcher d’une fonction linéaire
des bits d ’entrée.
- Si l’on fixe les bits les plus à gauche et les bits les plus à droite d’une table-S1,
et si l’on fait varier les 4 bits du milieu, toutes les sorties possibles de 4 bits sont
obtenues exactement une fois.
- Si deux vecteurs d ’entrée à une table-S ne diffèrent que d ’un bit, les vecteurs de
sortie doivent différer d’au moins deux bits.
- Si deux vecteurs d’entrée à une table S ne diffèrent que par les deux bits du
milieu, les vecteurs de sortie doivent différer d’au moins deux bits.
Si deux vecteurs d’entrée à une table-S 1 diffèrent par les deux premiers bits et
sont identiques sur les deux derniers, les vecteurs de sortie ne doivent pas être
les mêmes.
- Pour toute différence non nulle entre deux vecteurs d’entrée, parmi les 32 paires
possibles de vecteurs présentant cette différence, au plus 8 doivent donner la
même différence en sortie.
Un critère similaire au précédent, mais dans le cas de trois tables-S 1 actives.

14. C ’était la taille m axim ale intégrable dans une pu ce avec la technologie de 1974.
312 Chapitre 12 Le DES
Les critères pour les tables-P sont r
Les quatre bits de sortie de la table .S' de la ronde i sont distribués de manière
que deux d’entre eux affectent les deux bits du milieu de la table-S^ de la ronde
i + 1 et que les deux autres en affectent les deux derniers bits.
- Les quatre bits de sortie de chaque table-S' affectent six autres tables S ; deux
d’entre eux n’affectent jamais la même table-S.
- Si le bit de sortie d’une table-S affecte l’un des deux bits du milieu d’une autre
table-S, alors aucun bit de sortie de cette autre table S ne peut affecter l’un des
bits du milieu de la première table-S.
L’article continue sur l’explication des critères. Il est assez facile de générer des tables-
S de nos jours, mais cela constituait une tâche hardue au début des années 1970. Une
citation de T u c h m a n révèle qu’ils ont fait des tourner des ordinateurs durant des mois
pour mitonner les tables S.
12.6 Variantes du DES

Surchiffrement DES
Certaines réalisations utilisent le DES triple (voir figure 12.10). Comme le DES n’est
pas un groupe, le texte chiffré résultant est plus difficile à retrouver par recherche
exhaustive : 2 1 1 1 tentatives au lieu de 256. Voir le paragraphe 8.2 pour plus de détails.
FiG. 12.10 DES triple
Le DES avec des sous-clefs indépendantes

Une autre variante utilise une sous-clef différente pour chaque ronde, au lieu de les
engendrer à partir d ’une seule clef de 56 bits [902]. Comme il faut 48 bits de clef à
12.6 Variantes du D E S SIS
chacune des 16 rondes, cela signifie que la longueur de clef de cette variante est de 768
bits. Cette variante augmenterait radicalement la difficulté d’une attaque exhaustive
contre l’algorithme; cette attaque aurait une complexité de 2 768.
Cependant, une attaque par collisions (voir § 15.1) est possible. Cela réduit la com
plexité de l’attaque à 2 384 ; ce qui est encore assez grand pour toute exigence de sécurité
concevable.
Bien que l’utilisation de sous-clefs indépendantes contrecarre la cryptanalyse linéaire,
la cryptanalyse différentielle s’applique encore à cette variante qui peut être cassée avec
261 textes en clair choisis (voir le tableau 12.15) [174, 178]. Il semble qu’il n’existerait
aucune modification du plan de génération de clefs qui puisse rendre le DES beaucoup
plus fort.
DESX
DESX est une variante du DES de la R S A D a t a S e c u r i t y , I n c . qui a été incluse
dans le programme de courrier électronique sûr M a i l S a f e en 1986 et la « boîte à
outils » B SA FE en 1987. Le D E S X utilise une technique appelée le blanchiment (voir
§ 15.6) pour embrouiller les entrées et les sorties du DES. En plus de la clef de DES de
56 bits, le D E SX a une clef de blanchiment de 64 bits. Ces 64 bits sont combinés par
ou exclusif au texte en clair avant la première ronde du DES. 64 bits supplémentaires,
calculés à l’aide d ’une fonction à sens unique à partir de la clef totale de 1 2 0 bits, sont
combinés par ou exclusif au texte chiffré après la dernière ronde [162]. Le blanchiment
rend le D E S X nettement plus fort que le DES contre une attaque exhaustive ; l’attaque
fera 2120/n opérations avec n textes en clair connus. Il augmente aussi la sécurité face
à la cryptanalyse différentielle et à la cryptanalyse linéaire ; ces attaques nécessitent
261 textes en clair choisis et 260 textes en clair connus respectivement [1350].
crypt(3)
CRYPrr(3 ) est une variante du DES que l’on trouve dans les systèmes U NIX. Elle est
principalement utilisée comme fonction à sens unique pour les mots de passe, mais elle
est aussi parfois utilisée pour le chiffrement. A la différence du DES, CRYPT(3) a une
permutation expansive qui dépend de la clef avec 2 1 2 permutations possibles. Le but
initial était d ’empêcher l’utilisation des puces DES disponibles dans le commerce pour
construire un casseur de mots de passe.
Le DES généralisé
Le DES généralisé (G D E S pour « Generaltzed DES >) a été inventé à la fois pour ac
célérer le DES et pour renforcer l’algorithme [1386, 1387]. La taille des blocs augmente
tandis que la quantité de calcul reste constante.
La figure 12.11 donne le diagramme du G DES. Le G D E S opère sur des blocs de taille
variable de texte en clair. Les blocs à chiffrer sont divisés en q sous-blocs de 32 bits
dont le nombre exact dépend de la taille globale (il est libre, mais doit être fixé pour
chaque réalisation). En général, q est égal à la taille de bloc divisé par 32.
La fonction f est calculée une fois par ronde sur le bloc le plus à droite. Le résultat
est combiné par ou exclusif avec toutes les autres parties, qui sont alors décalées
circulairement vers la droite. Le G D E S utilise un nombre variable de rondes, n. Il y a
Texte en clair
i i H i i
*o(I) V 2) *o(3) B 0(V
- “V f \ _
' ,r
t
i
x
^X 4 X
*!«> b,<3> B,(q-o
k2
B2l 0 * 2<2> j [ g 2(q-nj | b 7(q)
■\— _ —
■ ««
« tld) (2)
B, (3)
~ ~ r~
Texte chiffré
F i g . 12.11 - Aperçu du G D ES
une légère modification pour la dernière ronde, de manière à ce que le chiffrement et

le déchiffrement ne diffèrent que par l’ordre des sous-clefs (tout comme le DES). En
fait, si q = 2 et n — 16, c'est le DES.
B i h a m et S h a m i r [174, 175] ont montré qu’en utilisant la cryptanalyse différentielle,

le G DES avec q = 8 et n = 16 peut être cassé avec seulement 6 textes en clair
choisis. Si des sous-clefs indépendantes sont aussi utilisées, 16 textes en clair choisis
sont nécessaires. Le G D E S avec q = 8 et n = 22 peut être cassé avec 48 textes en clair
choisis, et casser le G D ES avec q = 8 et n = 31 ne nécessite que 500000 textes en clair
choisis. Même le G D E S avec q — 8 et n = 64 est plus faible que le DES ; il faut 249
textes en clair choisis pour le casser. En fait, tout schéma G D E S qui est plus rapide
que le DES est aussi moins sûr (voir le tableau 12.15).
Une variante de ce concept a récemment vu le jour [1593]. Il est probable qu’elle ne

soit pas plus sûre que le GDES original. En général, toute variante du DES à largeur
de bloc plus grande qui est plus rapide que le DES a de grandes chances d ’être aussi
moins sûre que le DES.
12.6 Variantes du D E S 315
DES avec d ’autres tables—S

D’autres modifications du DES sont centrées sur les tables-S. Certaines conceptions
rendent l’ordre des tables-S variable. D ’autres concepteurs ont rendu le contenu des
tables-S lui-même variable. B i h a m et S h a m i r montrèrent [177, 178] que la concep
tion des tables-S, ainsi que leur ordre lui-même étaient optimisés pour résister à la
cryptanalyse différentielle :
« Le changement de l’ordre des huit tables-S du DES (sans changer leur

valeur) rend aussi le DES nettement plus faible: le DES avec 16 rondes
d ’un autre ordre particulier peut être cassé en 238 étapes environ... On
peut montrer que le D ES avec des tables-S aléatoires est très facile à
casser. Même des changements minimes d’une entrée d’une table-S du DES
peuvent rendre le DES plus facile à casser. »
Les tables-S du D ES n’ont pas été optimisées contre la cryptanalyse linéaire. Il existe
de meilleures tables-S que celles qui vont avec le DES, mais choisir en aveugle de
nouvelles tables-S est une mauvaise idée.
Le tableau 12.15 [174, 176] donne la liste de quelques modifications du DES et le
nombre de textes en clair choisis nécessaires pour en faire la cryptanalyse différentielle.
Une modification non évoquée dans la liste qui consiste à combiner les moitiés de droite
et de gauche en utilisant l’addition modulo 24 au lieu du ou exclusif est 2 17 fois plus
difficile à casser que le DES [690].
Tab. 12.15 Attaques par cryptanalyse différentielle contre des variantes du DES
Opération modifiée Nombre de textes en clair choisis1”

DES complet (aucune modification) 247 (clef dépendante)
Permutation-P Ne peut pas être restreint
Permutation identité 2I9
Ordre des tables-S 2ss
Ou exclusif par addition 239, 231
Tables S :
Aléatoires 218 --- 220
Permutations aléatoires 2S3 _ 241
Une entrée 233
Tables uniformes 226
Suppression de l’expansion E 226
Ordre de E et ou exclusif de sous-clef 244
G D E S (largeur q = 8) :
16 rondes 6, 16
64 rondes 249 (clef indépendante)
î n t r t • » • ■ » »
le o u e x c l u s i f est remplacé par l’addition ; des entrées séparées par un trait d ’union
indiquent l’intervalle du nombre de textes en clair choisis nécessaires en fonction
des nombres aléatoires.
RDES
RDES est une variante du DES où l’échange des moitiés gauche et droite n’est pas
toujours fait, cela dépend de la clef [893]. Les échanges sont fixés en fonction de la clef
uniquement. Cela veut dire qu’il y a 215 possiblités pour les 15 échanges dépendants de
la clef, et que la variante ne résiste pas à la cryptanalyse différentielle [817, 894, 119].
Le R D E S possède de nombreuses clefs faibles. En fait, presque toutes les clefs sont
plus faibles qu’une clef typique du DES. Cette variante ne devrait pas être utilisée.
Une meilleure idée consiste à n ’échanger qu’à l’intérieur de la moitié de droite au début
de chaque ronde. Une autre idée préférable consiste à faire dépendre les échanges des
données en entrée au lieu d’une fonction statique de la clef. 11 y a nombre de variantes
possibles [814, 815]. Dans le R D E S-1, les échanges dépendent des données de par le
mot de 16 bits au début de chaque ronde. Dans le R D ES-2, il y a échange des octets
dépendant des données au début de chaque ronde après les échanges sur 16 bits comme
dans le R D E S-1. Et ainsi de suite jusqu’au R D ES-4. R D ES-1 est sûr à la fois contre
la cryptanalyse différentielle [815] et la cryptanalyse linéaire [1145]. On peut présumer
que le R D E S-2 et les versions suivantes le sont aussi.
snDES
Un groupe de chercheur koréens, mené par Kwangjo K i m , a essayé de trouver un jeu
de tables-S sûres de manière optimale à la fois contre la cryptanalyse différentielle et
la cryptanalyse linéaire. Leur première proposition, connue sous le nom de s2DES, fut
présentée dans [835] et on prouva qu’elle était pire que le DES en ce qui concerne la
cryptanalyse différentielle [857, 858], Leur proposition suivante, s3DES fut présentée
dans [838] et on prouva qu’elle était pire que le DES en ce qui concerne la cryptanalyse
linéaire [854, 1498, 1535, 858, 839]. B i h a m suggéra un changement mineur rendant le
.s3DES sûr à la fois contre la cryptanalyse linéaire et la cryptanalyse différentielle [172].
Le groupe est retourné à ses ordinateurs et a développé de meilleures techniques pour
la conception de tables-S [837, 840]. Ils ont proposé par la suite le s4DES [836] et le
s5DES [839, 955].
Le tableau 12.16 donne les tables-S du .s3DES avec les tables-S 1 et 2 inversées, qui
sont sûres à la fois face à la cryptanalyse différentielle et la cryptanalyse linéaire. Insérer
cette variante dans un DES triple irritera à coup sûr les cryptanalystes.
Le DES avec des tables—S dépendantes de la clef

Les cryptanalysés différentielle et linéaire ne marchent que si le cryptanalyste connaît
la composition des tables S’ . Si les tables-S sont dépendantes de la clef et choisie par
une méthode cryptographiquement sûre, alors les cryptanalysés différentielle et linéaire
sont bien plus difficiles. N’oubliez pas cependant que des tables-S aléatoires ont des
caractéristiques différentielle et linéaire assez pauvres ; même si elles sont secrètes.
Voici une méthode pour utiliser une clef additionnelle de 48 bits afin de générer des
tables-S résistantes à la fois aux cryptanalysés différentielle et linéaire [172].
1. Réordonner les tables S : 2, 4, 6, 7, 3, 1, 5, 8.
2. Sélectionner 16 des bits restants de la clef. Si le premier bit est 1, intervertir

les deux premières lignes de la table-S 1 avec les deux dernières lignes de la
12.6 Variantes du D E S 317
Tab. 12.16 - Tables-S du s3DES où les tables-S 1 et 2 sont renversées
Table-S 1:
13 14 0 3 10 4 7 9 11 8 12 6 1 15 2 5
8 2 11 13 4 1 14 7 5 15 0 3 10 6 9 12
14 9 3 10 0 7 13 4 8 5 6 15 11 12 1 2
1 4 14 7 11 13 8 2 6 3 5 10 12 0 15 9
Table-S 2:
15 8 3 14 4 2 9 5 0 11 10 1 13 7 6 12
6 15 9 5 3 12 10 0 13 8 4 11 14 2 1 7
9 14 5 8 2 4 15 3 10 7 6 13 1 11 12 0
10 5 3 15 12 9 0 6 1 2 8 4 11 14 7 13
Table-S 3:
13 3 11 5 14 8 0 6 4 15 1 12 7 2 10 9
4 13 1 8 7 2 14 11 15 10 12 3 9 5 0 6
6 5 8 11 13 14 3 0 9 2 4 1 10 7 15 12
1 11 7 2 8 13 4 14 6 12 10 15 3 0 9 5
Table-S 4:
9 0 7 11 12 5 10 6 15 3 1 14 2 8 4 13
5 10 12 6 0 15 3 9 8 13 11 1 7 2 14 4
10 7 9 12 5 0 6 11 3 14 4 2 8 13 15 1
3 9 15 0 6 10 5 12 14 2 1 7 13 4 8 11
Table-S 5:
5 15 9 10 0 3 14 4 2 12 7 1 13 6 8 U
6 9 3 15 5 12 0 10 8 7 13 4 2 11 14 1
15 0 10 9 3 5 4 14 8 11 1 7 6 12 13 2
12 5 0 6 15 10 9 3 7 2 14 11 8 1 4 13
Table-S 6:
4 3 7 10 9 0 14 13 15 5 12 6 2 11 1 8
14 13 11 4 2 7 1 8 9 10 5 3 15 0 12 6
13 0 10 9 4 3 7 14 1 15 6 12 8 5 11 2
1 7 4 14 11 8 13 2 10 12 3 5 6 15 0 9
Table-S 7:
4 10 15 12 2 9 1 6 11 5 0 3 7 14 13 8
10 15 6 0 5 3 12 9 1 8 11 13 14 4 7 2
2 12 9 6 15 10 4 1 5 11 3 0 8 7 14 13
12 6 3 9 0 5 10 15 2 13 4 14 7 11 1 8
Table-S 8:
13 10 0 7 3 9 14 4 2 15 12 1 5 6 11 8
2 7 13 1 4 14 11 8 15 12 6 10 9 5 0 3
4 13 14 0 9 3 7 10 1 8 2 11 15 5 12 6
8 11 7 14 2 4 13 1 6 5 9 0 12 15 3 10
table- S 1. Si le deuxième bit est 1, intervertir les huits premières colonnes de

la tables-S 1 avec les huits dernières. Faire de même pour la table S 2 avec les
troisième et quatrième bits. Et ainsi de suite pour les tables-S 3 à 8.
3. Prendre les 32 bits restants. Combiner les quatre premiers par ou exclusif avec
chaque entrée de la table-S 1, les quatre suivants avec chaque entrée de la table-
S 2, et ainsi de suite.
La complexité d ’une cryptanalyse différentielle contre ce système est 251, la complexité

d’une cryptanalyse linéaire est 253, la complexité d ’une recherche exhaustive est 2102.
Ce qui est appréciable avec cette variante est qu’elle peut être réalisée avec du matériel
existant. Plusieurs vendeurs de puces DES proposent des puces avec des tables-S1
chargeables. On peut appliquer cette méthode de génération des tables-S1en dehors de
la puce et les charger ensuite. Les cryptanalysés différentielle et linéaire sont infaisables
vu le nombre de textes en clairs connus ou choisis qu’elles mettent en jeu, et une
recherche exhaustive est inconcevable— tout cela sans pénaliser la rapidité.
% _ - _
12.7 A quel point le DES est-il sûr de nos
jours ?
La réponse est à la fois facile et difficile. Dans la réponse facile, on ne regarde que
la longueur de la clef (voir § 7.1). Une attaque exhaustive menée par une machine
spécialement dédiée à cela ne prend que 3,5 heures en moyenne et la machine ne coûte
que un million de dollars en 1993 [1599, 1600]. Le DES est si répendu qu’il est naïf de
croire que la NSA et ses homologues n’ont pas construit une telle machine. Et rappelez
vous que le coût sera divisé par 5 tous les dix ans. Le DES deviendra de moins en moins
sûr avec le temps qui passe.
Dans la réponses difficile, on essaye d ’estimer les techniques cryptanalytiques. La cryp
tanalyse différentielle était connue de la NSA longtemps avant le milieu des années
1970, quand le DES devint un standard pour la première fois. Il est naïf de croire que
les théoriciens de la NSA sont resté inactifs depuis lors ; ils ont certainement déve
loppé des techniques cryptographiques nouvelles qui s’appliquent au DES. Mais il n’y
a aucun fait, seulement des rumeurs.
Winn SCHWARTAU a écrit que la NSA avait construit une machine à casser le DES
massivement parallèle dès le milieu des années 1980 [1409]. Au moins une telle ma
chine a été construite par Harris C o r p avec un C r a y Y -M P comme superviseur. U
existe probablement une série d ’algorithmes permettant de réduire la complexité d’une
attaque exhaustive de plusieurs ordres de grandeur. Des algorithmes contextuels, ba
sés sur le fonctionnement interne du DES, peuvent éliminer des ensembles de clef
possibles sur la base de solutions partielles. Des algorithmes statistiques réduisent la
taille effective de la clef davantage encore. Et d’autres algorithmes essayent des clefs
probables— mots, code A SC II imprimable, etc. (voir § 8.1). La rumeur dit que la NSA
peut casser le DES en 3 à 15 minutes, selon la puissance de calcul dont ils disposent.
Et ces machines ne coûteraient que 50000 $ chacune en grosse quantité.
Une rumeur différente insinue que la N SA possède une large bibliothèque de textes en
clair et de textes chiffrés, ces experts peuvent effectuer une sorte de calcul statistique
et se diriger ensuite vers une batterie de disques optiques pour récupérer la clef.
12.7 A quel point le D E S est-il sûr de nos jours? 319
Ce ne sont que des rumeurs, mais elles ne me rassurent pas à propos du DES. Il a
juste été une cible trop importante pendant trop longtemps. Presque n’importe quelle
modification du DES sera plus ennuyeuse ; il se peut que l’algorithme résultant soit
plus facile à casser, mais la N SA n’aura peut-être pas les ressources pour se consacrer
au problème.
Ma recommandation est d ’utiliser la construction de B i h a m pour des tables -S’ dé
pendantes de la clef. Elle est facile à réaliser en logiciel et dans les puces qui ont des
tables- S chargeables, et elle présente les mêmes performances que le DES. Elle acroît
la résistance de l’algorithme contre une attaque exhaustive, rend les cryptanalysés dif
férentielle et linéaire plus difficiles, et donne à la N SA quelque chose d’aussi solide que
le DES— mais différente— pour s’occuper.
Chapitre 13
Autres algorithmes
de chiffrement pair blocs
13.1 Lucifer
À la fin des années 1960, IB M lança un programme de recherche en cryptographie,
du nom de L u c i f e r , mené p a r Horst F e i s t e l puis p a r Walt T u c h m a n . L u c i f e r est
aussi un algorithme de chiffrement par blocs né de ce projet au début des années 1970
[1489, 1491], En fait, il existe au moins deux algorithmes différents portant ce nom
[554, 1499]. Et [554] laissait quelques lacunes dans les spécifications. Tout cela a créé
pas mal de confusion.
LU CIFER est un réseau de substitution-permutation constitué de briques de base simi
laires au DES. Dans le DES, la sortie de la fonction / est combinée par ou exclusif
avec l’entrée de la ronde précédente, ce qui donne l’entrée de la ronde suivante. Les
tables- S de L u c i f e r prennent quatre bits en entrée et quatre bits en sortie ; l’entrée
des tables-S est une permutation au niveau des bits de la sortie des tables-S de la
ronde précédente ; l’entrée des tables-S de la première ronde est le texte en clair. Un bit
de la clef est utilisé pour choisir la table-S à utiliser parmi deux tables-S possibles1.
Contrairement au D ES, il n’y a pas de moyens d’échange entre les rondes, et les blocs
ne sont pas coupés en deux. L u c i f e r est doté de 16 rondes, des blocs de 128 bits, et
d’une gestion de clef plus simple que celle du DES.
En utilisant la cryptanalyse différentielle contre la première version de L u c i f e r , B i h a m
et S i i a m i r ont montré que L u c i f e r avec des blocs de 32 bits et 8 rondes pouvait
être cassé par 40 textes en clair choisis et 229 étapes; la même attaque peut casser
L u c i f e r avec des blocs de 128 bits et 8 rondes par 60 textes en clair choisis et 253
étapes. Une autre attaque cryptanalytique différentielle cassa L u c i f e r à 128 bits et
18 rondes par 24 textes en clair choisis et 221 étapes. Toutes ces attaques utilisent les
tables-S1solides du DES. En utilisant la cryptanalyse différentielle contre la deuxième
mouture, ils trouvèrent que les tables-S1 étaient nettement plus faibles que celles du
DES. Des analyses plus poussées ont montré que plus de la moitié des clefs possibles
n’étaient pas sûres [119]. L’attaque à clefs corrélées peut casser L u c i f e r à 128 bits,
1. Dans L u c ife r , cela est représenté par une seule t a b le -T avec 9 bits en entrée et 8 bits en sortie.
322 Chapitre 13 Autres algorithmes de chiffrement par blocs
avec n’importe quel nombre de rondes, par 233 clefs choisies-textes en clair choisis ou
par 265 clefs choisies-textes en clair connus [165]. La deuxième version de L u c ife r est
encore moins fiable [177, 178, 119].
Certaines personnes croient que L u c i f e r est plus sûr que le DES à cause de la longueur
de la clef et du manque de résultats publiés. Ce n’est clairement pas le cas.
Aux Etats-Unis, L u c i f e r est couvert par plusieurs brevets : [555, 557, 556, 1490]. Tous
ont expiré.
13.2 Madryga
W.E. M adryga pro po sa cet algorithm e de chiffrem ent p a r blocs en 1984 [1008]. Il
est efficace p o u r des réalisations logicielles : il n ’y a pas de perm utations gênantes, et
toutes les opérations sont effectuées sur des octets.
Ses objectifs de conception méritent d ’être cités :
1. Le texte en clair ne peut pas être obtenu à partir du texte chiffré sans l’usage de
la clef. (Cela veut seulement dire que l’algorithme est sûr.)
2. Le nombre d’opérations nécessaires pour déterminer la clef à partir d ’un échan

tillon de textes en clair et textes chiffrés doit être égal (statistiquement) au pro
duit du nombre d’opérations pour un chiffrement par le nombre de clefs possibles.
(Cela veut dire qu’il ne peut pas y avoir d ’attaque à texte en clair plus efficace
que t’attaque exhaustive.)
3. La connaissance de l’algorithme ne doit pas diminuer son niveau de sécurité.

(Toute la sécurité réside dans la clef.)
4. Un changement d’un bit de la clef doit produire des changements radicaux dans
le texte chiffré d ’un même texte en clair, et un changement d’un bit du texte en
clair doit produire des changements radicaux dans le texte chiffré avec une même
clef. (On appelle cela l’effet d’avalanche.)
5. L’algorithme doit contenir une combinaison non commutative de substitutions et

permutations.
6. L’algorithme doit contenir des substitutions et des permutations contrôlées à la

fois par les données d ’entrée et par la clef.
7. Des groupes de bits redondants dans le texte en clair doivent être complètement
masqués dans le texte chiffré.
8. La longueur du texte chiffré doit être la même que celle du texte en clair.
9. Il ne doit pas y avoir la moindre relation simple entre les clefs possibles et leurs
effets sur le texte chiffré.
10. Toutes les clefs possibles doivent donner un système de chiffrement sûr. (Il ne
doit pas y avoir de clefs faibles.)
11. La longueur de la clef et celle du texte doivent être ajustables pour satisfaire les
exigences des applications et les niveaux de sécurité requis.
13.2 M adryga 323
12. L ’algorithme doit être réalisable efficacement sur les gros ordinateurs centraux,
les mini-ordinateurs, les micro-ordinateurs et sur les dispositifs logiques2.
Le DES satisfaisait déjà les objectifs 1 à 9, mais les trois derniers étaient neufs. En
faisant l’hypothèse que le meilleur moyen d ’attaquer l’algorithme est l’attaque exhaus
tive, la longueur de clef variable devait certainement faire taire les objections de ceux
qui pensaient qu’une clef de 56 bits était trop courte. Ils pouvaient réaliser l’algorithme
avec la longueur de clefs qu’ils désiraient. Et, pour tout ceux qui avaient déjà essayé
une réalisation logicielle du DES, un algorithme qui tenait compte des réalisations
logicielles était le bienvenu.
Description de Madryga
M a d r y g a a deux cycles imbriqués. Le cycle externe est répété 8 fois (bien que ce
nombre puisse être augmenté si la sécurité le justifie) et consiste en une application du
cycle interne au texte en clair. Le cycle interne est celui qui transforme le texte en clair
en texte chiffré et il est répété une fois pour chaque bloc de 8 bits (octet) du texte en
clair. Donc, cet algorithme passe 8 fois successivement sur tout le texte en clair.
Une itération du cycle interne opère sur une fenêtre de 3 octets de données, appelée le
cadre courant (voir la ligure 13.1). Cette fenêtre avance d ’un octet à chaque itéra
tion3. Les 2 premiers octets du cadre courant sont décalés circulairement ensemble d’un
nombre de positions variable, tandis que le dernier octet est combiné par ou exclusif
avec certains bits de la clef. A mesure que le cadre courant avance, tous les octets sont
successivement décalés circulairement et combinés par ou exclusif avec les éléments de
la clef. Les rotations successives se superposent avec les résultats des ou exclusif et
des rotations précédentes, et les résultats du ou exclusif sont utilisés pour influencer
la rotation. Cela rend tout le processus réversible.
Comme chaque octet influence les 2 octets à sa gauche et un octet à sa droite, après
8 passes chaque octet du texte chiffré dépend des 16 octets à sa gauche et des 8 octets
à sa droite.
Lors du chiffrement, chaque itération du cycle interne démarre le cadre courant à
l’avant-dernier octet du texte en clair et avance circulairement jusqu’au troisième oc
tet avant la fin. Tout d ’abord, la clef entière est combinée par ou exclusif avec une
constante aléatoire, puis décalée circulairement à gauche de 3 bits. Les 3 bits de poids
faible de l’octet de poids faible du cadre courant sont mémorisés ; ils contrôleront la
rotation des 2 autres octets. Après cela, l’octet de poids faible du cadre courant est
combiné par ou exclusif avec l’octet de poids faible de la clef. Ensuite, les 2 octets de
poids fort sont décalés ensemble circulairement vers la gauche d’un nombre variable de
bits (de 0 à 7). Enfin, le cadre courant est décalé vers la droite d ’un octet et tout le
processus est répété.
Le rôle de la constante aléatoire est de transformer la clef, quelle qu’elle soit, en une
suite pseudo-aléatoire. La longueur de cette constante doit être égale à la longueur de
la clef, et doit être la même pour tous ceux qui veulent communiquer entre eux. Pour
une clef de 64 bits, M a d r y g a recommande la constante : 0x0FlE2D3C4B5A6978.
Le déchiffrement est le processus inverse. Chaque itération du cycle interne démarre le
cadre courant au troisième octet avant la fin du texte chiffré, et avance circulairement
2. En fait, les fonctions utilisées dans l’algorithm e se limitent au o u e x c lu s if et aux décalages.
3. Les données sont considérées com m e circulaires quand on traite les 2 derniers octets.
Texte 1 2 3 4 5 6 TL-2 TL-1 TL
Déplacement
du cadre WF(1) WF(2) WF(3)
courant
8 bits 8 bits 8 bits
RQT
Amplitude
Transposition Mot à décaler
-du décalage
16 bits 3 bits
Translation
' 8 bits
\ ©
Clef 1 2 3 KL
® i
Empreinte 1 2 3 KL
de clef
F ig . 13.1 - Une itération de M adryga
dans la direction inverse jusqu’au deuxième octet avant la fin du texte chiffré. La clef
et les 2 octets de texte chiffré sont décalés vers la droite. Et le ou exclusif est effectué
avec les rotations.
Cryptanalyse de Madryga
Les chercheurs de la « Queensland. University of Technology » [676] ont examiné
M a d r y g a ainsi que d’autres algorithmes de chiffrement par blocs. Ils observèrent que
l’algorithme ne montrait pas de signes d ’effet d ’avalanche texte en clair-texte chiffré.
De plus, il y avait un plus haut pourcentage de 1 que de 0 dans leurs textes chiffrés de
test.
Bien que je ne connaisse pas d’analyse formelle de l’algorithme, une évaluation rapide
faite par Eli B i i i a m concluait ainsi [167] :
L’algorithme ne contient que des opérations linéaires (rotations et ou ex
clusif), qui sont légèrement modifiées en fonction des données.
Il n’y a rien qui vaille les solides tables-S du DES.
De plus, la parité de tous les bits du texte en clair et du texte chiffré est
une constante qui ne dépend que de la clef. Donc, si vous avez un texte en
clair et son texte chiffré correspondant, vous pouvez prédire la parité du
texte chiffré de n’importe quel texte en clair.
Rien de bien accablant en soi, mais cela ne me laisse pas une bonne impression de cet
algorithme. J’éviterais d ’utiliser M a d r y g a .
13.3 New DES 325
13.3 NewDES
Le N ew D E S a été conçu en 1985 par Robert S c o t t comme une alternative possible
au DES [1410, 368]. L’algorithme n’est pas une variante du DES comme son nom
pourrait le laisser entendre. Il manipule des blocs de 64 bits de texte en clair mais
il a une clef de 120 bits. Il est plus simple que le DES : il n’y a pas de permutations
initiale ni finale, et toutes les opérations sont sur des octets entiers -— à aucun moment,
l’algorithme ne lit, n’écrit ou ne permute le moindre bit individuellement. (En réalité,
NewDES n’a rien à voir avec une nouvelle version du DES, le nom est malheureux.)
Le bloc de texte en clair est divisé en sous-blocs de 8 octets: Bo, B\, ... , Be, B7.
Ensuite les blocs sont soumis à 17 rondes. Chaque ronde a 8 étapes. A chaque étape,
un des sous-blocs est combiné par ou exclusif avec une partie de la clef (il y a une
exception), remplacé par un autre octet calculé par une fonction / et ensuite combiné
par ou exclusif avec un autre sous-bloc pour devenir ce sous-bloc. La clef de 120 bits
de long est divisée en 15 sous-blocs: K 0, K i, ... , A i 3 , K\4. Le processus est plus facile
à comprendre visuellement qu’à décrire. La figure 13.2 décrit l’algorithme N ewDES.
La fonction f est obtenue à partir de la Déclaration d’indépendance américaine.
Voir [1410] pour une description plus détaillée.
S c o t t a montré que chaque bit du texte en clair affecte chaque bit du texte chiffré
après seulement 7 rondes. Il a aussi analysé la fonction f et n’a pas trouvé de défauts
évidents. Charles C o N N E L L [222] a remarqué que le N ew D E S a la même propriété
de complémentarité de clef que le DES : si E k { A4) = C alors E K>(A4') — C'. Cela
réduit le nombre d’étapes nécessaires pour une attaque exhaustive de 2 120 à 2 119.
B i h a m a remarqué que tout changement d ’un octet entier, appliqué à tous les octets
de la clef et, tous les octets de données excepté B 5, jouit d’une autre propriété de
complémentarité [167]. Ce qui réduit le nombre d’étapes nécessaires pour une attaque
exhaustive à 2 112.
Ce n’est pas bien inquiétant, mais l’attaque à clefs corrélées de B i h a m peut casser
NewDES avec 233 clefs choisies— textes en clair choisis en 24s étapes [114]. Bien que
cette attaque soit coûteuse en temps de calcul et largement théorique, elle rend le
NewDES nettement plus faible que le DES.
13.4 FEAL
FEAL a été conçu par Akihiro S h i m i z u et Shoji M i y a g u c h i , de N T T J a p o n [1442].
Il utilise une taille de blocs de 64 bits et une clef de 64 bits. L ’idée était de concevoir
un algorithme similaire au D ES mais où chaque ronde serait plus sûre que le DES.
Avec moins de rondes, l’algorithme irait plus vite. Malheureusement, la réalité est bien
en deçà des buts de conception.
Description de FEAL
La figure 13.3 donne le schéma d ’une ronde de l’algorithme. Le processus démarre avec
un bloc de 64 bits de données (soit du texte en clair, soit du texte chiffré). Au départ,
le bloc de données est combiné par ou exclusif avec les 64 bits de la clef. Ensuite le bloc
de données est coupé en deux moitiés (gauche et droite). La moitié gauche est combinée
par ou exclusif avec la moitié droite pour donner une nouvelle moitié droite, et les deux
Ronde 1 BO fil fi2 fi3 fi4 B5 B6 B1
fiO fil B2 B3 fi4 fi5 fi6 B1
F ig. 13.2 - Algorithme N ew D E S
moitiés passent à travers n rondes (4 à l’origine). À chaque ronde la moitié droite est
combinée avec 16 bits dérivés de la clef (en utilisant la fonction / ) et combinée par ou
exclusif avec la moitié gauche pour former la nouvelle moitié droite. La moitié droite
originale (avant la ronde) forme la nouvelle moitié gauche. Après n rondes (rappelez-
vous de ne pas échanger les moitiés gauche et droite après la ne ronde) la moitié gauche
est à nouveau combinée par ou exclusif avec la moitié droite pour former une nouvelle
moitié droite et ensuite les moitiés gauche et droite sont assemblées pour former un
134 FEAL 327
tout de 64 bits. Le bloc de données est combiné par ou exclusif avec 64 bits dérivés de
la clef, et l’algorithme se termine.
( V e x te en clair {Texte chiffré})

(K 8, K 9, K 10, K 11)
64 bits
{(K 12, K 1 3 , K 14, K+5)}
64 bits
32 bits 32 bits
L 0 { f l8 } R 0 {L&]
L 0 {/? 8 ) £ KQ[ K7)

/? 0 {L 8 }
f
L 1 {/? 7}
£ K\{ K6]
Rl { L7]
f
L7{ Rl )
£ K7[ K0}
R 7 { L 1}
f
R8{ L0} ■0
L 8 {/? 0 }
64 bits (K 12, K 13, K 14, K 15)
- { ( K 8 , K 9, K 10, K 1 1 )}
{}: Déchiffrement
(^Texte chiffré {Texte en clair}^)
F ig. 13.3 - Une ronde de F E A L
La fonction / prend 32 bits des données et 16 bits dérivés de la clef et mélange le

tout. Le bloc de données est divisé en morceaux de 8 bits, ensuite les morceaux sont
combinés par ou exclusif et se remplacent les uns les autres jusqu’à ce que cela sorte
par l’autre bout. La figure 13.4 décrit la fonction / . Les deux fonctions ,S'o et Si sont
définies par :
So{a,b) = décalage circulaire à gauche de 2 bits((a + b) mod 256)
Si(a,b) = décalage circulaire à gauche de 2 bits((o + 6 + 1 ) mod 256).
Le même algorithme est utilisé pour le chiffrement et le déchiffrement. La seule diffé

rence est que, lors du déchiffrement, les clefs dérivées doivent être utilisées dans l’ordre
inverse.
La figure 13.5 décrit la fonction permettant d’obtenir les clefs dérivées. D’abord, la clef
de 64 bits est divisée en deux. Les moitiés sont combinées par ou exclusif et soumises à
la fonction fk comme indiqué sur le diagramme. La figure 13.6 décrit la fonction fk- Les
deux entrées de 32 bits sont divisées en blocs de 8 bits puis combinées et substituées
So «0
f (a, b) ai , a
TlX e * — ©■ a2
32 bits
Cl\, b j . 8 bits
Remarquez que a est partagé en 4 sous - chaînes de 8 bits a,, a2, a3, a4.
F i g . 13.4 - Fonction f
comme indiqué. So et Si sont définies comme ci-dessus. Les blocs de 16 bits de clef
sont alors utilisés dans l’algorithme de chiffrement/déchiffrement.
Sur un processeur 80286 cadencé à 10 MHz, une réalisation en assembleur de F E A L -
32 peut chiffrer les données à la vitesse de 220 kilo-bits par seconde. F E A L - 64 peut
chiffrer à la vitesse de 120 kilo-bits par seconde [1110].
F i g . 13.5 - Plan de génération de clef de FE A L

1S-4 FEAL 329
a 32 bits
f K («’b>
50 (X, ,X2 ) = rot2((X, + X2 ) mod 256)
5 i (X ,,X 2) = rot2((X, + X2 + 1 ) mod 256)
Xj et X2 : entrées de 8 bits
SQet Si : résultats de 8 bits
r o t2 (r ) : décalage circulaire à gauche de 2 bits de T
F ig . 13.6 - Fonction fk
Cryptanalyse de FEAL
FEAL avec 4 rondes, appelé F E A L -4 , a été cryptanalysé avec succès au moyen d’une
attaque à texte en clair choisi [458] et a été démoli par la suite [1139]. Cette dernière
attaque, lancée par Sean M u r p h y , a été la première attaque par cryptanalyse dif
férentielle publiée et n’avait recours qu’à 20 textes en clair choisis. Les concepteurs
revinrent à la charge avec un F E A L à 8 rondes [1443, 1444, 1114] dont cryptanalyse
fut annoncée à la conférence SECURICOM’89 par B i h a m et S h a m i r [1419]. Une autre
attaque à texte en clair choisi utilisant 10000 chiffrements [612] obligea les concepteurs
à abandonner F E A L —8 et à concevoir F E A L -N [1109, 1110] avec un nombre variable
de rondes (plus grand que 8, bien sûr).
B i h a m et S h a m i r appliquèrent leurs techniques de cryptanalyse différentielle contre
FE A L -N et trouvèrent q u ’ils pouvaient casser F E A L -N plus rapidem ent que par
recherche exhaustive (avec m oins de 264 chiffrements de textes en clair choisis) pour
les versions de l ’algorithm e avec m oins de 32 rondes [176]. Il fallait 228 textes en clair
choisis ou 246,5 textes en cla ir connus p o u r casser F E A L -16. Il fallait 2000 textes en
clair choisis ou 237,5 textes en cla ir connus p o u r casser F E A L - 8. F E A L -4 peut être
cassé avec seulement 8 textes en cla ir choisis, sélectionnés soigneusement.
Les concepteurs de F E A L ont aussi défini F E A L —N X, une variante de FE A L, pour
accepter des clefs de 128 bits (voir la figure 13.7) [1107, 1110]. B i h a m et S h a m i r ont
montré que F E A L -N X avec une clef de 128 bits est aussi facile à casser que F E A L -N
avec une clef de 64 bits, quelle que soit la valeur de N [176]. Récemment, F E A L -N (X )S
a fait son apparition, il renforce F E A L grâce à une fonction dynamique d’interversion.
F ig. 13.7 - Plan de génération de clefs de F E A L —N X
Il y a plus. Une autre attaque contre F E A L -4 ne nécessitant que 1000 textes en clair
connus et ne nécessitant que 20 000 textes en clair connus contre F E A L -8 fut publiées
dans [1524]. D ’autres attaques se trouvent dans [1557, 1558]. L a meilleure attaque, est
celle de Mitsuru M a t s u i et Atsuhiro Y a m a g i s h i [1028]. C ’est la première utilisation
de la cryptanalyse linéaire et elle peut casser F E A L -4 avec 5 textes en clair connus,
13.5 REDOC 331
FEAL -6 avec 100 textes en clair connus, et F E A L —8 avec 215 textes en clair connus.
Chaque fois que quelqu’un trouve une nouvelle attaque cryptanalytique, il semble qu’il
assaye toujours sur F E A L en premier.
Brevets
FEAL est breveté aux Etats-Unis [1445] et des brevets sont en attente en Angleterre,
en France et en Allemagne. Toute personne désirant une licence pour cet algorithme
doit contacter: Intellectual Property Department, NTT, 1-6 Uchisaiwai-cho,
1-chome, Chiyada-ku, 100 Japan.
13.5 REDOC
REDOC II est un autre algorithme de chiffrement par blocs, conçu par Michael W O O D
pour C r y p t e c h , I n c . [887, 234]. Il a une clef de 20 octets (160 bits) et manipule des
blocs de 80 bits.
REDOC II effectue toutes ses manipulations — permutations, substitutions, ou ex
clusif avec la clef — au niveau des octets, ce qui rend l’algorithme très efficace en
logiciel. R E D O C II utilise des tables de fonctions variables. Contrairement au DES,
qui a un ensemble fixe de tables de permutation et substitution (bien qu’optimisées
pour la sécurité), R E D O C II utilise un ensemble de tables dépendantes de la clef et
du texte en clair (des tables-S1en réalité). R E D O C II se déroule en 10 rondes ; chaque
ronde est une série compliquée de manipulations sur les blocs.
Une autre caractéristique unique de sa conception est l’utilisation de masques. Ce
sont des nombres dérivés de la table de clefs, qui sont utilisés dans le choix des tables
pour une fonction donnée d ’une ronde donnée. La valeur des données et la valeur des
masques sont toutes deux utilisées pour sélectionner les tables de fonction.
En faisant l’hypothèse que l’attaque exhaustive est la plus efficace, R E D O C II est très
sûr: 2160 opérations sont nécessaires pour retrouver la clef. Thomas C u s iC K a cryp-
tanalysé une ronde de R E D O C II, mais n’a pas été capable d’étendre cette attaque
à plusieurs rondes [404]. En utilisant la cryptanalyse différentielle, B i h a m et S h a m i r
ont réussi, à cryptanalyser une ronde de R E D O C II avec 2300 textes en clair choi
sis [177], mais cette attaque ne peut pas être étendue à plusieurs rondes. Ils parvinrent
également à obtenir la valeur de 3 masques après 4 rondes mais cette attaque ne peut
pas être étendue non plus.
REDOC III
RED O C III est une version rationalisée de R E D O C II, également conçue par Michael
W o o d [1617]. Elle manipule des blocs de 80 bits. La longueur de clef est variable et peut
atteindre 2 560 octets (20480 bits). Cet algorithme ne comporte que des ou exclusif des
octets de la clef avec des octets du message ; il n’y a ni permutations ni substitutions.
1. Créez une table de clef de 256 clefs de 10 octets en utilisant la clef secrète.
2. Créez deux masques de 10 octets, M\ et M 2 - M\ est le résultat du ou exclusif

des 128 premières clefs de 10 octets; M 2 est le résultat du ou exclusif des 128
autres clefs de 10 octets.
3. Pour chiffrer un bloc de 10 octets :
(a) Calculez le ou exclusif du premier octet du bloc de données avec le premier

octet de M i. Sélectionnez la clef dans la table de clefs (celle qui a été calculée
à l’étape 1) en utilisant cette valeur comme index (compris entre 0 et 255).
Calculez le ou exclusif de chaque octet du bloc de données avec l’octet
correspondant de la clef ainsi sélectionnée (sauf pour le premier octet).
(b) Calculez le ou exclusif du second octet du bloc de données avec le second
octet de M\. Sélectionnez la clef dans la table de clefs (celle qui a été calculée
à l’étape 1) en utilisant cette valeur comme index (compris entre 0 et 255).
Calculez le ou exclusif de chaque octet du bloc de données avec l’octet
correspondant de la clef ainsi sélectionnée (sauf pour le deuxième octet).
(c) Continuez ainsi pour tout le bloc de données (octets 3 à 10) jusqu’à ce que
chaque octet ait été utilisé pour sélectionner une clef après avoir été combiné
par ou exclusif avec M \ , et en combinant chaque octet du bloc de données
avec la clef, sauf pour l’octet utilisé pour sélectionner la clef.
(d) Répétez les étapes (a) à (c) avec M i-
Cet algorithme est simple et rapide. Avec un processeur 80386 cadencé à 33 MHz,
l’algorithme chiffre les données à 2,75 mégabits par seconde. W o o d a estimé qu’une
conception VLSI avec pipelines, avec un chemin de données de 64 bits devrait être
capable de chiffrer les données à plus de 1,28 gigabit par seconde avec une horloge
cadencée à 20 MHz.
R E D O C III n’a pas un bon niveau de sécurité [1446], Il est vulnérable à la cryptanalyse
différentielle. Il suffit seulement de 223 textes en clair choisi environ pour reconstruire
les deux masques.
Brevets et licences
Les deux versions de R E D O C sont brevetées aux États-Unis [1616). Des brevets
à l’étranger sont en attente. Toute personne désireuse d ’obtenir une licence pour
R E D O C II ou R E D O C III doit contacter: Michael C. Wood, Delta Computec,
Inc., 6647 Old Thompson Rd., Syracuse, NY 13211.
13.6 LOKI
L O K I est australien et fut présenté en 1990 comme une alternative potentielle au
DES [278]. Il utilise des blocs de 64 bits et une clef de 64 bits. La structure générale
de l’algorithme et la gestion des clefs étaient basés sur [277, 279], et la conception des
tables-S1étaient basées sur [1257].
En utilisant la cryptanalyse différentielle, B i h a m et S h a m i r sont parvenus à casser
L O K I avec 11 rondes ou moins, plus vite que par attaque exhaustive [177]. De plus,
il existe une propriété de complémentarité par 8 bits qui réduit la complexité d’une
attaque exhaustive par un facteur 256 [177, 917, 918].
Lars K n u d se n a montré que LO K I, avec 14 rondes ou moins, est vulnérable à la cryp
tanalyse différentielle [853, 855]. De plus, si L O K I est réalisé avec d’autres tables-S', il
13.6 LO KI 333
est probable que l’algorithme de chiffrement résultant sera vulnérable à la cryptanalyse

différentielle.
LOKI91
En réponse à ces attaques, les concepteurs de LO K I retournèrent à la planche à dessin
et révisèrent leur algorithme. Le résultat est LOKI91 [276]4.
Pour rendre l’algorithme plus résistant à la cryptanalyse différentielle et pour supprimer
la propriété de complémentarité de la clef, les modifications suivantes ont été apportées :
1. L’algorithme de génération des sous-clefs a été changé de telle manière que les
moitiés sont échangées une ronde sur deux au heu de toutes les rondes.
2. L’algorithme de génération des sous-clefs a été changé de telle façon que le déca
lage circulaire de la sous-clef de gauche soit alternativement de 12 et 13 bits vers
la gauche.
3. Les ou exclusif initial et final du bloc avec la clef ont été supprimés.
4. Les tables-S1ont été modifiées pour mettre en ordre leurs propriétés vis à vis du
ou exclusif (pour augmenter leur résistence à la cryptanalyse différentielle), et
pour éliminer toute valeur x telle que f(x ) = 0 où f est la fonction résultant de
la combinaison des tables- E, des tables-s et des tables -P.
Description de LOKI
Le mécanisme de L O K I est similaire à celui du DES (voir la figure 13.8). Le bloc de
données est divisé en une moitié gauche et une moitié droite, puis soumis à 16 rondes,
tout comme dans le DES. A chaque ronde, la moitié droite est d’abord combinée par ou
exclusif avec un morceau de la clef, puis envoyé à travers une permutation expansive
(voir tableau 13.1).
T a b . 13.1 - Permutation expansive
3 2 1 32 31 20 29 28 27 26 25~
28 27 26 25 24 23 22 21 20 19 18 17
20 19 18 17 16 15 14 13 12 11 10 9
12 11 10 9 8 7 6 5 4 3 2 1
Les 48 bits de sortie sont divisés en quatre blocs de 12 bits et chaque bloc passe à
travers une table-S1de substitution. La table-S fonctionne ainsi : prenez chaque entrée
de 12 bits ; utilisez les deux bits de gauche et les deux bits de droite pour former le
nombre r, et les huits bits du centre pour former le nombre c. La sortie O de la table-S
est la suivante :
0(r,c) = (c + ((r * 17) © Oxf f)&0xf f) 31 modulo Pr
Pr est donné par le tableau 13.2.
4. La version précédente fut rebaptisée L O K I89.

334 Chapitre 13 Autres algorithmes de chiffrement par bloa
F ig . 13.8 - Aperçu de LOKI91
Ensuite, les quatres sorties de huit bits sont assemblées pour former un nombre d{
32 bits qui est envoyé à travers la permutation décrite dans le tableau 13.3. Enfin, Ie
moitié droite est combinée par ou exclusif avec la moitié gauche pour devenir la moitié
gauche, et la moitié gauche devient la nouvelle moitié droite. Après 16 rondes, le bloc
est à nouveau combiné par ou exclusif avec la clef pour produire le texte chiffré.
Les sous-clefs sont engendrées à partir d e la clef de manière simple. Tout d’abord, le
clef de 64 bits est divisée en une moitié gauche et une moitié droite. A chaque ronde, le
sous-clef est la moitié gauche. Cette moitié gauche est décalée circulairement de 12 or
T a b . 13 .2 - Pr
r: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Pr : 375 379 391 395 397 415 419 425 433 445 451 463 471 477 487 488
13.7 K hufu et K h a f r e 335
T a b . 13.3 - Table- P de permutation
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Pr : 375 279 391 395 397 415 419 425 433 445 451 463 471 477 487 488
13 bits vers la gauche, et ensuite les moitiés gauche et droite sont échangées toutes les
deux rondes. Tout comme pour le DES, le même algorithme peut être à la fois utilisé
pour le chiffrement et le déchiffrement, avec quelques modifications quant à l’utilisation
des sous-clefs.
Cryptanalyse de LOKI91
Lars K n u d se n a essayé de cryptanalyser LO K I91 [856, 858]. Il ne parvint pas à
utiliser la cryptanalyse différentielle contre l’algorithme révisé. Toutefois, il a trouvé
une attaque à texte en clair choisi qui réduit la complexité d ’une attaque exhaustive
par îm facteur de presque 4. Cette attaque exploite une faiblesse du plan de génération
de clefs, qui est également une faiblesse si l’algorithme est utilisé comme fonction de
hachage à sens unique.
Une autre attaque à clef corrélée de peut casser LOKI91 avec 232 clefs choisies-textes
en clair choisis ou 248 clefs choisies-textes en clair connus [165]. Cette attaque est
indépendante du nombre de rondes de l’algorithme. (Dans le même article, B ih a m
casse LO K I89 avec 217 textes en clair choisis ou 233 textes en clair connus.) U est facile
de rendre LO K I91 résistant à cette attaque ; il suffit d ’éviter le plan de génération de
clefs simple.
Brevets et licences
LOKI n’est pas breveté. Tout le monde peut le réaliser et l’utiliser. Le code source de
la réalisation donnée dans ce livre est protégée par le copyright de l’« University of
New South Wales ». Toute personne intéressée par l’utilisation commerciale de cette
réalisation (ou une autre réalisation plus rapide de plusieurs ordres de grandeur) doit
contacter: Director CITRAD, Department of Computer Science, University
Collège, UNSW, Australian Defense Force Academy, Canberra ACT 2600,
Australia, Fax : +61-6-268-8581.
13.7 Khufu et Khafre

En 1990, Ralph M e r k l e proposa deux algorithmes. Les principes de base du schéma
de conception de ces cryptosystèmes sont [1077] :
1. La taille de 56 bits de la clef DES est trop petite. Compte tenu du coût négligeable
de l’augmentation de la taille de la clef (la mémoire est bon marché et disponible
à volonté), celle-ci doit être augmentée.
2. Bien que l’utilisation intensive de permutations dans le DES convienne bien aux
réalisations matérielles, elles sont très difficiles pour les réalisations logicielles.
Les réalisations logicielles les plus rapides du DES utilisent des techniques de
recherche dans des tables pour réaliser les permutations. De telles techniques
peuvent donner les mêmes caractéristiques de « diffusion » que les permutations
et tout en étant plus flexibles.
3. Les tables-S du DES sont petites, avec seulement 64 entrées de 4 bits par table.
Maintenant que les mémoires sont plus grandes, les tables- S' doivent grandir.
De plus, les 8 tables - S sont utilisées simultanément. Bien que cela convienne
pour une réalisation matérielle, cela semble une restriction déraisonnable en logi
ciel. Une taille de table-S plus grande et une utilisation séquentielle (plutôt que
parallèle) des tables S doivent être employées.
4. Les permutations initiale et finale du DES sont considérées comme inutiles du

point de vue de la cryptographie et doivent être supprimées.
5. Toutes les réalisations rapides du DES précalculent les clefs de chaque ronde.
Donc, il n’y a pas de raison de ne pas rendre ce calcul plus compliqué.
6. Contrairement au DES, le schéma de conception des tables-S' doit être public.
Aujourd’hui, M e r k l e ajouterait probablement à sa liste : « résistant aux cryptanalysés

différentielle et linéaire », mais ces attaques étaient inconnues au début des années 90.
Khufu
K h u f u est un chiffrement p a r blocs de 64 bits. Les 64 bits de texte en clair sont
d’abord divisés en deux moitiés de 32 bits, G et D , qui sont combinées par ou exclusif
avec des clefs dérivées. Ensuite, elles sont l’objet d’une suite de rondes similaires au
DES. A chaque ronde, l’octet de poids le plus faible de G est utilisé comme entrée
d’une table S de 256 entrées. Chaque cellule de table -S a une longueur de 32 bits. La
cellule de 32 bits sélectionnée dans la table-S est combinée par ou exclusif avec R. L
est ensuite décalé circulairement d ’un multiple de 8 bits, L et R sont échangés et la
ronde se termine. La table-S elle-même n’est pas statique, mais change toutes les 8
rondes. Finalement, après la dernière ronde, L et R sont combinés par ou exclusif avec
des clefs dérivées et recombinés pour former le texte chiffré.
Bien que des parties de la clef soient combinées par ou exclusif avec le bloc chiffré au
début et à la fin, le but principal de la clef est d’engendrer les tables-S. Ces tables-S
sont secrètes et, par essence, font partie de la clef. L’algorithme de M e r k l e a besoin
d’une clef de longueur totale de 512 bits (64 octets) et il fournit un algorithme pour
engendrer les tables-S' à partir de la clef. Le nombre de rondes de l’algorithme est libre
M e r k l e fit remarquer que le K h u f u à 8 rondes est sensible à une attaque à textes
en clair choisis et recommandait 16, 24 ou 32 rondes [1077]. (Il a limité le choix du
nombre de rondes à un multiple de 8).
Comme K h u f u a des tables S dépendantes de la clef et secrètes, il est immune à
la cryptanalyse différentielle. Il existe une attaque différentielle contre le K h u f u à
16 rondes qui trouve la clef à l’aide de 231 textes en clair choisis [613], mais elle ne
s’applique pas avec plus de rondes. Si une attaque exhaustive est le meilleur moyen
d ’attaquer K h u f u , il est incroyablement difficile à casser. Une clef de 512 bits donne
une complexité de 2512 inconcevable dans toutes les circonstances
13.8 RC2 337
Khafre
Khafre est le second des cryptosystèmes proposés par M e r k l e [1077]5. Le schéma
de conception est similaire à celui de K h u f u , excepté qu’il a été conçu pour des appli
cations où il n’y a pas de temps de précalcul. Les tables-é> ne dépendent pas de la clef.
K h a f r e utilise des tables S fixées. De plus, la clef est combinée par ou exclusif avec
le bloc chiffré non seulement avant la première ronde et après la dernière, mais aussi
toutes les 8 rondes de chiffrement.
M e r k l e postula que des clefs de 64 ou 128 bits seraient utilisées pour K h a f r e et
que plus de rondes seraient nécessaires pour K h a f r e que pour K H U F U . Ceci, combiné
avec le fait que chaque ronde de K h a f r e est plus compliquée que pour K h u f u , rend
K h a f r e plus lent. En compensation, K h a f r e ne nécessite pas de précalcul et chiffre
des petites quantités de données plus rapidement.
En 1990, B i i i a m et S h a m i r utilisèrent leurs techniques de cryptanalyse différentielle
contre K h a f r e [177]. Ils réussirent à casser K h a f r e à 16 rondes avec une attaque
à texte en clair choisi qui utilise environ 1500 chiffrements différents. Cela leur prit
environ une heure, en utilisant un ordinateur personnel. Convertir cette attaque en
une attaque à texte en clair connu nécessiterait environ 238 chiffrements. KHAFRE à 24
rondes peut être cassé par une attaque à texte en clair choisi à l’aide de 253 chiffrements
et, par une attaque à texte en clair connu à l’aide de 259 chiffrements.
Brevets
K h u f u et K h a f r e sont tous deux brevetés [1078]. Le code source des algorithmes se
trouve dans les brevets. Toute personne désirant acquérir une licence pour l’un des al
gorithmes doit contacter : D ire c to r o f L ic e n s in g , Xerox C orp oration , P.O. Box
1600, Stam ford, CT, 0 6 9 0 4-1 60 0 .
13.8 RC2
R.C2 est un algorithme de chiffrement à clef de taille variable conçu par Ron R i v e s t
pour la société R S A D a t a S e c u r i t y , I n c . (R S A D S I). Apparemment, « R C » est
l’abréviation de « Ron’s Code » (« le code de Ron ») bien qu’officiellement il s’agisse
de celle de « Rivest’s Code » (« le code de Rivest » ) 6. Il s’agit dun algorithme « privé »
et sa description n’a pas été publiée. Ne pensez pas un seul instant que cela accroisse
la sécurité. R C2 a déjà été utilisé dans des produits commerciaux; je suis sûr que
quelqu’un l’a déjà désassemblé. Pour autant que je sache, R C 2 n’est pas breveté.
RC2 est un algorithme de chiffrement par bloc à clef de taille variable conçu comme
un remplaçant du DES. D ’après la société, les réalisations logicielles de R C2 sont trois
fois plus rapides que le DES. Il chiffre les données par blocs de 64 bits. R C2 est un
algorithme de chiffrement par blocs « mélange-et- broie ». Il n ’y a pas de tables-S
[813] ; les deux opérations sont « mélange-et broie » et l’une d’entre elles est chosie à
chaque ronde. Selon leur propre littérature [1345] :
« ...RC2 n ’est pas un algorithme de chiffrement par blocs itératif. Cela

5. K hufu et K hafre ont été baptisés d ’ après les nom s de deu x pharaons égyptiens.
6. R C 3 fut cassé dans les murs de R S A D S I durant son développem ent ; R C 1 n ’est jam ais sorti des
notes de R iv e s t .
suggère que R C2 offre plus de protection contre les cryptanalysés différen

tielle et linéaire que les autres algorithmes de chiffrement par blocs qui font
reposer leur sécurité sur une conception similaire à celle du DES. »
La volonté de R SA D SI de ne pas divulguer leur algorithme au public jette un doute sur

leurs affirmations. Ils sont prêts à fournir les détails de l’algorithme à des scientifiques
disposés à les cryptanalyser. Je ne connais personne qui les ait pris au mot car cela
reviendrait à faire le travail d’analyse pour eux.
Malgré tout, Ron R i v e s t n’est pas un charlatan. C ’est un cryptographe talentueux
et respecté. J’ai assez confiance dans son algorithme, bien que je n’aie pas inspecté
personnellement le code. R C 4 qui fut la propriété intelectuelle de R SA D SI a été
divulgué sur I n t e r n e t (voir § 17.1), et RC2 ne devrait pas tarder à l’être aussi.
Un accord récent entre l’Association des éditeurs de logiciels américaine (SPA pour
« Software Publishers Association ») et le Gouvernement américain a accordé un statut
d’exportation spécial (voir § 25.14) à R C2 et R C 4 (voir § 17.1). Les produits qui
utilisent l’un des deux algorithmes ont droit à une procédure d ’exportation simplifiée,
pour autant que les clefs n’aient pas plus de 40 bits de longueur.
Une longueur de clef de 40 bits est-elle suffisante? Il y a un total de 240 (~ 1012) clefs
possibles. En faisant l’hypothèse que la recherche exhaustive est la méthode la plus
efficace de cryptanalyse (une hypothèse forte s’il en est, étant donné que l’algorithme
n’a pas été publié) et en faisant l’hypothèse que le cryptanalyste peut tester un million
de clefs par seconde, il faudra 12,7 jours pour trouver la bonne clef. Un millier de
machines en parallèle trouveront la clef en vingt minutes.
Selon R S A D a t a S e c u r i t y , I n c ., bien que le chiffrement et le déchiffrement soient
rapides, la recherche exhaustive de clefs ne l’est pas. Un temps significatif est passé à
mettre en place le plan de génération de clefs. Bien que ce temps soit négligeable par
rapport au temps de chiffrement et de déchiffrement des messages, il ne l’est pas quand
on essaie toutes les clefs.
Le gouvernement américain n ’autoriserait jamais à l’exportation un algorithme qu’ils
ne puissent pas eux-mêmes casser, du moins en théorie. Une autre possibilité d’attaque
serait de créer une bande magnétique ou un disque compact (C D ) avec un bloc de texte
en clair chiffré selon toutes les clefs possibles. Pour casser un message donné, vous avez
juste à lire la bande magnétique et comparer les blocs de texte chiffré avec les blocs
de textes chiffrés sur la bande. S’il y a une concordance, essayez la clef candidate et
voyez si le message a un sens. Si vous choisissez un bloc de texte en clair assez usuel
(que des zéros, le caractère ASCII de l’espace, etc.), cette méthode devrait marcher.
La capacité de stockage nécessaire pour un bloc de texte en clair de 64 bits chiffré avec
toutes les 1012 clefs possibles est de 8 téra-octets — ce qui est faisable.
Pour obtenir des informations concernants les licences pour RC2, contacter RSADSI
(voir § 25.4).
13.9 IDEA
La première version du système de chiffrement ID E A , conçu par Xuejia L a i et James
M a s s e y , a fait surface en 1990 [940]. Il s’appelait PES (« Proposed Encryption
Standard »). L ’année suivante, après que B i h a m et S h a m i r eurent présenté la cryp

tanalyse différentielle, les auteurs ont renforcé leur système pour résister à cette
13.9 ID E A 339
attaque [942, 936]. Ils l’appelèrent alors IPES (« Improved Proposed Encryption
Standard »). IPES fut rebaptisé ID E A en 1992 (« International Data Encryption
Algorithm »).
IDEA est basé sur des fondations théoriques impressionnantes et bien que la cryp
tanalyse ait fait des progrès contre des variantes avec un nombre de ronde réduit,
l’algorithme a l’air solide. De mon point de vue, c ’est le meilleur et le plus sûr des
algorithmes disponibles publiquement à ce jour.
Le futur d ’ID E A n’est pas encore clair. Rien ne presse pour l’adopter en remplacement
du DES, en partie parce qu’il est breveté et nécessite une license pour être utilisé dans
les applications commerciales, et en partie parce que les gens attendent encore de voir
avec quel brio l’algorithme traversera les prochaines années de cryptanalyse.
Survol d’IDEA
IDEA est un algorithme de chiffrement par blocs ; il manipule des blocs de texte en
clair de 64 bits. La clef est longue de 128 bits. Le même algorithme est utilisé pour le
chiffrement et le déchiffrement.
Comme tous les algorithmes de chiffrement par blocs que nous avons déjà vus, ID E A
utilise à la fois la confusion et la diffusion. La philosophie de la conception de l’algo
rithme est basée sur le « mélange d’opérations de différents groupes algébriques ». Il y
a trois groupes algébriques dont les opérations sont mélangées, et toutes ces opérations
sont facilement réalisables à la fois en logiciel et en matériel :
- ou exclusif,
- addition modulo 2 16,
- multiplication modulo 2 16 + 1 (cette opération est un peu la table-S' de

ID E A ).
Toutes ces opérations (et ce sont les seules opérations de l’algorithme car il n’y a pas de
permutations) manipulent des sous-blocs de 16 bits. Cet algorithme est efficace même
sur des processeurs 16 bits.
Description d’IDEA
La figure 13.9 donne un aperçu d’ID E A . Le bloc de données de 64 bits est divisé en 4
sous-blocs de 16 bits : X L, X 2 , A 3 et A 4 . Ces 4 sous-blocs deviennent les entrées de la
première ronde de l’algorithme. Il y a 8 rondes au total. À chaque ronde, les 4 sous-blocs
sont combinés par ou exclusif, additionnés, multipliés entre eux et avec 6 sous-blocs de
16 bits dérivés de la clef. Entre chaque ronde, le deuxième et le troisième sous-bloc sont
échangés. Enfin, les quatre sous-blocs sont combinés avec les quatre sous-clefs dans une
transformation finale.
A chaque ronde, la séquence d’événements est la suivante :
1 . multipliez X i et la première sous-clef ;
2. additionnez X 2 et la deuxième sous-clef ;
3. additionnez A 3 et la troisième sous-clef ;

^1 ^2 Xj : sous-bloc de 16 bits de texte en clair ^3 ^4

Yj : sous-bloc de 16 bits de texte chiffré
z[r^ :sous-bloc de clef de 16 bits
© : ou exclusif bit à bit de sous-blocs de 16 bits
H - adoition modulo 2 16 d’entiers de 16 bits
Q : multication modulo 2 16+1 d’entiers de 16 bits
avec le sous-bloc nul correspondant à 216
F ig . 13.9 - Squelette d l D E A
4. multipliez X i et la quatrième sous-clef ;
5. combinez par ou exclusif les résultats des étapes (1) et (3) ;
6. combinez par ou exclusif les résultats des étapes (2) et (4) ;
7. multipliez le résultat de l’étape (5) avec la cinquième sous-clef ;
8. additionnez les résultats des étapes (6) et (7) ;
9. multipliez le résultat de l’étape (8) par la sixième sous-clef ;

13.9 ID E A 341
10. additionnez les résultats des étapes (7) et (9) ;
11. combinez par ou exclusif les résultats desétapes (1) et (9) ;
12. combinez par ou exclusif les résultats desétapes (3) et (9) ;
13. combinez par ou exclusif les résultats desétapes (2) et (10);
14. combinez par ou exclusif les résultats desétapes (4) et (10).

La sortie de la ronde est constituée des 4 sous-blocs produits par les étapes (11), (13),
(12) et (14). Echangez les deux blocs intérieurs (sauf lors de la dernière ronde) et cela
donne l’entrée de la ronde suivante.
Après la huitième ronde, il y a une transformation finale :
1. multipliez X i et la première sous-clef ;
2. additionnez X% et la deuxième sous-clef ;
3. additionnez X 3 et la troisième sous-clef;
4. multipliez X 4 et la quatrième sous-clef.

Enfin, les 4 sous-blocs sont réassemblés pour former le texte chiffré.
La création des sous-clefs est aussi facile. L’algorithme en utilise 52 (6 pour chacune
des 8 rondes et 4 pour la transformation finale). D ’abord, la clef de 128 bits est divisée
en 8 sous-clefs de 16 bits. Ce sont les 8 premièressous-clefs pour l’algorithme(les 6 de
la première ronde et les 2 premières de la deuxième ronde).Ensuite la clef est décalée
circulairement de 25 bits vers la gauche et à nouveau divisée en 8 sous-clefs. Les 4
premières sont utilisées lors de la deuxième ronde et les 4 autres lors de la troisième
ronde. La clef est à nouveau décalée circulairement de 25 bits vers la gauche pour les
8 sous-clefs suivantes, et ainsi de suite jusqu’à la fin de l’algorithme.
Le déchiffrement est exactement le même, excepté que les sous-clefs sont inversées
et légèrement différentes. Les sous-clefs de déchiffrement sont inverses par rapport
à l’addition ou par rapport à la multiplication des sous-clefs de chiffrement. (Pour
les besoins d’ID E A , tous les sous-blocs constitués uniquement de zéros représentent
216 = —1 modulo 216 + 1 pour la multiplication; et l’inverse de la multiplication de 0
est donc 0.) Calculer ces inverses prend du temps mais vous ne devez le faire qu’une
fois par clef de déchiffrement. Le tableau 13.4 indique les sous-clefs de chiffrement et
les sous-clefs de déchiffrement correspondantes.
Vitesse d’IDEA
Les réalisations logicielles actuelles d ’ID E A sont presque aussi rapides que le DES.
Sur un 80386 cadencé à 33 MHz, ID E A chiffre à la vitesse de 880 kilo-bits par seconde
et 2400 kilo-bits par seconde sur un 80486 cadencé à 66 MHz. Vous auriez pu croire
IDEA plus rapide, mais les multiplications coûtent cher. Multiplier deux nombres de
32 bits prend 40 cycles d’horloges sur un 80486 (et 10 sur un Pentium).
Une réalisation V LSI de P E S chiffre les données à 55 mégabits par seconde à
25 MHz [212, 402]. Une autre puce VLSI, développée à l’ETH de Zürich, conte
nant 251000 transistors sur une puce de 107,8 mm2 , chiffre les données à l’aide
d’ID EA à la vitesse de 177 mégabits par seconde avec une fréquence d’horloge de
25 MHz [935, 211, 401],
T a b . 13.4 - Sous-clefs de chiffrement et déchiffrement pour I D E A
Ronde Sous-clefs de chiffrement Sous-clefs de déchiffrement
1.-V
ÜN 00
1 : z p z ™ z P z p z p Z6 z<9)- J - z p - z p z p - z p
2: Z<2) z p z p z p z p z p z p 1 - z p - z p z p z p z p
3: z [ 3) z P z P z p z p z p z p - 1 - z p - z p z p - z p z p
4: Z [ 4) z P z P z p z p
7 (4 )
6 z p - 1 - z P - z p z P zp z p
5: z p z f 1 z f z P z p z p z p - 1 - z p - z p z p - z p z p
6: z [ 6) z P z f ] z p z p z p z p - 1 - z p - z p z p - z p z p
7: z P z P z P z p z p z p z P 1 -zp - z p z p - zp z p
8: z [ 8) z P z P z p z p z p z p - 1 - z p - z p z p - z p z p
finale: z [ 9) z f ] z P z p z p - 1 - z p - z P z p - ]
Cryptanalyse d’IDEA
La longueur de clef d’ID E A est de 128 bits — plus du double de celle du DES. En
faisant l’hypothèse que l’attaque exhaustive est la plus efficace, il faudrait 2128 (ss 1038)
chiffrements pour retrouver la clef. Concevez une puce qui peut tester un milliard de
clefs par seconde et mettez-en un milliard à la tâche, cela prendra 1013 années — c ’est
plus que l’âge de l’Univers. Une matrice de 1024 puces pourrait trouver la clef en un
jour mais il n’y a pas assez d ’atomes de silicium dans l’univers pour construire une
telle machine. Là, nous tenons du solide, mais je vais garder un œil sur le débat sur la
matière sombre, on ne sait jamais.
Peut-être, toutefois, que l’attaque exhaustive n’est pas la meilleure attaque contre
ID E A . L’algorithme est encore trop récent pour donner des résultats cryptanalytiques
définitifs. Les concepteurs ont fait de leur mieux pour rendre l’algorithme immune à la
cryptanalyse différentielle ; ils ont défini le concept de chiffre de Markov et ont montré
qu’il est possible de modéliser et de quantifier la résistence à la cryptanalyse différen
tielle [942, 937]. (La figure 13.10 montre l’algorithme PES original, à comparer avec
l’algorithme ID E A de la figure 13.9 qui a été renforcé pour résister à la cryptanalyse
différentielle. Il est étonnant de constater comment quelques changements subtils font
une grande différence.) L a i prétend (il donne des indices probants, pas une preuve)
qu’ID E A est immune à la cryptanalyse différentielle après seulement 4 de ses 8 rondes.
D ’après Eli B i h a m , son attaque à clefs corrélées ne marche pas contre ID EA [114].
Willi M e i e r a examiné les trois opérations algébriques de ID EA, et a fait remar
quer que bien qu’étant incompatibles, il arrive qu’on puisse les simplifier de manière
à faciliter la cryptanalyse de temps en temps [1058]. Son attaque est plus efficace que
l’attaque exhaustive pour l’ID E A à deux rondes (242 opérations), mais moins efficace
pour l’ID E A à trois rondes ou plus. ID E A avec ses huits rondes est sûr.
Joan D a e m e n a découvert une classe de clefs faibles pour ID E A [408, 413]. Ce ne
sont pas des clefs faibles dans le sens où certaines clefs du DES sont faibles, où la
fonction de chiffrement est sa propre inverse. Elles sont faibles dans le sens où si elles
sont utilisées, un attaquant peut facilement les identifier avec une attaque à texte en
clair choisi. Voici, par exemple, une classe de clefs faibles (en hexadécimal) :
0000 0000 0X00 0000 0000 000X XXXX X000

13.9 ID E A 343
F ig . 13.10 Squelette de PES
où « X » peut être n’importe chiffre hexadécimal. Si cette clef est utilisée, la combinaison
par ou exclusif de deux textes en clair donne la combinaison par ou exclusif des deux
textes chiffrés résultants.
Dans tous les cas, la chance d’engendrer une telle clef aléatoirement est extrêmement
faible: une sur 296. Il n’y a pas de danger si vous choisissez les clefs aléatoirement et
il est facile de modifier ID E A pour qu’il n’y ait plus de clefs faibles : combiner par ou
exclusif chaque clef avec OxODAE [413]
Je n’ai pas eu connaissance d’autres résultats.

Modes opératoires d’IDEA et de ses variantes

ID E A peut être utilisé avec n’importe lequel des modes opératoires de chiffrement par
blocs décrits dans le chapitre 9. Toute réalisation d’ID E A double serait vulnérable à
la même attaque par collisions que pour le DES (voir § 15.1). Toutefois, comme la
longueur de clef d’ID E A est plus du double de celle du DES, l’attaque est impossible.
Cela nécessiterait de stocker 64 x 2128 bits, ou 1039 octets. Peut-être y a-t-il suffisam
ment de matière dans l’univers pour créer un dispositif de mémoire aussi grand mais
j ’en doute.
Si vous êtes également tracassé par les univers parallèles, vous pouvez utiliser une
réalisation de l’ID E A triple (voir § 15.2) :
C = E K l ( D K2( E K l ( M ) ) ) .
Elle est immune à l’attaque par collisions.

Il n’y pas de raisons de ne pas réaliser ID E A avec des sous-clefs indépendantes.
L’algorithme nécessite au total 52 clefs de 16 bits ou une clef de longueur totale de 832
bits. Cette variante est certainement plus sûre, mais personne ne sait à quel point.
Une variante naïve pourrait consister à doubler la taille des blocs. L’algorithme mar
cherait aussi bien avec des sous-blocs de 32 bits au lieu de 16 bits, et avec une clef de
256 bits. Le chiffrement serait plus rapide et la niveau de sécurité augmenterait d’un
facteur 232. En est-il ainsi? La théorie sous-jacente à l’algorithme dépend de la prima
lité de 216 + 1 alors que 232 + l n ’est pas premier. L ’algorithme peut être éventuellement
être modifié pour marcher mais il aurait des propriétés de sécurité très différentes. L ai
dit qu’il serait difficile de le faire fonctionner [935].
Même si ID E A paraît nettement plus sûr que le DES, il n’est pas toujours facile de
remplacer l’un par l’autre dans une application existante. Si votre base de données et
vos écrans d’interrogation sont conçus pour accepter une clef de 64 bits, il pourrait
être impossible de mettre la clef de 128 bits d ’ID E A à la place.
Pour ces applications, engendrez la clef de 128 bits en accolant la clef de 64 bits à
elle-même. Mais sachez que cette modification affaiblit considérablement IDEA.
Si vous êtes plus concerné par la vitesse que par la sécurité, vous pourriez adopter une
variante de ID E A avec moins de rondes. Jusqu’à présent, la meilleure attaque contre
ID E A va plus vite que la recherche exhaustive pour seulement 2,5 rondes ou moins
[1058] ; ID E A serait deux fois plus rapide avec 4 rondes et aussi sûr d ’après ce que je
sais.
Avertissement
ID E A est un nouvel algorithme. Il n’y a encore aucun article publié quant à sa cryp
tanalyse. Est-ce qu’ID E A est un groupe? ( L a i pense que non [935].) Existe-t-il des
moyens non encore découverts de casser l’algorithme? ID E A a une base théorique
ferme. Toutefois, jour après jour des algorithmes qui paraissaient sûrs sont tombés
devant de nouvelles formes de cryptanalyse. Il y a pour le moment plusieurs groupes
académiques et militaires qui tentent de cryptanalyser ID E A . Aucun d’entre eux n’a
réussi jusqu’ici (et aucun n’est disposé à l’annoncer publiquement), mais qui sait, un
jour...
13.10 MMB 345
Brevets et licences
L’algorithme de chiffrement par blocs ID E A est breveté en Europe et
aux États-Unis [1018, 1019]. Le brevet est détenu par ASCOM-T e c h AG.
Il n’y a pas de droits d ’exploitation à payer pour un usage non com
mercial. Les utilisateurs commerciaux désireux d ’obtenir une licence doivent
contacter: Ascom Systech AG, Dept. CMVV, Gewerbepark, CH-5506, Mâgenwil,
S u isse, T e l: +41 64 565-983, Fax: +41 64 565-990, e -m a il: ideaascom .ch.
13.10 MMB
On reproche à ID E A d ’utiliser des blocs de chiffrement de 64 bits. Ce reproche a été
émis par Joan D a e m e n avec l’algorithme appelé M M B (pour « Modular Multiplication-
based Block cipher ») [390, 407, 408]. M M B est fondé sur la même théorie de base
qu’ID E A : mélanger des opérations de différents groupes algébriques. M M B est un
algorithme itératif qui consiste principalement en des étapes linéaires ( ou exclusif et
application de la clef) et l’utilisation en parallèle de quatre substitutions non inversibles
linéairement. Ces applications sont déterminées par une multiplication modulo 232 — 1
avec des facteurs constants. Le résultat est un algorithme comportant à la fois des blocs
de 128 bits et une clef de 128 bits.
M M B manipule des sous-blocs de 32 bits de texte ( xq,xi,x 2 ,X3) et des sous-blocs de
clef de 32 bits {ko,ki,k2 ,ks}- Cela rend l’algorithme bien adapté à la réalisation sur des
processeurs modernes de 32 bits. Une fonction non linéaire / est appliquée 6 fois en
alternance avec des o u e x c l u s i f . Voici l’algorithme (toutes les opérations sur les indices
sont effectuées modulo 4) :
Xi = X i® ki pour i = 0 à 3
f ( x 0 , X i , X 2 , X3 )
Xi = X i® ki+ 1 pour i = 0 à 3
f ( x 0 , X i, X 2 ,X3 )
Xi = X i® ki + 2 pour i = 0 à 3
f ( x o , X l , X 2 , X3 )
Xi = x ,® k i pour i = 0 à 3
f(x o ,X i,x 2,xs )
Xi = X i® kl+ 1 pour i = 0 à 3
f ( x 0 , x 1 , X 2 ,X3 )
Xi — X i ® ki+ 2 pour i — 0 à 3
f{Xc,X]_,X2,X?).
La fonction / a trois étapes :
1. Xi = Ci- x ï pour i = 0 à 3.
2. Si l’octet le moins significatif de xo est 1, alors xq = Xq © G ; si l’octet le moins

significatif de x% = 0, alors X 3 — X 3 ® C.
3. Xi = Xi~ 1 © xt © xt+i pour i = 0 à 3.

L’opération de multiplication de l’étape 1 se fait modulo 232 — 1. Pour les besoins de

l’algorithme, si le second opérande est 232 —1, alors le résultat est 232 —1. Les constantes
sont (en hexadécimal) :
C = 2AAAAAAA
c0 = 025F1CDB
Ci = 2c0
c2 — 23c0
c3 = 27c0.
La constante C est la constante la « plus simple » avec un poids ternaire élevé, le bit
le moins significatif égal à 0 et sans symétrie circulaire. La constante Co a été choisie
d ’après certaines caractéristiques. Les constantes Ci, c2 et c3 sont des versions décalées
de co pour éviter des attaques basées sur la symétrie. Voir [407] pour plus de détails.
Le déchiffrement est le processus inverse. Les étapes 2 et 3 sont leurs propres inverses.
L ’étape 1 utilise c~ 1 au lieu de c*. La valeur de c0 1 est 0DAD4694.
Sécurité de M M B
La conception de l’algorithme assure que chaque ronde a une diffusion considérable,
indépendamment de la clef. Avec ID E A , la diffusion dépend dans une certaine mesure
des sous-clefs en question. M M B a aussi été conçu pour ne pas avoir de clef faible à la
différence de ID E A .
M M B est mort [405]. Bien qu’aucune cryptanalyse n’ait été publiée, ceci est vrai pour
plusieurs raisons. Premièrement, il n’a pas été conçu pour résister à la cryptanalyse
linéaire. Les auteurs ont choisi ces facteurs multiplicatifs pour leur résistence à la
cryptanalyse différentielle mais ils ignoraient la cryptanalyse linéaire.
Deuxièmement, Eli B ih a m détient une attaque effective à clefs choisies [167] qui ex
ploite le fait que toutes les rondes sont identiques et que les clefs sont simplement
décalées cycliquement de 32 bits. Troisièmement, bien que M M B puisse être très effi
cace en logiciel, une réalisation matérielle de l’algorithme serait bien plus lente que le
DES.
D a e m e n conseille à toute personne intéressée dans l’amélioration de M M B de faire
une analyse de la multiplication modulaire par rapport à la cryptanalyse, de choisir des
nouveaux facteurs et de rendre la constante C différente à chaque ronde [405]. Enfin, il
conseille d’améliorer la gestion des clefs en ajoutant des constantes aux clefs de ronde
pour éliminer le biais. Il ne le fera pas lui-même, il a conçu 3 -W a y à la place (voir
§ 14.5).
13.11 C A —1.1
C A est un chiffrement par blocs construit à partir d ’un automate cellulaire, conçu par
Howard G u t o w i t z [678, 680, 679]. Il chiffre le texte en clair par blocs de 384 bits et
a une clef de 1088 bits (il s’agit en fait de deux clefs, une clef de 1024 bits et une de
64 bits). De par la nature de l’automate cellulaire, cet algorithme est le plus efficace
quand il est réalisé avec des circuits intégrés massivement parallèles.
C A 1.1 utilise des règles d’automate cellulaire à la fois réversibles et irréversibles. Par
une règle réversible, chaque état du réseau découle d ’un unique état prédécesseur, tandis
13.12 S k ip j a c k 347
que par une règle irréversible, un état peut avoir de nombreux états prédécesseurs.
Pendant le chiffrement, les règles irréversibles sont itérées en remontant le temps. Pour
aller en arrière par rapport à un état, un état est sélectionné aléatoirement parmi les
états prédécesseurs possibles. Ce processus peut être répété un grand nombre de fois.
L’itération arrière sert donc à mélanger de l’information aléatoire avec le message.
CA 1.1 utilise une catégorie particulière de règles partiellement linéaires irréversibles
qui sont telles qu’un état prédécesseur aléatoire peut être rapidement construit pour
n’importe quel état. Les règles réversibles sont aussi utilisées pour certaines étapes du
chiffrement.
Les règles réversibles (de simples permutations parallèles sur des sous-blocs de l’état)
sont totalement non linéaires. Les règles irréversibles sont entièrement déduites à partir
de la clef, tandis que les règles réversibles dépendent à la fois de la clef et des informa
tions aléatoires insérées pendant les étapes de chiffrement avec les règles irréversibles.
C A -1.1 est construit autour d ’une structure de blocs chaînés. C ’est-à-dire que la ma
nipulation des blocs de messages est partiellement découplée du flot d’informations
aléatoires insérées durant le chiffrement. Ces informations aléatoires servent à relier
les étapes de chiffrement ensemble. Elles peuvent aussi être utilisées pour chaîner le
chiffrement d ’un flot de blocs. L ’information dans le lien est engendrée dans l’appareil
de chiffrement.
C A -1.1 est un nouvel algorithme et il est trop tôt pour se prononcer quant à son
niveau de sécurité. G u t o w i t z décrit des attaques possibles, y compris la cryptanalyse
différentielle, mais il est incapable de casser l’algorithme. G u t o w i t z offre une prime
de 1000 $ à « toute personne qui développerait une méthode applicable pour casser
C A -1.1 ».
C A -l.le s t breveté [680], mais son utilisation est libre pour des utilisations non com
merciales. Toute personne intéressée par une licence pour l’algorithme ou par la prime
offerte pour sa cryptanalyse doit contacter : Howard G utow itz, ESPCI, L aboratoire
d’ É lectron iq u e, 10 rue Vauquelin, 75005 P a r is , France.
13.12 Skipjack
S k i p j a c k est l’algorithme de chiffrement développé par la NSA pour les puces C l i p p e r
et C a p s t o n e (voir § 24.16 et § 24.17). Comme cet algorithme est classé « Top Secret »,
il n’a jamais été publié. Il sera réalisé uniquement dans des puces résistantes à l’inves
tigation.
L’algorithme est classé « Top Secret » non pas parce que cela augmente la sécurité,
mais parce que la N SA ne veut pas que l’algorithme soit utilisé sans le mécanisme de
dépôt de clef C l i p p e r . Ils ne veulent pas que l’algorithme soit réalisé en logiciel et
s’étende à travers le monde.
S k i p J a c k est il sûr? Si la NSA veut produire un algorithme sûr, elle peut certainement
le faire. D ’un autre côté, si la N SA veut concevoir un algorithme avec brèche secrète,
elle peut tout aussi bien le faire.
Voici ce qui a été publié [1174, 468] :
- C ’est un algorithme itératif de chiffrement par blocs.
- La taille des blocs est de 64 bits.

Chapitre 13 Autres algorithmes de chiffrement par blocs
- Il a une clef de 80 bits.
- Il peut être utilisé avec les modes opératoires : E C B , C F B , O FB sur 64 bits et

C B C sur 1, 8, 16, 32 ou 64 bits.
- Il y a 32 rondes par opération simple de chiffrement ou de déchiffrement.
- La NSA a démarré la conception en 1985 et a terminé l’évaluation en 1990.
La documentation de la puce C l i p p e r de M y k o t r o n x indique que la latence de

l’algorithme S k i p j a c k est de 64 cycles d ’horloges. Cela veut dire que chaque ronde
prend deux cycles d’horloges : certainement un pour la substitution par table-S1et un
pour le o u e x c l u s if final à la fin de la ronde7. La documentation de M y k o t r o n x fait
référence à cette opération sur deux cycles sous le nom de « table G » et à l’ensemble
sous le nom de « s h if t » (« décalage »). (Une partie de la table-G est appelée table-F,
probablement une table de constantes, ou peut-être une table de fonctions.)
J ’ai entendu une ru m eur disant que S k i p j a c k utilise 16 tables S , et une autre disant
que la m ém oire totale prise p a r les tables -S est de 128 octets. Il y a p eu de chances
que ces rum eurs soient toutes les deux vraies.
Une autre rumeur insinue qu’à l’inverse de celles du DES, les rondes de S k i p j a c k
n’agissent pas sur des moitiés de bloc. Ceci combiné avec la notion de « décalages » et
une déclaration faite par mégarde à la conférence Crypto ’94 comme quoi S k i p j a c k a
« une structure interne sur 48 bits » implique qu’il est de conception similaire à SHA
(voir § 18.7) mais avec quatre sous-blocs de 16 bits : trois sous-blocs passent à travers
une fonction à sens unique dépendant de la clef pour donner 16 bits qui sont combinés
par ou exclusif avec le sous-bloc restant. Ensuite le bloc entier est décalé circulairement
de 16 bits pour devenir l’entrée de la ronde suivante. Cela implique aussi 128 octets de
données pour les tables-.S'. Je suspecte que les tables ,? dépendent de la clef.
L a structure de S k i p j a c k est probablem ent sim ilaire à celle d u D E S . L a N SA est
consciente de la possibilité de reconstruire l ’algorithm e à p a rtir des puces ; ils ne ris
queront pas de nouvelles techniques cryptographiques avancées.
Le fait que la NSA compte utiliser l’algorithme S k i p j a c k pour chiffrer son « Defense
Messaging System » (D M S) indique que l’algorithme est sûr. Pour convaincre les scep
tiques, le N IST a autorisé « des experts reconnus extérieurs au gouvernement à accéder
aux détails confidentiels de l’algorithme pour évaluer ses possibilités et rapporter pu
bliquement leurs résultats » [802].
Le rapport préliminaire de ces experts [266] conclut aussi :
« En faisant l’hypothèse que le coût de la puissance de calcul est divisé

par deux tous les dix-huit mois, c’est dans 36 ans que la difficulté pour
casser S k i p j a c k par attaque exhaustive égalera la difficulté de casser le
DES aujourd’hui. Donc il n’y a pas de risque significatif que S k i p j a c k soit
cassé par attaque exhaustive dans les 30 à 40 ans à venir.
« Il n’y a pas de risque significatif que S k i p j a c k puisse être cassé par
une méthode d ’attaque basée sur un raccourci, y compris la cryptanalyse
différentielle. Il n’y a pas de clefs faibles ; il n’y a pas de propriété de complé
mentarité. N ’ayant pas eu le temps d ’évaluer l’algorithme dans les détails,
7. R appelez vous que les perm utations ne prennent pas de tem ps en réalisation matérielle.
13.12 S k i p ja c k 349
les experts ont évalué le processus de conception et d’évaluation de la N SA

elle-même.
« Le niveau de sécurité de S k i p j a c k contre une attaque cryptanalytique
ne dépend pas du caractère secret de l’algorithme. »
Bien sûr les experts n’ont pas eu le temps d ’examiner l’algorithme d’assez près pour en
arriver à une conclusion par eux-mêmes. Tout ce qu’ils pouvaient faire était de regarder
les résultats que la N SA leur a montré.
Une question sans réponse est de savoir si l’espace des clefs est linéaire (voir § 8.2).
Même si S k i p j a c k n’a pas de clef faible au sens du D E S , des artéfacts du processus
de gestion des clefs pourrait rendre certaines clefs plus fortes que d’autres. SK IP JA C K
aurait beau avoir 270 clefs fortes, bien plus que le D E S , les chances d ’en choisir une au
hasard seraient seulement de 1 sur 1000. Personnellement, je pense que l’espace des clefs
de SK IP JA C K est linéaire, mais le fait que personne ne l’ait jamais dit publiquement
est inquiétant.
S k i p j a c k est breveté, mais le brevet est en train d ’être retiré de la distribution par
un accord sur la confidentialité du brevet [1128]. Le brevet ne verra le jour que si
l’algorithme S k i p j a c k est reconstitué avec succès depuis une puce. Cela fournit au
gouvernement le beurre et l’argent du beurre : la protection d ’un brevet et la confiden
tialité d’un marché secret.
Chapitre 14
Encore d’autres algorithmes

de chiffrement par blocs
14.1 GOST
GO ST est un algorithme de chiffrement par blocs provenant de l’ex-Union Soviétique
[657, 1399]. « GOST » est l’acronyme de « Gosudarstvennyi Standard », ce qui veut dire
« standard gouvernemental ». C ’est une sorte d ’analogue du FIPS américain mis à part
le fait qu’il se référé à n’importe quel type de standard1. Le numéro de ce standard est
28147-89. Le commité gouvernemental de normalisation soviétique autorisa le standard,
quel qu’il soit.
Je ne sais pas si G O S T 28147-89 a été utilisé pour des messages classés secrets ou
seulement pour des besoins civils. Une remarque préliminaire spécifie que l’algorithme
« remplit toutes les exigences cryptographiques et qu’il n’y a pas de limite sur le de
gré de confidentialité des informations à protéger ». J’ai entendu qu’il fut initialement
utilisé pour des communications à haut degré de confidentialité, y compris des com
munications militaires classées, mais sans en avoir la confirmation.
Description de GOST
GOST utilise des blocs de 64 bits et une clef de 256 bits. La clef comporte d’autre élé
ments suplémentaires qui seront présentés plus loin. L ’algorithme consiste en l’itération
sur 32 rondes d’un algorithme de chiffrement simple.
Pour chiffrer, il faut commencer par partager le texte en deux : la moitié gauche, L et
la moitié droite D. La sous-clef pour la ronde i est notée Ki. La ronde i de G O S T se
formalise ainsi :
t , — Ri—i
Ri = Li-i © f(Ri~î A )
1. En réalité, le nom com plet est « G osudarstvennyi Standard Soyuza SSR », soit « standard gou
vernemental de l’ Union des républiques socialistes soviétiques ».
S52 Chapitre 14 Encore d’autres algorithmes de chiffrement par blocs
La figure 14.1 illustre une ronde de G O S T . La fonction / est assez simple. Tout
d’abord, la moitié droite et la ie clef sont ajoutées modulo 232. Le résultat est coupé en
huit morceaux de 4 bits qui passent ensuite chacun à travers une table-S' différente. Il y
a huit tables S distinctes dans G O S T ; les quatres premiers bits vont dans la première
table-S, les quatre suivants dans la deuxième, et ainsi de suite. Chaque table-S est
une permutation des nombres de 0 à 15. Une table-S pourrait être la suivante par
exemple :
7, 10, 2, 4, 15, 9, 0, 3, 6, 12, 5, 13, 1, 8, 11
Dans ce cas, le bit en position 0 en entrée se retrouve en position 7 en sortie. Celui de

position 1 se retrouve en position 10, et ainsi de suite. Les huits tables-S sont toutes
différentes; elles sont considérées comme une partie de la clef et doivent rester secrètes.
F i g . 14.1 - Une ronde de G O S T
Les sorties des tables-,S' sont mises bout à bout pour former un mot de 32 bits qui
subit un décalage circulaire à gauche de 11 bits. Finalement, le résultat est combiné
par ou exclusif à la moitié gauche pour devenir la moitié droite, et la moitié droite
devient la nouvelle moitié gauche. Faites cela 32 fois et vous avez fini.
La génération des sous-clefs est simple. La clef de 256 bits est coupée en huit morceaux
de 32 bits : k\, fc2, ••-, kg. Chaque ronde utilise une des sous-clefs comme indiqué dans
le tableau 14.1. Le déchiffrement se fait avec le même algorithme en inversant l’ordre
des ki.
Le standard G O S T ne dit pas comment générer les tables S1, elles sont d ’une certaine
manière fournies [657]. Certains spéculèrent qu’une certaine organisation soviétique
pourrait fournir des tables-S solides à qui bon lui semblerait et des mauvaises à ceux
qu’elle voudrait espionner. Cela pourrait très bien être vrai mais des discussions plus
poussées avec un fabricant de puces G O S T en Russie mènent à une autre alternative.
14-1 GOST 353
Tab. 14.1 - Sous-clefs utilisées dans chaque ronde de G O S T
Ronde : ï 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Sous-clef: 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
Ronde: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Sous-clef: 1 2 3 4 5 6 7 8 8 7 6 5 4 3 2 1
Il a généré lui-même les permutations des tables-.S' avec un générateur de nombres

aléatoires.
Plus récemment, un ensemble de tables-S utilisé dans par la banque centrale de Russie
a vu le jour. Ces tables-S sont aussi utilisées dans la fonction de hachage à sens unique
GOST (voir § 18.11) [659]. Elles sont données dans le tableau 14.2.
Cryptanalyse de GOST
Il y a des différences majeures entre G O S T et le DES.
- La génération des sous-clefs est compliquée dans le DES. Elle est simple dans
GOST.
- Le DES utilise une clef de 56 bits; G O S T utilise une clef de 256 bits. Si vous
prenez en compte les tables S, cela représente environ 610 bits d’information
secrète.
- Les tables-S1du DES ont 6 bits d’entrée et 4 de sortie; celles de G O S T ont 4

bits d ’entrées et 4 de sortie. Les deux algorithmes utilisent 8 tables-S, mais celles
du DES sont quatre fois plus grandes que celles de G O S T .
- Le DES utilise une permutation irrégulière, appelée une table-P ; G O S T utilise

un décalage circulaire à gauche de 11 bits.
- Le DES opère 16 rondes ; G O S T en opère 32.
S’il n’y a pas d ’autre moyen de casser G O S T que l’attaque exhaustive, c ’est un algo
rithme très sûr. G O S T utilise une clef longue de 256 bits et même plus si on compte
les tables-S. G O S T est certainement plus résistant aux cryptanalyse différentielle et
T ab . 14.2 - Tables-S de G O S T
Table-S 1: 4 10 9 2 13 8 0 14 6 11 1 12 7 15 5 3
Table-S 2: 14 11 4 12 6 13 15 10 2 3 8 1 0 7 5 9
Table-S 3: 5 8 1 13 10 3 4 2 14 15 12 7 6 0 9 11
Table-S 4: 7 13 10 1 0 8 9 15 14 4 6 12 11 2 5 3
Table-S 5: 6 12 7 1 5 15 13 8 4 10 9 14 0 3 11 2
Table-S 6: 4 11 10 0 7 2 1 13 3 6 8 5 9 12 15 14
Table-S 7: 13 11 4 1 3 15 5 9 0 10 14 7 6 8 2 12
Table-S 8: 1 15 13 0 5 7 10 4 9 2 3 14 6 11 8 12
354 Chapitre 14 Encore d’autres algorithmes de chiffrement par blocs
linéaire que le DES. Bien que les tables -S aléatoires de G O S T soient probablement
plus faibles que celles adoptées dans le DES, le fait qu’elles soient secrètes renforce
la résistence de G O S T aux attaques différentielles et linéaires. Ces deux attaques dé
pendent aussi du nombre de rondes : plus il y a de rondes, plus l’attaque est difficile.
Le seul fait que G O S T ait deux fois plus de rondes que le DES rend probablement les
deux cryptanalysés différentielle et linéaire impratiquables.
Les autres parties de G O S T sont équivalentes ou inférieures à celles du DES. GOST
n’utilise pas de permutation expansive équivalente à celle du DES. Retirer cette per
mutation du DES l’affaiblit en réduisant l’effet d ’avalanche; il est raisonnable que
G O S T est plus faible que s’il utilisait une telle permutation. L ’emploie dans GOST
de l’addition au lieu du ou exclusif du DES n’est pas moins sûre.
La principale différence entre les deux algorithmes semble résider dans le décalage
circulaire de G O S T au lieu d ’une permutation expansive. Cette permutation augmente
dans le DES l'effet d ’avalanche. Dans G O S T , le changement d ’un bit d’entrée affecte
une table-S à la première ronde, ce qui affecte ensuite deux tables S à la deuxième
ronde, puis quatre à la troisième ronde, et ainsi de suite. Il faut huit rondes de GOST
avant que la modification d ’un bit n’affecte tous les bits de sortie, alors que cinq suffisent
avec le DES. Ceci est certainement une faiblesse. Mais n’oubliez pas que G O S T a 32
rondes et que le D ES en a 16.
Les concepteurs de G O S T ont essayé de réaliser un compromis entre l’efficacité et la
sécurité. Ils ont modifiés la conception originelle du DES pour obtenir un algorithme
mieux adapté à la réalisation par logiciel. Ils semblent avoir été moins sûrs de la sécurité
de l’algorithme et ils ont essayé de la compenser en allongeant la longueur de la clef, en
gardant les tables -S secrètes et en doublant le nombre d ’itérations. Que leurs efforts
aient abouti à un algorithme plus sûr que le DES reste encore à voir.
14.2 CAST
C A S T a été conçu au Canada par Carlisle A d a m s et Stafford T a v a r e s [14, 11]. Ils
prétendent que le nom provient de la façon dont l’algorithme a été conçu, et est sensé
évoquer l’image du hasard, mais remarquez les initiales des auteurs. Dans C A S T , les
blocs ont une taille de 64 bits, ainsi que la clef.
La structure de C A S T va vous paraître familière. L ’algorithme utilise huit tables ,?
prenant 8 bits en entrée et 32 en sortie. La construction de ces tables S est compliquée
et dépend de la réalisation, reportez-vous aux références pour les détails.
Pour chiffrer, il faut partager le texte en clair en la moitié gauche et la moitié droite.
L ’algorithme opère huit rondes. A chaque ronde, la moitié droite est combinée avec
une partie de la clef en utilisant une fonction / et avec la moitié gauche par ou exclusif
pour devenir la nouvelle moitié droite. La moitié droite originelle (avant modifications)
devient la nouvelle moitié gauche. Après la huitième ronde, il ne faut pas échanger les
deux moitiés droite et gauche ; le texte chiffré est obtenu en les mettant bout à bout.
La fonction / est simple :
1° Diviser les 32 bits d’entrée en quatre parts de 8 bits, a, b, c, d.

2° Diviser les 16 bits de la sous-clef en deux morceaux de 8 bits : l, m.
3° Passer a à travers la table S 1, b à travers la table-S 2, c à travers la table-S 3,
14-3 B lo w fis h 355
d à travers la table- S 4, l à travers la table-S 5, m à travers la table-S 6 .
4° Combiner par ou exclusif les six sorties des tables-S ensembles pour obtenir
la sortie finale de 32 bits.
Une alternative consiste à combiner par ou exclusif les 32 bits d’entrée et 32 bits de
la clef, à partager le résultat en quatre parts de 8 bits, et à combiner le tout par ou
exclusif [11]. Il se trouve que N rondes de cette version sont aussi sûres que N + 2
rondes de l’autre option.
Les sous-clefs de 16 bits sont facilement calculées d ’après la clef de 64 bits. En notant
ki,k-2 , ■■■fis les huits octets de la clef, les sous-clefs de chaque ronde sont les suivantes :
Ronde 1 : k\, k-2

Ronde 2 : kz, k4
Ronde 3 : k$, ke
Ronde 4 : k?, k$
Ronde 5 : k4, k-j,
Ronde 6 : k2 , fci
Ronde 7 : ks , fc7
Ronde 8 : k6,
La solidité de cette algorithme réside dans ses tables -S. Les tables S de C A S T ne sont
pas fixées ; de nouvelles tables sont construites pour chaque application. Les critères de
conception sont donnés dans [14] ; les fonctions courbées sont les colonnes des tables-
5, et sont choisies selon un certain nombre de propriétés désirées des tables-5 (voir
§ 14.10). Une fois qu’un ensemble de tables S a été attribué à une réalisation donnée
de C A S T , elles restent fixes à jamais. Les tables-5 dépendent de la réalisation, mais
pas de la clef.
Il est montré dans [14] que C A S T résiste à la cryptanalyse différentielle et dans [731]
qu’il résiste à la cryptanalyse linéaire. La seule méthode connue de casser C A S T est
l’attaque exhaustive.
La société N o r t h e r n T e l e c o m utilise C A S T dans leur logiciel de sécurité « Entrust »
qui est distribué pour les Macintosh, les PC, et les stations Unix. Les tables -S qu’ils
ont choisies n’ont pas été rendues publiques. Le gouvernement canadien évalue actuel
lement C A S T comme un nouveau standard de chiffrement. C A S T est en instance de
brevetage.
14.3 Blowfish
B l o w f i s h est un algorithme de ma conception, prévu pour être réalisé par logiciel sur
les gros microprocesseurs [1394, 1393]. L ’algorithme n’est pas breveté et le code source
en C qui se trouve à la fin de cette ouvrage fait partie du domaine publique. J’ai conçu
B l o w f i s h pour répondre aux critères de conception suivants :
1. Rapidité. B l o w f i s h chiffre sur un microprocesseur 32 bits à la vitesse de 26

cycles d ’horloge par octet.
2. Compacité. B l o w f is h peut tourner avec moins de 5 kilo-octets de mémoire.

3. Simplicité. B l o w f i s h n ’utilise que des opérations simples : addition, ou exclusif,

et recherche dans des tableaux avec des paramètres de 32 bits. Sa conception est
facile à analyser, ce qui le rend résistant aux erreurs de programmation [13951.
4. Sécurité variable. La longueur de la clef est variable dans B l o w f i s h et peut

atteindre 448 bits.
B l o w f i s h est optimisé pour les applications où la clef ne change pas souvent, comme
les liens de communication ou un chiffreur automatique de fichiers. Il est significative
ment plus rapide que le DES avec des microprocesseurs 32 bits possédant une mémoire
cache importante tels que le Pentium ou le PowerPC. B l o w f i s h n’est pas adapté aux
applications telles que l’échange de paquets avec beaucoup de changement de clefs, ou
à l’utilisation comme fonction de hachage à sens unique. L ’espace mémoire requis est
trop important pour l’utiliser dans les cartes à puces.
Description de Blowfish
B l o w f i s h est un algorithme de chiffrement par blocs de 64 bits à longueur de clef
variable. L ’algorithme se fait en deux phases : expansion de la clef et chiffrement des
données. L ’expansion de la clef convertit une clef de taille inférieure à 448 bits en
plusieurs tableaux de sous-clefs d’une taille totale de 4168 octets.
Le chiffrement est obtenu en itérant 16 fois une fonction simple (voir la figure 14.2).
Chaque ronde consiste en une permutation dépendant de la clef et une substitution
dépendant de la clef et des données. Toutes les opérations sont des additions et des ou
exclusifs sur des nombres de 32 bits. La seule opération supplémentaire est la consul
tation de quatre tableaux indéxés par ronde.
B lo w fis h utilise un grand nom bre de sous-clefs. C es sous-clefs doivent être pré
calculées avant tout chiffrement ou déchiffrement de données.
Le tableau P est constitué de 18 sous-clefs de 32 bits :
Pi,P'2 , ■■■,Pis-
Il y a quatre tables-S de 32 bits ayant 256 entrées chacune :
$1,0,$1.1 , •••A , 255

$ 2 ,0 ,$ 2 .1 ,- . . ,$2,255
$ 3 ,0 ,$ 3 ,l i ■••,$3,255
$ 4 ,0,$4.1 , - ■- ,$4,255
La méthode de calcul de ces sous-clef sera exposée un peu plus loin.

B l o w f i s h est un réseau de Feistel (voir § 14.10) constitué de seize rondes. L ’entrée
est un élément de données x de 64 bits. Pour chiffrer, procéder de la manière suivante :
Partager x en deux moitiés de 32 bits : x l ,x r .

Pour i variant de 1 à 16, effectuer:
XL = XL © Pt
x R = F (x l ) ® Xn
Echanger x l et x r .
14-3 B lo w fis h 35 7
F ig . 14.2 - B l o w f is h
Échanger xr et x r (annuler le dernier échange).

xr = xr ® Pn
x l = x r ® Pi8
Remettre xr et x r bout à bout.
La fonction F est la suivante (voir la figure 14.3) :
Diviser x r en quatre parts de 8 bits a,b,c,d.

x r ) = ((5 i,a + S2,b modulo 232) ® 5 3iC) + 5 4,d modulo 232
F {
Le déchiffrement s’effectue exactement de la manière en inversant l’ordre des Pi.

Les réalistions de B l o w f i s h nécessitant une vitesse maximale devraient dérouler la
boucle et s’assurer de la présence des sous-clefs dans la mémoire cache. Voir [570] pour
les détails.
8 bits 32 bits
Table-S 1
l
8 bits 32 bits 1
Table-S 2
32 bits
8 bits 32 bits
Table-S 3
32 bits
8 bits 32 bits
Table-S 4
F ig . 14.3 - La fonction F
Les sous-clefs sont calculées de la manière suivante :
1° Initialiser le tableau- P et les quatre tables-S avec une chaîne de caractères

fixée. Cette chaîne est constituée des décimales de tï.
2 ° Combiner par ou exclusif Pi et les 32 premiers bits de la clef, P2 avec les 32

bits suivants, et ainsi de suite pour tous les bits de la clef Itérer ce procédé le
nombre nécessaire de fois pour traiter tout le tableau-P.
3 ° Chiffrer la chaîne constituée de zéros uniquement avec B l o w f ish et les sous-

clefs telles qu’elles sont après les étapes 1 et 2 .
4 ° Remplacer Pi et P2 avec le résultat de l’étape 3.
5 ° Chiffrer le résultat de l’étape 3 avec B lo w fish et les sous-clefs modifiées.
6° Remplacer P3 et P4 avec le résultat de l’étape 5.
7° Itérer ce procédé de manière à remplacer tous les éléments du tableau-P et

des tables-S (dans l’ordre) avec le résultat de l’algorithme B l o w f ish modifié
à chaque fois.
521 itérations sont nécessaires au total pour générer toutes les sous-clefs. L’application
peut stocker les sous-clefs, il n’est pas nécessaire d ’effectuer ce procédé de génération
plusieurs fois.
Sécurité de Blowfish
Serge V a u d e n a y a examiné B l o w f ish avec r rondes en ayant connaissance des tables-
S. Une attaque différentielle permet de retrouver le tableau-P avec 2 8 r + 1 textes en
clair choisis [1570]. Pour certaines clefs faibles qui génèrent de mauvaises tables-5 (la
144 SAFER 359
probabilité d ’en prendre une au hasard est de une chance sur 214), cette attaque n’a
besoin que de 24r 11 textes en clair choisis. Si les tables- S ne sont pas connues, cette
attaque permet de détecter si une clef faible a été utilisée, mais ne permet pas de
la trouver (ni les tables- 5 , ni le tableau-P). Cette attaque ne marche que contre les
variantes avec peu de rondes; elle est complètement impraticable contre le B l o w f i s h
à 16 rondes.
Bien sûr, la découverte de clefs faibles est significative, même si elle semble impossible
à utiliser. Une clef faible est une clef pour laquelle deux entrées d’une des table-S1sont
identiques. Il n’y a pas moyen de tester si une clef est faible avant d ’effectuer la phase
d’expansion. Si vous vous inquiétez, il vous faut faire l’expansion de la clef et vérifier
qu’aucune des tables-S n’a deux entrées identiques. Cependant, je ne pense pas que
cela soit nécessaire.
Je ne connais aucune attaque cryptanalytique contre B l o w f i s h . Par prudence, ne
réalisez pas B l o w f i s h avec un nombre réduit de rondes.
La société K e n t M a r s h L t d . a incorporé B l o w f i s h dans leur produit de protection
« FolderBolt » pour Microsoft Windows et Macintosh. Il fait aussi partie de « Nautilus »
et « PGPfone ».
14.4 SAFER
SA F E R K -64 vient de « Secure And Fast Encryption Routine » qui veut dire procédure
de chiffrement rapide et sûre [1015]. « K-64 » signifie que la clef a une longueur de 64
bits. James M a s s e y a conçu cet algorithme non déposé pour C y l i n k C o r p . et fait
partie de certains de leurs produits. Le gouvernement de Singapour prévoit d’utiliser
cet algorithme avec une clef de 128 bits [1016] pour une large variété d ’applications. Il
n’y a ni brevet, ni droits d ’exploitation, ni aucune autre restriction sur son utilisation.
La taille des blocs et de la clef sont de 64 bits. Ce n’est pas un réseau de Feistel comme
le DES (voir § 14.10), mais un algorithme de chiffrement par blocs itératif: la même
fonction est appliquée pour un certain nombre de rondes. Chaque ronde utilise deux
sous-clefs de 64 bits, et l’algorithme n’utilise que des opérations sur des octets.
Description de SAFER
Le bloc de texte en clair est divisé en huit parts d ’un octet : . . . ,BH. Les sous-
blocs subissent alors r rondes. Pour finir, une transformation de sortie est appliquée
aux sous-blocs; Chaque ronde utilise deux sous-clefs : —i et K^r-
La figure 14.4 illustre une ronde de S A F E R K-64. Les sous-blocs sont tout d’abord
combinés avec des bits de la sous-clef K<ir i par ou exclusif ou par addition. Les huits
sous-blocs subissent ensuite une des deux transformations non linéaire suivantes :
y — 45x modulo 257. (Si x = 0, on pose y = 0.)

y = log45 x. (Si x = 0, on pose y = 0.)
Ce sont des opérations dans le corps fini Z/257, et 45 est un générateur de ce corps.
Dans les réalisations pratiques de SA F E R , il est plus rapide de stocker ces valeurs
dans un tableau que de les recalculer à chaque fois. Les sous-blocs sont alors combi
nés avec des bits de la sous-clef K ir par ou exclusif ou par addition. Les résultats
F ig . 14.4 - Une ronde de S A F E R
de cette opération passent alors à travers trois couches d’opérations linéaires dont
l'intérêt est d ’augmenter l’effet d’avalanche. Chaque opération est appelée une pseudo
transformation d’Hadamard (P T H en abrégé). Si une P T H prend en entrée ai et a2,
alors sa sortie est :
bi = (2 * ai + a2) modulo 256
62 = (ai + a2) modulo 256
Après les r rondes, on opère une transformation finale, la même que la première étape
de chaque ronde. Bi, B 4 , B 5 , et Bs sont combinés par ou exclusif avec les octets
correspondants de la dernière sous-clef, et Z?2, B 3 , Bç, et B 7 sont additionnés avec les
bits correspondants de la dernière sous-clef. Le résultat est le texte chiffré.
Le déchiffrement est le procédé inverse: la transformation de sortie (avec des sous
tractions au lieu des additions), puis r rondes inversées. La PTH inversée (P T H I) est
donnée par :
ax = (£>1 — 6 2 ) modulo 256
a 2 = {—bi + 2è2) modulo 256
M A S S E Y conseille d ’effectuer 6 rondes, m ais vous pouvez en faire plus p o u r plus de

sécurité.
14.5 3 -W A Y 361
La génération des sous-clefs est simple. La première sous-clef K\ est la clef elle même.
Les sous-clefs suivantes sont produites de la manière suivante :
K i+1 = (K i « < 3i) + Ci
Le symbole « < < < » est un décalage circulaire vers la gauche soit encore une rotation
vers la gauche. La rotation se fait octet par octet, et c, est une constante de la ronde.
Si Cij représente le j e bit de la constante de la ie ronde, vous pouvez calculer les
constantes de toutes les rondes grâce à la formule suivante :
Cij = 4545<e‘ l j) modul° 257 modulo 257 m o d u lo 2 5 ?
Généralement, ces valeurs sont stockées dans un tableau.
SAFER K-128
Cette alternative de gestion des clefs a été développée par le ministère de l’intérieur
de Singapour, et incorporée ensuite par M a s s e y dans S A F E R [1016]. Elle repose sur
deux clefs de 64 bits K a et Kb- L’astuce consiste à générer deux séquences de sous-clefs
en parallèle et à prendre alternativement une sous-clef dans chaque séquence. Cela
signifie qu’en prenant K a — K h, la clef de 128 bits est compatible avec la clef de 64
bits K a.
Sécurité de SAFER k-64

M A S S E Y a montré que S A F E R est immune à la cryptanalyse différentielle à partir de
huit rondes et suffisament résistant à cette attaque après six rondes. La cryptanalyse
linéaire est inefficace contre cet algorithme après trois rondes seulement [1016].
KNUDSEN a trouvé une faiblesse dans la gestion des clefs : il existe virtuellement pour
chaque clef au moins une autre clef (et parfois jusqu’à neuf autres clefs) telle que
les clefs chiffrent des textes en clair différents en textes chiffrés identiques [862]. Le
nombre de textes en clair différents qui deviennent le même texte chiffré après six
rondes est compris entre 222 et 228. Si la sécurité de S A F E R n’en patît pas lorsqu’il
est utilisé comme algorithme de chiffrement, cela réduit considérablement sa sécurité
s’il est employé comme fonction de hachage à sens unique. Dans tous les cas, K N U D SEN
conseille d ’effectuer huit rondes.
SA F E R a été conçu pour C y l i n k qui est soudoyée par la N SA [87]. Je recommande
quelques années de cryptanalyse intensive avant d ’utiliser S A F E R sous quelque forme
que soit.
14.5 3-W A Y
3-W AY est un algorithme de chiffrement par blocs conçu par Joan D A E M E N [405, 411].
Il utilise des blocs et une clef de même taille : 96 bits, et il est conçu pour être très
efficace en réalisation matérielle.
3-W AY n ’est pas un réseau de Feitel mais un algorithme de chiffrement itératif. 3-
W AY peut comprendre n rondes; D a e m e n en conseille 11.
Description de 3-W A Y
L’algorithme est simple à décrire Pour chiffrer un bloc de texte en clair x , procédé
comme suit :
Pour i variant de 0 à n — 1, effectuer les opérations suivantes :
x = x © Kt
x = theta(x)
x = pi — l(x )
x = gamma(x)
x = pi — 2(x)
x = x © K n+ 1
x = theta(x)
Les fonctions sont les suivantes :
theta(x) est une fonction de substitution linéaire— en substance, un mélange de

décalages circulaires et de ou exclusifs.
- pi — l(x ) et pi — 2(x) sont des permutations simples.
- gamma(x) est une fonction de substitution non linéaire. C’est cette étape qui a
donné son nom à 3-W A Y ; il s’agit de l’exécution en parallèle d ’opérations de
substitution sur des blocs de 3 bits de l’entrée.
Le déchiffrement se fait de la même manière en inversant les bits de l’entrée et aussi

ceux de la sortie. Le code source de 3-W A Y se trouve à la fin de ce livre.
Jusqu’à présent, personne n’a réussi à cryptanalyser 3-W AY. L’algorithme n’est pas
breveté.
14.6 CRAB
Les auteurs de cet algorithme sont Burt KALISKI et Matt RoBSHAW des laboratoires
R SA [800]. L ’idée de C R A B est d’utiliser les techniques propres au fonctions de ha
chage à sens unique pour construire un algorithme de chiffrement rapide. Du coup,
C R A B ressemble beaucoup à M D5, et les concepts du paragraphe 18.5 seront suppo
sés connus dans ce qui suit.
C R A B s’appuie sur une grande taille de blocs : 1024 octets. Comme C R A B est plutôt
un travail de recherche qu'un algorithme réel, aucune procédure de génération de clef
n’est décrite. Les auteurs suggèrent une méthode permettant de déduire d ’une clef de
80 bit les trois sous-clef requises, bien que l’algorithme pourrait très bien accepter des
clefs de longueur variable.
C R A B utilise deux ensembles de grandes sous-clefs:
Une permutation des nombres de 0 à 255 : Po,Pi, ■•■,p 2bc-

Un tableau de 2048 nombres de 32 bits : So,S \, . . . ,52047-
14.6 CRAB 363
Ces sous-clefs doivent être calculées avant le chiffrement ou le déchiffrement.

Voici comment chiffrer un bloc X de 1024 octets :
1° D i v i s e r X e n 256 s o u s -b lo c s d e 32 b i t s : X 0 , X i , . . . , X 255.
2° P e r m u t e r les s o u s -b lo c s d e X s e lo n P .
3° P o u r r v a r ia n t de 0 à 3 e t g v a r ia n t de 0 à 63, e ffe c tu e r :
A = X {4g )< < < 2r

B = -V(4ff+ l ) « < 2 r
C = X ( 4g+2 ) < « 2 r
B = X ( 4 f/+3'j < < < 2 r
P o u r s v a r ia n t de 0 à 7, fa ir e :
A = A © (B + f r(B ,C ,D ) + *S'512ir+8g+s)
A’ = D
D = C
C = B
B = A « < 5
A = A'
^ { 4g ) < « 2r = A
A ( 4 s- | _ i ) « < 2r — B
X ( 4 g + 2) < « 2 r = C
X (4 < , i - 3 ) « < 2 r — D
4° R e m e t tr e X 0 , X i , . . . , X 255 e n s e m b le p o u r f o r m e r le t e x t e c h iffr é.
Les fonctions f r ( B , C , D ) sont similaires à celles utilisées dans M D -5 :
f ( B , C , D ) — ( B A C ) V ( ( - .B ) A D )
f ( B , C , D ) = ( B A D ) V ( C V (-,£>))
f(B ,C ,D ) — B 0 C ® D
f { B , C , D ) = C © ( B V (-.£>))
Le déchiffrement se fait par le procédé inverse.

La génération des clefs est une lourde tâche. Voici comment produire le tableau P
représentant la permutation requise à partir d’une clef K de 80 bits :
1° ln itia lis e r K^, K\, . . . ,Kg a v e c les d ix o c te ts d e K .
2° P o u r i v a r ia n t d e 10 à 255 e ffe c tu e r :
Ki = 2 © K i—g © K i - 7 © K i - 10.
3° P o u r i v a r ia n t de 0 à 255, p o s e r P i = i.
4° m = 0.
Chap re 14 Encore d’autres algorithmes de chiffrement par blocs
5° Effectuer deux fois la boucle suivante : pour i variant de 256 à 1 (par incré
mentations de —1), faire:
m = ( K 256-i + K 257- i ) modulo i

K 257-i = ^257-i « < 3
Echanger I\ et l\-\
Le tableau S pourrait être construit d ’une manière similaire, soit à partir de la même
clef de 80 bits, soit à partir d’une autre. Les auteurs attirent l’attention sur l’importance
de ces détails : « il peut très bien exister des schémas alternatifs à la fois plus efficaces
et offrant plus de sécurité » [800].
C R A B a été présenté plus comme un nid d ’idées nouvelles que comme un algorithme
fonctionnant. Il utilise beaucoup de techniques similaires à celles de M D -5. B ih a m
prétend qu’une taille de bloc trop large rend la cryptanalyse d ’un algorithme plus
aisée [167]. D ’un autre côté, C R A B pourrait fort bien s’accomoder d’une très longue
clef. Dans ce cas, « plus aisé à cryptanalyser » risque de ne plus vouloir dire grand
chose.
14.7 SXAL8 et M B AL
Il s’agit d ’un algorithme par blocs de taille 64 bits [769]. SX A L 8 est l’algorithme de
base; M B A L est une version étendue dans laquelle la taille des blocs est variable.
Partant du fait que M B A L opère intelligemment de façon interne, les auteurs pré
tendent obtenir une sécurité suffisante avec peu de rondes seulement. Avec une taille de
bloc de 1024 bits, M B A L est environ 70 fois plus rapide que le DES. Malheuresement,
il est montré dans [1180] que M B A L est propice à la cryptanalyse différentielle et dans
[866] qu’il est propice à la cryptanalyse linéaire.
14.8 R.C5
RC5 est un algorithm e de chiffrement p a r blocs avec de nom breux param ètres : taille
des blocs, taille de la clef, et nom bre de rondes. R o n R iv e s t en estl’inventeur et il a
été analysé p a r les laboratoires R SA [1335, 1336],
Il y a trois opérations: ou exclusif, addition, et rotation. Les rotations prennent un
temps constant sur la plupart des processeurs et les rotations variables sont des fonc
tions non linéaires. Ces rotations qui dépendent à la fois de la clef et des données
constituent la partie intéressante.
La longueur des blocs est variable dans R C5, mais on se concentrera dans l’exemple
qui suit sur une taille de 64 bits. Le chiffrement nécessite 2r + 2 mots de 32 bits
dépendants de la clef, Sq,Si , . . . ,S2r+2, où r est le nombre de rondes. Nous parlerons
de leur génération plus tard. Pour chiffrer, diviser tout d’abord le bloc de texte en clair
en mots de 32 bits : A et B. Il faut alors procéder ainsi :
A = A + iSo
B = B + Si
14-8 RC5 365
Pour i variant de 1 à r, effectuer :
A — {{A 0 B) « < B ) + S2i

B = ((B ® A) « < A) + S2i+ 1
La sortie est constituée des registres A et B.

Le déchiffrement est tout aussi facile. Partager le texte chiffré en deux mots A et B ,
et effectuer :
Pour i décroissant de r à 1 :
B = {{B - S 2z+1) » > A) ® A

A = (( A - S m ) » > B ) ® B
B = B +Sx
A = A 4- Sq
La création du tableau de ciels est plus compliquée mais directe aussi. Commencez
par copier les bits de la clef dans un tableau L de c mots de 32 bits (en remplissant
si nécessaire le dernier mot avec des zéros). Initialisez alors le tableau en utilisant un
générateur congruentiel modulo 232 :
S0 = P
Pour i variant de 1 à 2 (r + 1) — 1, effectuer :
St = {Si + Q ) modulo 232
P = 0xB7E15163 et P = 0x9E3779B9 sont des constantes basées sur e.

Pour finir, mélangez L et S :
i= j = 0
A = B = 0
Effectuer n fois (où n est le maximum de 2(r + 1) et c) :
A = Si = (Sz + A + B) « < 3
B = Lt = { L j + A + B ) « < {A + B)
i = {i + 1) modulo 2(r + 1)
j = (j + 1) modulo c
RC5 est en fait une famille d’algorithmes. Nous avons défini R C 5 avec des mots de 32
bits de long et des blocs de 64 bits de long ; rien n’empêche l’algorithme de fonctionner
avec des mots de 64 bits de long et des blocs de 128 bits de long. R i v e s t désigne
les réalisations particulières de R C5 par R C 5 - w / r / b où w est la taille des mots, r le
nombre de rondes, et b la longueur de la clef en octets. Pour w = 64, P et Q valent
respectivement 0xB7E151628AED2A6B et 0x9E3779B97F4A7C15.
R C5 est nouveau, mais les laboratoires R SA ont passé un temps considérable à l’ana
lyser avec une taille de bloc de 64 bits. Après 5 rondes, les statistiques paraissent très
bonnes. Après 8 rondes, chaque bit du texte en clair affecte au moins une rotation. Il
existe une attaque différentielle avec 224 textes en clair choisis- pour 5 rondes, 245 pour
10 rondes, et 268 pour 15 rondes. 11 n ’y a bien sûr que 264 textes en clair possibles,
aussi cette attaque ne marchera pas pour 15 rondes ou plus. Des estimations en crypta
nalyse linéaire indiquent que l’algorithme est sûr après 6 rondes. R i v e s t recommande
au moins 12 rondes et 16 si possible [1336]. Ce nombre pourrait changer.
R SA D SI est en train de faire breveter R C5, et le nom est déposé. La société prétend
que les frais de license seront très réduits, mais vous feriez mieux de vérifier au près
d’eux.
14.9 Autres algorithmes de chiffrement par

blocs
11 existe dans la littérature un algorithme appelé C R Y P T O -M E C A N O [303]; il
n’est pas sûr. Quatre cryptographes japonais ont présenté un algorithme basé sur
la théorie du chaos à la conférence EUROCRYPT’91 [688, 689]. B i h a m a cryp-
tanalysé cet algorithme à la même conférence [164], Un autre algorithme repose
sur des sous-ensemble d ’un ensemble particulier de chiffres aléatoires [694]. Il existe
plusieurs algorithmes basés sur la théorie des codes correcteurs d’erreurs : une va
riante de l’algorithme de M c E l i e c e (voir § 19.7) [786, 1301], l’algorithme de R a o -
N a m [1303, 735, 1508, 1302, 1064, 1066, 1065, 1304], des variantes de l’algorithme de
R a o - N a m [470, 751, 1507], et l’algorithme de L i - W a n g [975, 1532] ; aucun n’est sûr.
C A L C n’est pas sûr [1115]. Un algorithme du nom de T E A pour « Tiny Encryption
Algorithm » (petit algorithme de chiffrement) est encore trop neuf pour être commenté.
V i n o est encore un autre algorithme [1271]. M a c G u f f i n , un algorithme de chiffre
ment par blocs conçu par Matt B l a z e et moi-même n’est pas sûr non plus [196] ; il fut
cassé durant la conférence où il a été présenté. B a s e K i n g , un algorithme de conception
philosophiquement identique à celle de 3-W AY mais avec une taille de bloc de 192 bits
[390], est trop nouveau pour être commenté.
Il y a bien plus d ’algorithmes de chiffrement par blocs disponibles hors de la com
munauté cryptologique. Certains sont utilisés par diverses organisations gouvernemen
tales et militaires. Je n’ai aucune information les concernant. Il y a aussi des douzaines
d ’algorithmes commerciaux privés. Certains peuvent être bons ; la plupart ne le sont
probablement pas. Si les sociétés estiment que rendre l’algorithme public ne sert pas
leurs intérêts, il vaut mieux faire l’hypothèse qu’elles ont raison et éviter l’algorithme.
14.10 Théorie des algorithmes de chiffre

ment par blocs
J’ai décrit au paragraphe 11.1 les principes de confusion et de diffusion de S h a n n o n .
Cinquante après la première rédaction de ces principes, ils restent les fondations de la
conception d ’un bon algorithme de chiffrement par blocs.
14-10 Théorie des algorithmes de chiffrement par blocs 367
La confusion sert à cacher les relations entre le texte en clair, le texte chiffré, et la clef.
Vous rappelez vous comment la cryptanalyse différentielle peut exploiter la moindre
relation entre ces trois éléments? Une bonne confusion rend les relations statistiques
si compliquées que mêmes ces outils cryptanalytiques puissants ne marche pas.
La diffusion répand l’influence d ’un bit particulier du texte en clair ou de la clef aussi
loin que possible dans le texte chiffré. Cela camoufle aussi les relations statistiques et
rend la cryptanalyse plus difficile.
La confusion à elle seule suffit pour la sécurité. Un algorithme qui mettrait en corres
pondance en fonction de la clef les 264 textes en clair possibles avec les 264 textes chiffrés
possibles serait tout à fait solide. Le problème est que cela nécessiterait beaucoup de
mémoire : il faudrait stocker un tableau de 1020 octets. La conception d ’algorithmes de
chiffrement par blocs consiste à créer quelque chose qui ressemble à un tel algorithme,
mais en utilisant beaucoup moins de mémoire.
L’astuce est de mélanger répétivement la confusion (avec des tableaux beaucoup plus
petits) et la diffusion avec un seul algorithme de chiffrement dans différentes com
binaisons. Ceci s’appelle un algorithme de chiffrement produit. Un algorithme
constitué de couches de substitution et de permutations est parfois appelé un réseau
substitution-permutation ou encore un réseau SP.
Considérez la fonction / du DES. La permutation expansive et la table P servent à
la diffusion ; les tables—S servent à. la confusion. La permutation expansive et la table-
P sont linéaires ; les tables S ne sont pas linéaires. Chaque opération isolée est assez
simple ; ensembles, elles fonctionnent plutôt bien.
Le DES présente quelques principes de conception d’algorithmes de chiffrement sup
plémentaires. Le premier est l’idée d’un algorithme de chiffrement itératif. Cela
désigne tout simplement le fait de prendre une fonction de ronde simple est de la ré
péter plusieurs fois. Le DES à deux rondes n’est pas bien solide ; il faut au moins cinq
rondes avant que les bits de sortie dépendent de tous les bits d’entrée et de tous les
bits de la clef [1088, 1084]. Le DES à seize rondes est solide; le DES à trente deux
rondes l’est encore plus.
Réseaux de Feistel
La plupart des algorithmes de chiffrement par blocs sont des réseaux de Feistel.
Cette idée date du début des années 1970 [554, 555]. Prenez un bloc de longueur n et
divisez le en deux moitiés de longueur n /2 : L et R. n doit bien sûr être pair. Vous
pouvez définir un algorithme de chiffrement par blocs itératif où la sortie de la ie ronde
est déterminée d’après la sortie de la ronde précédente :
h) Ri 1
R i = L i_ i © f ( R i ~ i , K t )
Ki est la sous-clef utilisée dans la ie ronde and / est une fonction quelconque.
Vous avez pu rencontrer ce concept dans les algorithmes DES, L u c i f e r , FE A L,
K h u f u , K h a f r e , LO K I, G O S T , C A S T , B l o w f i s h , et d’autres. Pourquoi en parler
tant? Il est garanti que la fonction est inversible. Comme la moitié droite et la sortie
de la fonction de ronde sont combinées par ou exclusif, l’égalité suivant est forcément
vérifiée :
Ri © f{Ri— îjff») — I~>i—i © f(Ri-i,Ki) © / ( R ^ — ijKi) = Li -1
368 Chapitre 14 Encore d ’autres algorithmes de chiffrement par blocs
Un algorithme de chiffrement construit avec cette méthode est forcément inversible

pour peu qu’on puisse reconstruire l’entrée de la fonction / à chaque ronde. La nature
de / n’est pas importante ; / n’a pas besoin d ’être inversible. On peut concevoir une
fonction / aussi compliquée que désiré, et il ne sera pas nécessaire de réaliser deux
algorithmes différents— un pour le chiffrement et un pour le déchiffrement. La structure
des réseaux de Feistel prend cela en compte automatiquement.
Relation simples
Le DES vérifie la propriété suivante: E k { M ) = C implique E K' { M ' ) = C' où M ' , C
et K ' sont les compléments bit à bit de A f, C et K respectivement. Cette propriété
réduit la complexité d ’une attaque exhaustive d’un facteur deux. LO K I vérifie des
propriétés de complémentation qui réduisent la complexité d ’un facteur 256.
Une relation simple peut être définie comme dans [860] :
Si E k ( M ) = C, alors E f{K)( g ( M , K ) ) = h(C,K).
où f , g et h sont des fonctions simples. Par simples, j ’entends qu’elles sont faciles à
calculer, bien plus faciles qu’une itération de l’algorithme. Dans le cas du DES, / , g
et h sont la complémentation bit à bit (de leur première variable). C ’est le résultat de
la combinaison par ou exclusif de la clef avec des parties du texte.
Les bons algorithmes de chiffrement ne vérifient aucune relation simple. Des méthodes
pour trouver de telles faiblesses sont données dans [918].
Structure de groupe
Quand on examine un algorithme, il est naturel de se demander si c ’est un groupe. Les
éléments du groupe sont les blocs de texte chiffré avec chaque clef possible, et l’opération
du groupe est la composition. Regarder la structure de groupe d ’un algorithme sert
à comprendre combien de brouillage supplémentaire on obtient en chiffrant plusieurs
fois.
Cependant, la question pertinente n’est pas de savoir si un algorithme est vraiment
un groupe, mais à quel point il est proche d’un groupe. Si cela revenait à perdre un
élément, ce ne serait pas un groupe ; mais statistiquement le double chiffrement serait
une perte de temps. Les travaux concernant le DES ont montré qu’il est loin d’être un
groupe. Il reste encore des questions intéressantes à propos du semi-groupe généré par
le chiffrement par le DES. Est-qu’il contient l’identité : c ’est à dire, engendre-t-il un
groupe? En d ’autres termes, certaines combinaisons d ’opérations de chiffrement (pas
de déchiffrement) fournissent-elles éventuellement la fonction identité? Si c ’est le cas,
quelle est la longueur de la combinaison la plus petite?
Le but est d’estimer la taille de l’espace des clefs pour une attaque exhaustive théorique
et de donner la meilleure borne inférieure de l’entropie de l’espace des clefs.
Clefs faibles
Dans un bon algorithme de chiffrement par blocs, toutes les clefs sont aussi solides les
une que les autres. Les algorithmes qui ont un petit nombre de clefs faibles ne posent
généralement pas de problème. Il y a peu de chance d ’en tirer une au hasard et il est
facile de les éviter. Cependant, on peut parfois exploiter ces clefs faibles si l’algorithme
est utilisé comme fonction de hachage à sens unique (voir § 18.11).
Résistence aux cryptanalysés différentielle et linéaire

L’étude des cryptanalyse différentielle et linéaire a éclairé de manière significative la
théorie des bons algorithmes de chiffrement par blocs. Les concepteurs d’ID E A ont
introduit le concept de différentielles, une généralisation de l’idée de base des ca
ractéristiques [942], Ils soutiennent qu’un algorithme de chiffrement par blocs peut
être conçu pour résister à cette attaque; ID E A est le résultat de ce travail [942]. Ce
concept est davantage formalisé dans [1186,1187], où Kaisa N y b e r g et Lars K n u d s e n
ont montré comment construire des algorithmes de chiffrement par blocs dont il est
possible de prouver la résistance à la cryptanalyse différentielle. Cette théorie s’étend
aux différentielles de plus haut degré [703, 168, 938, 858, 861] et aux différentielles
partielles [861]. Les différentielles de haut degré ne semblent s’appliquer qu’aux algo
rithmes ayant un petit nombre de rondes, mais les différentielles partielles se combinent
parfaitement avec les différentielles.
La cryptanalyse linéaire est plus récente, et est encore en cours d’amélioration. Des
notions de rang de clef [1023] et d ’approximation multiple [801, 802] ont été définies.
D’autres travaux étendant l’idée de la cryptanalyse linéaire se trouvent dans [1281] ;
dans [949], on tente de combiner les cryptanalysés linéaire et différentielle en une seule
attaque. Les techniques de conceptions qui protégeront contre ces types d ’attaques sont
encore floues.
K n u d s e n a fait quelques progrès en considérant quelques critères nécessaires (mais
peut-être pas suffisants) pour ce qu’il appelle les les réseaux de Feistel sûr en
pratique: des algorithmes de chiffrement qui résistent à la fois à la cryptanalyse
différentielle et la cryptanalyse linéaire [860]. N y b e r g a introduit en cryptanalyse
linéaire un concept analogue à celui des différentielles en cryptanalyse différentielle
[794].
De manière assez intéressante, il semble y avoir une sorte de dualité entre les cryp-
tanalyses différentielle et linéaire. Cette dualité apparaît à la fois dans la conception
de techniques pour construire de bonnes caractéristiques ou de bonnes approximations
linéaires [171, 1027], et dans la conception de critères de construction d ’algorithmes
résistants à ces deux attaques [312], Qui sait où mènera cette ligne de recherche. Pour
commencer, D a e m e n a développé une stratégie de conception d’algorithmes basée sur
les cryptanalysés linéaire et différentielle [405].
Conception de tables—S
La solidité d’une variété de réseaux de Feistel— et plus spécifiquement leur résistence
aux cryptanalyse différentielle et linéaire— est directement reliée à leurs tables-S. Ceci
a lancé une voie de recherche sur ce qui constitue de bonnes tables S.
Une table—S est une simple substitution : une application de m bits d ’entrée vers n bits
de sortie. Une table- S avec m bits en entrée et n bits en sortie s’appelle une table—
S à m*n bits. Les tables- S constituent en général la seule étape non linéaire d’un
algorithme ; elles sont ce qui lui donne sa sécurité. En général, plus elles sont grandes,
meilleures elles sont.
Le DES a huit tables S à 6*4 bits différentes. K h u f u et K h a f r e ont une seule table-
5 à 8*32 bits, L O K I a une table S à 12*8 bits, et B l o w f i s h et C A S T ont tous les
deux des tables S à 8*32 bits. Dans ID E A la table-S1est en fait l’étape de mulitpli-
cation modulaire ; c’est une table- S à 16* 16 bits. Plus la table-S est grande, plus il
est difficile de trouver des statistiques utiles à l'attaque par cryptanalyse linéaire ou
différentielle [655, 730, 1628]. Aussi, quand des tables S aléatoires ne protègent pas
optimalement en général contre les cryptanalysés différentielle et linéaire, il est plus
facile de trouver des tables S solides si elles sont plus grandes. La plupart des tables-S
aléatoires ne sont ni linéaires, ni dégénérées, et offrent une forte résistence à la cryp
tanalyse linéaire, et la fraction qui ne satisfait ces critères devient rapidement infime
quand le nombre de bits en entrée décroît [1190, 1191, 1192],
La grandeur de m est plus importante que celle de n. Augmenter n réduit l’efficacité de
la cryptanalyse différentielle, mais augmente largement celle de la cryptanalyse linéaire;
En fait, si n > 2m — m, il y a toujours une relation linéaire entre les bits en entrée et
en sortie de la table S'. Et si n > 2m, alors il existe une relation linéaire entre les bits
de sortie [171].
La plupart de ces travaux met enjeu les fonctions booléennes [101,1104,1273,1413].
Pour être sûres, les fonctions booléennes utilisées dans une table-S1doivent satisfaire
des conditions spécifiques. Elles ne devraient pas être linéaires ou affines, ni même s’en
approcher [13, 1184, 1183, 1193]. Il devrait y avoir un équilibre entre les un et les
zéros, et aucune corrélation entre différentes combinaisons de bits. Les bits en sortie
devraient se comporter indépendamment lorsqu’on eomplémente un bit en entrée. Ces
critères de conception sont aussi reliés à l’étude des fonctions courbées qui sont les
fonctions dont on peut prouver qu’elles sont optimalement non linéaires. Bien que leur
définition soit simple et naturelle, leur étude est très compliquée [1356, 1225, 958, 906,
1182, 1282, 299, 300, 301, 156, 353, 503, 302].
Une propriété très importante semble être l’effet d’avalanche : combien de bits changent
en sortie d’une table-S quand certains bits sont changés en entrée. Il est facile d’im
poser certaines conditions aux fonctions booléennes pour qu’elles satisfassent certains
critères d ’avalanche, mais les construire est bien plus difficile. Le critère d ’ avalanche
strict (C A S en abrégé) guarantit que la moitié des bits changent en sortie quand un
bit change en entrée [1588]. Se référer aussi à [1483, 574, 1273, 403]. Un article tente
d’examiner tous ces critères en termes de perte d’information [1642],
Il y a quelques années, les cryptographes ont proposé de choisir les tables -S de sorte
que le tableau des distributions des différences soit uniforme. Cela protégerait de la
cryptanalyse différentielle en aplatissant les différentielles de n’importe quelle ronde [10.
445, 446, 1184]. LO K I, par exemple, suit cette conception. Cependant, cette approchi
peut parfois favoriser la cryptanalyse différentielle [178]. En fait, une meilleure approcht
consiste à s’assurer que la différentielle maximale est aussi petite que possible. Kwangjc
Kim a proposé cinq critères de construction des l abiés- S [835], similaires aux critères
de conception des tables-S1du DES.
Choisir de bonnes tables S n’est pas une tâche aisée ; il y a plusieurs idées qui s’op
posent sur la façon de le faire. On peut recenser quatre approches différentes.
1. Choisir aléatoirement. Il est clair que les petites tables -S aléatoires ne sont pas
sûres, mais les grandes tables S aléatoires peuvent l’être suffisament. Les tables-
S prenant en entrée huit bits ou plus sont assez solides [1191, 1192]. Celles dr
douze bits sont meilleures. On obtient encore plus de robustesse si les tables -S
sont à la fois aléatoires et dépendantes de la clef. ID E A utilise des tables S à la
fois grandes et dépendantes de la clef.
2. Choisir et tester. Certains algorithmes de chiffrement produisent des tables S et

testent alors si elles ont les propriétés requises. Voir [13, 730] pour des exemples
de cette approche.
3. Les faire à la main. Cette technique utilise peu les mathématiques : les tables
S sont produites par des méthodes plus intuitives. Bart P r e n e e l a établi que
«...les critères intéressants théoriquement ne sont pas suffisants [pour choisir des
fonctions booléennes pour les tables- 5]...» et que «...des critères de conception
ad hoc sont nécessaires » [1273].
4. Les faires grâce aux mathématiques. Il s’agit de générer des tables S selon des
principes mathématiques de sorte que l’on puisse prouver qu’elles soient résis
tantes aux cryptanalysés différentielle et linéaire, et qu’elles ont de bonnes pro
priétés de diffusion. Voir [1185] pour un excellent exemple de cette approche.
Il y a eu quelques demandes de combinaison des approches « à la main » et « grâce

aux mathématiques », mais le principal débat semble se tenir entre les tables choisies
aléatoirement et les tables S ayant certaines propriétés. La dernière approche a cer
tainement l’avantage d’être optimale contre les attaques connues— les cryptanalysés
linéaire et différentielle— mais elle offre une protection inconnue contre les attaques
inconnues. Les concepteurs du DES connaissaient la cryptanalyse différentielle et ses
tables- S ont été optimisées contre elle. Il semble qu’ils ne connaissaient pas la crypta
nalyse linéaire et les tables du DES sont très faibles contre elle [1027]. Des tables-S1
aléatoires seraient plus faibles contre la cryptanalyse différentielle et plus fortes contre
la cryptanalyse linéaire.
D’un autre côté, des tables -5 aléatoires peuvent ne pas être optimales contre ces deux
attaques, mais on peut les rendre assez grandes pour qu’elles soient suffisament ré
sistantes. Il y aussi plus de chances pour qu’elles soient suffisament résistantes aux
attaques inconnues. Le débat fait toujours rage, mais mon opinion est que les tables S
devraient être aussi grandes que possible, aléatoires, et dépendantes de la clef.
Concevoir un algorithme de chiffrement par blocs
Il est facile de concevoir un algorithme de chiffrement par blocs. Si vous visualisez un

algorithme avec des blocs de taille 64 bits comme une permutation des nombres de 64
bits, il est clair qu’à peu près toutes ces permutations sont sûres. La difficulté consiste
à concevoir un algorithme non seulement sûr, mais aussi facile à décrire et à réaliser.
Il est facile de concevoir un algorithme si vous assez de mémoire pour des tables-5 à
48*32 bits. Il est difficile de concevoir un DES non sûr si vous faites 128 rondes. Si
votre clef fait 512 bits, vous ne vous souciez pas ses propriétés de complémentation.
Le vrai but — et la raison pour laquelle la conception d’algorithmes de chiffrement par
blocs est si difficile — est de concevoir un algorithme avec une plus petite clef possible,
des besoins en espace mémoire les plus petits possibles, et un temps d’exécution le plus
court possible.
14.11 Utilisation de fonction de hachage à

sens unique
Le moyen le plus simple de chiffrer avec une fonction de hachageà sens uniqueconsiste
à appliquer cette fonction à la concaténation du bloc de textechiffré précédent et de la
clef, puis à combiner le résultat avec le bloc de texte en clair courant par ou exclusif:
Ci = M t © H { K , C i - 1 )
M.% = Ci © H ( K, Ci —1 )
La taille des blocs est celle de la sortie de la fonction de hachage Ceci donne en fait un
algorithme en mode C FB . Une construction similaire donne un algorithme en mode
OFB:
Ci = M i ® Si ; Si = HiKiCi-i)
M i = Ci ® Si ; St = H ( K , C t- i )
La sécurité de ce schéma dépend de celle de la fonction de hachage.
Karn
Cette méthode, inventée par Phil K a r n et placée dans le domaine public, dérive un
algorithme de chiffrement réversible à partir d’une fonction de hachage à sens unique
particulière.
L’algorithme manipule le texte en clair et le texte chiffré par blocs de 32 octets.La
clef peut avoir n’importe quelle longueur, bien que certaines longueurs de clefs soient
plus efficaces pour certaines fonctions de hachage à sens unique. Pour les fonctions de
hachage à sens unique M D 4 et M D5, des clefs de 96 octets (768 bits) conviennent le
mieux.
Pour chiffrer, divisez d’abord le texte en clair en deux moitiés de 16 octets: M g et
M d ■ Ensuite, divisez la clef en deux moitiés de 48 octets: K g et Kd-
M = M g, Md
K = K g; K d
Joignez K g et M g et calculez l’empreinte par une des fonctions de hachage à sens

unique décrites au chapitre 14, ensuite combinez cette empreinte par ou exclusif avec
M d pour obtenir la moitié droite du texte chiffré: Cd- Ensuite, joignez Kd à Cd et
calculez l’empreinte par la fonction de hachage à sens unique, ensuite combinez le
résultat par ou exclusif avec M g pour obtenir Cg. Finalement, joignez Cd à Cg pour
produire le texte chiffré.
Cd = M d ® H { M g, Kg)
Cg = M g ® H { M d , K d)
C = Cgffd
14-11 Utilisation de fonction de hachage à sens unique 373
Pour le déchiffrement, inversez simplement le processus. Joignez K,j et C,j, calculez

l’empreinte et combinez la par ou exclusif avec Cg pour produire A4g. Joignez K g à
M.g, calculez l’empreinte et combinez-la par ou exclusif avec Cd pour obtenir Aid-
M g = C g © H(Cg, K g)
Aid — Cg © H{Cd,Kd)
A4 = A4g,A4d
La structure générale de l’algorithme est la même que la plupart des algorithmes par
blocs décrits dans cette section. Il n’y a que 2 rondes, car la complexité de l’algorithme
est cachée dans la fonction de hachage à sens unique. Et, puisque la clef n ’est utilisée
que comme entrée à la fonction de hachage à sens unique, elle ne peut pas être retrouvée
par une attaque à texte en clair choisi — en faisant, bien sûr, l’hypothèse que la fonction
de hachage à sens unique est sûre.
Luby—Rackoff
Michael L u b y et Charles R a c k o f f montrèrent que K a r n n’était pas sûr[1002].
Considérez deux messages d’un bloc : A B et A C . Si le cryptanalysteconnaît à la
fois le texte en clair et le texte chiffré du premier message, et s’il connaît la première
moitié du texte en clair du second message, alors il peut aisément calculer la deuxième
moitié du second message. Ceci est une attaque à texte en clair connu utile seulement
dans certaines circonstances mais c ’est un problème de sécurité majeur.
Un algorithme de chiffrement à trois rondes évite ce problème [1002, 1645, 1646]. Il
utilise trois fonctions de hachage à sens unique Hi, H 2 et H3. Des travaux plus poussés
ont montré que l’on peut prendre f / j = H 2 ou bien H 2 ~ Hz, mais pas les deux en
même temps [1202]. De plus, H\, H 2 et Hz ne peuvent pas se baser sur l’itération de la
même fonction de base [1645]. Dans tous les cas, en supposant que H{k,x) se comporte
comme une fonction pseudo-aléatoire, voici une version à trois rondes :
1° divisez la clef en deux moitiés K g et Kd ;

2° divisez le bloc de texte en clair en deux moitiés Go et Do ;
3° joignez K g à Go et calculez l’empreinte du résultat à l’aide de la fonction de
hachage à sens unique; combinez l’empreinte par ou exclusif avec D 0 pour
obtenir D\ :
Di = Do © H ( K g,Go) ;
4° joignez Kd à D\ et calculez l ’empreinte du résultat à l’aide de la fonction de

hachage à sens unique; combinez l’empreinte par ou exclusif avec G q pour
obtenir G x :
Gi = G 0 ® H ( K d, Dl ) ;
5° joignez K g à G 1 et calculez l’empreinte du résultat à l’aide de la fonction de

hachage à sens unique; combinez l’empreinte par ou exclusif avec Di pour
obtenir D 2 :
D 2 — D 1 ® H ( K g,Gi) ;
6° joignez G 1 à D 2 pour obtenir le message.

Chapitre 14 Encore d’autres algorithmes de chiffrement par blocs
« Message Digest Cipher » (M DC)

M D C , inventé par Peter G uTM A N N [677], est un moyen de transformer une fonction
de hachage à sens unique en un algorithme de chiffrement par blocs qui opère en mode
C FB . Le système est virtuellement aussi rapide et au moins aussi sûr que la fonction
de hachage. Il est supposé dans le reste du paragraphe que vous êtes familier avec le
chapitre 18.
Les fonctions de hachage telles que M D5 et SHA utilisent un bloc de 512 bits de texte
pour transformer une valeur d ’entrée (de 128 bits dans M D5, et 160 bits dans SHA)
en une valeur de sortie de même taille. Cette transformation n’est pas inversible, mais
elle est parfait pour le mode C F B : la même opération est utilisée pour le chiffrement
et le déchiffrement.
Examinons M D C avec SHA. M D C a une taille de blocs de 160 bits et une clef de
512 bits. La fonction de hachage est utilisée par effets de bord avec l’ancienne empreinte
comme bloc de texte en entrée (160 bits) et la clef comme entrée de 512 bits (voir la
figure 14.5). Normalement, quand on utilise la fonction de hachage seulement pour
calculer l’empreinte d ’une entrée, l’entrée de 512 bits varie chaque fois que l’empreinte
d’un nouveau bloc de 512 bits est calculée. Mais dans ce cas, l’entrée de 512 bits devient
une clef fixe.
B lo c m essage C le f
Valeur Fonction Valeur F onction

— ► -------►
d ’ entree de hachage de sortie de hachage
T exte en c la ir- -► Texte chiffre
(a ) F onction d e hachage (b ) F onction de hachage utilisée en tant

q u ’ algonthm e de chiffrem ent par b lo c
en m od e CFB
F ig . 14.5 - M D C
M D C peut être utilisé avec n ’im p orte quelle fonction de hachage à sens unique : MD4,
M D5, S n e f r u , et autres. Il n ’est pas breveté. N ’im porte q u i peut l ’utiliser à tout
m om ent, com m e il le désire, sans payer de royalties [677].
Cependant, je ne fais pas confiance à cette construction. Il est possible d’attaquer la
fonction de hachage d’une manière qui échappe à ce qui est prévu dans sa conception.
Il n’est pas important que les fonctions de hachage à sens unique résistent aux attaques
à textes en clair choisis, où un cryptanalyste choisit plusieurs de ces valeurs de départ
de 160 bits, les « chiffre » par la même « clef » de 512 bits, et utilise cela pour obtenir
des informations sur la clef de 512 bits utilisée. Comme les concepteurs de la fonction
de hachage ne se sont pas préoccupés de cela, il semble que c ’est une mauvaise idée
d ’espérer voir votre algorithme de chiffrement par blocs résister à cette attaque.
14-12 Choisir un algorithme de chiffrement par blocs 375
Sécurité des algorithmes de chiffrement basés sur des fonctions

de hachage à sens unique
Même si ces constructions peuvent être sûres, elles dépendent du choix de la fonc
tion de hachage à sens unique sous-jacente. Une bonne fonction de hachage ne fait
pas forcément un algorithme de chiffrement sûr. Les nécessités cryptographiques sont
différentes. Par exemple, la cryptanalyse linéaire n’est pas une attaque envisageable
contre les fonctions de hachage à sens unique, mais elle marche contre les algorithmes
de chiffrement. Une fonction de hachage telle que SHA pourrait présenter des caracté
ristiques linéaires qui pourraient fragiliser un algorithme de chiffrement tel que M D C,
sans pour autant affecter la sécurité de SHA en tant que fonction de hashage. Je ne
connais aucune cryptanalyse particulière à des algorithmes de chiffrement basés sur
des fonctions de hachage ; attendez l’arrivée d ’une telle analyse avant d ’avoir confiance
en l’un d ’eux.
14.12 Choisir un algorithme de chiffrement

par blocs
C’est une question difficile. Le DES n’est certainement pas sûr contre les principaux
gouvernements mondiaux à moins que vous ne chiffriez que de petites quantités de
données avec la même clef. Il est probablement suffisant contre n’importe qui d’autre,
mais cela est train de changer. Toutes sortes d ’organisations auront bientôt les moyens
de se payer des machines dédiées à la recherche exhaustive de clefs pour le DES.
Les tables S dépendantes de la clef de B i h a m résisteront probablement des années à
tous les adversaires excepté les plus fortunés, et peut-être même à ceux-ci aussi. Si vous
voulez une confidentialité qui perdure des décades ou si vous avez peur des possibilités
de cryptanalyse des principaux gouvernements, utilisez le DES triple avec trois clefs
indépendantes.
Les autres algorithmes ne sont pas dénués d ’intérêt. J’aime B l o w f i s h pour sa rapidité
et pour l’avoir écrit. 3-W A Y a l’air bon, et G O S T est probablement acceptable. Le
problème pour recommander l'un d ’eux est que la NSA dispose certainement d’une bat
terie impressionante de techniques cryptanalytiques qui sont toujours classées secrètes,
et je ne sais pas quels sont les algorithmes qu’ils peuvent casser avec. Le tableaul4.3
donne les rapidités de quelques algorithmes. Ils sont là à titre de comparaison.
Mon algorithme favori est ID E A . Sa clef de 128 bits, combinée avec sa résistance à
toutes les méthodes de cryptanalyse connues publiquement, m’incline à le préférer.
L’algorithme a été cryptanalyse par de nombreux groupes différents, et aucun résultat
sérieux n’a été révélé jusqu’à présent. On annoncera peut-être demain des résultats de
cryptanalyse dévastateurs ; en attendant je parie sur ID EA.
T a b . 14.3 - Vitesse de chiffrement de quelques algorithmes de chiffrement par blocs

sur un 486SX à 33 MHz_________________________________________________________
Vitesse de chiffrement Vitesse de chiffrement
Algorithme (kilo-octets/seconde) Algorithme (kilo-octets/seconde)
B l o w f ish (12 rondes) 182 M D C (avec M D 4 ) 186
B l o w f ish (16 rondes) 135 M D C (avec M D 5 ) 135
B l o w fish (20 rondes) 110 M D C (avec S H A ) 23
DES 35 N e w DES 233
F E A L -8 300 R E D O C II 1
F E A L -16 161 R E D O C III 78
F E A L -3 2 91 R C 5 -3 2 /8 127
G O ST 53 R C 5 -3 2 /1 2 86
ID E A 70 R C 5 -3 2 /1 6 65
K h u fu (16 rondes) 221 R C 5 -3 2 /2 0 52
K h u fu (24 rondes) 153 S A F E R (6 rondes) 81
K h u fu (32 rondes) 115 S A F E R (8 rondes) 61
L u b y - R a c k o f f (avec M D 4 )4 7 S A F E R (10 rondes) 49
L u b y - R a c k o f f (avec M D 5 )3 4 S A F E R (12 rondes) 41
L u b y -R a c k o f f (avec S H A ) 11 3 -W A Y 25
L u c ife r 52 D E S triple 12
Chapitre 15
Combinaison d’algorithmes
de chiffrement par blocs
Il existe de nombreuses façon de combiner des algorithmes de chiffrement par blocs pour
obtenir de nouveaux algorithmes. Le but de la manœuvre est d ’essayer d ’augmenter
la sécurité en évitant les turpitudes de la conception d ’un nouvel algorithme. Le DES
est un algorithme sûr ; il a été cryptanalysé pendant plus de vingt ans et le meilleur
moyen de la casser en pratique reste l’attaque exhaustive. Cependant, la clef est trop
courte. Ne serait-il pas souhaitable d ’utiliser le DES comme un élément de base d ’un
autre algorithme? Nous aurions tous les avantages: l’assurance de deux décennies de
cryptanalyse et une longue clef.
Le surchiffrement est une technique de combinaison : utiliser le même algorithme
pour chiffrer le même bloc de texte en clair plusieurs fois avec différentes clefs. Il existe
d’autres techniques.
Chiffrer un bloc de texte en clair deux fois avec la même clef, que ce soit avec le même
algorithme ou avec un autre, ne sert pas à grand chose. Pour le même algorithme,
cela n’affecte pas la complexité d ’une recherche exhaustive1. Pour des algorithmes
différents cela peut être ou ne pas être le cas. Si vous allez utiliser une des techniques
de ce chapitre, assurez vous que les différentes clefs sont différentes et indépendantes.
15.1 Surchiffrement double

Un moyen naïf d ’augmenter le niveau de sécurité d ’un algorithme de chiffrement par
blocs est de chiffrer le bloc deux fois avec deux clefs différentes. Premièrement, chiffrez
le bloc avec la première clef, et ensuite chiffrez le résultat avec la deuxième clef. Le
déchiffrement est le processus inverse.
C = E K2(E K l(M ))
M = D K l ( D K a(C ))
1. Rappelez vous de supposer qu ’ un cryptanalyste connaît les détails de l’ algorithm e ainsi que le
nombre de chiffrements effectués.
378 Chapitre 15 Combinaison d’algorithmes de chiffrement par blocs
Si l’algorithme de chiffrement par blocs est un groupe (voir § 11.3), il existera forcément
une clef K$ telle que :
C = EK, { E Kl( M ) ) = E Ka(M)
Dans le cas contraire, le bloc de texte chiffré résultant du double chiffrement serait
beaucoup plus difficile à retrouver par recherche exhaustive. Au lieu de 2n tentatives (où
n est le nombre de bits de la clef), il faudrait 22n tentatives. Si l’algorithme manipule des
blocs de 64 bits, le texte doublement chiffré nécessiterait 2 128 tentatives pour retrouver
la clef.
Cela n’est pas vrai pour une attaque à texte en clair connu. M e r k l e et H e llm a n [1072]
ont développé un compromis temps-mémoire qui, dans le cadre d’une attaque à texte
en clair connu, permet de casser ce chiffrement double avec 2 n+1 tentatives et non pas
22" tentatives2. Cette attaque est appelée attaque par collisions et elle marche en
chiffrant à une extrémité, en déchiffrant à l’autre et en mettant en correspondance les
résultats au milieu.
L’attaque est conduite de la manière suivante: le cryptanalyste connaît A4i, Ci, A4 2
et C2 , tels que :
Ci -- E k 3 ( Ekx{ M 1 ))
C2 — E k 2 ( E k, ( M . 2 ))
Pour tous les K possibles (soit K i , soit K 2 ), calculez Ek{-M-i) et gardez le résultat en
mémoire. Quand vous les avez tous, calculez D u {Ci) pour tous les K et cherchez le
même résultat en mémoire. Si vous le trouvez, il est possible que la clef courante soit
K 2 et la clef en mémoire K j . Essayez de chiffrer M 2 avec K\ et K 2 : si cela donne C2,
vous pouvez être pratiquement sûr (avec une probabilité de succès de 2 2n~2b, où b est
la taille de bloc) que vous avez K\ et K 2. Sinon, continuez à chercher. Attendez-vous
à avoir environ (22” -26) faux résultats positifs avant de trouver le bon. Le nombre
maximal de tentatives de chiffrement que vous devrez probablement essayer est 2 x 2 ",
ou 2 n+1. Si la probabilité d’erreurs est trop grande, vous pouvez utiliser un troisième
bloc de texte chiffré pour avoir une probabilité de succès de 2 2n~ 3b. Il y a encore
d’autres optimisations [914].
Cette attaque nécessite beaucoup de mémoire, 2n blocs. Pour un algorithme à 56 bits,
cela donne 256 blocs de 64 bits, ou 259 octets. C ’est encore beaucoup de mémoire
par rapport à ce que quelqu’un peut appréhender aisément mais c ’est suffisant pour
convaincre le plus paranoïaque des cryptographes que le chiffrement double ne vaut
rien.
Pour une clef de 128 bits, la mémoire requise ateind la somme astronomique de 1039
octets. Si nous supposons qu’il existe un moyen de stocker un bit d’information sur
un seul atome d ’aluminium, le périphérique de mémoire nécessaire à cette attaque
formerait un cube d’aluminium solide de 1 km de côté. L ’attaque par collisions semble
infaisable pour des clefs de cette longueur. .
Une autre méthode de surchiffrement double, appelée parfois Davies-Price, est une
variante de C B C [435].
Ct = EKl ( M t © EK2(Ci~i))
■Mi — D k x{Ci ) © D k 2(Ci ~ 1 )
2. Ils l’ont m ontré pou r le DES, mais le résultat peu t être généralisé à n ’ im porte quel algorithme
de chiffrement par blocs.
15.2 Surchiffrement triple 379
Ils prétendent que « ce mode n’a pas de vertu spéciale », mais il semble vulnérable à
la même attaque par collisions que les autres modes de surchiffrement double.
15.2 Surchiffrement triple

Surchiffrement triple avec deux clefs
Une meilleure idée, proposée par T u c h m a n dans [1559], est de chiffrer un bloc trois
fois avec deux clefs : primo avec la première clef, ensuite avec la seconde clef, et finale
ment avec la première clef à nouveau. Il suggéra que l’expéditeur chiffre d’abord avec
la première clef, ensuite déchiffre avec la deuxième clef et finalement chiffre avec la
troisième clef.
C = E k i ( D K2 (EKi ( M )))
M = D Kl(EK2 (DKl(C)))
Cette méthode est parfois appelée le mode « chiffre-déchiffre-chiffre » (ED E pour

« encrypt-decrypt-encrypt ») [57]. Si l’algorithme de chiffrement par blocs a une clef
de n bits, alors ce schéma a une clef de 2n bits. Le curieux schéma « chiffre-déchiffre-
chiffre » a été conçu par IB M pour préserver la compatibilité avec des réalisations
conventionnelles de l’algorithme : en choisissant la même clef pour K\ et K 2 on ramène
l’opération au chiffrement unique avec la clef. Il n’y a pas de sécurité inhérente au
schéma « chiffre-déchiffre-chiffre » mais il a été utilisé pour améliorer l’algorithme DES
dans les standards X 9.17 et ISO 8732 [57, 765].
K\ et I <2 sont alternées pour contrecarrer l’attaque par collisions décrite plus haut.
SiC = E k 2 (E k 1 (Ei;i( M) ) ) , un cryptanalyste pourrait précalculer E ^ 1 (Ek, (.Ad)) pour
tous les K i possibles et effectuer ensuite l’attaque. Cela ne requiert que 2n+2 chiffre
ments.
Le surchiffrement triple avec deux clefs n’est pas sujet à la même attaque par collisions
décrite auparavant. Mais M e r k l e et H e l l m a n ont développé un autre compromis
temps-mémoire qui peut casser cette technique en 2 n _ 1 étapes en utilisant 2 ” blocs de
mémoire [1072].
Pour toutes les K 2 possibles, déchiffrer 0 et stocker le résultat en mémoire. Ensuite,
déchiffrer 0 avec toutes les K\ possibles pour obtenir M .. Chiffrer alors triplement M.
pour obtenir C, puis déchiffrer C avec K\. Si ce déchiffrement est un déchiffrement de 0
avec un K 2 (stocké en mémoire), la paire K \ ,K 2 est une candidate éventuelle. Vérifier
si c’est juste. Sinon, continuer à chercher.
C’est une attaque à texte en clair choisi, qui nécessite pour être montée, un nombre
énorme de textes en clair choisis. Cela demande 2 " étapes, 2 ” blocs de mémoire et 2 b
textes en clair choisis. Ce n ’est pas très pratique, mais c ’est une faiblesse.
Paul van O o r s c h o t et Michael W ie n e r ont converti cette attaque en une attaque à
texte en clair, nécessitant p textes en clair connus. Cet exemple repose sur l’hypothèse
du mode EDE.
1° Deviner la première valeur intermédiaire a.

2° Tabuler, pour chaque K % possible, la seconde valeur intermédiaire b quand la

première valeur intermédiaire est a, en utilisant le texte en clair connu :
b = D Kl(C)
où C le texte chiffré provenant d’un texte en clair connu.
3° Regarder dans le tableau, pour chaque K 2 possible, les éléments qui donnent
une seconde valeur valeur intermédiaire b qui correspond :
b = E K2 (a)
4° La probabilité de succès est p/b où p est le nombre de textes en clair connus et

b est la taille des blocs. Si aucune valeur ne correspond, essayer un autre a et
recommencer.
L’attaque requiert 2rl+rn/ p étapes et p blocs de mémoire. Pour le DES, cela fait 2120/p
[1564]. Pour p supérieur à 256, cette attaque est plus rapide que la recherche exhaustive
Surchiffrement triple avec trois clefs

Si vous allez utiliser le chiffrement triple, je recommande trois clefs différentes. La
longueur de clef est plus grande, mais le stockage de la clef n’est, en général, pas un
problème.
C = E K3 {DK2 {EKl{M) ) )
•M = S>k , ( E K2 (Ük 3 (C)))
L’attaque avec le meilleur compromis temps-mémoire nécessite 22" étapes et 2” blocs

de mémoire [1072]. Le chiffrement triple, avec trois clefs indépendantes, est aussi sûr
que ce que l’on pourrait attendre du chiffrement double.
Surchiffrement triple avec clef minimale (TEM K )

Il existe un moyen sûr d’utiliser le surchiffrement triple avec deux clefs qui n’est pas
sujet à l’attaque précédente. Cela s’appelle le surchiffrement triple avec clef minimale
(T E M K pour « Triple Encryption with Minimum K ey ») [858]. L ’astuce consiste à
dériver trois clefs de deux et X 2 :
K l = E x , (D X2 (EX i (Ti)))
K 2 = E X2 (DXl ( e X2 { t 2)))
K 3 = EXl (E > x2 (EX i (T3)))
Ti, T2 et I 3 sont des constantes non nécessairement secrètes. Cette une construction
spéciale qui garantie que pour n’importe quelle paire de clefs, la meilleure attaque est
une attaque à texte en clair connu.
Modes de surchiffrement triple

11ne suffit pas de spécifier surchiffrement triple ; il y a plusieurs manières de le faire.
En choisir une affecte à la fois la sécurité et l’efficacité.
Voici deux modes possibles de surchiffrement triple :
C B C interne. Chiffrer le fichier entier en mode C B C trois fois (voir la

figure 15.1a). Cela nécessite trois IV différents.
Cj = EK3(Si(BCi-1) ; St = Dfc2(TiQ)Siî) ; T) =
M i — TiîCBDhî'E) ; Tt — Sl-\ Q)Ek .2(Si) ; S, - C * _ i (BD^-ffCi)
Co, S0 et T0 sont les IV.

C B C externe. Surchiffrer triplement le fichier entier en mode C B C (voir
la figure 15.1b). Cela nécessite un seul IV.
Ci = EKs (Dk 2 (Ekx(M i © C ,_ i)))

Ci = 1 © D Kl ( Ek 2 (D a 3 (Ci)))
Le IV est Co-
F ig . 15.1 - Surchiffrement triple en mode CB C
Les deux modes requièrent plus de ressources que le chiffrement simple : plus de ma
tériel ou plus de temps. Cependant, avec trois puces de chiffrement, la bande passante
du C B C interne est aussi grande que celle du chiffrement simple. Comme les trois chif
frements C B C sont indépendants, les trois puces peuvent travailler en permanence,
chacune ayant une rétroaction sur elle-même.
Par contre, la rétroaction du C B C externe est extérieure aux trois chiffrements. Cela
veut dire que même avec trois puces, la bande passante est le tiers de celle du chiffrement
simple. Pour obtenir la même bande passante, il faut intercaler des IV (voir § 9.12) :
Ci = E k 3 {D k 3 ( E ^ i - M i 3)))
Dans ce cas, les IV sont Co, C 1 et C _ 2 . Cela ne facilite pas les réalisations logicielles,
à moins que vous ne disposiez d’une machine parallèle.
Malheureusement, le mode le plus simple est aussi le moins sûr. BIHAM a étudié plu
sieurs modes dans l’optique de la cryptanalyse différentielle à texte chiffré choisi et a
trouvé que le C B C interne est seulement légèrement plus sûr que le chiffrement simple
contre une attaque différentielle. Si vous visualisez le surchiffrement triple comme un
seul algorithme plus gros, alors la rétroaction interne autorise l’introduction d ’infor
mation connue et externe dans les rouage internes de l’algorithme ; ceci facilite la
cryptanalyse. Les attaques différentielles ont besoin d ’une quantité énorme de textes
chiffrés choisis et ne sont pas très pratiques, mais les résultats devraient inspirer la
méfiance des paranoïaques. Un autre examen vis à vis de l’attaque par colüsions et de
l’attaque exhaustive montre qu’ils sont tous les deux sûrs [807].
Il existe aussi d’autres modes. Vous pouvez chiffrer le fichier entier une fois en ECB,
puis deux fois en C B C ; ou une fois en C B C , une fois en EC B , et une fois en CBC ;
ou encore deux fois en C B C et une fois en E C B . B ih a m a montré que ces variantes ne
sont pas plus sûres que le DES vis à vis d ’une attaque par cryptanalyse différentielle à
texte en clair choisi [170]. Et il n’y a pas beaucoup d’espoir pour les autres variantes. Si
vous voulez utiliser le surchiffrement triple utilisez des modes sans rétroaction externe.
Variantes du surchiffrement triple

Avant qu’il y ait des preuves que le DES n’est pas un groupe, plusieurs schémas de
surchiffrement furent proposés. Une façon de s’assurer que le surchiffrement triple ne se
réduit pas à un simple chiffrement consiste à changer effectivement la taille des blocs.
Une méthode simple est d’ajouter un bit de remplissage. Complétez le texte avec une
chaîne de bits aléatoires de longueur égale à la moitié de la longueur d’un bloc, entre le
premier et le second et entre le second et le troisième chiffrement (voir la figure 15.2).
Si P est la fonction de remplissage, on a :
C = E K3 ( P ( DK2 (P(EKl(M)))))
Ce remplissage non seulement brouille les motifs réguliers mais aussi superpose les
blocs chiffrés comme des briques. Cela ne rajoute qu’un bloc à la longueur du message.
Une autre technique, proposée par Cari E llison consiste à utiliser de fonction de
permutation sans clef entre les trois chiffrements. La permutation pourrait opérer sur
de grands blocs— de l’ordre de 8 kilo-octets— et donnerait une taille de bloc effective
de 8 kilo-octets à cette variante. En supposant que la permutation est rapide, cette
variante n’est pas beaucoup plus lente que le surchiffrement triple classique.
C = E K3(T(DK2(T(EKl(M)))))
T rassemble un block en entrée (jusqu’à 8 kilo-octets de long) et utilise un générateur

pseudo-aléatoire pour le transposer. Le changement d’un bit en entrée cause le change
ment de huit octets en sortie après le premier chiffrement, de 64 octets au mieux après
le deuxième chiffrement, et de 512 octets au mieux après le troisième chiffrement. Si
chaque algorithme par blocs fonctionne en mode C B C , comme proposé à l’origine, alors
l’effet du changement d’un seul bit a des chances d ’atteindre le bloc de 8 kilo-octets en
entier, même dans les blocs autres que le premier.
La version la plus récente de ce schéma répond à l’attaque de B ih a m sur le CBC
interne en introduisant une passe de blanchiment pour masquer les motifs du texte
en clair. Cette passe est un flot de combinaisons par ou exclusif avec un générateur
de nombres aléatoires cryptographiquement sûr, appelé R ci-dessous. L’application de
T avant et après empêche le cryptanalyste de savoir à priori quelle clef a été utilisée
pour chiffrer n’importe quel bit donné en entrée du dernier chiffrement. Le deuxième
chiffrement est noté nE (chiffrement avec n clefs utilisées de manière cyclique) :
C = E Ks(R(T(nEK2(T(EKl( m ) ) )
Tous les chiffrement sont fait en mode C B C et les clefs sont fournies au moins pour
les n + 2 clefs de chiffrement et générateur de nombres aléatoires cryptographiquement
sûr.
Ce schéma a été proposé avec le DES, mais il fonctionne avec n’importe quel algorithme
de chiffrement par blocs. Je ne connais aucune étude de la sécurité de ce schéma.
15.3 Doublement de la longueur de bloc

Certains arguments circulent dans la communauté académique pour savoir si des blocs
de 64 bits sont suffisament longs. D ’un côté, cette taille ne permet la diffusion du texte
en clair que sur 8 octets du texte chiffré. D ’un autre côté, une taille de blocs plus
grande rend les motifs difficiles à masquer de façon sûre ; il n’y a plus de place pour
les erreurs.
Certains ont proposé de doubler la longueur des blocs d ’un algorithme en utilisant le
surchiffrement [305]. Avant de réaliser cela, vérifiez l’existence potentielle d ’attaques
par collisions. Le schéma de Richard OUTERBRIDGE, illustré par la figure 15.3, n’est pas
plus sûr que le surchiffrement triple à deux clefs avec une taille de bloc classique [859].
F ig . 15.3 - Doublement correct de la longueur de bloc
Cependant, je ne conseille pas ce genre de choses. Ce n’est pas plus rapide que le
surchiffrement triple conventionnel : il faut toujours six chiffrements pour chiffrer deux
blocs de données. Nous connaissons les caractéristiques du surchiffrement triple ; les
constructions telles que celle-ci ont souvent des vices cachés.
15.4 Autres schémas de surchiffrement

Le problème avec le surchiffrement triple avec deux clefs est qu’il permet de doubler
l’espace des clefs, mais nécessite trois chiffrements par bloc de texte en clair. Ne serait-
il pas opportun de trouver un moyen intelligent de combiner deux chiffrements de
manière à doubler l’espace des clefs?
15.4 Autres schémas de surchiffrement 385
Mode compteur OFB double

Cet algorithme utilise un algorithme par blocs pour générer deux flots de clefs qui sont
alors utilisés pour chiffrer le texte en clair.
Si — E ü ïiS i-i © f i ) ; f i = / i + l
Ti — E x2(Ti-1 © I 2) ; h = I2 + 1
Ci = M z © Si © Ti
Si et Ti sont des variables internes et Ji et J2 sont des compteurs. Deux copies de l’al
gorithme fonctionnent dans une sorte de mode compteur O F B , et le texte en clair Si et
Tt sont combinés ensemble par ou exclusif. Les deux clefs K\ et K 2 sont indépendantes.
Je ne connais aucune cryptanalyse de cette variante.
ECB avec OFB

Cette méthode a été conçue pour chiffrer plusieurs messages de même taille fixée, par
exemple des secteurs de disques [193, 194], Utiliser deux clefs. Il faut tout d’abord
créer un masque à la taille voulue à l’aide de K i et de l’algorithme. Ce masque sera
utilisé à chaque fois qu’on chiffre un message avec les mêmes clefs. Combinez alors
par ou exclusif le texte en clair avec le masque. Finalement, chiffrez le résultat avec
l’algorithme et / f 2 en mode E CB.
Ce mode n’a pas été analysé ailleurs que dans l’article où il est apparu. Il est claire
ment au moins aussi solide qu’un simple chiffrement en mode E C B et peut-être aussi
solide que deux passes de l’algorithme. Un cryptanalyste pourrait vraissemblablement
chercher les deux clefs indépendamment si plusieurs textes en clair connus sont chiffrés
avec les mêmes clefs.
Pour contrecarrer l’analyse de blocs identiques à des positions identiques dans différents
messages, vous pouvez ajouter un IV. A l’inverse de l’utilisation classique d’un IV dans
tous les autres modes, ici l’IV est combiné par ou exclusif avec chaque bloc du message
avant le chiffrement en mode E CB.
Matt B l a z e a conçu ce mode pour son sytème cryptographique de fichiers sous U N IX
(appelé CFS pour « Cryptographie File System »). C’est un mode pratique car la
latence n’est que d’un chiffrement en mode E C B ; on peut générer le masque une fois
pour toutes en le stockant. Dans CFS, l’algorithme de chiffrement n’est autre que le
DES.
xDES*
Dans [1646, 1647], le DES est utilisé comme élément de construction d’une série d’al
gorithmes de chiffrement par blocs avec à la fois une taille de clef et une taille de bloc
plus grandes. Ces constructions ne dépendent pas du tout du DES et peuvent être
reproduites avec n’importe quel algorithme par blocs.
Le premier algorithme, x D E S 1, est simplement une construction de LlJBY-RACKOFF
avec l’algorithme de chiffrement par blocs comme fonction sous-jacente (voir § 14.11).
La taille de bloc et la taille de clef sont respectivement le double de celles de l’algorithme
sous-jacent. Dans chacune des trois rondes, chiffrez la moitié droite avec l’algorithme
par blocs et l’une des clefs, combinez le résultat par ou exclusif avec la moitié de
gauche, et échangez les deux moitiés.
C’est plus rapide que le surchiffrement triple classique car trois chiffrements permettent
de chiffrer deux fois plus que l’algorithme sous-jacent. Mais une simple attaque par
collisions permet de trouver la clef avec 2 k blocs de mémoire, où k est la taille de la clef
de l’algorithme sous-jacent. Chiffrez la moitié droite d’un bloc de texte en clair avec
toutes les valeurs possibles de K\, combinez la par ou exclusif avec la moitié gauche
du texte en clair, et stockez ces valeurs dans un tableau. Chiffrez alors la moitié droite
du texte chiffré avec toutes les valeurs possibles de K 3 et regardez si cela correspond à
une des valeurs du tableau. Si vous en trouvez une, la paire de clefs K i , K 3 forme un
candidat potentiel. Répétez l’attaque plusieurs fois et il ne restera qu’un seul candidat.
Cela montre que x D E S 1 n’est pas une solution idéale. Il y a même pire, il existe une
attaque à texte en clair choisi qui prouve que x D E S 1 n ’est pas beaucoup plus sûr que
l’algorithme de chiffrement par blocs sous-jacent [858],
xD E S2 étend cette idée à un algorithme à 5 rondes avec une taille de bloc 4 fois
supérieure et une taille de clef 10 fois supérieure à celles de l’algorithme sous-jacent.
La figure 15.4 illustre une ronde de x D E S 2 ; chacun des quatre sous-blocs ont même
taille que les blocs de l’algorithme sous-jacent et les 10 clefs sont indépendantes.
F ig . 15.4 Une ronde de x D E S 2
Ce schéma est lui aussi plus rapide que le surchiffrement triple : dix chiffrements per
mettent de chiffrer un bloc de taille quatre fois plus grande. Cependant, il est vulné
rable à la cryptanalyse différentielle [858] et ne devrait pas être utilisé. Le schéma est
vulnérable même si le DES est utilisé avec des clefs de rondes indépendantes.
Pour i > 3, xDES* est probablement trop imposant pour s’avérer utile en tant qu’al
gorithme par blocs. Par exemple, la taille de bloc de xD E S6 est six fois supérieure à
celle de l’algorithme sous-jacent, sa taille de clef est 21 fois supérieure, et 21 chiffre
ments sont nécessaires pour chiffrer un bloc six fois plus gros que ceux de l’algorithme
sous-jacent. Le surchiffrement triple est plus rapide.
Surchiffrement quintuple
Si le surchiffrement triple ne vous paraît pas assez sûr vous avez peut-être besoin de
chiffrer des clefs du surchiffrement triple en utilisant un algorithme encore plus sûr—
15.5 Troncature de clef (dans C D M F ) 387
alors vous pourriez utiliser des surchiffrements de plus haut degré. Le surchiffrement
quintuple est très résistant à l’attaque par collisions3.
C = E Ki(DK2 (EK3 (DK2 ( E k A M ) ) ) ) )

M = DK i (EK2(DK3(EKADKi (C)))))
Cette construction est compatible avec le surchiffrement triple en prenant = K 3 et

aussi avec le chiffrement conventionnel en prenant K \ = K 2 = K 3. Bien sûr, il serait
encore plus sûr de prendre cinq clefs indépendantes.
15.5 Troncature de clef (dans CDMF)

IBM a conçu cet algorithme pour leur utilitaire C D M F (voir § 24.8) pour réduire une
clef de 56 bits à 40 bits ce qui est la taille requise pour l’exportation [785]. La clef est
supposée inclure les bits de parité.
1° Mettre à zéro les bits de parité qui sont les bits 8, 16, 24, 32, 40, 48, 56, 64.
2° Chiffrer le résultat de l’étape 1 avec le DES et la clef OxC408B0540BAlEOAE,
et combiner le résultat avec la clef obtenue à l’étape 1 par ou exclusif.
3° Mettre à zéro les bits suivants dans le résultat de l’étape 2 : 1, 2, 3, 4, 8, 16,
17, 18, 19, 20, 24, 32, 33, 34 35, 36, 40, 48, 49, 50, 51, 52, 56, 64.
4° Chiffrer le résultat de l’étape 3 avec le DES et la clef 0xEF2C041CE6382FE6.
Cette clef est alors utilisée pour chiffrer les messages.
Retenez que cette méthode racourcie la longueur des clefs, et affaiblit par conséquent
l’algorithme.
15.6 Blanchiment
B lanchim ent est le no m donné à une technique consistant à com biner p a r ou exclusif
une partie de la clef avec l ’entrée d ’un algorithm e de chiffrement p a r blocs, et à com biner
par ou exclusif une pa rtie de la clef avec la sortie de l ’algorithm e. La variante D ESX,
développée p a r RSA D I, est la prem ière à l ’avoir em ployée; viennent ensuite K h u f u
et K hafre (probablem ent indépendam m ent de celle-là)4.
L’idée est d’empêcher le cryptanalyste d’obtenir une paire texte en clair, texte chiffré
pour l’algorithme en question. La technique oblige les cryptanalystes à deviner non
seulement la clef de l’algorithme, mais aussi les valeurs de blanchiment. Comme il y a
une combinaison par ou exclusif avant et après l’algorithme, cette technique n’est pas
propice à une attaque par collisions.
C = K 3 0 E K 2( M ® A r)
M = K i © D K 2(C © K 3)
3. Des arguments similaires à ceux utilisés à propos du surchiffrement dou ble perm ettent de mon
trer que le surchiffrement quadruple n’a pporte qu’ une faible am élioration de sécurité par rapport au
surchiffrement triple.
4. RiVBST a nom m é cette technique ainsi, ce m ot n’ est pas d ’ un usage conventionnel.
Si K i = K%, une attaque exhaustive nécessite 2n+fc/,p opérations où n est la taille de

la clet, b la taille des blocs, et p le nombre de textes en clair connus. Si K\ et K-A sont
différentes, une attaque exhaustive nécessite 2 " 15 11 opérations avec trois textes en clair
connus. Contre les cryptanalysés différentielle et linéaire, ces mesures ne fournissent
que quelques bits de clef de protection. Mais sur le plan du temps de calcul, c’est un
moyen très économique d ’augmenter la sécurité d ’un algorithme de chiffrement par
blocs.
15.7 Mise en cascade de plusieurs algo

rithmes
Qu’en est-il si on chiffre le bloc tout d’abord avec l’algorithme A et la clef K a et ensuite
avec l’algorithme B et la clef K b ? Il se peut qu’Alice et Bernard ne soient pas d ’accord
sur la sécurité des algorithmes : Alice veut utiliser un algorithme A et Bernard veut
utiliser un algorithme B. Cette technique est parfois appelée m ise en cascade et peut
être généralisée à bien plus de deux algorithmes et deux clefs.
Les pessimistes disent qu’il n’y a pas de garantie que les deux algorithmes ensemble
augmenteront le niveau de sécurité. Il pourrait y avoir des interactions subtiles entre
les deux algorithmes qui, au contraire, diminueraient le niveau de sécurité. Même le
surchiffrement avec deux ou trois algorithmes différents pourrait ne pas être aussi sûr
que vous le croyez. La cryptographie est un art difficile.
La réalité est beaucoup plus rose. Les avertissements précédents ne valent que si les
clefs sont reliées les unes aux autres. Dans le cas où toutes les clefs sont indépendantes,
le résultat est au moins aussi difficile à casser que le premier algorithme [1042]. Si le
second algorithme est vulnérable à une attaque à texte en clair choisi, alors le premier
algorithme pourrait faciliter cette attaque et rendre le second algorithme vulnérable
à une attaque à texte en clair connu seulement quand ils sont utilisés en cascade.
Cette attaque potentielle n’est pas limitée aux algorithmes de chiffrement : si vous
laissez quelqu’un d ’autre précisez quel algorithme est utilisé sur vos messages avant
chiffrement, vous feriez mieux de vous assurer que votre chiffrement résistera à une
attaque en texte en clair choisi5.
On peut formuler cela de meilleure manière ainsi : face à une attaque à texte en clair
choisi, une cascade d ’algorithmes de chiffrement est au moins aussi difficile à casser
que l’une de ses composantes [858]. Un précédent résultat statuait qu’une cascade
d ’algorithmes est au moins aussi difficile à casser que la plus solide de ses composantes,
mais ce résultat est basé sur des hypothèses non fondées [530]. C ’est seulement quand
les algorithmes commutent, comme c’est le cas pour une cascade d’algorithmes de
chiffrement en continu (ou d’algorithmes de chiffrement par blocs en mode O F B ), que
leur mise en cascade donne un résultat au moins aussi solide que le plus solide des
algorithmes la composant.
Si Alice et Bernard n’ont pas confiance en l’algorithme de l’autre, ils peuvent utiliser
une mise en cascade. Si ce sont des algorithmes de chiffrement en continu, l’ordre n’a
pas d ’importance. Si ce sont des algorithmes par blocs, Alice peut utiliser l’algorithme
5. N otez au passage que l’ algorithm e utilisé couram m ent pou r com presser et numériser la parole à
la vitesse des m odem s est C E L P qui a été con çu par la NSA.
15.8 Combïaer plusieurs algorithmes de chiffrement par blocs 389
A puis B et Bernard qui a plus confiance en B peut utiliser B puis A. Ils pourraient
même ajouter un bon algorithme de chiffrement en continu entre les deux ; cela ne fait
pas de mal et ça peut très bien augmenter la sécurité.
Retenez que chaque clef doit être indépendante. Si A a une clef de 64 bits et B une
clef de 128 bits, le résulat après mise en cascade doit avoir une clef de 192 bits. Si vous
n’utilisez pas des clefs indépendantes, alors il y a beaucoup plus de chances que les
pessimistes aient raison.
15.8 Combiner plusieurs algorithmes de

chiffrement par blocs
Voici un autre moyen de combiner plusieurs algorithmes de chiffrement par blocs, l’un
d’eux offre au moins autant de sécurité que chaque algorithme. Effectuer avec deux
algorithmes (et deux clefs indépendantes) les opérations suivantes :
1° Générer une chaîne de bits aléatoire R de même taille que le message.

2° Chiffrer R avec le premier algorithme.
3° Chiffrer R (B A4 avec le second algorithme.
4° Le texte chiffré est le résultat des étapes 2 et 3.
En supposant que la chaîne de bit est réellement aléatoire, cette méthode consiste
à chiffrer A4 avec un masque jetable et à chiffrer à la fois le message chiffré et le
masque, chacun avec un des deux algorithmes. Comme les deux sont nécessaires pour
reconstruire A4, un cryptanalyste doit casser les deux algorithmes. L ’inconvénient est
que le texte chiffré est deux fois plus gros que le texte en clair.
On peut étendre cette méthode pour un plus grand nombre d’algorithmes, mais le texte
chiffré augmente avec chaque addition d ’un algorithme. C ’est une bonne idée, mais je
ne pense pas qu’elle soit très pratique.
Chapitre 16
Générateurs de suites
aléatoires et chiffrement en
continu
16.1 Générateurs pseudo-aléatoires de

suites
Générateurs linéaires congruentiels
Les g é n é r a t e u r s lin é a ir e s c o n g r u e n t ie ls sont des générateurs pseudo-aléatoires de
suites de la forme :
X n = {u X n _i 4- b) mod m
où X n est le ne nombre de la suite et le nombre précédent de la suite. Les sym

boles a, b, et m dénotent des constantes : a est le m u lt ip li c a t e u r , b est l’ in c r é m e n t
et m est le m o d u le . Le germe est la valeur initiale de Xq.
Ce générateur a une période qui n’est pas plus grande que m. Si a, b e t m sont choisis
correctement1, alors le générateur sera un g é n é r a t e u r d e p é r io d e m a x im a le , et
aura une période m. Les détails concernant le choix des constantes qui garantit la
période maximale peuvent être trouvés dans [864, 953] Une autre bonne publication
sur les générateurs linéaires congruentiels et leur théorie est [1452].
Le tableau 16.1, emprunté à [1283], donne une liste des bonnes constantes pour des gé
nérateurs linéaires congruentiels. Elles donnent toutes des générateurs à période maxi
male et même, plus important encore, ces générateurs passent le test spectral de carac
tère aléatoire pour les dimensions 2, 3, 4, 5 et 6 [390, 864]. Elles sont arrangées dans
l’ordre croissant du plus grand produit qui ne donne pas de dépassement de capacité
pour une longueur de mot donnée.
L’avantage des générateurs linéaires congruentiels est qu’ils sont rapides, ne nécessitant
que peu d ’opérations par bit.
1. Par exem ple, b et m doivent être premiers entre eux.

392 Chapitre 16 Générateurs de suites aléatoires et chiffrement en continu
Tab 16.1 Constantes pour générateurs linéaires congruentiels
Dépassement pour a b m
ÿiu 106 1283 6075
221 211 1663 7875
222 421 1663 7875
223 430 2531 11979
936 1399 6655
1366 1283 6075
224 171 11213 53125
859 2531 11979
419 6173 29282
967 3041 14406
225 141 28411 134456
625 6571 31104
1541 2957 14000
1741 2731 12960
1291 4621 21870
205 29573 139968
226 421 17117 81000
1255 6173 29282
281 28411 134456
227 1093 18257 86436
421 54773 259200
1021 24631 116640
1021 25673 121500
228 1277 24749 117128
741 66037 312500
2041 25673 121500
229 2311 25367 120050
1807 45289 214326
1597 51749 244944
1861 49297 233280
2661 36979 175000
4081 25673 121500
3661 30809 145800
230 3877 29573 139968
3613 45289 214326
1366 150889 714025
23i 8121 28411 134456
4561 51349 243000
7141 54773 259200
232 9301 49297 233280
4096 150889 714025
233 2416 374441 1771875
234 17221 107839 510300
36261 66037 312500
235 84589 45989 217728
16.1 Générateurs pseudo-aléatoires de suites 393
Malheureusement, les générateurs linéaires congruentiels ne peuvent pas être utilisés

pour la cryptographie par chiffrement en continu, car ils sont prévisibles. Les géné
rateurs linéaires congruentiels ont été cassés pour la première fois par Jim R e e d s
[1305, 1306, 1307] et Joan B o y a r [702], Elle a aussi cassé les générateurs quadra
tiques :
X n — (a X + bX n - 1 + c) mod m
et les générateurs cubiques :
X n - (aX „ _ i 4 bX%_ 1 4 cX n - 1 4 d) mod m.
D’autres chercheurs ont étendu les travaux de B o y a r pour casser tout générateur
œngruentiel polynomial [934, 899, 900]. Les générateurs linéaires congruentiels tron
qués ont aussi été cassés [583, 706, 582], de même que les générateurs linéaires congruen
tiels tronqués avec des paramètre inconnus [1505, 215], L ’évidence est faite que les
générateurs congruentiels ne sont pas utiles pour la cryptographie.
Toutefois, les générateurs linéaires congruentiels restent utiles pour des applications
non cryptographiques, comme les simulations. Ils sont efficaces et ont de bons com
portements statistiques par rapport aux tests empiriques les plus raisonnables. Vous
trouverez pas mal d’information sur les générateurs linéaires congruentiels et leurs
réalisations dans [953].
Combinaison de générateurs linéaires congruentiels

Plusieurs personnes ont examiné la combinaison de générateurs linéaires congruentiels
[1597, 952]. Leurs résultats ne sont pas plus sûrs cryptographiquement, mais ils ont
des périodes plus longues etils passent mieux les tests de caractère aléatoire.
Utilisez ce générateur sur les ordinateurs à motde 32 bits [532] :
s t a t i c lo n g s i = 1 ; / * Un " l o n g " d o i t a v o ir 32 b i t s . */
s t a t i c lo n g s2 = 1 ;
# d e f i n e M O D M U L T (a,b ,c,m ,s) q = s / a ; s = b * (s -a * q ) - c*q; if ( s < 0 ) s+=m;

/ * M 0 D M U L T (a ,b ,c,m ,s) c a l c u l e s * b mod m,
é t a n t d o n n é m =a*b+c e t 0 <= c < m. */
/ * com binedLCG f o u r n i t u n e v a l e u r r é e l l e p s e u d o - a lé a t o ir e dans

* l ’ in te r v a lle (0 ,1 ). E lle co m b in e d e s g é n é r a t e u r s l i n é a i r e s
* 31 31
* c o n g r u e n t ie ls a vec d es p é r io d e s de 2 -8 5 e t 2 -2 4 9
* e t a une p é r i o d e é g a l e au p r o d u i t d e c e s d eu x
* n om b res p r e m i e r s . */
d o u b l e com binedLCG ( v o i d )
t
lo n g q ;
lo n g z ;
M0DMULT ( 5 3 6 6 8 , 4 0 0 1 4 , 12211, 2147483563L, s i )

M0DMULT ( 5 2 7 7 4 , 4 0 6 9 2 , 3791, 2147483399L , s2 )
z = si - s2 ;
if ( z < 1 )
z += 2 1 4 7 4 8 3 5 6 2 ;
r e t u r n z * 4 . 6 5 6 6 1 3 e - 10 ;
>
/* En g é n é r a l , il f a u t a p p e l e r in itL C G a v a n t d ’ u t i l i s e r com binedL C G . */

v o i d in itL C G ( lo n g I n i t S l , lo n g I n itS 2 )
{
s i = I n itS l ;
s2 = In itS 2 ;
>
Ce générateur fonctionne tant que la machine peut représenter tous les entiers compris
entre —231 -f 85 et 231 — 85. Les variables s i et s2 sont globales; elles maintiennent
l’état courant du générateur. Avant le premier appel, elles doivent être initialisées. La
variable s i doit avoir une valeur initiale entre 1 et 2147483562; la variable s2 doit
avoir une valeur initiale entre 1 et 2147483398. Le générateur a une période d’environ
1018.
Si vous n’avez qu’un ordinateur 16 bits, utilisez plutôt le générateur suivant :
s ta tic in t s i = 1 / * Un " i n t " d o i t a v o i r 16 b i t s . */

s ta t ic in t s2 = 1
s t a t ic in t s3 = 1
# d e f i n e M 0 D M U L T (a ,b ,c,m ,s) q « s / a ; s = b * (s -a * q ) - c*q; if (s < 0 ) s+=m;
/* com binedLCG f o u r n i t u n e v a l e u r r é e l l e p s e u d o - a l é a t o i r e dams

* l ’ in te r v a lle (0 ,1 ). E lle co m b in e d e s g é n é r a t e u r s l i n é a i r e s
* 15 15 15
* c o n g r u e n t ie ls a v ec d es p é r io d e s de 2 -4 0 5 , 2 -1 0 4 1 , et 2 -1 1 1 1
* e t a u n e p é r i o d e é g a l e au p r o d u i t d e c e s t r o i s
* n o m b re s p r e m i e r s . * /
d o u b le com binedLCG ( v o i d )
in t q ;
in t z ;
MODMULT ( 206, 157, 21, 32363, si )

MODMULT ( 217, 146, 4 5 , 31727, s2 )
MODMULT ( 222, 142, 133, 31657, s3 )
z = si - s2 ;
if ( z > 706 )
z -= 3 2 3 62 ;
z += s 3 ;
if ( z < 1 )
z += 3 2 3 6 2 ;
r e t u r n z * 3 .0 8 9 9 e -5 ;
>
/ * En g é n é r a l , il f a u t a p p e l e r in itL C G a v a n t d ’ u t i l i s e r com binedL C G . * /

v o i d in itL C G ( in t I n it S l, in t In itS 2 , In itS 3 )
16.2 Registres à décalage à rétroaction linéaire 395
i
si = InitSl ;
ë2 = InitS2 ;
e 3 = InitS3 ;
Ce générateur fonctionne tant que la machine peut représenter tous les entiers entre
—32 363 et 32 363. Les variables s i , s2 et s3 sont globales; elles maintiennent l’état
courant du générateur. Avant le premier appel, elles doivent être initialisées. La variable
si doit avoir une valeur initiale entre 1 et 32 362. La variable s2 doit avoir une valeur
initiale entre 1 et 31762. La variable s3 doit avoir une valeur initiale entre 1 et 31656.
Le générateur a une période de 1,6 x 1013.
Pour ces deux générateurs, le terme constant b est nul.
16.2 Registres à décalage à rétroaction li

néaire
Les séquences de registres à décalage s’utilisent à la fois en cryptographie et en théorie
des codes. Il existe une théorie très riche à leur propos ; les algorithmes de chiffrement en
continu basés sur des registres à décalage ont été le cheval de bataille des cryptographes
militaires depuis les débuts de l’électronique.
Un registre à décalage à rétroaction est composé de deux parties : un registre à
décalage et une fonction de rétroaction (voir la figure 16.1). Le registre à décalage
est une suite de bits. Chaque fois qu’un bit est nécessaire, tous les bits du registre
à décalage sont décalés vers la droite de un bit. Le nouveau bit le plus à gauche est
calculé en fonction des autres bits dans le registre. Le registre à décalage produit un
bit en sortie, le moins significatif en général. La période d ’un registre à décalage est
la longueur de séquence produite avant qu’elle ne commence à se répéter.
bn bn-l bt b3 b2 bi
r ir 1r r ir ir
-------- -— Fonction de rétroaction
F i g . 16.1 - Registre à décalage à rétroaction
Les cryptographes ont rafolé des algorithmes de chiffrement faits de registre à décalage
car ils sont faciles à réaliser en matériel. Je ne traiterai que la théorie mathématique.
Ernst S e l m e r le responsable de la cryptographie pour le gouvernement norvégien a
fondé la théorie des séquences de registre à décalge en 1965 [1416]. Solomon G o l o m b ,
un mathématicien de la NSA, a écrit un livre avec les résultats de S e l m e r et d ’autres
qui lui sont propres [645]. Voir aussi [982, 981, 1649].
La forme la plus simple de registre à décalage est le registre à décalage à rétroac-
tion linéaire, ou en abrégé R D R L 2 (voir la figure 16.2). La fonction de rétroaction

est simplement la combinaison par ou exclusif de certains des bits du registre ; la liste
de ces bits s’appelle une séquence de dérivation ou parfois une configuration de
Fibonaeci. Comme la rétroaction est simple, une large partie des théories mathé
matiques s’appliquent à l’analyse des R D R L . Les cryptographes aiment analyser les
suites de bits pour se convaincre qu’elles sont assez aléatoires pour être utilisées en
cryptographie.
F i g . 16.2 - Registre à décalage à rétroaction linéaire
La figure 16.3 représente un R D R L de 4 bits, dérivé au premier et au quatrième bit.

Il est initialisé avec la valeur 1111, produira la suite d’états internes suivante avant de
se répéter :
1 1 1 1
0 111
10 11
0 10 1
10 10
110 1
0 110
0 0 11
10 0 1
0 10 0
0 0 10
0 0 0 1
10 0 0
2. N ote du traducteur : en anglais, les registres à décalage à rétroaction linéaire sont appelés « h n ea r
feed ba ck sh ift reg isters » et sont abrégés * L F S R ».
F ig . 16.3 - R D R L à 4 bits
110 0
1 1 1 0
La suite de sortie est la chaîne des bits les moins significatifs :
1 1 1 1 0 1 0 1 1 0 0 1 0 0 0 ___
Un R D R L à n bits est dans l’un de ses 2n —1 états. En théorie, il peut donc engendrer
des suites pseudo-aléatoires de 2'n — 1 bits de long avant de se répéter3. Seul les R D R L
avec certaines séquences de dérivation passeront par tous les 2" — 1 états internes ; ils
sont appelés R D R L d e p é r io d e m axim ale. La suite de bits produite alors en sortie
s’appelle une m -suite.
Pour qu’un R D R L soit de période maximale, le polynôme formé par les éléments de
la séquence de dérivation + 1 doit être un polynôme primitif modulo 2. Le d eg ré du
polynôme est la longueur du registre à décalage. Un polynôme primitif de degré n est
un polynôme irréductible qui divise x 2 _1 + 1 mais pas x d + 1 pour tout d qui divise
2n — 1 (voir § 11.3). Pour un aperçu plus mathématique consulter [645, 1651, 1650].
En général, il n’existe pas de moyen de générer des polynômes primitifs modulo 2 de
degré donné. Le moyen le plus facile consiste à choisir un polynôme aléatoirement et
à vérifier s’il est primitif. C ’est compliqué— à peu près autant que de vérifier qu’un
nombre aléatoire est premier— mais il existe de nombreux logiciels mathématiques qui
font cela. Quelques méthodes se trouvent dans [982, 981].
Le tableau 16.2 donne une liste de polynômes primitifs modulo 2 de différents degrés
[1585, 645, 1651, 1650, 1283, 692]. Par exemple, l’entrée (3 2 ,7 ,5 ,3 ,2 ,1 ,0 ) indique que
le polynôme suivant est primitif modulo 2 :
x 32 + x 7 + x 5 + x 3 + x 2 + x + 1.
Il est aisé de transformer ceci en un R D R L de période maximale. Le premier nombre

est le degré et la taille du R D R L , et le dernier nombre toujours 0, peut être ignoré.
Tous les nombres, excepté le 0, spécifient la séquence de dérivation. Il faut compter à
partir de la gauche du registre à décalage, c ’est à dire que les termes de faible degré
correspondent à des bits de dérivation sur la gauche du registre.
Pour continuer avec l’exemple, l’entrée (3 2 ,7 ,5 ,3 ,2 ,1 ,0 ) indique que, si vous prenez
un registre à décalage de 32 bits et que vous engendrez le nouveau bit en combinant
par ou exclusif les 32e , 7e , 5e , 3e , 2e et 1er bits ensemble (voir la figure 16.4), alors le
RDRL aura une période maximale ; il parcourra les 232 —1 valeurs avant de se répéter.
Fig. 16.4 - R D R L à 32 b its d e p é r io d e m a x im a le
3. C ’ est 2” — t et non pas 2n parce q u ’un registre à décalage rem pli de 0 donnera un R D R L qui
produit une suite infinie de 0, ce qui n ’est pas particulièrement utile.
T ab. 16.2 - Quelques polynômes primitifs modulo 2
(1,0) (3 2 ,7 ,6 ,2 ,0 ) (5 8,6,5,1 ,0) (8 5,8,2,1 ,0)

(2,1,0) (33,13,0) (5 9 ,7 ,4 ,2 ,0 ) (8 6,6,5,2 ,0)
(3,1,0) (33,16,4,1,0) (5 9 ,6 ,5 ,4 ,3 ,1 ,0 ) (87,13,0)
(4,1,0) (3 4,8,4 ,3 ,0 ) (60,1,0) (87,7,5,1 ,0)
(5,2,0) (3 4 ,7 ,6 ,5 ,2 ,1 ,0 ) (6 1 ,5 ,2 ,1 ,0 ) (88,11,9,8,0)
(6,1,0) (35,2,0) (6 2,6,5,3 ,0) (8 8 ,8 ,5 ,4 ,3 ,1 ,0 )
(7,1,0) (36,11,0) (63,1,0) (89,38,0)
(7,3,0) (3 6 ,6 ,5 ,4 ,2 ,1 ,0 ) (6 4,4,3,1 ,0) (89,51,0)
(8 ,4 ,3 ,2 ,0 ) (3 7 ,6 ,4 ,1 ,0 ) (65,18,0) (89,6,5,3,0)
(9,4,0) (3 7 ,5 ,4 ,3 ,2 ,1 ,0 ) (6 5,4,3,1 ,0) (90,5,3,2 ,0)
(10,3,0) (3 8,6,5 ,1 ,0 ) (6 6,9,8,6 ,0) (91,8,5,1 ,0)
(11,2,0) (39,4,0) (6 6 ,8 ,6 ,5 ,3 ,2 ,0 ) (9 1 ,7 ,6 ,5 ,3 ,2 ,0 )
(1 2 ,6 ,4,1 ,0) (4 0 ,5 ,4 ,3 ,0 ) (6 7 ,5 ,2 ,1 ,0 ) (92,6,5,2 ,0)
(13 ,4,3 ,1 ,0 ) (41,3,0) (68,9,0) (93,2,0)
(1 4,5,3 ,1 ,0 ) (4 2,7,4 ,3 ,0 ) (6 8 ,7 ,5 ,1 ,0 ) (94,21,0)
(15,1,0) (4 2 ,5 ,4 ,3 ,2 ,1 ,0 ) (6 9,6,5,2 ,0) (94,6,5,1 ,0)
(1 6,5,3 ,2 ,0 ) (4 3,6,4 ,3 ,0 ) (7 0,5,3,1 ,0) (95,11,0)
(17,3,0) (44,6 ,5,2 ,0) (71,6,0) (9 5 ,6 ,5 ,4 ,2 ,1 ,0 )
(17,5,0) (4 5 ,4 ,3,1 ,0) (7 1,5,3,1 ,0) (96,10,9,6,0)
(17,6,0) (46,8,7 ,6 ,0) (72,10,9,3,0) (9 6 ,7 ,6 ,4 ,3 ,2 ,0 )
(18,7,0) (4 6 ,8 ,5 ,3 ,2 ,1 ,0 ) (7 2 ,6 ,4 ,3 ,2 ,1 ,0 ) (97,6,0)
(1 8 ,5 ,2 ,1 ,0 ) (47,5,0) (73,25,0) (98,11,0)
(1 9,5,2 ,1 ,0 ) (4 8 ,9 ,7,4 ,0) (7 3,4,3,2 ,0) (9 8 ,7 ,4 ,3 ,1 ,0 )
(20,3,0) (4 8 ,7 ,5 ,4 ,2 ,1 ,0 ) (7 4,7,4,3 ,0) (99,7,5,4 ,0)
(21,2,0) (49,9,0) (7 5,6,3,1 ,0) (100,37,0)
(22,1,0) (4 9 ,6 ,5,4 ,0) (7 6,5,4,2 ,0) (100,8,7,2,0)
(23,5,0) (5 0 ,4 ,3,2 ,0) (7 7 ,6 ,5 ,2 ,0 ) (101,7,6,1,0)
(2 4,4,3 ,1 ,0 ) (5 1 ,6 ,3,1 ,0) (7 8,7,2,1 .0) (102,6,5,3,0)
(25,3,0) (52,3,0) (79,9,0) (103,9,0)
(2 6 ,6 ,2 ,1 ,0 ) (53,6 ,2,1 ,0) (7 9 ,4 ,3 ,2 ,0 ) (104,11,10,1,0)
(2 7,5,2 ,1 ,0 ) (54,8 ,6,3 ,0) (8 0,9,4,2 ,0) (105,16,0)
(28,3,0) (5 4 ,6 ,5 ,4 ,3 ,2 ,0 ) (8 0 ,7 ,5 ,3 ,2 ,1 ,0 ) (106,15,0)
(29,2,0) (55,24,0) (81,4,0) (107,9,7,4,0)
(30,6 ,4,1 ,0) (55,6 ,2,1 ,0) (8 2,9,6,4 ,0) (108,31,0)
(31,3,0) (5 6,7 ,4 ,2 ,0 ) (8 2 ,8 ,7 ,6 ,1 ,0 ) (109,5,4,2,0)
(31,6,0) (57,7,0) (8 3,7,4,2 ,0) (110,6,4,1,0)
(31,7,0) (5 7 ,5 ,3,2 ,0) (84,13,0) (111,10,0)
(31,13,0) (58,19,0) (8 4 ,8 , 7 , 5 ,3 ,1 ,0 ) (111,49,0)
(112,11,6,4,0) (142,21,0) (164,12,6,5,0) (236,5,0)
(113,9,0) (143,5,3,2,0) (165,9,8,3,0) (250,103,0)
(113,15,0) (144,7,4,2,0) (166,10,3,2,0) (255,52,0)
(113,30,0) (145,52,0) (167,6,0) (255,56,0)
(114,11,2,1,0) (145,69,0) (170,23,0) (255,82,0)
(115,8,7,5,0) (146,5,3,2,0) (172,2,0) (258,83,0)
T ab. 16.2 - Quelques polynômes primitifs modulo 2 (suite)
(116,6,5,2,0) (147,11,4,2,0) (174,13,0) (266,47,0)

(117,5,2,1,0) (148,27,0) (175,6,0) (270,133,0)
(118,33,0) (149,10,9,7,0) (175,16,0) (282,35,0)
(119,45,0) (150,53,0) (175,18,0) ^ (282,43,0)
(119,8,0) (151,3,0) (175,57,0) (286,69,0)
(120,9,6,2,0) (151,9,0) (177,8,0) (286,73,0)
(121,18,0) (151,15,0) (177,22,0) (294,61,0)
(122,6,2,1,0) (151,31,0) (177,88,0) (322,67,0)
(123,2,0) (151,39,0) (178,87,0) (333,2,0)
(124,37,0) (151,43,0) (183,56,0) (350,53,0)
(125,7,6,5,0) (151,46,0) (194,87,0) (366,29,0)
(126,7,4,2,0) (151,51,0) (198,65,0) (378,43,0)
(127,1,0) (151,63,0) (201,14,0) (378,107,0)
(127,7,0) (151,66,0) (201,17,0) (390,89,0)
(127,15,0) (151,67,0) (201,59,0) (462,73,0)
(127,30,0) (151,70,0) (201,79,0) (521,32,0)
(127,63,0) (152,6,3,2,0) (202,55,0) (521,48,0)
(128,7,2,1,0) (153,1,0) (207,43,0) (521,158,0)
(129,5,0) (153,8,0) (212,105,0) (521,168,0)
(130,3,0) (154,9,5,1,0) (218,11,0) (607,105,0)
(131,8,3,2,0) (155,7,5,4,0) (218,15,0) (607,147,0)
(132,29,0) (156,9,5,3,0) (218,71,0) (607,273,0)
(133,9,8,2,0) (157,6,5,2,0) (218,71,0) (1279,216,0)
(134,57,0) (158,8,6,5,0) (218,83,0) (1279,418,0)
(135,11,0) (159,31,0) (225,32,0) (2281,715,0)
(135,16,0) (159,34,0) (225,74,0) (2281,915,0)
(135,22,0) (159,40,0) (225,88,0) (2281,1029,0)
(136,8,3,2,0) (160,5,3,2,0) (225,97,0) (3217,67,0)
(137,21,0) (161,18,0) (225,109,0) (3217,576,0)
(138,8,7,1,0) (161,39,0) (231,26,0) (4423,271,0)
(139,8,5,3,0) (161,60,0) (231,34,0) (9689,84,0)
(140,29,0) (162,8,7,4,0) (234,31,0)
(141,13,6,1,0) (163,7,6,3,0) (234,103,0)
Le code en langage C pour ce R D R L est donné par :
i n t RDRL ( ) {
s t a t i c u n s ig n e d l o n g S h i f t R e g i s t e r = 1 ; /* N’ im p o r t e q u o i s a u f 0 . * /
S h iftR e g is te r = ( (((S h ift R e g is t e r » 31)
~ (S h iftR e g is te r » 6)
(S h iftR e g is te r » 4)
“ (S h iftR e g is te r » 2)
' ( S h i f t R e g i s t e r >> 1 )
S h iftR e g is te r ))
& 0x00000001)
« 31)
I (S h iftR e g is te r » 1 );
re tu rn S h ift R e g is t e r & 0x00000001;
>
Le code est légèrement plus compliqué quand la taille du registre à décalage est plus
grande que la taille d ’un mot de l’ordinateur.
Remarquez qu’ils ont tous un nombre impair de coefficients. J’en ai donné un si grand
nombre parce que les R D R L sont souvent utilisés pour le chiffrement en continu, et je
voulais qu’il y ait suffisamment d ’exemples différents pour que des personnes différentes
choisissent des polynômes primitifs différents. Puisque si p(x) est primitif x” p ( l /x) l’est
aussi, alors chaque entrée de la table représente en fait deux polynômes primitifs.
Par exemple, si (a, 6,0) est primitif, alors (a, a — 6,0) est aussi primitif. Si (a, 6, c, d, 0)
est primitif, alors (a, a — d, a — c, a — b, 0) est aussi primitif. Mathématiquement :
si x a + x b + 1 est primitif, alors x a + x a~b + 1 l’est aussi,
si x a + x b + xc + xd + 1 est primitif, alors xa + x a^d + x a~c + x a~b + 1 l’est

aussi.
Les trinômes primitifs donnent les réalisations logicielles les plus rapides car seuls deux
bits du registre à décalage doivent être combinés par ou exclusif. En fait, les polynômes
primitifs modulo 2 donnés dans le tableau 16.2 sont clairsem és, ce qui veut dire que
la plupart de leur coefficients sont nuls. Les polynômes clairsemés sont toujours plus
faibles cryptographiquement, parfois cela suffit pour casser l’algorithme. Il vaut mieux
utiliser des polynômes primitifs modulo 2 denses (ceux qui ont beaucoup de coefficients
non nuls) pour les applications cryptographiques. Si vous utilisez des polynômes denses,
et à plus forte raison si vous les incluez dans la clef, vous pourrez manier des RDRL
beaucoup plus petits.
Il n’est pas facile de générer des polynômes primitifs modulo 2 denses. En général,
pour générer des polynômes primitif de degré k, vous devez connaître la factorisation
de 2k — 1. Trois bonnes références sur la génération de polynômes primitifs sont [653,
1296, 1297].
Les R D R L sont des générateurs de suites aléatoires par eux-mêmes mais ils ont des
propriétés non aléatoires gênantes. Les suites de bits successifs sont linéaires, ce qui les
rend tout sauf utiles pour la cryptographie. Pour un R D R L de taille n, l’état; interne
est donné par les n bits précédents de sortie du générateur. Même si le schéma de
rétroaction est inconnu, il ne faut que 2n bits consécutifs de la sortie pour le déterminer
avec l’algorithme très efficace de Berlekamp-Massey [1086, 1087] (voir § 16.3).
De grands nombres aléatoires engendrés à partir de bits successifs de telles suites
sont fortement corrélés et, pour certains types d’applications, pas du tout aléatoires.
Malgré cela, les R D R L sont souvent utilisés comme briques de base d’algorithmes de
chiffrement.
Réalisations logicielles de RDRL

Les réalisations logicielles de R D R L sont lentes mais elles sont plus rapides en langage
machine. Une solution consiste à faire tourner 16 R D R L (ou 32 selon la taille des mots
de votre ordinateur) en parallèle. Ce schéma utilise un tableau de mots dont la longueur
est celle du R D R L , et où chaque position de bit représente un R D R L différent. En

supposant que tous les polynômes de rétroaction sont les mêmes, cela peut tourner
assez vite. En général, le moyen le plus rapide de mettre à jour des registres à décalage
est de multiplier l’état courant par des matrices binaires apropriées [901].
Il est aussi possible de modifier le schéma de rétroaction des R D R L . Le générateur
résultant n’est pas meilleur cryptographiquement mais il est toutefois de période maxi
male et il est plus facile à réaliser en logiciel [1283].
Au lieu d ’utiliser certains bits pour les combiner par ou exclusif pour former le bit le
plus à gauche, certains bits sont combinés par ou exclusif avec la sortie du générateur
puis remplacés par ce résultat et, ensuite, la sortie du générateur devient le bit le plus
à gauche (voir la figure 16.5). Ceci est parfois appelé con fig u ra tion d e G alois.
Eîitde
ortie
-----► b32 h? b6 b5 b4 b3 h2 b{ 1
/p A /p A /p A /p A
F ig . 16.5 - R D R L à 32 bits modifié
En langage C, on a :
# d e f i n e mask 0 x 8 0 0 0 0 0 5 7
s t a t i c u n s ig n e d l o n g S h i f t R e g i s t e r = l ;
v o i d seed_RDRL ( u n s i g n e d l o n g s e e d )
f
if ( s e e d == 0 ) / * pou r é v it e r l a ca ta stro p h e * /
seed = 1;
S h iftR e g is te r = seed ;
}
i n t m od ifie d _ R D R L (v o id )
f
if (S h ift R e g is t e r & 0x00000001) {
S h i f t R e g i s t e r = ( ( S h i f t R e g i s t e r ~ m ask) » 1) I 0x8000000;
retu rn 1;
> e ls e {
S h iftR e g is t e r » = 1;
retu rn 0;
>
}
L’avantage ici est que tous les ou exclusif peuvent être faits en une seule opération.
Ceci peut aussi être parallélisé et les polynômes de rétroaction peuvent différer. Cette
configuration de Galois peut aussi s’avérer plus rapide en réalisation matérielle, surtout
dans des réalisation V LSI spécialement conçues. En général, si votre matériel est bon
dans les décalages, utilisez une configuration de Fibonacci ; si vous pouvez exploiter le
parallélisme, utiliser une configuration de Galois.
40 2 Chapitre 16 Générateurs de suites aléatoires et chiffrement en continu
16.3 Conception et analyse d’algorithmes

de chiffrement en continu
La plupart des concptions pratiques d’algorithmes de chiffrement en continu tournent
autour des R D R L . Dans les toutes premières années de l’électronique, ils étaient très
facile à construire. Un registre à décalage n’est rien d’autre qu’un tableau de bits de
mémoire et la rétroaction est juste une série de porte logiques. Même avec les circuits
VLSI, un algorithme de chiffrement en continu basé sur un R D R L peut vous donner
beaucoup de sécurité avec peu de portes logiques.
Le problème des R D R L est que leur réalisations logicielles sont très lentes. Vous devez
éviter les polynômes primitifs clairsemés, qui facilitent les attaques par corrélation, et
les polynômes primitifs denses donnent des algorithmes inefficaces Tout algorithme
de chiffrement en continu sort un bit à la fois ; vous devez le répéter 64 fois pour
chiffrer autant que le DES en une itération. En fait, même un R D R L simple tel que
le générateur à réduction qui sera décrit un peu plus loin, n’est pas plus rapide que le
DES en réalisation logicielle.
Cette branche de la cryptographie croît très rapidement et est très influencée politique
ment. La plupart des conceptions sont secrètes ; la majorité des systèmes de chiffrement
militaires utilisés aujourd’hui est basée sur les R D R L . De fait, la plupart des ordina
teurs C r a y (Cray 1, Cray X-MP, Cray Y-M P) possèdent une instruction curieuse du
nom de « comptage de la population ». Elle compte les 1 dans un registre et peut être
utilisée à la fois pour calculer efficacement la distance de Hamming entre deux mots
binaires et pour réaliser une version vectorielle d ’un R D R L . Certains la nomment
l’instruction canonique de la NSA, elle est demandée sur presque tous les contrats
d ’ordinateur
D ’un autre côté, un nombre étonnamment grand de générateurs de codons à base de
registres à décalage ont été cassés. Et il est pratiquement certain que les institutions
militaire^çje cryptanalyse telle que la NSA en ont cassé beaucoup plus. Il est parfois
surprenant de voir les mêmes idées simple revenir encore et encore.
Complexité linéaire
Il est souvent plus facile d’analyser les algorithmes de chiffrement en continu que les
algorithmes de chiffrement par blocs. Par exemple, une des mesures importantes dans
l’analyse des générateurs à base de R D R L est la complexité linéaire. Elle est défi
nie comme la taille n du plus petit R D R L qui peut simuler la sortie du générateur
Toute suite de bits générée par une machine à nombre d’états fini sur un corps fini a une
complexité linéaire finie [1022]. La complexité linéaire est importante parce qu’un algo
rithme simple, l’algorithme de Berlekamp-Massey, permet de produire ce RDRL
après avoir examiné seulement 2n bits de la suite de bits [1021]. Une fois que vous avez
construit ce R D R L , vous avez cassé l’algorithme de chiffrement en continu qui utilise
ce générateur.
Cette idée a des extensions quand on considère des anneaux au lieu de corps [1309], et
quand le flux de codons est vu comme une suite d ’éléments d ’un corps de caractéristique
impaire [843]. Une amélioration plus poussée se trouve être la notion de profil de
complexité linéaire, qui permet de mesurer la complexité linéaire du flux de codons
au fur et à mesure qu’il augmente [1359, 1, 414, 1584]. Il existe un autre algorithme,
16.4- Chiffrement en continu à base de R D R L
permettant de calculer la complexité linéaire, qui n’est utile que dans des circonstances
très spéciales [599, 597, 598, 1347]. Une généralisation de la complexité linéaire est
donnée dans [776]. Citons aussi la notion de sphère de complexité [500] et la complexité
deux-adique [845].
Dans tous les cas, retenez qu’une complexité linéaire élevée n ’indique pas forcément
que le générateur est sûr, mais qu’une complexité linéaire faible dénote un générateur
non fiable [1359, 1259].
Immunité à l’attaque par corrélation

Les cryptographes essaient d ’obtenir une complexité linéaire élevée en combinant plu
sieurs flux de codons d’une manière non linéaire. Le danger ici est que l’un des flux
interne— souvent la sortie d ’un certain R D R L — soit corrélé avec la sortie combinée et
puisse être attaqué en utilisant l’algèbre linéaire. On appelle souvent cela l ’a t t a q u e
p a r c o r r é la t io n ou encore l’attaque « diviser pour régner ». Thomas S lE G E N a montré
comment définir précisément l’imunité à l’attaque par corrélation, et la nécessité de
trouver un compromis entre l’immunité à l’attaque par corrélation et la complexité
linéaire [1456].
L’idée de base derrière l’attaque par corrélation est d ’identifier une corrélation entre la
sortie du générateur et la sortie d’un de ses morceaux internes. En observant alors le flux
de codons en sortie, on peut obtenir des informations à propos de cette sortie interne. En
utilisant cette information et d’autres corrélations, il reste à trouver assez d ’information
sur les autres sorties internes pour pouvoir casser entièrement le générateur.
Les attaques par corrélations et ses variantes telles que l’ attaque par corrélation rapide,
qui offre un compromis entre la complexité de calcul et l’efficacité, ont permis de casser
de nombreux générateurs de codons à base de R D R L [1457, 282, 1458, 573, 1638, 1059,
1096, 354, 635, 1062, 1095, 1005]. Quelques idées nouvelles intéressantes au milieu de
tout cela se trouvent dans [47, 1643].
Autres attaques
Il existe d ’autres attaques générales contre les générateurs de codons. Le t e s t d e
c o n s is t e n c e lin é a ir e est une tentative d’identification d’une partie de la clef de chif
frement en utilisant des techniques matricielles [1640]. Il y a aussi l ’a t t a q u e d e c o n s is
te n ce p a r c o llis io n [40, 43]. L ’a lg o r it h m e d u s y n d r o m e lin é a ir e repose sur la pos
sibilité d ’écrire un fragment du flux de sortie sous forme d ’équation linéaire [1638, 1639].
Il y l ’a t t a q u e d e la m e ille u r e a p p r o x im a t i o n a ffin e [500] et l ’a t t a q u e d e la s u it e
d é r iv é e [42]. Même les techniques de la cryptanalyse différentielle ont été appliquées
aux algorithmes de chiffrement en continu [499], ainsi que celles de la cryptanalyse
linéaire [633].
16.4 Chiffrement en continu à base de

RDRL
L’approche classique de la conception de générateurs de codons à base de R D R L
est simple. Vous commencez par prendre un ou plusieurs R D R L généralement de
longueurs différentes et avec des polynômes primitifs distincts4. La clef est l’état initial
des R D R L . Chaque fois qu’un bit est nécessaire, décalez les R D R L d ’un cran (on
parle parfois d ’im p u ls io n d ’ h o r lo g e ) . Le bit de sortie est une fonction de préférence
non linéaire de certains des bits de sortie des R D R L . Cette fonction est appelée la
f o n c t io n d e c o m b in a is o n et le générateur global est appelé un g é n é r a t e u r p a r
c o m b i n a is o n 5. La plupart des considérations théoriques sur ce type d’objets sont
l’œuvre de S e l m e r et Neal Z i e r l e r [1649].
Des complications ont pu être ajoutées. Certains générateurs ont des horloges de ca
dences différentes ; la cadence d ’un générateur dépend parfois de la sortie d’un autre.
Toutes ces idées de versions électroniques de machines à chiffrer d’avant guerre ont
pour nom g é n é r a t e u r s à h o r lo g e c o n t r ô lé e [643]. Le contrôle d’horloge se fait par
action simple si la sortie d ’un R D R L contrôle l’horloge d ’un autre, ou par rétroaction
si la sortie d ’un R D R L contrôle sa propre horloge.
Bien que ces générateurs soient au moins en théorie vulnérables aux attaques par
plongement et corrélation probabiliste [636, 634], beaucoup sont sûr à l’heure qu’il est.
On trouvera plus de théorie sur les registres à décalage à horloge contrôlée dans [97].
Ian C A S S E L L S , qui fut à la tête du département de mathématiques pures de Cambridge
et qui est un ancien cryptanalyste de Bletchy Park, a dit que « la cryptographie est un
mélange de mathématiques et de désordre, et que sans le désordre, les mathématiques
peuvent être utilisées contre vous ». Ce qu’il voulait dire est que dans les algorithmes
de chiffrement en continu, vous avez besoin d ’une structure mathématique telle que le
R D R L pour guarantir une taille maximale et d ’autres propriétés, et ensuite de désordre
compliqué et non linéaire pour empêcher autrui d ’obtenir le registre et de le résoudre.
Ce conseille vaut aussi pour les algorithmes de chiffrement par blocs.
Ce qui suit est un petit nombre de générateurs de codons à base de R D R L qui sont
apparus dans la littérature. Je ne sais pas si aucun d ’eux n’a jamais servi dans un
produit cryptographique réel. La plupart d’entre eux n ’ont d’intérêt que théorique.
Certains ont été cassés, d’autres sont peut être toujours sûrs.
Comme les algorithmes de chiffrement en continu sont généralement réalisés en maté
riel, les symbole de logique électronique seront utilisé dans les figures. Dans le texte,
© désigne le ou exclusif, A le et, V le ou, et -i la négation.
Générateur de G e f f e
Ce générateur de codons utilise trois R D R L , combinés de façon non linéaire (voir la
figure 16.6) [608]. Les sorties de deux des R D R L servent d ’entrées à un multiplexeur
et le troisième R D R L contrôle la sortie du multiplexeur. Si Oi, a2 et a3 sont les sorties
des trois R D R L , la sortie du générateur de G e f f e peut être décrite par la relation :
b = (oi A a2) © ( ( -iUi) A a3).
Si les polynômes primitifs de rétroaction des trois R D R L ont respectivement des degrés
m , n 2 et ris, alors la complexité linéaire du générateur est donnée par:
(ni + l)n 2 + n i n 3.
4. Si to u te s les lon g u eu rs son t p rem ières e n tre elles et si les p o ly n ô m e ch oisis p o u r la r étroa ction
son t to u s p rim itifs, ie g é n é ra te u r t o ta l e st d e p é rio d e m axim a le.
5. Si le b it de s o r tie n ’est fo n c t io n q u e d ’ un seu l g én éra teu r, o n p arle alors d e g énérateur par
filtre.
16.4 Chiffrement en continu à base de R D R L 405
La période de ce générateur est le plus petit commun multiple des périodes des trois
générateurs. En faisant l’hypothèse que les degrés des trois polynômes primitifs de
rétroaction sont premier entre eux, la période est égale au produit des périodes des
trois R D R L .
Multiplexeur
2 pour 1
a2(t)
RDRL-2 ------------- ► 0
Y -------- ► b(t)
a3(t)
RDRL-3 -------------- ►
1 Sélection
afft)
RDRL-1
F ig . 16.6 - Générateur de G effe
Bien que ce générateur ait bonne allure sur le papier, il est cryptographiquement faible
et vulnérable à une attaque par corrélation [830, 1640]. Si vous passez par les pro
babilités, vous constaterez que la sortie du générateur est égale à celle du R D R L -2
dans 75 % des cas. Si les séquences de dérivation sont connues, vous pouvez essayer
de deviner la valeur initiale du R D R L -2 et générer le flux de sortie de ce générateur.
Vous pouvez alors compter le nombre de fois où la sortie du R D R L est égale à celle
du générateur. Si vous avez bien deviné les suites seront égales 75 % du temps, si vous
vous êtes trompés, elle ne seront égales que 50 % du temps.
De même qu’elle est égale à celle du R D R L -3 dans 75 % des cas. Avec de telles
corrélations, le générateur de codons peut être cassé de manière relativement aisée. Par
exemple, si les polynômes primitifs n’ont que trois termes chacun et que le polynôme
de degré le plus élevé a un degré n, il ne faut alors qu’un segment de 37 x n codons de
la suite de sortie pour reconstruire les états internes des trois R D R L [1641],
Générateur de Geffe généralisé

Au lieu de choisir entre deux R D R L , on choisi dans ce schéma entre k R D R L où k
est une puissance de 2. Il y a k + 1 R D R L au total (voir la figure 16.7). L’horloge du
R D R L -1 doit avoir une cadence log2 k fois plus rapide que celles des autres R R L.
Bien que ce schéma soit plus compliqué que le générateur de G e f f e , le même type
d’attaque par corrélation est possible. Je ne recommande pas ce générateur.
Générateur de J e n n in g s
Ce schéma utilise un multiplexeur pour combiner deux R D R L [778, 779, 780]. Pour
chaque bit de sortie, le multiplexeur, contrôlé par R D R L -1 , choisit un bit de R D R L -
2. U y aussi une fonction qui met en correspondance la sortie de R D R L -2 avec l’entrée
du multiplexeur (voir la figure 16.8).
F ig . 16.7 - Générateur de G effe généralisé
♦
La clef est l’état initial des deux R D R L et la tonction de correspondance. Bien que
ce générateur ait de très bonnes propriétés statistiques, il est tombé sous le coup de
l’attaque de consistence par collision de Ross A n d e r s o n [40] et l’attaque de consitence
linéaire [1640, 444]. N’utilisez pas ce générateur.
Générateur à signal d’arrêt Beth—Piper

Ce générateur décrit par la figure 16.9 utilise la sortie d ’un R D R L pour contrôler
l’horloge d ’un autre R D R L [158]. L’entrée d’horloge de R D R L -2 est contrôlée par la
sortie de R D R L -1 , en sorte que R D R L -2 ne change d ’état au temps t que si la sortie
de R D R L -1 était à 1 à l’instant t — 1.
Personne n’a pu montrer de résultats à propos de la complexité linéaire de ce générateur
G(t+io) H » _k-
------ —► -------
(J)
ü(t+i j )
RDRL-1
Sfft) CD'
e Multiplexeur C(t)
—--------- ------------- ^ o
a(t +i h_x) =>0 1 n- 1
f + Sk- \W
Kn b(t) b{t+n-1)
RDRL-2
F ig . 16.8 - Générateur de J e n n in g s
16-4 Chiffrement en continu à base de R D R L
F i g . 16.9 - Générateur à signal d’arrêt de B e t h - P iper
dans le cas général. Cependant, il est susceptible d ’une attaque par corrélation [1641].
Générateur à signal d’arrêt alterné

Ce générateur utilise trois R D R L de tailles différentes. R D R L -2 est cadencé quand
la sortie de R D R L 1 est à 1 ; R D R L -3 est cadencé quand la sortie de R D R L -1
est à 0. La sortie du générateur est le ou exclusif de R D R L -2 et R D R L -3 (voir la
figure 16.10) [674].
Ce générateur a une longue période et une grande complexité linéaire. Les auteurs ont
trouvé une attaque par corrélations contre R D R L -1 , mais elle n’affaiblit pas substan
tiellement le générateur. Il y a eu d ’autres essais de générateurs de codons dans cette
voie [1542, 1576, 1484]
Générateur à signal d’arrêt bilatéral

Ce générateur utilise deux R D R L , tous deux de taille i (voir la figure 16.11) [1640].
La sortie du générateur est le ou exclusif des sorties de chacun des R D R L . Si la sortie
F ig . 1 6 .1 0 - Générateur à signal d’arrêt alterné

de R D R L -1 au temps t — 1 est 0 et que la sortie au temps t — 2 est 1, alors R D R L -2

ne change pas d ’état au temps t. Inversement, si la sortie de R D R L -2 au temps t — 1
est 0 et la sortie au temps t —2 est 1, et si R D R L -2 a changé d ’état au temps t, alors
R D R L -1 ne change pas d ’état au temps t.
F i g . 16.11 - Générateur à signal d’arrêt bilatéral
La complexité linéaire de ce système est approximativement égale à la période. D’après

[1640], « aucune redondance de codons évidente n’a été constatée dans ce système ».
Générateur à seuil
Ce générateur essaie de pallier les défauts de sécurité des générateurs précédents en
utilisant un nombre variable de R D R L [281]. La théorie veut que si vous utilisez un
grand nombre de R D R L , il est plus difficile de casser le chiffre.
Ce générateur est illustré par la figure 16.12. Prenez la sortie d ’un grand nombre de
R D R L (prenez-en un nombre impair). Assurez-vous que les tailles de tous ces R D R L
soient premières entre elles et que tous les polynômes de rétroaction soient primitifs
— pour maximiser la période. Si plus de la moitié des bits de sortie sont à 1, alors la
sortie du générateur est à 1. Si plus de la moitié des bits sont à 0, alors la sortie du
générateur est à 0.
Avec trois R D R L , la sortie du générateur peut être décrite par :
b = (ai A o2) ® (ai A 0 3 ) © (a 2 A a3).
C ’est très sim ilaire à un générateur d e G e f f e , ex ce p té q u ’il y a une com p lexité linéaire
plus grande :
nin 2 + nl n3 + n 2 n3
où ni, n2 et n3 sont les tailles respectives des premier, second et troisième R D R L .

Ce générateur n’est pas extraordinaire. Chaque bit de sortie du générateur donne un
peu d ’information sur l’état des R D R L , 0,189 bit pour être exact, et le tout tombe
sous le coup d ’une attaque par corrélation. Je ne conseille pas de l’utiliser.
16-4 Chiffrement en continu à base de RDRL 409
F i g . 16.12 - Générateur à seuil
Générateurs auto-cadencés
Les générateurs auto-cadencés sont des générateurs qui contrôlent leur propre horloge.
Deux propositions ont été faites, l’une par R u e p p e l (voir la figure 16.13) [1361] et
l’autre par C h a m b e r s et G o l l m a n n [313] (voir la figure 16.14). Dans le générateur
de R u e p p e l , quand la sortie du R D R L est à 0, le R D R L est cadencé d fois. Quand
la sortie du R D R L est à 1, le R D R L est cadencé k fois. Le générateur de C h a m b e r s
et G o l l m a n n est plus compliqué mais l’idée est la même. Malheureusement, ces deux
générateurs ne sont pas sûrs [1641], malgrés des modifications qui pourraient corriger
les problèmes [1364].
F ig . 16.13 - Générateur auto-cadencé de R u e p p e l
F i g . 1 6 .1 4 - Générateur auto-cadencé de C hàm bers et G ollm ann

4 10 Chapitre 16 Générateurs de suites aléatoires et chiffrement en continu
Générateur multivitesse à produit scalaire

Ce générateur, conçu par M a s s e y et R u e p p e l [1020], utilise deux R D R L cadencés à
deux vitesses différentes (voir la figure 16.15). R D R L -2 est cadencé d fois plus vite
que R D R L -1 . Puis les bits individuels des deux R D R L sont combinés entre eux par
et logique et ensuite combinés par ou exclusif les uns avec les autres pour produire le
bit de sortie du générateur.
F ig . 1 6 .1 5 - Générateur multivitesse à produit scalaire
Bien que la complexité linéaire soit élevée et que ce générateur possède d’excellentes
propriétés statistiques, il tombe encore sous le coup d ’une attaque de consistence li
néaire [1641]. Si ni est la longueur de R D R L —1, n2 est la longueur de R D R L -2 , et
d est le quotient de vitesse entre les deux, alors l’état interne du générateur peut être
reconstruit à partir d ’une suite de bits de sortie de longueur :
n\ + n2 + log2 d.
Générateur sommatoire
Fruit des travaux Rainer R u e p p e l , ce générateur combine la sortie de deux R D R L
dans un additionneur avec retenue [1360, 1359]. Cette opération est fortement non
linéaire et, jusqu’à la fin des années 80, ce générateur était ce qui se faisait de mieux en
matière de sécurité, mais il est tombé sous le coup de l’attaque par corrélation [1061,
1062, 1097]. De plus, il a été prouvé que c ’est un cas de registre à décalage à rétroaction
avec retenue (voir § 17.4) qui peut être cassé [845].
Générateur dynamique
Le nom complet est générateur dynamique de suites aléatoires6 [1123]. L’idée est
d’avoir deux générateurs par filtre, à seuil, sommatoires, ou autres, alimentés par un
ensemble de R D R L et contrôlé par un autre R D R L .
6- On note en abrégé D N R S G pou r « d yn arm c ra n d o m -s eq u e n c e g e n e r a to r ».

16. f Chiffrement en continu à base de R D R L 411
Opérer d’abord les R D R L . Si la sortie du R D R L —0 est 1 alors calculer la sortie du

premier générateur par filtre, si c’est 0, alors calculer la sortie du second générateur
par filtre. La sortie finale est la combinaison par ou exclusif des différentes sorties.
Cascade de G o l l m a n n
La cascade de G o l l m a n n (voir la figure 16.16) décrite dans [638, 314] est une version
renforcée du générateur à signal d’arrêt. Il consiste en une série de R D R L dont l’horloge
est contrôlée par le R D R L précédent. Si la sortie de R D R L -1 est 1 à l’instant t — 1,
alors R D R L -2 change d ’état. Si la sortie de R D R L —2 est 1 à l’instant t — 1, alors
R D R L -3 change d’état, et ainsi de suite. La sortie du R D R L final est la sortie du
générateur. Si tous les R D R L ont la même taille, n, la complexité linéaire d’un système
de k R D R L est :
n(2” — l ) fc—1.
F ig . 16.16 - Cascade de G ollm ann
Les cascades sont une bonne idée : leur conception est très simple, et elle permettent
de générer des suites avec des périodes énormes, des complexités linéaires énormes, et
de bonnes propriétés statistiques. Elles sont vulnérables à une attaque appelée v é r -
r o u illa g e [642], C ’est une technique dans laquelle le cryptanalyste reconstruit l’entrée
du dernier registre à décalage de la cascade, puis remonte la cascade registre par re
gistre. Cela pose un problème sérieux dans certaines situations en réduisant la longueur
effective de la clef de l’algorithme, mais il possible de prendre certaines précautions pour
minimiser l’attaque.
Des analyses plus poussées ont montré que la suite se rapproche de l’aléatoire quand
k grandit [639, 640, 644, 641], Sur la base d ’attaques récentes sur les cascades de
G o l l m a n n courtes, je recommande de prendre k supérieur à 15. Vous feriez mieux
d’utiliser plus de R D R L de petite taille plutôt que peu de grande taille.
Générateur à réduction
Le générateur à réduction [382] repose sur une forme différente de contrôle d ’horloge
que celle des générateurs précédents. Prenez deux R D R L , R D R L —1 et R D R L —2.
Opérez un cycle d ’horloge sur chacun d ’eux. Si la sortie du R D R L -1 est 1, alors la
sortie du générateur est celle du R D R L -2 . Dans le cas contraire, annulez les deux bits,
opérez un cycle d ’horloge sur chacun des R D R L , et essayez à nouveau.
Cette idée est simple, raisonnablement efficace et semble sûre. Si les polynômes primitif
sont clairsemés, le générateur est vulnérable, mais aucun autre problème n’a été décelé.
Même ainsi, c’est récent. Un problème de réalisation vient du fait que la cadence de
sortie n’est par régulière ; si le R D R L -1 sort beaucoup de zéros à la suite, le générateur
ne sort aucun bit Les auteurs suggèrent d’utiliser une mémoire tampon pour résoudre
cela [382] Une réalisation pratique du générateur à réduction est présentée dans [901].
Générateur à auto-réduction
Le générateur à réduction [1058] est une variante du générateur à réduction. Au lieu
d’utiliser deux R D R L , considérez une paire de bits provenant d ’un seul R D R L . Opérez
deux cycle d ’horloge sur un R D R L . Si le premier bit de la paire est 1, la sortie est le
second bit. Si le premier bit est 0, jetez les deux bits et recommencez. Si le généra
teur à auto-réduction utilise environ deux fois moins de mémoire que le générateur à
réduction, il est aussi deux fois moins rapide
Si le générateur à auto-réduction semble aussi sûr, il présente encore des comportements
inexpliqués et des propriétés inconnues. C ’est un générateur tout nouveau ; consacrez-y
du temps.
16.5 A5
L’algorithme de chiffrement en continu A5 sert à chiffrer les messages en téléphonie
GSM (dont le nom vient de « Group Spécial Mobile »). C ’est le standard non améri
cain pour les téléphones cellulaires numériques. L’algorithme est utilisé pour chiffrer
la communication entre le mobile et la borne reliée au réseau. Le reste de la commu
nication n’est, pas chiffrée ; la compagnie téléphonique peut facilement espionner vos
conversations.
Beaucoup d’affaires politiques étranges entourent ce projet. A l’origine, on pensait
qu’insérer de la cryptographie en téléphonie G SM nuierait à son exportation dans
certains pays. Maintenant, certains rapports offciels mettent en cause A5, impliquant
qu’il est si faible que cela peut nuire aux ventes à l’exportation. La rumeur dit que
plusieurs services de renseignements de l’OTAN se sont disputés au milieu des années
1980 pour savoir si le chiffrement de GSM devait être solide ou faible. Les allemands
voulaient un chiffrement solide commme ils se trouvaient à côté de l’Union Soviétique.
Les autres pays ont pris le dessus, et A 5 est de conception française.
Nous connaissons la plupart des détails. Une compagnie téléphonique britanique a
fournit toute la documentation à l’Université de Bradford en omettant de leur faire
signer un contrat de non divulgation. Il y eu des fuites ça et là, et l’algorithme aurait
même été posté sur In t e r n e t . Un article décrit A5 [1624], et le code source se trouve
à la fin de ce livre.
A5 est constitué de trois R D R L , de tailles de registres 19, 22 et 23 ; tous les polynômes
primitifs utilisés pour les rétroactions sont clairsemés. Chaque registre est cadencé en
fontion de son propre bit du milieu, combiné par ou exclusif avec l’inverse de la fonction
de seuil des bits du milieu des trois registres. Habituellement, deux des R D R L opèrent
un cycle d’horloge à chaque ronde.
Il existe une attaque évidente nécessitant 240 chiffrements : deviner le contenu des deux
premiers R D R L et essayez alors de déterminer le troisième R D R L d ’après le flux de
codons. (La faisabilité de cette attaque est encore sujette à débats, mais une machine
16.6 H ugues X P D / K P D 413
à rechercher les clefs, actuellement en cours de conception, devrait bientôt clore la

discussion [46].)
Néanmoins, il apparaît que les idées fondamentales de A 5 sont bonnes. Il est très
efficace. Il réussit tous les tests statistiques connus; sa seule faiblesse connue est la
taille de ses registres qui sont assez petits pour permettre la recherche exhaustive. Des
variantes de A 5 avec des registres à décalage plus longs et des polynômes primitifs plus
denses devraient être sûres.
16.6 H u g u e s X P D /K P D
Cet algorithme vous est donné par H u g u e s A i r c r a f t C o r p . Il a été incorporé dans
des radios tactiques de l’armée et dans des équipements d’orientation vendus à des
militaires étrangers. Il fut conçu en 1986 et nommé X P D pour « Exportable Protection
Device » qui veut dire appareil de protection exportable. Plus tard, il ne fut plus classé
secret et fut rebaptisé K P D pour « Kinetic Protection Device » qui veut dire appareil
de protection dynamique [1045, 1044],
L’algorithme utilise un R D R L à 61 bits. Il y a 210 polynômes primitifs distincts qui ont
été approuvés par la NSA. La clef sélectionne un de ces polynômes (qui sont stockés
quelque part en mémoire morte), ainsi que l’état initial du R D R L .
Il a huit filtres non linéaires différents, chacun d’eux produit un bit à partir de six
dérivations provenant du R D R L . Les bits sont combinés pour générer un octet qui
sert à chiffrer ou à déchiffrer le flot de données.
Cet algorithme a l’air assez impressionnant, mais je doute qu’il le soit vraiment. La
NSA l’autorise à l’exportation, il doit donc exister une attaque avec un nombre d ’opé
rations de l’ordre de 240 ou moins. Quelle est-elle?
16.7 Nanoteq
N a n o t e q est une société sud africaine en électronique. Ceci est leur algorithme qui
a été adopté par la police sud africaine pour chiffrer leur communications par fax, et
certainement pour d’autres utilisations aussi.
L’algorithme est plus ou moins décrit dans [903, 904]. Il utilise un R D R L à 127 bits
avec un polynôme primitif de rétroaction fixé ; la clef est l’état initial du registre. Les
127 bits du registre sont réduits à un flux de codons au moyen de 25 cellules primitives.
Chaque cellule a cinq entrées et une sortie :
f(xi,X 2 ,X3 ,X4 ,X5) = X\ + X2 + ( Xi + X 3) ( x 2 + X4 + X5) + + X4 )(x2 + X3) + X5
Chaque entrée de la fonction est combinée par ou exclusif avec certains bits de la clef. Il
y a aussi une permutation secrète qui dépend de la réalisation, et qui n’est pas détaillée
dans l’article. On ne peut se procurer cet algorithme qu’en réalisation matérielle.
Est-ce que cet algorithme est sûr? J’en doute. Durant le passage à la démocratie,
certains faxs embarassants d ’une station de police à une autre sont parfois apparus
dans les journaux libéraux. Cela pourrait très bien être le résultat des efforts des
services de rensignement américains, britaniques, ou soviétiques. Ross A n d e r s o n a
fait les premiers pas vers la cryptanalyse de cet algorithme dans [47] ; j ’espère voir
davantage de résultats arriver bientôt.
4U Chapitre 16 Générateurs de suites aléatoires et chiffrement en continu
16.8 Rambutan
R a m b u t a n est un algorithme britanique conçu par le « Communication Electronics
Security Group », soit groupe de sécurité en électronique et en communication. Il n’est

vendu que sous forme de module matériel et il est approuvé pour la protection de
document classés jusqu’à « confidentiels ». L’algorithme lui-mème est classé secret, et
la puce n’est générallement pas disponible dans le commerce.
R a m b u t a n a une clef de 112 bits (sans compter les bits de parité) et peut opérer dans
trois modes : E C B , C B C , et C FB à huit bits. Cela sous-entend fortement que c ’est
un algorithme par blocs, mais les rumeurs ne vont pas dans ce sens. Il est supposé être
un algorithme de chiffrement en continu à base de R D R L. Il aurait cinq registres à
décalage, chacun d’une taille de 80 bits environ. Les polynômes de rétroaction seraient
plutôt clairsemés, avec à peu près 10 dérivations chacun. Chaque registre fournirait
quatre entrées à une fonction linéaire très grande et très compliquée qui sortirait un
bit à la fois.
D ’où vient le nom ? C ’est peut-être du fruit7 qui est épineux et repoussant à l’extérieur
et doux et moelleux à l’intérieur. D ’un autre côté, ce n’est peut-être pas la raison.
16.9 Générateurs additifs

Les g é n é r a t e u r s a d d it if s (appelés parfois générateurs de Fibonacci) sontextrême
ment efficaces car ils produisent des mots aléatoiresau lieu de bitsaléatoires [864]. A
eux seuls, ils ne sont pas sûrs, mais ils peuvent être utilisés comme élément de base de
générateurs sûrs.
L ’état initial du générateur est un tableau de mots de n bits (mots de 8, 16 ou 32
bits, ou autre) : X i , X ï , ■- ■, X m. Cet état initial est la clef. Le ie mot produit par le
générateur est donné par :
X t — ( X l—a + X l-b + X t-.c + ••■+ X t—k) modulo 2"
Si les coefficients a,b,c, . . . ,k sont bien choisis, la période de ce générateur est au moins
2n — 1. Une condition nécessaire sur les coefficients est que l’on obtienne un R D R L de
longueur maximale lorsqu’on ne considère que les bits de poids faible.
Par exemple, (55,24,0) est un polynôme primitif d’après le tableau 16.2. Cela implique
que le générateur additif suivant est de longueur maximale :
X t = (X j _ 5 5 + X , - 24) modulo 2"
Cela fonctionne dans ce cas parce que le polynome a trois coefficients non nuls. S’il
en a plus, d ’autres conditions sont requises pour obtenir un générateur de longueur
maximale. Consulter [254] pour les détails.
Fish
F ish est un générateur a d d itif basé sur des techniques utilisées dans le générateur à
réd u ction [197]. Il p rod u it un flux d e m ots d e 32 b its qui peu t être com bin é par ou
7. N ote du traducteur : le ram boutan en français.

16.9 Générateurs additifs 415
exclusif avec un flux de texte en clair pour produire le texte chiffré, ou avec le flux
de texte chiffré pour produire le texte en clair. Lenom vient de « Fibonacci shrinking
generator » qui veut dire générateur à réduction de Fibonacci.
Commencez par prendre deux générateurs additifs. La clef est constituée des états
initiaux de ces générateurs.
A z — { A i - 55 + A i24) modulo 2 32
Bi = 52 + -B j-ig) modulo 2 32
Ces suites sont réduites, par paires, selon le bit de poids faible de Bi : s’il vaut 1 , utilisez
la paire, s’il vaut 0 ignorez la paire. Notons par Cj la suite des mots de A t utilisés et
par Dj la suite des mots de B , utilisés. Ces mots servent par couples, 6 2 , et C 2j + \,
I)2j et D 2} f 1 pour former des couples de mots de 32 bits K 2j et K 2]+i en sortie.
E 2, = C 2j © (D 2j A D 2j + i )
F2j — D 2j + i © (E2j A C 2j+ 1 )
K 2j = E2j © F2j
K 2j+ i = G2j+ i © F2j
Cet algorithme est rapide. Sur un 486 à 33 MHz, une réalisation de Fish en C permet
de chiffrer 15 megaoctets de données par seconde. Malheureusement, il n’est pas sûr ;
une attaque demande un travail de 2 40 opérations environ [46].
Pike
P lK E est une version épurée de F i s h nous venant de Ross A n d e r s o n qui est celui qui
a cassé F ish [46]. Il comprend trois générateurs additifs, ceux-ci par exemple:
Ai = ( Aj _ 5 5 + 2 4 ) modulo 232
Bi = (H ,__57 + B i - 7 ) modulo 232
C i = { C i - 58 + C i_ 19) modulo 232
Pour générer le flux de codons, considérez les bits de retenue des trois additions. S’ils
sont tous les trois égaux (tous des 0, ou tous des 1), opérez un cycle d’horloge sur
les trois générateurs. Si ce n’est pas le cas, n’opérez un cycle d’horloge que sur les
deux générateurs dont les bits de retenue sont égaux. Mémorisez le bit de retenue du
troisième générateur pour la fois suivante La sortie finale est la combinaison par ou
exclusif des sorties des trois générateurs.
PlKE est plus rapide que FlSH puisqu’il faut en moyenne 2,75 étapes par sortie au
lieu de 3. Il est beaucoup trop récent pour inspirer confiance, mais il fait bonne figure
jusqu’ à présent.
Mush
Mush est un générateur à réduction mutuelle. C ’est facile à expliquer [1592], Prenez
deux générateurs additifs A et B . Si le bit de retenue de A est à 1, opérez un cycle
d’horloge sur B . Si le bit de retenue de B est à 1, opérez un cycle d ’horloge sur A .
Opérez un cycle d ’horloge sur A et B et retenez les bits de retenue pour la fois suivante.
La sortie finale est la combinaison par ou exclusif des sorties de A et B.
Les générateurs les plus faciles à utiliser sont ceux de F i s h :
A t = (.4,-55 + A t_ 2 4 ) modulo 232

B , = (£?,_52 + B, _19) modulo 232
En moyenne, il faut trois itérations de générateur pour obtenir un mot en sortie. Si

les coefficients des générateurs additifs sont correctement choisis et sont premiers entre
eux, la suite de sortie aura une période maximale. Je ne connais aucune attaque ayant
réussi, mais sachez que cet algorithme est très récent.
16.10 Gifford
Dabid G i f f o r d a inventé un algorithme de chiffrement en continu et l’a utilisé pour
chiffrer des dépêches par câble dans la région de Boston de 1984 jusqu’à 1988 [610,
609, 611]. L’algorithme a un seul registre de 8 octets : B\,B 2 , ■■■,B-j. La clef est l’état
initial du registre. L ’algorithme fonction en mode O F B ; le texte en clair n ’affecte pas
du tout l’algorithme. (Voir la figure 16.17).
F ig . 16.17 - G if f o r d
Pour générer un codon c,, joignez B 0 et i?2, joignez B 4 et B7 - Multipliez les deux
ensemble pour obtenir un nombre de 32 bits. Le troisième en partant de la gauche est
c,.
Pour mettre à jour le registre, décalez les bits de B t vers la droite de 1 bit en laissant
une copie du bit le plus à gauche en place. Décalez les bits de B 7 vers la gauche de 1
16.11 A lg o r ith m e M 417
en mettant le bit le plus à droite à 0. Combinez par ou exclusif B\ et B 7 ainsi modifiés

et B(j. Décaler le registre, dans son état initial, de un octet vers la droite et placez cet
octet en première position à gauche.
Cet algorithme est resté sûr dînant la durée de son utilisation, mais il fut cassé en 1994
[291]. Il se trouve que le polynôme de rétraction n’est pas primitif et peut-être attaqué
de cette manière.
16.11 Algorithme M
Le nom est du à K n u t h [864]. Il s’agit d’une méthode pour combiner deux flux pseudo
aléatoires de manière à augmenter leur sécurité. La sortie d’un des générateurs sert à
sélectionner une sortie retardée de l’autre de générateur [1006, 1012]. Cela se traduit
en C par :
# d e f in e TAILLE_TAB (8 1 9 2 ) / * p a r e x e m p le - p l u s c ’ e s t g r a n d , m ieu x c a v a u t * /
s t a t i c u n s ig n e d c h a r d e l a y l TAILLE_TAB ] ;
u n s ig n e d c h a r p r n g A ( v o i d ) ;
lo n g p r n g B ( v o i d ) ;
v o id i n i t _ a l g M ( v o i d )
I
lon g i ;
fo r ( i= 0 ; i < TAILLE_TAB ; i+ + )
d e la y li] = prngA C ) ;
} / * in it_a lgM * /
u n s ig n e d c h a r a l g lM ( v o i d )
1
lo n g j , v ;
j = prngB O % TAILLE_TAB ; /* o b t e n t i o n l ’ in d e x d a n s d e l a y l ] */
v = d e la y lj] ; /* o b t e n t io n de l a v a l e u r a r e n v o y e r */
d e la y lj] = prngA O ; /* le r e m p la c e r * /
retu rn ( v ) ;
} / * a lg lM * /
Ceci est solide dans le sens que si prngA était vraiment aléatoire, on ne pourrait rien
apprendre de prngB (et il serait impossible de le cryptanalyser). Il serait possible de
cryptanalyser prgnA seulement si sa sortie était accessible dans le bon ordre, (c’est à
dire si prngB était d ’abord cryptanalysé), et dans le cas contraire, s’il était vraiment
aléatoire, la combinaison serait sûre.
16.12 PKZIP
Roger S C H L A F L Y a conçu l’algorithme de chiffrement intégré dans le programme de
compression P K Z IP . C ’est un algorithme de chiffrement en continu qui chiffre les
418 Chapitre 16 Générateurs de suites aléatuires et chiffrement en continu
données octet par octet. Ceci est au moins l’algorithme de la version 2.04g. Je ne peux
pas me prononcer pour les version ultérieures, mais à moins que cela ne soit annoncé,
vous pouvez supposer qu’elles l’utilisent aussi.
L’algorithme utilise des variables de 32 bit initialisées ainsi :
K 0 = 305419896
K 2 = 591751049
K 2 = 878082192
Il y a une clef K 3 déduite de K 2. Voici l’algorithme (tous les symboles viennent du C) :
Cx = M i ~ K 3
K0 = ct c32(Ko, Mi )
K\ = Ki + (A'o&OxOOOOOOFF)
Ki = Ki * 134775813 + 1
K2 = ct c3 2 {K2, K 1 » 24)
K3 = ((K 2 12) * {{K 2 12)-1)> » 8
La fonction crc32 prend la valeur précédente et un octet, les combine par ou exclusif et
calcule la valeur suivante au moyen du polynôme C R C noté 0xEDB88320. En partique,
on peut pré-calculer un tableau T de 256 nombres et le calcul par crc32 devient :
crc32(a,6) — (a > > 8)~T[(n& OxFF © 6]
Le tableau est pré-calculé selon la définition originelle de crc3 2 :
T[i] = crc32(i,0)
Pour chiffrer un flux de texte en clair, commencez faire passez les octets de la clef
dans l’algorithme pour mettre à jour les clefs. Ignorez le texte chiffré correspondant.
Chiffrez alors le texte en clair octet par octet. Douze octets aléatoires sont acollés au
début du texte en clair, mais cela n’est pas vraiment important. Le déchiffrement se
fait de manière similaire au chiffrement, mis à part qu’il faut prendre Ci à la place de
M i à la deuxième étape de l’algorithme.
Sécurité de PKZIP
Malheureusement, elle n ’est pas extraordinaire. Une attaque a besoin de 40 à 200 octets
de texte en clair connu et prend environ 227 opérations [173]. Vous pouvez la faire en
quelques heures avec votre ordinateur personnel. Si le fichier compressé possède une
entête standard, ce n’est pas un problème d’obtenir le texte en clair. N’utilisez pas le
chiffrement intégré dans P K Z IP .
Chapitre 17
Autres algorithmes de
chiffrement en continu et
générateurs de suites vraiment
aléatoires
17.1 RC4
RC4 est un algorithme de chiffrement en continu à clef de longueur variable développé
en 1987 par Ron R i v e s t pour R S A D a t a S e c u r i t y , In c. Il a été durant sept ans
une marque déposée, et les détails de l’algorithme n’étaient dévoilés qu’après signature
d’un contrat de non divulgation.
En septembre 1994, quelqu’un a envoyé anonymement le code source aux abonnés de la
liste de courrier électronique « Cypherpunks ». Il s’est rapidement répandu tout autour
du monde via les sites ftp d ’iN T E R N E T . Des possesseurs de copies légales de RC4
ont confirmé la compatiblité. R SA D a t a S e c u r i t y , I n c . essaya d ’étouffer l’affaire
en prétendant qu’il s’agissait d’un secret de fabrication bien qu’étant devenu public ;
c’était trop tard. Il a depuis été disséqué et commenté, distribué à des conférences et
enseigné dans les cours de cryptographie.
RC4 est simple à décrire. L ’algorithme fonctionne en mode O FB : le flux de codons
ne dépend pas du texte en clair. Il a une table- S à 8*8 bits: S o , S i , . . . ,S 25 5 - Les Si
forment une permutation des nombres entre 0 et 255, et la permutation dépend de la
clef de longueur variable. Il y a deux compteurs i et j , initialisés à zéro.
Pour générer un octet aléatoire, procéder ainsi :
i = (i + 1) modulo 256
j — (j + Si) modulo 256
Echanger Si et S j .
t = (S i + S j ) modulo 256
K = St
420 Chapitre 17 Autres algorithmes de chiffrement en continu
L ’octet K est combiné par ou exclusif avec le texte en clair pour produire le texte
chiffré ou bien avec le texte chiffré pour produire le texte en clair. Le chiffrement est
rapide, environ 10 fois plus que le DES.
L’initialisation est facile aussi. Commencez avec l’identité : Sa — 0,S\ = 1 ,... ,6 2 5 5 =
255. Remplissez un autre tableau de 256 octets avec la clef, en répétant celle-ci suffi
samment de fois pour combler le tableau : Kq,K\, . . . , K 2ss- Initialisez l’index j à zéro
et effectuez ceci :
Pour i variant de 0 à 255, effectuer :
j — (j + St + K r) modulo 256
Echanger Si et S3.
R SA D SI prétend que l’algorithme est immune aux cryptanalyse différentielle et li

néaire, qu’il n’a pas de cycle court, et qu’il est hautement non linéaire1. La table-S
évolue lentement au cours de l’algorithme: i permet d’assurer que chaque élément
change et j permet assurer que les éléments changent aléatoirement. L’algorithme est
si simple que la plupart des programmeurs peuvent rapidement écrire le code de mé
moire.
Il devrait être possible de généraliser cette idée à des tables-S 1 et à des mots de tailles
plus grandes. La version qui précède est le R C4 à 8 bits. Il n’y a pas de raison de ne pas
définir le R C4 à 16 bits avec une table-S 1 à 16*16 bits (100 kilo-octets de mémoire) et
des mots de 16 bits. Il vous faudrait itérer beaucoup plus de fois l’étape d ’initialisation,
65536 pour suivre la conception actuelle, mais l’algorithme résultant serait plus rapide.
RC4 possède un statut spécial pour l’exportation si la longueur de la clef ne dépasse
pas 40 bits (voir § 13.8). Ce statut spécial n ’a rien à voir avec la confidentialité de
l’algorithme, bien que R SA D SI l’ai laissé sous entendre durant des années. Le nom
est déposé, aussi, toute personne écrivant son propre code doit l’appeler de manière
différente. Divers document internes de la R SA D a t a S e c u r i t y , I n c . n’ont toujours
pas été rendus publics [1333, 1349].
Quel est le marché avec R C 4 ? Il n’y a plus de secret de fabrication, aussi n ’importe
qui peut l ’utiliser. Cependant, R SA D SI poursuivra certainement en justice tous ceux
qui incorporent RC4 sans license à des produits commerciaux. Ils ne gagneront pro
bablement pas, mais il sera moins cher pour une société d ’acheter une license que de
combattre.
RC4 fait partie d'une douzaine de produits commerciaux, tels que Lotus Notes, AOCE
d’ A p p l e , et Oracle Secure SQL. Il est aussi dans la spécification de téléphones modu
laires « Cellular Digital Packet Data » [38].
17.2 SEAL
SEAL est un algorithme de chiffrement en continu efficace sous forme de logiciel conçu
chez IBM par Phyl R o g a w a y et Don C o p p e r s m i t h [1352]. L ’algorithme a été conçu
pour les processeurs 32 bits : pour bien fonctionner, il lui faut des registres de 32 bits
et une mémoire cache de quelques kilo-octets. Au moyen d ’une opération assez lente,
1. Il n’y existe aucun résultat cryptanalytique public. R C 4 peut se trouver dans environ 21700
(256! x 2562) états possibles, un nom bre incomm ensurable.
17.2 SEAL 421
SEAL calcule au préalable un ensemble de tableaux à partir de la clef. Ces tableaux

accélèrent ensuite le chiffrement et le déchiffrement.
Famille de fonctions pseudo-aléatoires

Une particularité nouvelle de SEAL est de ne pas être un algorithme traditionnel
de chiffrement en continu : c ’est une f a m ille d e f o n c t io n s p s e u d o - a lé a t o ir e s .E t a n t
donné une clef k de 160 bits et un mot n de 32 bits, SEA L dilate n jusqu’à une chaîne
k(n) de L bits. L peut prendre n’importe quelle valeur inférieure à 64 kilo-octets.
SEAL est supposé avoir la propriété suivante : si k est pris aléatoirement, alors k{n)
est indistinguable par calcul du résultat d’une fonction aléatoire de L bits appliquée à
n.
L’intérêt pour SEAL d’être une famille de fonctions pseudo-aléatoires est que cela
le rend utile dans des applications où les algorithmes traditionnels de chiffrement en
continu ne le sont pas. Avec la plupart des algorithmes de chiffrement en continu,
vous générez une suite de bits dans une seule direction : sachant la clef et une position
i, le seul moyen de déterminer le ie bit est de générer tous les bits jusqu’au ie . Mais
une famille de fonctions pseudo-aléatoires agit différemment : l’accès à n’importe quelle
position dans le flux de codons est aisée. C ’est très utile.
Imaginez que vous deviez protéger un disque dur. Vous voulez chiffrer chacun des
secteurs de 512 octets. Avec une famille de fonctions pseudo-aléatoires telle que SEAL,
vous pouvez chiffrer le contenu du secteur n en le combinant par ou exclusif avec k(n).
Tout se passe comme si le disque entier était combiné par ou exclusif avec une longue
chaîne pseudo-aléatoire où chaque morceau de cette longue chaîne peut être calculé
sans difficulté.
Une famille de fonctions pseudo-aléatoires simplifie aussi le problème de synchronisa
tion rencontré avec les algorithmes classiques. Supposez que vous deviez chiffrer des
messages envoyés par un canal qui perd parfois des messages. Avec une famille de fonc
tions pseudo-aléatoires, vous pouvez chiffrer avec k le ne message xn que vous envoyez
sous la forme de n suivi de la combinaison par ou exclusif de xn et k(n). Le destinataire
n’a pas besoin de stocker d ’état pour retrouver xn, il n’a pas non plus à s’inquiéter de
la perturbation du processus de déchiffrement par la perte d ’un message.
Description de SEAL
La boucle interne de SEAL est illustrée par la figure 17.1. L ’algorithme repose sur trois
tableaux, R, S et T, dérivés de la clef. L’étape de pré-calcul produit ces trois tableaux
à partir de la clef k au moyen d ’une procédure basée sur SHA (voir § 18.7). Le tableau
T de 2 kilo-octets est une table-S à 9*32 bits.
SEAL utilise aussi quatre registres de 32 bits A, B, C et D dont les valeurs initiales
dépendent de n, R et T. Ces registres sont modifiés au cours de plusieurs itérations,
chacune d’elle comprenant huit rondes. A chaque ronde, 9 bits d’un premier registre
[A, B, C ou D) servent d ’index dans le tableau T. La valeur retirée de T est alors
ajoutée ou combinée par ou exclusif à un deuxième registre. Le premier registre est
décalé circulairement de neuf positions. Dans certaines rondes le second registre (après
décalage) subit des modifications suplémentaires en le combinant par ou exclusif avec
le premier registre ou en le lui ajoutant. Après huit rondes de ce type, A, B , C et D
viennent gonfler le flux de codons, après avoir masqué chacun d ’eux en le combinant
F ig . 17.1 - Boucle interne de SEAL
avec un certain mot de S par addition ou par ou exclusif. L’itération s’achève en

ajoutant à A et C des valeurs suplémentaires dépendantes de n, n i, n2, 'ris, n 4 , selon
la parité du numéro de l’itération.
Les idées importantes de la conception semble être :
1. Utiliser une grande table-S1secrète et dérivée de la clef (T).
2. Alterner des opérations arithmétiques qui ne commutent pas (addition et ou

exclusif).
3. Utiliser un état interne maintenu par l’algorithme qui ne se manifeste pas direc
tement dans le flot de données (les valeurs des n%qui servent à modifier A et C
à la fin de chaque itération).
4. Faire varier la fonction de ronde avec le numéro de la ronde, la fonction d ’itération

avec le numéro d’itération.
SEAL fait appel à environ cinq opérations élémentaires de la machine pour chiffrer un
octet de texte en clair. Il fonctionne à 58 mégaoctets par seconde sur un 486 cadencé
à 50 MHz. C ’est l’algorithme de chiffrement le plus rapide du livre.
D ’un autre côté, SEAL doit pré-calculer ses tableaux internes à partir de la clef. Ces
tableaux occupent en mémoire environ 3 kilo-octets au total et leur calcul requiert à
peu près 200 calculs de SHA. SEAL n’est donc pas adapté aux situations où vous
n’avez pas de temps pour effectuer le pré-calcul sur la clef, ou la mémoire suffisante
pour stocker les tableaux.
17.3 W AKE
Sécurité de SEAL
SEAL est un nouvel algorithme et n’est encore le sujet d’aucune cryptanalyse publiée.
Cela incite à la prudence. Il semble cependant que SEAL est bien pensé. Ses curiosité
ont un sens au bout du compte. Et Don C O P P E R S M IT H est généralement considéré
comme le cryptanalyste le plus intelligent du monde.
Brevets et licenses
SEAL est en cours de brevetage [384]. Quiconque désire se procurer une license pour
utiliser SEAL devrait contacter: Director of Licenses, IBM Corporation, 500
Columbus Ave., Thurnwood, N Y , 10594, États-Unis.
17.3 WAKE
W AK E a été inventé par David W H E E L E R [1591], Il produit un flux de mots de 32
bits qui peut être combiné par ou exclusif avec le texte en clair pour le chiffrement,
ou avec le texte chiffré pour le déchiffrement.
W AKE fonctionne en mode C FB ; le mot précédent de texte chiffré est utilisé pour
produire le codon suivant. Il utilise aussi une table-S1de 256 valeurs de 32 bits. Cette
table-S1vérifie une propriété spéciale : les octets de poids fort des 256 valeurs forment
une permutation de tous les octets possibles et les trois octets de poids faibles sont
aléatoires.
Tout d ’abord, générez les valeurs Si de la table-S1à partir de la clef. Initialisez alors
quatre registre cto, bo, Co et do avec la clef (ou avec un autre clef). Pour générer un
codon K l de 32 bits, appliquez simplement ceci :
Ki dj
Le mot de texte chiffré Ci est obtenu par combinaison par ou exclusif du mot de texte
en clair A4, avec Ki.
Mettez alors à jour les quatre registres :
Gà-j-1 — 7Vd(GEj,dj)
5-i+i — Af(6j ,g j_|_i )
ci+i = M (c i,b i+ 1 )
di+i ■ 4lL(dj,Cj-ri)
La fonction M est donnée par :
M( x, y) = (x + y) » 8 ® S^x+y)2ss
Ceci est illustré par la figure 17.2. L ’opération > > est un décalage à droite et non une
rotation. Les bits de poids faible de x + y sont les entrées de la table-S1. W H E E L E R
propose une procédure pour générer la table-S1, mais elle n’est pas vraiment complète.
N’importe quel algorithme générant des octets aléatoires et une permutation aléatoire
conviendra.
Le principal atout de W A K E est sa rapidité. Cependant il ne résiste pas à une attaque
à texte en clair choisi ou à une attaque à texte chiffré choisi. Il est utilisé dans la version
courante du programme « Dr. Solomon’s Anti-Virus ».
m Chapitre 17 Autres algorithmes de chiffrement en continu
F ig . 17.2 - W A K E
17.4 Registres à décalage à rétroaction avec

retenue
Un registre à décalage à rétroaction avec retenue ou en abrégé R D R R 2, ressemble à

un R D R L . Ils ont tous les eux un registre à décalage et une fonction de rétroaction ; la
différence est qu’un R D R R a aussi un registre de retenue (voir la figure 17.3). Au lieu
de combiner par ou exclusif tous les bits de la séquence de dérivation, ajoutez les bits
et le contenu du registre de retenue ensemble. Le résultat modulo 2 devient le nouveau
bit. Le résultat divisé par 2 devient le nouveau contenu du registre de retenue.
La figure 17.4 présente un exemple de R D R R à 3 bits dérivé au premier et eu deuxième

bit. Sa valeur initiale est 0 0 1 et le registre de retenue contient initialement 0. Le bit
2. N ote du traducteur : en anglais, les registres à décalage à rétroaction avec retenue sont appelés
« feed ba ck w ith c a r r y shzft r e g iste r s » et sont abrégés « F C S R ».
17.J, Registres à décalage à rétroaction avec retenue
Registre à décalage
Som m e m odulo 2 h ae
b,4 b b bl
n bn-l i 2
Somme divisée par 2
F i g . 17.3 Registre à décalage à rétroaction avec retenue
de sortie est le bit le plus à droite du registre.
Registre à décalage Registre de retenue

0 0 1 0
1 0 0 0
0 1 0 0
1 0 1 0
1 1 0 0
1 1 1 0
0 1 1 1
1 0 1 1
0 1 0 1
0 0 1 1
0 0 0 1
1 0 0 0
Notez que l’état interne final (y compris le contenu du registre de retenue) est identique
au second état interne. La suite boucle à partir de ce point et sa période est 10.
Il faut préciser quelques points. Premièrement, le registre de retenue n’est pas un simple
bit ; c’est un nombre. La taille du registre de retenue doit être au moins log2 1 où t est le
nombre de dérivations. Il n’y a que deux dérivations dans l’exemple précédent, aussi le
registre de retenue ne requiert qu’un seul bit. S’il y avait quatre dérivations, le registre
de retenue aurait deux bits, et pourrait valoir 0, 1, 2, ou 3.
Ensuite, le R D R R passe initialement par une séquence transitoire avant de se répéter
périodiquement. Dans l’exemple précédent, un seul état n’est jamais répété. Pour des
R D R R plus grands et plus compliqués, il peut y en avoir plus.
Enfin, la période maximale d ’un R D R R n’est pas 2n — 1, n étant la taille du registre à
décalage. La période maximale est q — 1 où q est l ’e n t ie r d e c o n n e x io n . Ce nombre
identifie la séquence de dérivation, il est donné par :
q — 2qi + 2 2Ç2 + 24Q4 + •■•+ 2nqn — 1

Chapitre 17 Autres algorithmes de chiffrement en continu
Somme modulo 2 Bit de sortie

H h
u3 b_2 b,
ui ►
Somme
Somme divisée par 2
F ig. 17.4 - Un R D R R à 3 bits
(Les q, sont bien numérotés de gauche à droite et valent 1 lorsque le bit correspondant
du registre à décalage est dérivé, 0 sinon.) q doit être premier et admettre 2 comme
racine primitive. On supposera par la suite que q est bien de cette forme.
Dans l’exemple précédent, ç = 2 x 0 + 4 x l + 8 x l - 1 = 11. Et 11 est un nombre
premier admettant 2 comme racine primitive. La période maximale est donc 10.
Tous les états initiaux ne conduisent pas à une période maximale, considérez par
exemple le R D R R précédent avec une valeur initiale de 1 0 1 et le registre de re
tenue à 4.
Registre à décalage Registre de retenue
10 1 4
110 2
111 1
111 1
À partir de là, le registre produit une suite sans fin de un.

Tout état initial appartient à l’une des quatre catégories suivantes. 1°) Il fait partie de
la période maximale. 2°) Il conduit à la période maximale après une séquence initiale
de transition. 3°) Il conduit à une suite infinie de zéros après une éventuelle séquence
initiale de transition. 4°) Il conduit à une suite infinie de un après une éventuelle
séquence initiale de transition.
Il existe une formule mathématique permettant de déterminer ce qu’il adviendra à
partir d’un état initial donné, mais il est beaucoup plus facile de le tester. Faites
fonctionner le R D R R un moment. (Si m est la taille de la mémoire initiale et t le
nombre de dérivations, alors log2 1 + log2 m -I- 1 étapes suffisent.) S’il dégénère en une
suite continue de 1 ou de 0 d ’au moins n bits, où n est la taille du R D R R , ne l’utilisez
pas. Dans le cas contraire, utilisez le. Comme l’état initial d ’un R D R R dépend de la
clef, cela signifie qu’un générateur à base de R D R R aura des clefs faibles.
Le tableau 17.1 rassemble tous les entiers de connexion q inférieurs à 10 000 admettant
2 comme racine primitive. Ils donnent tous une période maximale de q —1. Pour obtenir
17.5 Chiffrement en continu à base de R D R R 427
a séquence de dérivation, il suffit de calculer la représentation binaire de q + 1. Par

exemple, 9949 se traduit par la dérivation des bits 1, 2, 3, 4, 6, 7, 9, 10, et 13 car
9950 = 213 + 210 + 29 + 27 -f 26 + 24 + 23 + 22 + 21.
Le tableau 17.2 rassemble toutes les séquences de dérivation à quatre bit qui donnent
in R D R R de taille maximale pour un registre à décalage de 32, 64, 96 ou 128 bits.
Les quatres valeurs a,b,c,d donnent toujours un nombre premier q dont 2 est une racine
primitive.
q= 2 “ + 2b + 2 e + 2d - 1
Chacune de ces séquences de dérivation permet de construire un R D R R de période

7- 1.
L’idée d’utiliser des R D R R pour la cryptographie est encore très récente; elle est
actuellement défrichée par Andy K l a p p e r et Mark G o r e s k y [845, 846, 656, 844, 847],
Tout comme l’analyse des R D R L est basée sur l’addition des polynômes primitifs
modulo 2, l’analyse des R D R R est basée sur ce que l’on appelle les nombre 2-adiques.
La théorie dépasse largement le cadre de ce livre, mais il semble exister un analogue
2-adique pour chaque chose. Par analogie à la complexité linéaire, on peut définir la
complexité 2-adique. Il y a même un analogue 2-adique de l’algorithme de Berlekamp-
Massey.
17.5 Chiffrement en continu à base de

R D R R
Il n’existe pas d’algorithmes de chiffrement en continu à base de R D R R dans la littéra

ture ; la théorie est encore trop récente. J’en propose quelques uns ici pour faire avancer
les choses. Je me lance dans deux voies différentes : je propose des générateurs à base
de R D R R identiques à ceux présentés avec des R D R L , et je propose des générateurs
utilisant à la fois des R D R R et des R D R L . II est probablement possible d ’évaluer la
sécurité des premiers avec la théorie des nombres 2-adiques; les seconds ne peuvent
pas être analysés avec des techniques algébriques, il est probablement possible de les
analyser indirectement. Dans tous les cas, il est important de choisir des R D R R et des
RDRL dont les périodes soient premières entre elles.
Ceci fait partie de l’avenir. Je ne connais aucune réalisation ou analyse de ces idées.
Attendez quelques années et consultez alors la littérature avant de leur faire confiance.
Générateurs en cascade
Il y a deux façons de mettre des R D R R en cascade dans un générateur :
- Cascade de R D R R . Reprendre la cascade de G o llm an n avec des R D R R au

lieu de R D R L .
- Cascade de R D R L /R D R R . Reprendre la cascade de G ollm an n avec une al

ternance de R D R L et de R D R R .
T ab . 17.1 - Entiers de connexion pour R D R R de période maximale
2 653 1549 2477 3539 4397 5693 6781 7 717 8861

5 659 1571 2531 3547 4451 5701 6803 7757 8 867
11 661 1619 2539 3 557 4483 5 717 6 827 7789 8923
13 677 1621 2549 3571 4493 5741 6829 7829 8933
19 701 1637 2557 3581 4507 5749 6869 7853 8 963
29 709 1667 2579 3613 4517 5779 6883 7877 8971
37 757 1669 2621 3637 4547 5813 6899 7883 9011
53 773 1693 2659 3643 4603 5827 6907 7901 9029
59 787 1733 2677 3659 4621 5843 6917 7907 9 059
61 797 1741 2683 3 677 4637 5851 6947 7933 9173
67 821 1747 2693 3691 4691 5869 6949 7949 9181
83 827 1787 2699 3701 4723 5923 6971 8053 9203
101 829 1861 2707 3709 4 787 5939 7013 8069 9221
107 853 1867 2741 3733 4789 5 987 7019 8093 9 227
131 859 1877 2789 3779 4813 6011 7027 8117 9283
139 877 1901 2 797 3 797 4877 6029 7043 8123 9293
149 883 1907 2803 3803 4933 6053 7069 8 147 9323
163 907 1931 2819 3851 4957 6067 7109 8171 9341
173 941 1949 2837 3853 4973 6101 7187 8179 9349
179 947 1973 2843 3877 4 987 6131 7211 8219 9371
181 1019 1979 2851 3 907 5003 6173 7219 8221 9397
197 1061 1987 2861 3917 5011 6197 7229 8237 9419
211 1091 1997 2909 3923 5051 6203 7237 8243 9421
227 1109 2 027 2939 3931 5059 6211 7243 8269 9 437
269 1117 2029 2957 3947 5 077 6229 7253 8291 9467
293 1123 2053 2963 3989 5099 6269 7283 8293 9491
317 1171 2069 3011 4 003 5 107 6 277 7307 8363 9533
347 1187 2083 3019 4013 5147 6299 7331 8387 9 539
349 1213 2099 3037 4019 5171 6 317 7349 8429 9547
373 1229 2131 3067 4021 5179 6323 7411 8443 9587
379 1237 2141 3083 4091 5189 6373 7451 8 467 9613
389 1259 2213 3 187 4093 5227 6379 7459 8539 9619
419 1277 2221 3203 4099 5261 6389 7477 8563 9629
421 1283 2237 3253 4133 5309 6397 7499 8573 9643
443 1291 2243 3299 4139 5333 6469 7507 8597 9661
461 1301 2267 3307 4157 5 387 6491 7517 8 627 9677
4 67 1307 2269 3323 4219 5443 6547 7523 8669 9733
491 1373 2293 3 347 4229 5477 6619 7541 8 677 9749
509 1381 2309 3371 4243 5483 6637 7547 8693 9803
523 1427 2333 3413 4253 5501 6653 7549 8699 9851
541 1451 2339 3461 4259 5507 6659 7573 8731 9859
547 1453 2357 3 467 4261 5 557 6691 7589 8741 9883
557 1483 2371 3469 4283 5563 6701 7603 8747 9901
563 1493 2389 3491 4 349 5573 6709 7621 8803 9 907
587 1499 2437 3499 4 357 5651 6733 7643 8 819 9923
613 1523 2459 3 517 4363 5659 6763 7669 8821 9941
619 1531 2467 3533 4 373 5683 6779 7691 8 837 9949
Tab. 17.2 - Séquences de dérivation pour R D R R de période maximale
(3 2 .6 .3 .2 ) (6 4 ,2 4 ,1 9 ,2 ) (6 4 ,5 9 ,2 8 ,2 ) (9 6 ,5 5 ,5 3 ,2 )
(3 2 .7 .5 .2 ) (6 4 ,2 5 ,3 ,2 ) (6 4 ,5 9 ,3 8 ,2 ) (9 6 ,5 6 ,9 ,2 )
(3 2 .8 .3 .2 ) (6 4 ,2 5 ,4 ,2 ) (6 4 ,5 9 ,4 4 ,2 ) (9 6 ,5 6 ,5 1 ,2 )
(3 2 .1 3 .8 .2 ) (6 4 ,2 5 ,1 1 ,2 ) (6 4 ,6 0 ,4 9 ,2 ) (9 6 ,5 7 ,3 ,2 )
(3 2 .1 3 .1 2 .2 ) (6 4 ,2 5 ,1 9 ,2 ) (6 4 ,6 1 ,5 1 ,2 ) (9 6 ,5 7 ,1 7 ,2 )
(3 2 .1 5 .6 .2 ) (6 4 ,2 7 ,5 ,2 ) (6 4 ,6 3 ,8 ,2 ) (9 6 ,5 7 ,4 7 ,2 )
(3 2 .1 6 .2 .1 ) (6 4 ,2 7 ,1 6 ,2 ) (6 4 ,6 3 ,1 3 ,2 ) (9 6 ,5 8 ,3 5 ,2 )
(3 2 .1 6 .3 .2 ) (6 4 ,2 7 ,2 2 ,2 ) (6 4 ,6 3 ,6 1 ,2 ) (9 6 ,5 9 ,4 6 ,2 )
(3 2 .1 6 .5 .2 ) (6 4 ,2 8 ,1 9 ,2 ) (9 6 ,6 0 ,2 9 ,2 )
(3 2 .1 7 .5 .2 ) (6 4 ,2 8 ,2 5 ,2 ) (9 6 ,1 5 ,5 ,2 ) (9 6 ,6 0 ,4 1 ,2 )
(3 2 .1 9 .2 .1 ) (6 4 ,2 9 ,1 6 ,2 ) (9 6 ,2 1 ,1 7 ,2 ) (9 6 ,6 0 ,4 5 ,2 )
(3 2 .1 9 .5 .2 ) (6 4 ,2 9 ,2 8 ,2 ) (9 6 ,2 5 ,1 9 ,2 ) (9 6 ,6 1 ,1 7 ,2 )
(3 2 .1 9 .9 .2 ) (6 4 ,3 1 ,1 2 ,2 ) (9 6 ,2 5 ,2 0 ,2 ) (9 6 ,6 3 ,2 0 ,2 )
(3 2 .1 9 .1 2 .2 ) (6 4 ,3 2 ,2 1 ,2 ) (9 6 ,2 9 ,1 5 ,2 ) (9 6 ,6 5 ,1 2 ,2 )
(3 2 .1 9 .1 7 .2 ) (6 4 ,3 5 ,2 9 ,2 ) (9 6 ,2 9 ,1 7 ,2 ) (9 6 ,6 5 ,3 9 ,2 )
(3 2 .2 0 .1 7 .2 ) (6 4 ,3 6 ,7 ,2 ) (9 6 ,3 0 ,3 ,2 ) (9 6 ,6 5 ,5 1 ,2 )
(3 2 .2 1 .9 .2 ) (6 4 ,3 7 ,2 ,1 ) (9 6 ,3 2 ,2 1 ,2 ) (9 6 ,6 7 ,5 ,2 )
(3 2 .2 1 .1 5 .2 ) (6 4 ,3 7 ,1 1 ,2 ) (9 6 ,3 2 ,2 7 ,2 ) (9 6 ,6 7 ,2 5 ,2 )
(3 2 .2 3 .8 .2 ) (6 4 ,3 9 ,4 ,2 ) (9 6 ,3 3 ,5 ,2 ) (9 6 ,6 7 ,3 4 ,2 )
(3 2 .2 3 .2 1 .2 ) (6 4 ,3 9 ,2 5 ,2 ) (9 6 ,3 5 ,1 7 ,2 ) (9 6 ,6 8 ,5 ,2 )
(3 2 .2 5 .5 .2 ) (6 4 ,4 1 ,5 ,2 ) (9 6 ,3 5 ,3 3 ,2 ) (9 6 ,6 8 ,1 9 ,2 )
(3 2 .2 5 .1 2 .2 ) (6 4 ,4 1 ,1 1 ,2 ) (9 6 ,3 9 ,2 1 ,2 ) (9 6 ,6 9 ,1 7 ,2 )
(3 2 .2 7 .2 5 .2 ) (6 4 ,4 1 ,2 7 ,2 ) (9 6 ,4 0 ,2 5 ,2 ) (9 6 ,6 9 ,3 6 ,2 )
(3 2 .2 9 .1 9 .2 ) (6 4 ,4 3 ,2 1 ,2 ) (9 6 ,4 1 ,1 2 ,2 ) (9 6 ,7 0 ,2 3 ,2 )
(3 2 .2 9 .2 0 .2 ) (6 4 ,4 3 ,2 8 ,2 ) (9 6 ,4 1 ,2 7 ,2 ) (9 6 ,7 1 ,6 ,2 )
(3 2 .3 0 .3 .2 ) (6 4 ,4 5 ,2 8 ,2 ) (9 6 ,4 1 ,3 5 ,2 ) (9 6 ,7 1 ,4 0 ,2 )
(3 2 .3 0 .7 .2 ) (6 4 ,4 5 ,4 1 ,2 ) (9 6 ,4 2 ,3 5 ,2 ) (9 6 ,7 2 ,5 3 ,2 )
(3 2 .3 1 .5 .2 ) (6 4 ,4 7 ,5 ,2 ) (9 6 ,4 3 ,1 4 ,2 ) (9 6 ,7 3 ,3 2 ,2 )
(3 2 .3 1 .9 .2 ) (6 4 ,4 7 ,2 1 ,2 ) (9 6 ,4 4 ,2 3 ,2 ) (9 6 ,7 7 ,2 7 ,2 )
(3 2 .3 1 .3 0 .2 ) (6 4 ,4 7 ,3 0 ,2 ) (9 6 ,4 5 ,4 1 ,2 ) (9 6 ,7 7 ,3 1 ,2 )
(6 4 ,4 9 ,1 9 ,2 ) (9 6 ,4 7 ,3 6 ,2 ) (9 6 ,7 7 ,3 2 ,2 )
(6 4 .3 .2 .1 ) (6 4 ,4 9 ,2 0 ,2 ) (9 6 ,4 9 ,3 1 ,2 ) (9 6 ,7 7 ,3 3 ,2 )
(6 4 .1 4 .3 .2 ) (6 4 ,5 2 ,2 9 ,2 ) (9 6 ,5 1 ,3 0 ,2 ) (9 6 ,7 7 ,7 1 ,2 )
(6 4 .1 5 .8 .2 ) (6 4 ,5 3 ,8 ,2 ) (9 6 ,5 3 ,1 7 ,2 ) (9 6 ,7 8 ,3 9 ,2 )
(6 4 .1 7 .2 .1 ) (6 4 ,5 3 ,4 3 ,2 ) (9 6 ,5 3 ,1 9 ,2 ) (9 6 ,7 9 ,4 ,2 )
(6 4 .1 7 .9 .2 ) (6 4 ,5 6 ,3 9 ,2 ) (9 6 ,5 3 ,3 2 ,2 ) (9 6 ,8 1 ,8 0 ,2 )
(6 4 .1 7 .1 6 .2 ) (6 4 ,5 6 ,4 5 ,2 ) (9 6 ,5 3 ,4 8 ,2 ) (9 6 ,8 3 ,1 4 ,2 )
(6 4 ,1 9 ,2 ,1 ) (6 4 ,5 9 ,5 ,2 ) (9 6 ,5 4 ,1 5 ,2 ) (9 6 ,8 3 ,2 6 ,2 )
(6 4 .1 9 .1 8 .2 ) (6 4 ,5 9 ,8 ,2 ) (9 6 ,5 5 ,4 4 ,2 ) (9 6 ,8 3 ,5 4 ,2 )
(9 6 .8 3 .6 0 .2 ) (1 2 8 ,3 1 ,2 5 ,2 ) (1 2 8 ,8 1 ,5 5 ,2 ) (1 2 8 ,1 0 5 ,1 1 ,2 )
(9 6 .8 3 .6 5 .2 ) (1 2 8 ,3 3 ,2 1 ,2 ) (1 2 8 ,8 2 ,6 7 ,2 ) (1 2 8 ,1 0 5 ,3 1 ,2 )
(9 6 .8 3 .7 8 .2 ) (1 2 8 ,3 5 ,2 2 ,2 ) (1 2 8 ,8 3 ,6 0 ,2 ) (1 2 8 ,1 0 5 ,4 8 ,2 )
(9 6 .8 4 .6 5 .2 ) (1 2 8 ,3 7 ,8 ,2 ) (1 2 8 ,8 3 ,6 1 ,2 ) (1 2 8 ,1 0 7 ,4 0 ,2 )
(9 6 .8 5 .1 7 .2 ) (1 2 8 ,4 1 ,1 2 ,2 ) (1 2 8 ,8 3 ,7 7 ,2 ) (1 2 8 ,1 0 7 ,6 2 ,2 )
(9 6 .8 5 .3 1 .2 ) (1 2 8 ,4 2 ,3 5 ,2 ) (1 2 8 ,8 4 ,1 5 ,2 ) (1 2 8 ,1 0 7 ,1 0 2 ,2 )
(9 6 .8 5 .7 6 .2 ) (1 2 8 ,4 3 ,2 5 ,2 ) (1 2 8 ,8 4 ,4 3 ,2 ) (1 2 8 ,1 0 8 ,3 5 ,2 )
(9 6 .8 5 .7 9 .2 ) (1 2 8 ,4 3 ,4 2 ,2 ) (1 2 8 ,8 5 ,6 3 ,2 ) (1 2 8 ,1 0 8 ,7 3 ,2 )
(9 6 .8 6 .3 9 .2 ) (1 2 8 ,4 5 ,1 7 ,2 ) (1 2 8 ,8 7 ,5 7 ,2 ) (1 2 8 ,1 0 8 ,7 5 ,2 )
(9 6 .8 6 .7 1 .2 ) (1 2 8 ,4 5 ,2 7 ,2 ) (1 2 8 ,8 7 ,8 1 ,2 ) (1 2 8 ,1 0 8 ,8 9 ,2 )
T ab . 17.2 - Séquences de dérivation pour R D R R de période maximale (suite)
(9 6 .8 7 .9 .2 ) (1 2 8 ,4 9 ,9 ,2 ) (1 2 8 ,8 9 ,8 1 ,2 ) (1 2 8 ,1 0 9 ,1 1 ,2 )
(9 6 .8 7 .4 4 .2 ) (1 2 8 ,5 1 ,9 ,2 ) (1 2 8 ,9 0 ,4 3 ,2 ) (1 2 8 ,1 0 9 ,1 0 8 ,2 )
(9 6 .8 7 .4 5 .2 ) (1 2 8 ,5 4 ,5 1 ,2 ) (1 2 8 ,9 1 ,9 ,2 ) (1 2 8 ,1 1 0 ,2 3 ,2 )
(9 6 .8 8 .1 9 .2 ) (1 2 8 ,5 5 ,4 5 ,2 ) (1 2 8 ,9 1 ,1 3 ,2 ) (1 2 8 ,1 1 1 ,6 1 ,2 )
(9 6 .8 8 .3 5 .2 ) (1 2 8 ,5 6 ,1 5 ,2 ) (1 2 8 ,9 1 ,4 4 ,2 ) (1 2 8 ,1 1 3 ,5 9 ,2 )
(9 6 .8 8 .4 3 .2 ) (1 2 8 ,5 6 ,1 9 ,2 ) (1 2 8 ,9 2 ,3 5 ,2 ) (1 2 8 ,1 1 4 ,8 3 ,2 )
(9 6 .8 8 .7 9 .2 ) (1 2 8 ,5 6 ,5 5 ,2 ) (1 2 8 ,9 5 ,9 4 ,2 ) (1 2 8 ,1 1 5 ,7 3 ,2 )
(9 6 .8 9 .3 5 .2 ) (1 2 8 ,5 7 ,2 1 ,2 ) (1 2 8 ,9 6 ,2 3 ,2 ) (1 2 8 ,1 1 7 ,1 0 5 ,2 )
(9 6 .8 9 .5 1 .2 ) (1 2 8 ,5 7 ,3 7 ,2 ) (1 2 8 ,9 6 ,6 1 ,2 ) (1 2 8 ,1 1 9 ,3 0 ,2 )
(9 6 .8 9 .6 9 .2 ) (1 2 8 ,5 9 ,2 9 ,2 ) (1 2 8 ,9 7 ,2 5 ,2 ) (1 2 8 ,1 1 9 ,1 0 1 ,2 )
(9 6 .8 9 .8 7 .2 ) (1 2 8 ,5 9 ,4 9 ,2 ) (1 2 8 ,9 7 ,6 8 ,2 ) (1 2 8 ,1 2 0 ,9 ,2 )
(9 6 .9 2 .5 1 .2 ) (1 2 8 ,6 0 ,5 7 ,2 ) (1 2 8 ,9 7 ,7 2 ,2 ) (1 2 8 ,1 2 0 ,2 7 ,2 )
(9 6 .9 2 .7 1 .2 ) (1 2 8 ,6 1 ,9 ,2 ) (1 2 8 ,9 7 ,7 5 ,2 ) (1 2 8 ,1 2 0 ,3 7 ,2 )
(9 6 .9 3 .3 2 .2 ) (1 2 8 ,6 1 ,2 3 ,2 ) (1 2 8 ,9 9 ,1 3 ,2 ) (1 2 8 ,1 2 0 ,4 1 ,2 )
(9 6 .9 3 .3 9 .2 ) (1 2 8 ,6 1 ,5 2 ,2 ) (1 2 8 ,9 9 ,1 4 ,2 ) (1 2 8 ,1 2 0 ,7 9 ,2 )
(9 6 .9 4 .3 5 .2 ) (1 2 8 ,6 3 ,4 0 ,2 ) (1 2 8 ,9 9 ,2 6 ,2 ) (1 2 8 ,1 2 0 ,8 1 ,2 )
(9 6 .9 5 .4 .2 ) (1 2 8 ,6 3 ,6 2 ,2 ) (1 2 8 ,9 9 ,5 4 ,2 ) (1 2 8 ,1 2 1 ,5 ,2 )
(9 6 .9 5 .1 6 .2 ) (1 2 8 ,6 7 ,4 1 ,2 ) (1 2 8 ,9 9 ,5 6 ,2 ) (1 2 8 ,1 2 1 ,6 7 ,2 )
(9 6 .9 5 .3 2 .2 ) (1 2 8 ,6 9 ,3 3 ,2 ) (1 2 8 ,9 9 ,7 8 ,2 ) (1 2 8 ,1 2 1 ,9 5 ,2 )
(9 6 .9 5 .4 4 .2 ) (1 2 8 ,7 1 ,5 3 ,2 ) (1 2 8 ,1 0 0 ,1 3 ,2 ) (1 2 8 ,1 2 1 ,9 6 ,2 )
(9 6 .9 5 .4 5 .2 ) (1 2 8 ,7 2 ,1 5 ,2 ) (1 2 8 ,1 0 0 ,3 9 ,2 ) (1 2 8 ,1 2 3 ,4 0 ,2 )
(1 2 8 ,7 2 ,4 1 ,2 ) (1 2 8 ,1 0 1 ,4 4 ,2 ) (1 2 8 ,1 2 3 ,7 8 ,2 )
(1 2 8 .5 .4 .2 ) (1 2 8 ,7 3 ,5 ,2 ) (1 2 8 ,1 0 1 ,9 7 ,2 ) (1 2 8 ,1 2 4 ,4 1 ,2 )
(1 2 8 .1 5 .4 .2 ) (1 2 8 ,7 3 ,6 5 ,2 ) (1 2 8 ,1 0 3 ,4 6 ,2 ) (1 2 8 ,1 2 4 ,6 9 ,2 )
(1 2 8 .2 1 .1 9 .2 ) (1 2 8 ,7 3 ,6 7 ,2 ) (1 2 8 ,1 0 4 ,1 3 ,2 ) (1 2 8 ,1 2 4 ,8 1 ,2 )
(1 2 8 .2 5 .5 .2 ) (1 2 8 ,7 5 ,1 3 ,2 ) (1 2 8 ,1 0 4 ,1 9 ,2 ) (1 2 8 ,1 2 5 ,3 3 ,2 )
(1 2 8 .2 6 .1 1 .2 ) (1 2 8 ,8 0 ,3 9 ,2 ) (1 2 8 ,1 0 4 ,3 5 ,2 ) (1 2 8 ,1 2 5 ,4 3 ,2 )
(1 2 8 .2 7 .2 5 .2 ) (1 2 8 ,8 0 ,5 3 ,2 ) (1 2 8 ,1 0 5 ,7 ,2 ) (1 2 8 ,1 2 7 ,1 2 1 ,2 )
Générateurs à combinaison de R D RR
Ces générateurs utilisent un nombre variable de R D R L et de R D R R , et toute une
variété de fonctions pour les combiner entre eux. L ’opération de ou exclusif détruit les
propriétés algébriques des R D R R , aussi, il est sensé de les utiliser pour combiner. Le
générateur, illustré par la ligure 17.5, utilise un nombre variable de R D R R . Sa sortie
est la combinaison par ou exclusif des sorties des R D R R .
Voici générateurs du même type :
- Générateur R D R R équitable. Tous les registres sont des R D R R combinés par

ou exclusif.
— Générateur R D R L /R D R R équitable. Les registres sont un mélange de R D RL

et de R D R R combinés par ou exclusif.
Générateur R D R R à seuil. Tous les registres sont des R D R R combinés selon la

majorité.
Générateur R D R L /R D R R à seuil. Les registres sont un mélange de R D R L et

de R D R R combinés selon la majorité
F i g . 17.5 - Combinaison de générateurs
- Générateur R D R R sommatoire. Tous Les registres sont des R D R R combinés par

addition avec retenue.
- Générateur R D R L /R D R R sommatoire. Les registres sont un mélange de R D R L

et de R D R R combinés par addition avec retenue.
Cascade de R D R L /R D R R sommatoire/équitable
La théorie dit que l’addition avec retenue détruit les propriétés algébriques des R D R L
et que l’opération de ou exclusif détruit celles des R D R R . Ce générateur combine ces
idées, telles qu’elles sont utilisées dans le générateur R D R L /R D R R sommatoire et le
générateur R D R L /R D R R équitable, avec la cascade de G o l l m a n n .
Le générateur est une série de tableaux de registres où l’horloge de chaque tableau est
contrôlée par la sortie du tableau précédent. La figure 17.6 illustre une couche de ce
générateur. Après avoir opéré un cycle d ’horloge sur un premier tableau de R D R L , les
résultats sont combinés par addition avec retenue. Si le résultat de cette combinaison
est 1, alors on opère un cycle d’horloge sur le tableau suivant, qui composé de R D R R ,
et les sorties de ces R D R R sont combinées par ou exclusif. Si le résultat de la première
combinaison est 0, le tableau de R D R R n’est pas actionné et le résultat est seulement
ajouté à la retenue de la ronde précédente. Si le résultat de la deuxième combinaison
est 1, alors le troisième tableau est actionné, et ainsi de suite.
Ce générateur utilise beaucoup de registres n par m où n est le nombre de couches et
m le nombre de registre par couche. Je recommande n = 10 et m ~ 5.
Générateurs à signal d’arrêt alterné

Ces générateurs sont des générateurs à signal d’arrêt avec des R D R R à la place de
certains R D R L . On peut remplacer de plus l’opération de ou exclusif par une autre
fonction de combinaison telle que l’addition avec retenue (voir la figure 17.7).
F ig . 17.6 - Mixture de générateurs
- Générateur R D R R à signal d ’arrêt. Les registres 1, 2 et 3 sont des R D RR. La

fonction de combinaison est l’opération de ou exclusif.
- Générateur R D R R /R D R L à signal d’arrêt. Le registre 1 est un R D R R , les

registres 2 et 3 sont des R D R L . La fonction de combinaison est l’addition avec
retenue.
- Générateur R D R L /R D R R à signal d’arrêt. Le registres 1 est un R D R L, les

registres 2 et 3 sont des R D R R . La fonction de combinaison est l’opération de
ou exclusif.
F i g . 1 7 .7 - Générateurs à signal d’arrêt alterné

17 6 Registres à décalage à rétroaction non linéaire
Générateurs à réduction
Il y a quatre types principaux de générateurs à réduction utilisant des R D R R :
- Générateur R D R R à réduction. Un générateur à réduction conventionnel avec

des R D R R à la place des R D R L .
- Générateur R D R R /R D R L à réduction. Un générateur à réduction avec un

R D R L réduisant un R D R R .
- Générateur R D R L /R D R R à réduction. Un générateur à réduction avec un

R D R R réduisant un R D R L .
- Générateur R D R R à auto-réduction. Un générateur à auto-réduction avec un

R D R R à la place du R D R L .
17.6 Registres à décalage à rétroaction non

linéaire
Il est facile d ’imaginer des séquences de rétroaction plus compliquées que celles des
RDRL et des R D R R . Le problème est qu’il n’existe pas de théorie mathématique
permettant de les analyser. Vous obtiendrez quelque chose, mais Dieu sait quoi. En
particulier, voici quelques problèmes susceptibles d’êtres rencontrés avec les registres à
décalage à rétroaction non linéaire :
- La suite de sortie risque d ’être biaisée, par exemple si elle contient plus de un
que de zéros.
- La période maximale peut s’avérer plus faible que prévu.
- La période de la suite de sortie peut différer pour des valeurs de départ distinctes.
- La suite peut paraître aléatoire pendant un temps, puis se coincer sur la même
valeur. (Il est facile d ’éviter cela en combinant par ou exclusif la fonction non
linéaire avec le bit le plus à droite.)
Le bon côté de l’absence de théorie pour analyser la sécurité des registres à décalage
à rétroaction non linéaire est qu’il existe peu d ’outils de cryptanalyse des algorithmes
de chiffrement qui les utilisent. On peut utiliser les registres à décalage à rétroaction
non linéaire pour chiffrer en continu, mais il faut être prudent.
Dans un registre à décalage à rétroaction non linéaire, la fonction de rétroaction peut
être ce que vous voulez (voir la figure 17.8).
La figure 17.9 illustre un registre à décalage utilisant la fonction de rétroaction suivante :
le nouveau bit est à égal au produit du premier et du troisième bit. Init.ialisé avec la
valeur 110, il produira la suite d’états internes suivante:
110
0 11
10 1
0 10
0 0 1
0 0 0
0 0 0
Et ainsi de suite.
La suite de sortie est la chaîne des bits les moins significatifs :
0 1 1 0 1 0 0 0 0 0 0 0 ________
Ce n’est pas très utile.

Cela peut être pire. Initialisé avec 100, il produit les états 010, 001, et boucle à jamais
sur 000. Si la valeur initiale est 111, il se répétera à jamais depuis le début.
Il existe quelques travaux sur le calcul de la complexité linéaire du produit de deux
R D R L [1652, 728, 1366, 632, 660, 661]. Une construction s’appuyant sur le produit de
R D R L dans un corps de caractéristique impaire [315] s’est avérée peu sûre [843].
F ig . 17.9 - Un registre à décalage à rétroaction non linéaire (probablement pas sûr)

17.7 Autres algorithmes de chiffrement en continu 435
17.7 Autres algorithmes de chiffrement en

continu
Beaucoup d ’autres algorithmes de chiffrement en continu sont apparus dans la littéra
ture ça et là. En voici quelques uns.
Générateur de Pless
Ce générateur est conçu autour des possibilités des bascules bistables JK [1260]. Il
consiste en huit R D R L qui commandent quatre bascules bistables JK. Chaque bascule
bistable agit comme un combinateur non linéaire pour deux des R D R L . Pour éviter le
problème hé au fait que la connaissance de la sortie d’une bascule identifie à la fois la
source et la valeur du codon suivant, à chaque impulsion d’horloge, les sorties de trois
des quatre bascules sont ignorées. Les sorties sont ensuite mélangées pour produire le
flux de codons final.
Cet algorithme a été cryptanalysé par l’attaque indépendante de chacune des quatre
bascules [1358]. De plus, combiner des bascules bistables JK est cryptographiquement
faible et les générateurs de ce type tombent sous le coup des attaques par corréla
tion [1457].
Générateur à base d’automates cellulaires

Dans [1611, 1610], Steve W o l f r a m propose d ’utiliser un automate cellulaire unidi-
mensionnel comme G PASCS. Une description du mécanisme des automates cellulaires
dépasse le cadre de cet ouvrage mais, en bref, le générateur de W o l f r a m consiste en
un vecteur de bits a±, ü2 , ..., ük, —, an et une fonction de mise à jour :
a'k ~ ak-\ © (d-k V Ofc+l).
Le bit est extrait d ’une des valeurs ; peu importe laquelle.

Le comportement de ce générateur a une apparence aléatoire. Toutefois, il existe une
attaque à texte en clair connu contre ce type de générateurs [1060]. Cette attaque
marche sur un PC avec des valeurs de n jusqu’à 500 bits. De plus, Paul B a r d e l l a
prouvé que la sortie d’un automate cellulaire est identique à la sortie d ’un registre à
décalage à rétroaction linéaire, et qu’il n’offrait donc pas plus de sécurité [90].
Générateur 1/p
Ce générateur fut proposé et ensuite cryptanalysé dans [200]. Si l’état interne du gé
nérateur à l’instant t est donné par x t, alors :
xt+i = bx, mod p .
La sortie du générateur est donnée par le bit le moins significatif de x t div p, où

« div » est la division entière tronquée. Pour une période maximale, les constantes b et
p doivent être choisies telles que p soit premier et b soit une racine primitive modulo
p. Mal heureusement, ce générateur n’est pas sûr du tou t3.
3. Notez que pou r b = 2, un R D R R d oté d ’un entier de connexion valant p sortira cette suite de
bits dans l’ordre inverse.
crypt(l)
L’algorithme de chiffrement original d ’U N IX, C R Y P T ( l) , est un chiffrement en continu
basé sur la même technologie que P E n i g m a . Il utilise un seul tambour de 256 éléments
et un réflecteur Le tambour et le réflecteur sont tous deux engendrés à partir de la clef.
Cet algorithme est nettement plus simple que P E n i g m a allemand de la Seconde Guerre
mondiale et, pour un cryptanalyste doué, il est très facile à casser [1578, 1310]. Un
programme U N IX du domaine public, appelé « Crypt Breakers Workbench » (CBW),
peut être utilisé pour casser des fichiers chiffrés avec C R Y P T ( l) .
Autres schémas
Il existe aussi un générateur basé sur le problème des empilements (voir § 19.2) [1365].
C R Y P T O -L E G G O n’est pas sûr. Joan D a e m e n a développé S u b S t r e a m , J a m et
S t e p R i g h t U p [405] ; ils sont trop récents pour être commentés. Beaucoup d’autres
algorithmes sont décrits dans la litérature, et davantage encore gardé secrets et incor
porés à des équipements.
17.8 Approche par la théorie des systèmes

En pratique, la conception d ’algorithmes de chiffrement en continu ressemble beau
coup à la conception d ’algorithmes de chiffrement par blocs. Elle implique davantage
de théories mathématiques, mais au bout du compte, un cryptographe propose un
algorithme et essaye ensuite de le cryptanalyser.
Selon Rainer R u e p p e l , il y a quatre approches différentes de la construction d ’algo
rithmes de chiffrement en continu [1363, 1364] :
- L’approche par la théorie des systèmes. Elle consiste à s’assurer que chaque
conception pose un problème difficile et inconnu au cryptanalyste, en utilisant
un ensemble de principes et de critères fondamentaux de conception
- L’approche par la théorie de l’information. Il s’agit de masquer le plus possible

le texte en clair au cryptanalyste. Peu importe la somme de travail qu’il mettra
en jeu, il n’obtiendra jamais une seule solution.
L’approche par la théorie de la complexité. Elle consiste à baser le cryptosys

tème sur, ou à le rendre équivalent à, un problème connu et difficile tel que la
factorisation ou le calcul de logarithmes discrets.
- L’approche par recherche de l’aléatoire. Il s’agit de générer un problème trop

gros pour être résolu en forçant le cryptanalyste à examiner beaucoup de données
inutiles dans ses tentatives de cryptanalyse.
Ces approches différent par les hypothèses faites sur les capacités du cryptanalyste,
la définition d’une cryptanalyse réussie, et la notion de sécurité. La plupart des re
cherches dans ce domaine sont théoriques, mais il existe quelques bons algorithmes de
chiffrement en continu parmi ceux qui sont impraticables.
L’approche par la théorie des système est celle qui a été utilisée pour tous les al
gorithmes de chiffrement en continu décrits précédemment ; elle est à l’origine de la
17.9 Approche par la théorie de la complexité
plupart des algorithmes qui sont réalisables en pratique. Un cryptographe conçoit des
générateurs de codons dont on peut tester les propriétés de sécurité— période, distri
bution des motifs de bits, complexité linéaire, et ainsi de suite— et non des algorithmes
basés sur des théories mathématiques. Le cryptographe essaye aussi plusieurs tech
niques cryptographiques contre ces générateurs et s’assure qu’ils leur résistent.
Au fil des années, cette approche a abouti à un ensemble de critères de conception
pour les algorithmes de chiffrement en continu [1438, 106, 1359, 1259]. R u e p p e l les a
étudié dans [1364] où il a détaillé les théories sous-jacentes.
- Période longue, pas de répétitions.
Critères de complexité linéaire : grande complexité linéaire, profil de complexité

linéaire, complexité linéaire locale, et ainsi de suite.
- Critères statistiques tels que les distributions idéales de fc-uplets.
- Confusion : chaque bit des codons doit provenir d’une transformation complexe
de tous les bits de la clef ou de la plupart d ’entre eux.
- Diffusion: les redondances dans les sous-structures doivent se dissiper dans les
statistiques à grande échelle.
- Critères de non linéarité pour les fonctions booléennes comme l’immunité à la

corrélation d’ordre m, la distance aux fonctions linéaires, le critère d ’avalanche,
et ainsi de suite.
Cette liste ne se restreint aux algorithmes conçus avec l’approche par la théorie des
systèmes ; elle est valable pour tous les algorithmes de chiffrement en continu. Elle
est même valable pour les algorithmes de chiffrement par blocs. Le point important
avec l’approche par la théorie des systèmes est que les algorithmes sont conçus pour
directement satisfaire ces buts.
Le problème majeur avec ces cryptosystèmes est qu’on ne rien prouver à propos de leur
sécurité ; il n’a jamais été prouvé que ces critères de conception soient nécessaires ou
suffisants à la sécurité. Un générateur de codons peut satisfaire tous ces principes de
conception et s’avérer malgré tout peu sûr. Un autre peut s’avérer sûr. Il reste quelque
chose de magique dans le procédé.
D’un autre côté, casser chacun de ces générateurs de codons constitue un problème
différent pour le cryptanalyste. S’il existe assez de générateurs, le cryptanalyste n’a
peut être pas intérêt à essayer de casser chacun d’eux. Il obtiendra peut être plus de
gloire et de renommée en trouvant de meilleurs moyens de factoriser les grands nombres
ou de calculer les logarithmes discrets.
17.9 Approche par la théorie de la com

plexité
R u e p p e l a aussi détaillé une approche de la conception d’algorithmes de chiffrement
en continu basée sur la théorie de la complexité. Ici, le cryptographe essaie d’utiliser
la théorie de la complexité pour prouver que ses générateurs sont sûrs. De ce fait, ces
générateurs ont tendance à être plus compliqués, ils sont basés sur le même type de
problèmes que nous avons déjà vus pour la cryptographie à clef publique. Et, tout
comme la cryptographie à clef publique, ils ont tendance à être lents et peu commodes.
Générateur pseudo-aléatoire de nombres de S h a m i r

Sham i r utilise l’algorithme R S A comme générateur pseudo-aléatoire de nombres
[1424]. Bien que S h a m i r ait montré que prédire la sortie du générateur pseudo-aléatoire
de nombres est équivalent à casser R SA , des biais potentiels dans la sortie ont été dé
crits dans [1406, 206].
Générateur de B l u m - M i c a l i
La sécurité de ce générateur dépend de la difficulté de calculer des logarithmes dis
crets [206]. Soit g un nombre premier et p un nombre premier impair. Un codon, Xo,
démarre le processus :
Xi+i — gx' mod p.
La sortie du générateur vaut 1 si x l < (p — l)/2 , et 0 sinon.

Si p est grand assez pour que le calcul de logarithmes discrets modulo p soit infai
sable, alors le générateur est sûr. Des résultats théoriques supplémentaires sont décrits
dans [1629, 996, 995, 1247, 896, 808].
RSA
Le générateur R SA [36, 37] est une variante de [206], Les paramètres initiaux sont N , le
produit de deux grands nombres premiers p et ç, un entier e premier avec (p ~ l ) ( ç —1),
et un germe aléatoire Xo inférieur à N :
Xi+ 1 = xf modulo N.
La sortie du générateur est le bit le moins significatif de xt. La sécurité de ce générateur

est basée sur la difficulté de casser le R SA . Si N est assez grand, alors le générateur
est sûr. Vous trouverez d’avantage de théorie dans [1571, 1572, 1573, 34, 358].
Blum Blum Shub

Actuellement, le générateur le plus simple et le plus efficace est appelé le générateur
B l u m B l u m S h u b d ’après les noms de ses inventeurs. Nous utiliserons l’abréviation
BBS, bien que de temps à autre il soit appelé « générateur à résidu quadratique » [200].
La théorie sous-jacente au générateur BBS est liée aux résidus quadratiques modulo
n (voir § 11.3). Voici comment il fonctionne:
Trouvez deux grands nombres premiers p et g qui soient congrus à 3 modulo 4. Le
produit de ces nombres n = p x q est un entier de B l u m . Choisissez un autre entier
aléatoire x qui soit premier par rapport à n. Calculez
Xo = x 2 modulo n.
C ’est le germe du générateur.

17.10 Autres approches à la conception d’algorithmes de chiffrement en continuas9
Maintenant, vous pouvez commencer à calculer des bits. Le ie bit pseudo-aléatoire est
le bit le moins significatif de x, où
Xi = modulo n.
La propriété la plus étrange de ce générateur est que vous n’avez pas à calculer tous
les i — 1 bits précédents pour obtenir le 2e bit. Si vous connaissez p et q, vous pouvez
calculer le ie bit directement :
bi est le bit le moins significatif de Xi où Xi = Xq ^ m°duIo ((p i)(«/-i)) moc[
n.
Cette propriété signifie que vous pouvez utiliser ce générateur pseudo-aleatoire de bits
comme un cryptosystème de chiffrement en continu pour des fichiers à accès aléatoire.
La sécurité de ce schéma dépend de la difficulté de factoriser n. Vous pouvez rendre n
public, ainsi tout le monde peut engendrer des bits en utilisant le générateur. Toutefois,
à moins que les cryptanalystes puissent factoriser n, ils ne pourront jamais prédire la
sortie du générateur — même sous la forme d ’affirmations telles que « le bit suivant a
51 % de chances d ’être un 1 ».
Il y a mieux, le générateur BBS est imprévisible à gauche et imprévisible à droite.
Cela signifie que, étant donné une suite engendrée par le générateur, les cryptanalystes
ne peuvent pas prédire le bit suivant ou le bit précèdent de la suite. Sa sécurité n’est
pas basée sur un générateur de bits compliqué que personne ne comprend, mais sur les
mathématiques sous-jacentes à la factorisation de n.
Cet algorithme est lent, mais il existe des améliorations. 11 semble que vous puis
siez utiliser plus que le bit le moins significatif de Xi comme bit pseudo-aléatoire.
D’après [1571, 1572, 1573, 36, 37], si t est la longueur de x lt les log2 é bits les moins si
gnificatifs de x.Lpeuvent être utilisés. Le générateur BBS est relativement lent et n’est,
pas utile pour le chiffrement en continu. Toutefois, pour des applications de haute
sécurité, telles que la génération de clefs, ce générateur est le meilleur.
17.10 Autres approches à la concep

tion d’algorithmes de chiffrement en
continu
Dans le cadre de l’approche par la théorie de l’information, le cryptanalyste est supposé
disposer de ressources illimitées en temps et en puissance de calcul. Le seul chiffrement
en continu qui soit sûr contre ce type d ’adversaire est le masque jetable (voir § 1.5).
Pour les besoins de l’illustration, faisons l’hypothèse que les masques sont stockés sur
des bandes magnétiques. Deux bandes magnétiques, l’une du côté du chiffrement et
l’autre du côté du déchiffrement, porteraient la même suite de codons. Pour chiffrer,
on combine simplement par ou exclusif le texte en clair avec les bits sur la bande.
Pour déchiffrer, on combine par ou exclusif le texte chiffré avec les bits de l’autre
bande identique. Comme les suites de codons sont vraiment aléatoires, vous n ’utilisez
jamais deux fois la même suite de codons. Si vous brûlez les bandes après vous en être
servi, vous avez le niveau de sécurité parfait4.
4. Note du traducteur : cette technique est parfois appelée « bande à usage unique ».
Un autre chiffre en continu, développé par Claus S c h n o r r , fait l’hypothèse que le

cryptanalyste n’a accès qu’à un nombre limité de bits du texte chiffré [1400]. Les
résultats sont fortement théoriques et n’ont pas de valeur pratique, du moins pas encore.
Pour plus de détails, consultez [1362, 1645, 1202].
Par un chiffrement en continu rendu aléatoire, le cryptographe essaie de s’assurer que
le cryptanalyste a un problème de taille non soluble. L’objectif est d’augmenter le
nombre de bits que le cryptanalyste doit manipuler, tout en gardant la clef secrète
petite. Cela peut être rendu possible en utilisant une grande chaîne aléatoire publique
pour le chiffrement et le déchiffrement. La clef spécifierait quelle partie de la chaîne doit
être utilisée pour le chiffrement et le déchiffrement. Le cryptanalyste, qui ne connaît pas
la clef, devrait utiliser une attaque exhaustive en parcourant toute la chaîne aléatoire.
Le niveau de sécurité de ce type de chiffre peut être exprimé comme le nombre moyen
de bits que le cryptanalyste doit examiner avant que les chances de trouver la clef ne
soient meilleures que le simple tirage au sort.
Chiffre de Rip v a n W in k le
James M a s s e y et Ingemar I n g e m a r s s o n ont proposé le chiffre de Rip v a n

W in k le [566], ainsi appelé parce que le destinataire doit recevoir 2n bits du texte
chiffré avant de tenter le déchiffrement5. L’algorithme illustré par la figure 17.10 est
facile à réaliser, on peut démontrer qu’il est sûr et il est totalement inutilisable. D ’après
M a s s e y : « On peut facilement garantir que le cryptanalyste ennemi aura besoin de
milliers d’années pour casser le chiffre, si quelqu’un est prêt à attendre des millions
d’années pour lire le texte en clair. » D ’autres travaux partant de cette idée sont décrits
dans [1579, 757].
Flux de bits
aléatoires Canal Retard -i
(multi-
Flux de bits___
du texte en clair ■é- Retard plexé)
Texte
en clair
0-20 ans
(Le retard est secret et dépend de la clef)
F ig . 17.10 Chiffre de Rip van W in k le
Chiffre rendu aléatoire de D iffie
Whietfield D i f f i e est le premier a avoir présenté ce schéma [1364]. Les données sont
formées de 2" chaînes aléatoires. La clef k est une chaîne aléatoire de n bits. Pour
chiffrer un message, Alice utilise la ke chaîne aléatoire comme masque jetable. Elle
envoie le texte chiffré et les 2" chaînes aléatoires sur 2 n + 1 canaux de communication
différents.
5. Note du traducteu r: R ip VAN WlNKLE a dorm i pendant 20 ans.
17.11 Chiffrement en continu en cascade 441
Bernard qui connaît k peut facilement choisir le bon masque jetable pour déchiffrer le
message. Estelle n’ a pas d’autre choix que d’examiner toutes les chaînes aléatoires les
unes après les autres jusqu’à ce qu’elle trouve le bon masque jetable. Toute attaque
doit examiner un nombre de bits moyen de l’ordre de 2n. R u e p p e l fait remarquer
qu’en envoyant n chaînes aléatoires au lieu de 2", et en utilisant la clef pour spécifier
une combinaison linéaire de ces chaînes, la sécurité est la même.
Chiffre rendu aléatoire de M a u r e r
Ueli M a u r e r a décrit un schéma basé sur la combinaison par ou exclusif de plusieurs

chaînes de bits aléatoires très longues [1041, 1038, 1037]. La clef est l’ensemble des
positions de départ dans chaque chaîne. Il se trouve que la presque totale sécurité de
ce schéma est prouvable, en calculant la probabilité de le casser selon la quant ité de
mémoire dont dispose l’attaquant. M a u r e r prétend que cela serait viable avec environ
100 chaînes aléatoires de 1020 bits. Numériser la surface entière de la Lune serait une
façon d’obtenir autant de bits.
17.11 Chiffrement en continu en cascade

Si la performance n’est pas primordiale, rien n’empêche de choisir plusieurs algorithmes
de chiffrement en continu et de les mettre en cascade. Il suffit de combiner par ou
exclusif toutes les sorties des générateurs avec le texte en clair pour obtenir le texte
chiffré. Si les clefs des générateurs sont indépendantes, le résultat de Ueli M a u r e r
(voir § 15.7) implique que la sécurité de la cascade est au moins aussi grande que celle
du meilleur algorithme de la cascade. Elle est probablement beaucoup plus sûre que
cela.
Les algorithmes en continu peuvent aussi être combiné de la même manière que les
algorithmes par blocs (voir le chapitre 15). On peut mettre en cascade (voir § 15.7) les
algorithmes de chiffrement en continu avec d’autres algorithmes en continu ou aussi
avec des algorithmes de chiffrement par blocs.
Une idée intelligente consiste à utiliser un algorithme, soit en continu, soit par blocs,
pour fréquemment changer la clef d’un algorithme rapide de chiffrement en continu (ou
même un algorithme par blocs en mode O F B ). Peu importe la faiblesse de l’algorithme
rapide puisqu’un cryptanalyste n’aura jamais beaucoup de texte en clair chiffré avec
la même clef.
Il faut trouver un compromis entre la taille de l’état interne de l’algorithme rapide
(ce qui influe sur la sécurité) et la fréquence avec laquelle vous pouvez vous permettre
de changer de clef. Le changement de clef doit être assez rapide ; les algorithmes qui
prennent un long moment pour mettre en place la clef ne sont pas adaptés pour ce
type d ’application. Le changement de clef devrait être indépendant de l’état interne de
l’algorithme rapide.
17.12 Choisir un algorithme de chiffrement

en continu
S’il y a un enseignement à tirer de l’étude du chiffrement en continu, c’est que de nou
velles sortes d ’attaques voient le jour avec une régularité alarmante. Les algorithmes de
chiffrement en continu reposent souvent sur de considérables théories mathématiques.
Ces théories permettent de prouver des propriétés intéressantes à propos de l’algo
rithme, mais aussi de trouver de nouvelles attaques. Je m’inquiète pour les algorithmes
à base de R D R L pour cette raison.
Je préfère les algorithmes qui suivent davantage les traces des algorithmes de chif
frement par blocs: transformations non linéaires, grandes tables-iS1, et ainsi de suite.
R C 4 est mon préféré, et SEAL arrive tout de suite derrière. Je serait très intéressé de
voir des résultats de cryptanalyse sur mes générateurs combinant des R D R L et des
R D R R ; cela semble un domaine très fructueux de recherche à creuser pour trouver
de réelles conceptions. Vous pouvez utiliser un algorithme par blocs en mode O FB ou
C FB pour obtenir un algorithme de chiffrement en continu.
Le tableau 17.3 donne des mesures de vitesse de quelques algorithmes à titre de com
paraison.
Tab. 17.3 - Vitesses de chiffrement en continu de quelques algorithmes sur un 486SX

à 33 MHz ____________________________________________
Algorithme Vitesse de chiffrement
(en mégaoctets par seconde)
A5 5
P IR E 62
R C4 164
SEAL 381
17.13 Génération de plusieurs flux à par

tir d’un seul générateur pseudo
aléatoire de suites
Si vous avez besoin de chiffrer plusieurs canaux de communication en même temps,
dans un multiplexeur par exemple, la solution simple consiste à utiliser un générateur
pseudo-aléatoire par canal. Cela pose deux problèmes : c’est coûteux en matériel et
il faut synchroniser les différents générateurs. Il serait plus simple d ’utiliser un seul
générateur.
Une solution consiste à donner une cadence plus rapide à l’horloge du générateur. Si
vous voulez trois flux indépendants, opérez trois cycles d’horloge et envoyez 1 bit dans
chaque canal. Cette technique marche mais vous risquez d ’avoir du mal à cedencer le
générateur aussi vite que vous le voudriez. Par exemple, si vous ne pouvez multiplier la
cadence du générateur que par 3, vous ne pourrez créer que trois flux. Un autre moyen
17.13 Génération de plusieurs flux à partir d’un seul générateur pseudo-aléatoire
de suites 448
consiste à utiliser le même flux pour tous les canaux avec d’éventuels délais. Mais ce
n’est pas sûr.
Une idée vraiment intelligente [1496], brevetée par la NSA, est illustrée par la fi
gure 17.11. Détournez la sortie de votre générateur favori vers un registre à décalage
usuel de m bits. A chaque impulsion d ’horloge, décaler le registre de un bit vers la'
droite. Pour chaque flux de sortie, combinez par et le registre avec un vecteur de
contrôle de m bits, qui identifie de manière unique ce flux, et combinez alors par ou ex
clusif les bits ensembles pour obtenir le bit de sortie de ce flux. Si vous voulez produire
plusieurs flux en parallèle, vous avez besoin d ’un vecteur de contrôle et d’un tableau
logique de et/ou exclusif par flux.
Générateur
Vecteur de Vecteur de Sortie Vecteur de

contrôle 2 de m bits contrôle n
contrôle 1
1 1
et logique et logique et logique
bit à bit bit à bit bit à bit
ou exclusif ou exclusif ou exclusif

bit à bit bit à bit bit à bit
v
Flux 1 Flux 2 Flux n
F ig. 17.11 - Générateur de plusieurs flux
Il faut être vigilant sur un point. Si un seul des flux est une combinaison linéaire des
autres, alors le système peut être cassé. Mais si vous êtes intelligent, c’est, un moyen
sûr et facile de résoudre le problème.
17.14 Générateurs de suites vraiment aléa

toires
Parfois, les générateurs pseudo-aléatoires de suites cryptographiquement sûrs ne sont
pas suffisants. Il y a de nombreuses circonstances en cryptographie où vous désirez des
nombres vraiment aléatoires. La génération de clefs est un des principaux exemples
d ’une telle situation. C ’est bien d ’engendrer des clefs cryptographiques aléatoires à
partir d ’un générateur pseudo-aléatoire de suite, mais si un adversaire obtient une
copie de ce générateur pseudo-aléatoire de suite et de toute autre information secrète
que vous auriez utilisée pour produire les nombres, il peut créer les mêmes clefs et
casser votre cryptosystème, quel que soit le niveau de sécurité de votre algorithme. Des
suites engendrées par un générateur de suites vraiment aléatoires ne peuvent pas être
reproduites. Personne, pas même vous, ne peut reproduire la suite de bits à partir de
ces générateurs.
Il y a un grand débat philosophique quant à savoir si l’une de ces techniques permet
réellement de produire des bits vraiment aléatoires. Je ne vais pas m’attarder sur ce
débat. L ’objet qui nous occupe ici est de produire des bits qui aient les mêmes propriétés
statistiques que des bits aléatoires et qui ne soient pas reproductibles.
L’important concernant n’importe quel générateur aléatoire de suites est qu’il ait été
testé. Il existe une littérature abondante à ce sujet. Les tests de caractère aléatoire sont
décrits dans [864, 106]. Ueli M a u r e r a montré que tous ces tests peuvent être déduits
de tentatives de comprimer la suite [1039, 1040]. Si vous pouvez comprimer une suite
aléatoire, alors elle n’est pas vraiment aléatoire.
De toute façon, ce que nous avons, c ’est une bonne dose de magie noire. Le point prin
cipal est d ’engendrer une suite de bits que votre adversaire ne puisse deviner sans une
chance inhabituelle. Cela n’a l’air de rien mais c ’est plus difficile que vous ne le pensez.
Je ne peux pas prouver qu’une de ces techniques engendre des bits aléatoires, mais ces
techniques produisent des suii.es de bits qui ne peuvent être facilement reproduites.
Pour plus de détails, voyez [1378, 1377, 512].
Tables RAND
En 1955, à l ’époque où les ordinateurs faisaient seulement leur app arition, la société
R and C o r p o r a t io n a publié un livre qu i contenait u n m illio n de chiffres aléa
toires [1300]. L e u r m éthode est décrite dans le livre:
« Les chiffres aléatoires de ce livre ont été produits par mélange aléatoire
d ’une table de base engendrée par une roulette électronique. Brièvement, un
source d ’impulsions de fréquence aléatoire, fournissant en moyenne 100000
impulsions environ par seconde, était connectée environ une fois par seconde
par une impulsion de fréquence constante. Des circuits de normalisation
des impulsions passaient les impulsions à travers un compteur binaire à 5
cases En principe, la machine était une roulette à 32 cases qui effectuait, en
moyenne, 3000 révolutions environ par essai et qui produisait un nombre
par seconde. Un convertisseur binaire décimal était utilisé pour convertir
20 des 32 nombres (les 12 autres étaient ignorés) et ne retenait que le
dernier chiffre des nombres de deux chiffres ; ce chiffre final alimentait une
17.14 Générateurs de suites vraiment aléatoires
perforatrice IBM pour produire la table finale de chiffres aléatoires sur

cartes perforées. »
Le livre décrit ensuite les résultats de divers tests de caractère aléatoire des données.
Il suggère également comment utiliser le livre pour trouver un nombre aléatoire :
« Les lignes de la table des chiffres sont numérotées de 00000 à 19999.

Pour toute utilisation de la table, on doit d’abord trouver une position
de départ aléatoire. Une procédure habituelle pour réaliser ceci consiste à
ouvrir le livre à une page non utilisée de la table de chiffres et choisir en
aveugle un nombre de 5 chiffres ; avec le premier chiffre réduit modulo 2 ce
nombre détermine la ligne de départ ; les deux chiffres à droite du nombre de
5 chiffres initialement sélectionné sont réduits modulo 50 pour déterminer
la colonne de départ parmi la ligne sélectionnée. Pour se prémunir de la
tendance qu’ont les livres de toujours s’ouvrir à la même page et de la
tendance naturelle qu’ont, les gens de choisir un nombre près du centre de
la page, chaque nombre de 5 chiffres utilisé pour déterminer une position
de départ doit être marqué afin de ne pas être utilisé une deuxième fois à
cette fin. »
La matière principale du livre est la table de chiffres aléatoires. Elle les énumère par
groupe de 5 chiffres — « 10097 32533 76520 13586 . . . » — à raison de 50 par ligne
et de 50 lignes par page. La table continue ainsi sur 400 pages, ce qui, excepté pour
une section particulièrement osée à la page 283 qui indique « 69696 », s’avère d’une
lecture particulièrement ennuyeuse. Le livre comprend également une table des 100 000
écarts types.
Ce qui est intéressant à propos de la table R A N D n’est pas qu’elle contienne un
million de chiffres aléatoires, mais qu’elle a été créée avant la révolution informatique.
De nombreux algorithmes cryptographiques utilisent des constantes arbitraires — aussi
appelées « n o m b r e s m a g i q u e s ». Choisir les nombres magiques à partir de la table
RAND garantit qu’ils n’ont pas été choisis pour quelque raison cachée. Par exemple,
K h a f r e se sert de la table R A N D .
Utilisation de bruit aléatoire

Le meilleur moyen de collecter un grand nombre de bits aléatoires est de se raccorder
sur le caractère aléatoire naturel du monde réel. Cette méthode nécessite la plupart
du temps du matériel spécialisé, mais il y a des techniques que vous pouvez employer
avec les ordinateurs.
Trouvez un événement qui a lieu souvent mais aléatoirement : le bruit atmosphérique
dépassant un certain niveau, les chutes d’un bambin qui apprend à marcher, etc.
Mesurez l’intervalle de temps entre un événement et le suivant. Enregistrez-le. Mesurez
l’intervalle de temps entre ce second événement et le troisième. Enregistrez-le égale
ment. Si le premier intervalle de temps est plus grand que le second, produisez un 1
comme bit aléatoire. Si le second intervalle de temps enregistré est plus grand que le
premier, produisez un 0 comme bit aléatoire. Continuez ainsi pour le bit suivant.
Lancez une fléchette sur le journal de votre choix. Comparez la lettre la plus proche de
la pointe et la lettre qui précède celle-là. Produisez un 1 si la première suit 1a deuxième
dans l’ordre alphabétique, et un 0 sinon.
Branchez un compteur Geiger à votre ordinateur, comptez le nombre d ’émissions pro

duites durant un intervalle de temps fixé et gardez le dernier bit significatif. Ou encore,
mesurez le temps entre deux émissions. (Comme la source radioactive se consume, le
temps moyen entre deux émissions s’allonge continuellement. Si vous voulez une source
de durée de vie suffisante, prenez le plutonium. Si vous craignez pour votre santé, vous
pouvez faire les corrections statistiques appropriées.)
G.B. A g n e w a proposé un vrai générateur aléatoire de bits adapté à l’intégration
dans une puce VLSI [25]. C ’est une capacité à semi-conducteurs (M ISC pour « Métal
Insulator Semiconduction Capacitor »). Deux d’entre elles sont placées à proximité
l’une de l’autre et le bit aléatoire est une fonction de la différence de charge entre
les deux. Un autre générateur aléatoire de nombre en technologie LSI engendre un
flux de bits aléatoires basé sur des instabilités de fréquence d ’un oscillateur en boucle
ouverte [537]. Une puce commercialisée par A T & T engendre des nombres aléatoires
à partir du même phénomène [73]. M. G u d e a construit un générateur aléatoire de
nombres qui collecte des bits aléatoires à partir de phénomènes physiques tels que la
décroissance radioactive [669, 670]. Manfield R i c h t e r a développé un générateur de
nombres aléatoires basé sur le bruit thermique d ’une diode semiconductrice [1320].
Il paraît que l’interval de temps entre deux émissions lumineuses d’un atome de mercure
piégé seraient aléatoires. Exploitez cela. Mieux vaut finalement trouver une société de
semi-conducteurs qui fabrique des puces générant des nombres aléatoires ; elles existent.
Il y a aussi un générateur de nombres aléatoires qui utilise le disque dur de l’ordinateur
[439]. Le générateur mesure le temps nécessaire pour lire un bloc du disque et utilise la
variabilité de ce temps comme source de nombres aléatoires. Il filtre les données pour
enlever les structures provenant de la quantification, puis effectue une transformée de
Fourrier à des vecteurs de nombres. Ceci retire le biais et la corrélation. Finalement
il tire les bits aléatoires grâce à des fréquences spectrale entre 0 et n normalisées à
l’intervalle de temps unitaire. Une grande part des variations de la vitesse de rotation
du disque étant due aux turbulences de l’air, il y a donc un caractère aléatoire propre au
système. Il y a pourtant des points noirs. Si vous gardez trop de bits de la sortie, vous
utilisez la transformation de Fourrier comme générateur, ce qui risque d ’être prévisble.
Et il vaut mieux toujours lire le même bloc du disque pour éviter au filtrage d’avoir à
retirer les structures provenant du gestionnaire de disque. Une réalisation de ce système
permet de produire environ 100 bits par minute [439].
Utilisation de l’horloge de l’ordinateur

Si vous avez besoin d’un seul bit aléatoire (ou de quelques-uns), prenez le bit le moins
significatif de n’importe quel registre d ’horloge. Sur un système U N IX, cela peut ne
pas être tellement aléatoire à cause de différentes synchronisations potentielles mais
cela marchera bien sur un ordinateur personnel.
Évitez d’obtenir trop de bits de cette façon : utiliser la même routine plusieurs fois
de suite peut facilement biaiser les bits engendrés de cette manière. Par exemple, si
chaque exécution de la routine de génération de bit utilise un nombre pair de clics
d’horloge, vous obtiendrez une suite infinie de la même valeur de bit de ce générateur.
Si chaque exécution nécessite un nombre impair de clics d’horloge, vous obtiendrez une
suite infinie de valeurs alternantes de ce générateur. Même si la résonance n’est pas
aussi simpliste, le flux de bits résultant sera loin d ’être aléatoire.
17.14 Générateurs de suites vraiment aléatoires
Il existe un générateur de nombres aléatoires fonctionnant de la manière suivante [929] :
« Notre générateur de nombres vraiment aléatoires... fonctionne en réglant

une alarme et en incrémentant rapidement un compteur dans un registre du
microprocesseur jusqu’à l’arrivée d’une interruption. Le contenu du registre
est alors combiné par ou exclusif avec un tampon de sortie de un octet (en
tronquant ainsi les données du registre à 8 bits). Une fois que le tampon
de sortie est rempli, il subit un décalage circulaire vers la droite de 2 bits,
ce qui a pour effet de pousser les bits les plus actifs (et aléatoires) de poids
faible vers les positions de poids fort. Le procédé entier est répété trois fois.
A la fin, chaque bit du tampon a touché un des deux bits les plus aléatoires
du registre après interruption. On obtiendra donc n octets aléatoires au
bout de 4n interruptions. »
Cette méthode est très sensible au caractère aléatoire des interruptions système et à la
granularité de l’horloge. La sortie faisait bonne figure au cours de tests sur de réelles
machines UNIX.
Mesure de caractéristiques de la vitesse de frappe

Les rythmes de frappe au clavier des gens sont aléatoires et en même temps ne le sont
pas. Ils possèdent assez d’information pour permettre l’identification, mais ils sont
assez aléatoires pour générer des bits aléatoires. Mesurez le temps entre deux frappes
de touche successives et prenez ensuite le bit le moins significatif de ces mesures. Cette
technique pourrait ne pas marcher sur des terminaux U N IX, parce que les touches
utilisées passent à travers toute une série de filtres avant d’atteindre votre programme.
Mais elle est adéquate pour les ordinateurs personnels.
Idéalement, vous ne devriez collecter qu’un bit aléatoire par touche. En collecter plus
pourrait biaiser le résultat en fonction des talents de dactylo de celui qui est au clavier.
Toutefois, cette technique est limitée. Bien qu’il soit facile de demander à quelqu’un
d’entrer une centaine de mots quand il est temps d ’engendrer une clef, il n’est pas
raisonnable de lui demander de taper un roman de 100000 mots pour engendrer un
flux de codons pour un masque jetable.
Biais et corrélations
Le défaut majeur de tous ces systèmes est qu’il peut y avoir des corrélations et des biais
dans les suites engendrées. Le processus physique sous-jacent peut être aléatoire mais
il y a de nombreux instruments de mesures entre la partie numérique de l'ordinateur et
le dispositif physique. Ces instruments peuvent facilement introduire des biais et des
corrélations.
Un moyen d’éüminer ce biais est de combiner par ou exclusif plusieurs bits ensemble.
Si un bit aléatoire a un biais e en faveur de 0, alors la probabilité du résultat 0 peut
être écrite :
P ( 0) = 0,5 + e.
Combiner par ou exclusif deux de ces bits donne :
P(Q) = (0,5 + e)2 + (0,5 - e)2 = 0,5 + 2 x e2.

Par le même type de calcul, la combinaison par ou exclusif de 4 bits ddonne :
P ( 0) = 0,5 + 8 x e4.
Combiner par ou exclusif m bits convergera exponentiellement vers une probabilité

égale de 0 et de 1.
Une bien meilleure méthode consiste à retirer tout biais de la source aléatoire. Analysez
les paires de bits. Si deux bits sont identiques, jetez-les et analysez la paire suivante.
Si les deux bits sont différents, prenez le premier bit comme sortie du générateur. Ceci
élimine complètement le biais. D ’autres techniques de réduction du biais reposent sur
la compression de données, et les transformées de Fourrier [512],
Le défaut potentiel de ces deux méthodes est que s’il y a une c o r r é l a t i o n entre bits
adjacents, alors ces méthodes augmentent le biais. Un moyen de corriger cela est d’uti
liser plusieurs sources aléatoires. Prenez quatre sources aléatoires et combinez par ou
exclusif les bits ; ou prenez deux sources aléatoires et analysez les bits par paires.
Par exemple, prenez une source radioactive et branchez un compteur G ei GER à votre
ordinateur. Prenez une paire de diodes « bruyantes » et enregistrez un événement
chaque fois que le bruit dépasse un certain seuil. Mesurez le bruit atmosphérique.
Prenez un bit aléatoire de char-une des sources et combinez-les par ou exclusif pour
produire le bit aléatoire. Les possibilités sont infinies.
Le simple fait qu’un générateur aléatoire soit biaisé ne le rend pas nécessairement
inutilisable. Cela veut seulement dire qu’il est moins sûr. Par exemple, Alice veut
engendrer une clef de 112 bits pour le DES T R I P L E , en disposant uniquement d’un
générateur avec un biais vers 0 : il produit 55 % de 0 et 45 % de 1. Cela signifie qu’il
n’y a que 0,99277 bit d’entropie par bit de la clef, au lieu de 1 bit si le générateur
était parfait. Martin, qui essaie de casser la clef, peut optimiser son attaque exhaustive
pour essayer la clef la plus probable en premier lieu ( 0 0 0 ... 0) et continuer ainsi vers
la clef la moins probable ( 1 1 1 ... l). A cause du biais, Martin peut espérer trouver la
clef en 2109 tentatives. S’il n’y avait pas de biais, Martin devrait s’attendre à faire 2111
tentatives. La clef résultante est moins sûre, mais pas de façon appréciable.
*
Epuration du caractère aléatoire
En général, le meilleur moyen de générer des nombres aléatoires est de se trouver un
grand nombre d ’événements apparemment aléatoires et d’en extraire le caractère aléa
toire. Les fonctions de hachage sont faites pour cela ; elles sont rapides et traiteront une
grande quantité de données avant de faire baisser les performances, tout en améliorant
le caractère aléatoire de vos observations. Passez par des fonctions de hachage tout ce
qui vous passe sous la main et qui soit un peu aléatoire. Essayez entre autres :
- une copie de chaque touche frappée,
les commandes de la souris,
- le numéro de secteur, la date du jour, et la latence de recherche pour opération

sur le disque,
- la position courante de la souris,
- le numéro de la ligne courante de balayage du moniteur,

17.14 Générateurs de suites vraiment aléatoires 449
- le contenu de l’image affichée,
- le contenu de la table d’allocation des fichiers (FA T), des tables du noyau, etc.,
- les temps d ’accès et de modification du fichier /d e v /t t y ,
- la charge du processeur,
- le temps d’arrivée des paquets du réseau,
- l’entrée d ’un microphone,
- le contenu du fichier /d e v /a u d io sans micro branché.
Si votre système utilise des oscillateurs à quartz différents pour le microprocesseur

et l’horloge, essayez de lire la date du jour dans une boucle serrée. Sur certains sys
tème (mais pas tous), cela reflétera le tremblement aléatoire de phase entre les deux
oscillateurs.
Comme le caractère aléatoire de la plupart de ces événements provient de datations,
utilisez l’horloge la plus précise possible. Un P C standard utilise une puce d ’horloge
Intel 8254 (ou une équivalente) cadencée à 1,1931818 MHz; aussi la lecture directe
du compteur vous donne une précision de 838 nanosecondes. Pour ne pas fausser les
résultats, évitez d’échantillonner lors d’une interruption.
Voici le code en C avec M D 5 (voir § 18.5) comme fonction de hachage :
char c h a ineAleat[16];
/* Appelez souvent la fonction suivante sur une variété d ’événements

* aléatoires ou pseudo-aléatoires pour brasser la chaîne aléatoire.
* L a forme exacte et la longueur de evenAleat n ’importe pas du
* moment que son contenu soit un tant soit peu imprévisible.
*/
void b rasserAleat(char *evenAleat, unsigned int evenLong)
f
MD5_CTX md5;
M D5Init(&md5);
MD5MiseAJour(&md5,chaineAleat,siezof(chaineAleat));
MD5MiseAJour(&md5,evenAleat,evenLong);
MD5Final(chaineAleat,&md5);
}
Après suffisamment d’appels à bra sserA lea t () pour que chaineA leat soit assez aléa
toire, vous pouvez en tirer des bits aléatoires. Pour cela, M D 5 nous sert à nouveau,
cette fois comme générateur d’octets pseudo-aléatoires en mode compteur.
long comptAleat;
void genAleat(char *buf, unsigned int longbuf)
f
MD5_CTX md5;
char t m p [16];
unsigned int n;
while(longbuf != 0) {
/* Passer la chaîne aléatoire dans la fonction de hachage

* avec un compteur.
*/
M D5Init(&md5);
MD5MiseAJour(&md5,chaineAleat,siezof(chaineAleat));
MD5MiseAJour(&md5,(unsigned char *)&comptAleat,
siezof(comptAleat));
MD5Final(tmp,&md5);
comptAleat++; /* Incrémenter le compteur */
/* Copier 16 octets, ou la quantité requise, mais moins

* que le contenu du tampon de l ’utilisateur.
*/
n = (longbuf < 16) ? longbuf : 16;
m e m c py(buf,t m p ,n ) ;
buf += n;
longbuf -= n;
>
>
La fonction de hachage est ici cruciale pour plusieurs raisons. Elle permet tout d ’abord
de générer facilement une quantité arbitraire de données pseudo-aléatoires sans devoir
appeler brasserAleat () à chaque fois. Dans les faits, le système se passe élégamment
de l’aléatoire parfait à l’aléatoire pratique quand la demande dépasse l’offre. Dans ce
cas, il devient théoriquement possible d ’utiliser le résultat d’un appel à genAleatO
pour déterminer le résultat de l’appel suivant ou précédent. Mais cela exige d’inverser
M D 5, ce qui n’est pas faisable en pratique.
Ceci est important car la procédure ignore ce qu’il adviendra du résultat de chaque
appel, il se peut qu’un appel serve à générer un nombre aléatoire pour un protocole
qui l’enverra en clair, par exemple en réponse à une requête d ’un attaquant. L ’appel
suivant peut servir dans une session sans rapport que l’attaquant essaye de pénétrer.
Il est clairement important qu’un attaquant ne puisse déduire le résultat d’un appel
d ’aucun autre.
Il reste un problème. chaineAleat [] doit être suffisament aléatoire avant le premier
appel à genAleatO. Si le système a fonctionné quelque temps avec un utilisateur au
clavier, il n’y a pas de problème. Mais qu’en est-il d ’un système automatique qui se
réinitialise tout seul sans qu’aucune commande au clavier ou à la souris n ’advienne?
Ce problème est difficile. Une solution partielle consiste à faire taper au clavier un
moment l’utilisateur après la toute première mise en route de la machine et d’en créer
un fichier de germes germeAleat [] à utiliser à chaque initialisation de la machine. Mais
ne sauver pas sur disque germeAleat [] directement. Un attaquant qui copierait se
fichier pourrait déterminer tous les résultats générés par genAleatO après la création
du fichier jusqu’au premier appel à brasserAleat ().
Pour résoudre ce problème, il faut appliquer la fonction de hachage à germeAleat []
juste avant de le sauver. Quand le système se réinitialise, il charge le fichier de germes,
le passe à brasserAleat ( ) et le détruit aussitôt. Malheureusement, il reste la menace
du vol du fichier de germes entre la réinitialisation et sa destruction, et son utilisation
pour deviner les résultats des futurs appels à genAleatO. Je ne vois pas d’autre
solution à ce problème que d’attendre l’arrivée d’événements aléatoires extérieurs après
17.H Générateurs de suites vraiment aléatoires 451
la réinitialisation avant d’autoriser des appels à genAleatO.

Chapitre 18
Fonctions de hachage à sens

unique
18.1 Introduction
Une fonction de hachage à sens unique, H (A i), opère sur un message A i de longueur
arbitraire. Elle fournit une valeur de hachage de longueur fixe h.
h = H (Ai), où h est de longueur m.
Il existe de nombreuses fonctions qui prennent une entrée de longueur arbitraire et qui
fournissent une sortie de longueur fixe, mais les fonctions de hachage à sens unique ont
les caractéristiques additionnelles suivantes :
Étant donné A i, il est facile de calculer h.

Étant donné h, il est difficile de calculer A i.
Étant donné A i, il est difficile de trouver un autre message A i' tel que
H ( M ) = H (M ').
Si Martin pouvait effectuer la partie difficile, cela minerait la sécurité de tout protocole
utilisant la fonction de hachage à sens unique. L ’essence même des fonctions de hachage
est de fourinir une « empreinte » de A i qui soit unique. Si Alice signait A i en utilisant
un algorithme de signature numérique sur H (A i), et si Bernard pouvait produire un
Ai' tel que H (A i) = H (Ai'), alors Bernard pourrait prétendre qu’Alice a signé A i'.
Dans certaines applications il ne suffit pas que la fonction soit à sens unique ; il faut
de plus qu’elle est ait une propriété appelée résistan ce à la collision :
Il est difficile de trouver deux messages aléatoires A i et A4' tels que

H (A l) = H (A i').
Vous vous rappelez de l’attaque des anniversaires du paragraphe 7.4. Elle ne consiste
pas à trouver un autre message A i' tel que I I (A4') = II(A i), mais à trouver deux
messages aléatoires A4 et A i' tels que H (A i) — H (A i1).
Chapitre 18 Fonctions de hachage à sens unique
Le protocole suivant, décrit pour la première fois par Gideon Y u v a l [1637], montre
comment Alice peut utiliser l’attaque des anniversaires pour duper Bernard si la pro
priété supplémentaire n’était pas vérifiée.
1° Alice prépare deux versions d’un contrat, l’une favorable à Bernard, et l’autre
qui lui fait faire ce que bon lui semble.
2° Alice apporte des modifications subtiles à chaque document et calcule l’em

preinte de chacun L
3° Alice compare les valeurs des ensembles d’empreintes pour chacun des deux
documents, pour rechercher une paire qui concorde2. Elle reconstruit les deux
documents qui ont la même empreinte.
4° Alice fait signer par Bernard la version du contrat qui lui est favorable en
utilisant un protocole où il signe seulement l'empreinte.
5° Plus tard, Alice remplace le contrat signé par Bernard par celui qu’il n’a pas
signé. Maintenant elle peut convaincre un juge que Bernard a signé cet autre
contrat.
C’est un problème sérieux. (La morale de cette histoire est de toujours faire un petit
changement à un document que vous signez.)
Il existe des attaques similaires qui peuvent être montées en faisant l’hypothèse d’une
attaque des anniversaires réussie. Par exemple, les adversaires peuvent envoyer à un
système de contrôle automatique (d’un satellite, peut-être) des messages aléatoires
avec des signatures aléatoires. Finalement, l’un de ces messages aléatoires aura une
signature valide. Les adversaires n’auraient aucune idée de ce que la commande ferait,
mais si leur seul but consistait à fausser le satellite, cela réussirait.
Longueur des empreintes

Des fonctions de hachage à sens unique à 64 bits sont juste trop petites pour survivre
à une attaque des anniversaires. La plupart des fonctions de hachage à sens unique
pratiques produisent des empreintes de 128 bits. Cela oblige toute personne qui essaie
l’attaque des anniversaires à calculer 264 empreintes de documents aléatoires pour en
trouver deux qui aient la même empreinte. Le N IST, dans son standard de hachage
sûr (SHS pour « Secure Hash Standard »), utilise des empreintes de 160 bits. Cela rend
l’attaque des anniversaires encore plus difficile, nécessitant le calcul de 280 empreintes
aléatoirement.
Pour engendrer une empreinte plus longue que le produit de la fonction de hachage, la
méthode suivante a été proposée :
1° Engendrez l’empreinte d’un message en utilisant une fonction de hachage à

sens unique reprise dans cet ouvrage.
2° Joignez l’empreinte au message.
1. L es c h a n g e m e n ts p e u v e n t co n s is te r à : re m p la ce r u n e s p a c e p a r la c o m b in a is o n « e sp a ce—re to u r en
a r r iè re -e sp a ce » , r a jo u te r un o u d e u x e sp a ces avan t les « aller à la lig n e », e tc . E n faisant o u n e fa isan t
p as un seul c h a n g e m e n t p arm i 3 2 lignes, A lic e p e u t fa cilem en t en g en d rer 2 32 d o cu m e n ts d ifférents.
2. Si la fo n c t io n d e h a ch ag e p r o d u it des valeurs d e 64 b it s seu lem en t, elle p o u r ra it év en tu ellem en t
tro u v e r une p a ire c o n c o r d a n te a v e c 2 32 v ersion s d e ch a q u e d o cu m e n t.
18.2 Snefru 455
3° Engendrez l’empreinte de la jointure du message et de l ’empreinte du message.

4° Créez une grande empreinte constituée de l’empreinte engendrée à l’étape 1
jointe à l’empreinte engendrée à l’étape 3.
5° Répétez les étapes 1 à 3 autant de fois que vous le voulez.
Bien que cette méthode n ’ait jamais été prouvée sûre ou non sûre, plusieurs personnes
émettent de sérieuses réserves à son propos [1273, 859].
Survol des fonctions de hachage à sens unique

Il n’est pas facile de concevoir une fonction qui prenne en entrée un paramètre de
longueur variable, et de la rendre à sens unique. Dans la réalité, les fonctions de hachage
à sens unique sont inspirées des fo n ctio n s d e com p ression . Ces fonctions qui sont à
sens unique, produisent une valeur de longueur n, à partir d ’une entrée de longueur m
supérieure à n [1076, 416]. L’entrée de la fonction de compression est un bloc de texte
et l’empreinte du bloc précédent (voir la figure 18.1). La sortie est l’empreinte de tous
les blocs jusqu’à ce point. C ’est-à-dire que l’empreinte du bloc M.i est donnée par :
K =
L’empreinte en cours et le bloc de texte suivant servent de paramètre à l’application

suivante de la fonction de compression. L’empreinte du dernier bloc devient l’empreinte
de tout le message.
M kr
Fonction de hachage
à sens unique ► hi
“ i-l '
F ig. 18.1 - Fonction de hachage à sens unique
Le message d ’entrée devrait contenir sous une certaine forme la représentation binaire
de la longueur du message en entier. Cette technique prévient un problème de sécurité
éventuel, qui résulterait de messages de longueurs différentes pouvant avoir la même
empreinte [1076, 416]. Cette technique est parfois appelée ren forcem en t-M D [941],
Différents chercheurs ont conjecturé que si une fonction à sens unique est sûre pour un
seul bloc, alors cette méthode de hachage d’une suite de longueur quelconque de blocs
est aussi sûre, mais rien n’a été prouvé [1147, 1075, 416].
On a beaucoup écrit à propos des fonctions de hachage à sens unique. Pour plus
d’indications mathématiques consultez [1033, 793, 791, 1147, 1076, 416, 98, 858, 1275].
La thèse de doctorat de Bart P R E N E E L [1273] est probablement l’exposé le plus complet
concernant les fonctions de hachage à sens unique.
18.2 Snefru
Sn e f r u 3 est une fonction de hachage à sens unique conçue par Ralph M erkle [1075].
3. Snefru, à l’ instar de Khufu et Khafre, est un des pharaons d ’Egypte.

456 Chapitre 18 Fonctions de hachage à sens unique
S n e f r u calcule des em preintes de 128 ou 256 b its po ur des messages de longueur

arbitraire.
Au départ, le message est découpé en morceaux de (512 — m) bits chacun (m est la
longueur de l’empreinte). Si l’empreinte calculée a 128 bits les morceaux sont longs de
384 bits ; si l’empreinte a 256 bits, les morceaux ont 256 bits.
Le cœur de l’algorithme est une fonction H qui hache une valeur de 512 bits en une
valeur de m bits. La fonction H a été conçue pour qu’il soit facile de calculer l’empreinte
d ’une entrée mais qu’il soit impossible en pratique de calculer une entrée qui a une
empreinte spécifique.
Les m premiers bits de la sortie de H forment l’empreinte du bloc ; le reste est inutilisé.
Le bloc suivant est joint à l’empreinte du bloc précédent et haché à nouveau. Le bloc
initial est joint à une suite de 0. Après le dernier bloc (si le message n ’a pas une
longueur multiple de la taille de bloc, le dernier bloc est complété par une suite de 0),
les m premiers bits sont joints à la représentation binaire de la longueur du message
et hachés une fois de plus.
La fonction H est basée sur une autre fonction E qui est une fonction de chiffrement
par bloc réversible qui opère sur des blocs de 512 bits. La valeur de H est donnée par
les m derniers bits de la sortie de E combinés par ou exclusif avec les m premiers bits
de la sortie de E.
La sécurité de S n e f r u dépend de la fonction E qui rend aléatoires les données en
plusieurs passes. Chaque passe est composée de 64 rondes de brouillage. Dans chaque
ronde, un octet différent des données est utilisé comme entrée d ’une table 5 ; le mot
de sortie de la table-5' est combiné par ou exclusif avec les deux mots voisins du
message. Les tables-5 sont construites d ’une manière similaire à celles de K h a f r e . Il
y a également quelques rotations. A l’origine, S n e f r u était conçu avec deux passes.
Cryptanalyse de Snefru
En utilisant la cryptanalyse différentielle, B i h a m et S h a m i r ont prouvé que S n e f r u
à 128 bits et à deux passes n’était pas sûr [178].
Leur attaque trouve les paires de messages qui ont la même empreinte en quelques
minutes.
Pour S n e f r u à 1 2 8 bits, leur attaque est plus efficace que la recherche exhaustive
pour quatre passes ou moins. Une attaque des anniversaires contre S n e f r u requiert
264 opérations ; la cryptanalyse différentielle peut trouver une paire de messages ayant
la même empreinte en 2 28,5 opérations pour un S n e f r u à trois passes et en 2 44,5 opé
rations pour un S n e f r u à quatre passes. Trouver un message ayant une empreinte
donnée par recherche exhaustive nécessite 2128 opérations ; la cryptanalyse différen
tielle requiert 2 56 opérations pour un S n e f r u à trois passes et 2 88 opérations pour un
S n e f r u à quatre passes.
Bien que B i h a m et S h a m i r n’aient pas considéré les empreintes à 256 bits, ils éten
dirent leur analyse à des empreintes de 224 bits. Par comparaison avec l’attaque des
anniversaires, qui requiert 2112 opérations, ils peuvent trouver des messages avec la
même empreinte en 212-5 opérations pour un S n e f r u à deux passes, 233 opérations
pour un S n e f r u à trois passes et 288 opérations pour un S n e f r u à quatre passes.
Actuellement, M e r k l e recommande d’utiliser S n e f r u avec au moins huit
passes [1079]. Toutefois, avec autant de passes, l’algorithme est nettement plus lent
que M D5 et SHA.
18.3 N - H ash 457
18.3 N—Hash
N -H ashest un algorithme inventé par des chercheurs de la N i p p o n T é l é p h o n é a n d
T eleg raph, les mêmes que ceux qui ont inventé F E A L en 1990 [1111, 1112]. N - H a s h
utilise des blocs de message de 128 bits, une fonction de brouillage compliquée similaire
à celle de F E A L et produit des empreintes de 128 bits.
L’empreinte de chaque bloc de 128 bits est une fonction du bloc et de l’empreinte du
bloc précédent :
ho = / , où I est une valeur initiale quelconque

h i - g ( M i ,h i 1 ) © M , © h i_i.
L’empreinte du message entier est l’empreinte du dernier bloc La valeur initiale quel
conque I peut être n’ importe quelle valeur choisie par l'utilisateur (même tous des
0).
La fonction g est une fonction compliquée. La figure 18.2 donne un aperçu de l’algo
rithme. Au départ, les 64 bits de gauche et les 64 bits de droite de l’empreinte de 128
bits du bloc précédent du message hi- 1 sont échangés; les deux moitiés sont ensuite
combinées par ou exclusif avec 1010___ 1010 (sur 128 bits) en binaire et ensuite com
binées par ou exclusif avec le bloc courant du message A4 j. Cette valeur passe alors
dans N étapes (N — 8 pour les figures) de traitement. L ’autre entrée d ’une étape de
traitement est la valeur de l’empreinte précédente combinée par ou exclusif avec une
constante binaire parmi huit.
Une étape de traitement est illustrée par la figure 18.3. Le bloc de message est coupé
en quatre valeurs de 32 bits. L ’empreinte précédente est coupée également en quatre
valeurs de 32 bits. La fonction f est donnée par la figure 18.4. Les fonctions So et ,S'i
sont les mêmes que pour FE A L :
S'ü(c.,b) = décalage circulaire à gauche de 2 bits de ((a + b) mod 256)

5i(a,6) = décalage circulaire à gauche de 2 bits de ((a + 6 + 1 ) mod 256).
La sortie d ’une étape de traitement devient l’entrée de l’étape de traitement suivante.

Après la dernière étape de traitement, la sortie est combinée par ou exclusif avec A4,
et 6 j_ i, et ensuite le bloc suivant est prêt à être haché.
Cryptanalyse de N—Hash
Bert DEN B o e r a découvert un moyen de provoquer des collisions dans la fonction de
ronde de N- H a s h [1273]. BlHAM et S h a m i r ont utilisé la cryptanalyse différentielle
pour casser N - H a s ii à 6 rondes [176, 178]. Leur attaque particulière (il y en a certai
nement d’autres) marche pour n’importe quel N qui est divisible par 3, et elle est plus
efficace que l’attaque des anniversaires pour tout N inférieur à 15.
La même attaque permet de trouver des paires de messages qui ont la même empreinte
pour N- H a SII à 12 rondes en 256 opérations au lieu des 264 opérations nécessaires pour
une attaque exhaustive. N H a s h à 15 rondes n’est pas vulnérable à la cryptanalyse
différentielle qui requiert dans ce cas 272 opérations.
Les concepteurs de l’algorithme recommandent d’utiliser N H a s h avec au moins
8 rondes [1112]. Étant donné le peu de sûreté de N - H a s h et de FE A L (et étant
donné sa lenteur avec 8 rondes), je conseille d’ utiliser un autre algorithme.
F i g . 18.2 - Aperçu de N - H ash
18.4 M D4
M D 4 est une fonction de hachage à sens unique conçue par Ron R iv e s t [1329, 1330,
1331]. L ’acronyme « MD » vient de « Message Digest » et l’algorithme produit des
empreintes de 128 bits du message d’entrée.
Dans [1330], R iv e s t décrit les objectifs de conception pour l’algorithme:
Sécurité. Il est impossible de trouver par le calcul deux messages qui

aient la même empreinte. Aucune attaque n’est plus efficace que l’attaque
exhaustive.
Sécurité directe. La sécurité de M D 4 n’est basée sur aucune hypothèse,
telle que la difficulté de la factorisation.
Vitesse. M D 4 est adapté pour des réalisations logicielles rapides. Il est
18-4 MD4 459
F ig. 18.3 - Une étape de traitement de N H A SU
basé sur un ensemble de manipulations de bits sur des opérandes de 32

bits.
Simplicité et compacité. MD4 est aussi simple que possible sans grandes
structures de données ni programme compliqué.
Favorise les architectures « à octet de poids faible en premier ».
MD4 est optimisé pour les architectures à microprocesseurs (spécifiquement
les processeurs I n t e l ) ; des ordinateurs plus grands et plus rapides feront
les transformations nécessaires.
Après que l’algorithme ait été présenté pour la première fois, Bert DEN BOER et Antoon
B o sselaers ont cryptanalysé avec succès les deux dernières des trois rondes de l’algo
rithme [459]. Ralph M e r k l e a attaqué avec succès les deux premières rondes [459]. Eli
B iham décrit une attaque par cryptanalyse différentielle possible contre deux tiers de
MD4 [166]. Bien que ces attaques ne puissent pas être étendues à l’algorithme complet,
R iv est a renforcé l’algorithme. Le résultat est M D5.
fU p )
S0( X ,, X 2 ) = rot2((X , + X 2 ) mod 256)

5, (X l, X 2) = rot 2((X , + X 2 + 1 ) mod 256)
X, et X 2 : entrées de 8 bits
S0 et 5, : résultats de 8 bits
rot 2 (7 ’) : décalage circulaire à gauche de 2 bits de T
F ig. 18.4 - Fonction f
18.5 M D5
M D5 est une version améliorée de M D 4 [1391, 1332]. Bien que plus complexe, il est
similaire de conception et il produit également des empreintes de 128 bits.
Description de M D5
Après un traitement initial, M D5 manipule le texte d ’entrée par blocs de 512 bits
divisés en 16 sous-blocs de 32 bits. La sortie de l’algorithme est un ensemble de 4 blocs
de 32 bits qui, joints ensemble, forment une seule empreinte de 128 bits.
Tout d ’abord le message est complété de manière à ce que 64 bits de plus amèneraient
sa longueur à un multiple de 512. Ce remplissage se fait avec un seul 1 rajouté à la fin
du message suivi d ’autant de 0 que nécessaire. Ensuite, une représentation de 64 bits
de la longueur totale du message (avant que le remplissage ne soit effectué) est jointe
au résultat. Ces deux étapes servent à rendre la longueur du message multiple de 512
bits (ce qui est nécessaire pour la suite de l’algorithme), tout en s’assurant que des
messages différents n’auront pas l’air similaires après le remplissage.
Quatre variables de 32 bits sont initialisées :
A = 0x01234567
18.5 MD5 461
B = 0x89ABCDEF
C = 0xFEDCBA98
D = 0x76543210.
On les appelle « variables de chaînage ».

Maintenant, la boucle principale de l’algorithme commence. Cette boucle est effectuée
autant de fois qu’il y a de blocs de 512 bits dans le message à traiter.
Les quatre variables sont copiées dans d ’autres variables A dans A A , B dans B B , C
dans C C et D dans D D .
La boucle principale a 4 rondes (M D 4 n’avait que 3 rondes), toutes très similaires.
Chaque ronde consiste en 16 exécutions d’une opération. Chaque opération calcule une
fonction non linéaire de trois des variables A, B , C et D. Ensuite elle ajoute au résultat
la quatrième variable, un sous-bloc et une constante. Ce nouveau résultat est ensuite
décalé circulairement vers la gauche d’un nombre variable de bits et ensuite ajouté à
l’une des A , B, C, D. Finalement ce dernier îésultat remplace l’une des A, B , C, D.
Voir les figures 18.5 et 18.6.
F ig . 18.5 - Boucle principale de M D5
Il y a 4 fonctions non linéaires, une différente pour chaque ronde4 :
F (X ,Y ,Z ) = ( X A Y ) V (--X A Z)
G (X ,Y ,Z ) = ( X A Z) V (Y A -<Z)
H (X ,Y ,Z ) = X ® Y ® Z
I{X ,Y ,Z ) = Y ® (X V iZ ).
Ces fonctions sont conçues de telle manière que si les bits correspondants de X , Y et
Z sont indépendants et non biaisés, alors les bits du résultat sont aussiindépendants
et non biaisés. La fonction F est la conditionnelle bit à bit : si X , alorsY, sinon Z. La
fonction H est l’opérateur de parité bit à bit.
4. Signification des opérateurs logiques : A dén ote le « et logique » logique, V dénote le « ou in clu sif »,
i dénote la négation et ffi dénote le « ou exclu sif ».
F ig . 18.6 - Une opération de M D5
Si M .3 représente le j e sous-bloc du message (j allant de 0 à 15), et si Os représente

un décalage circulaire à gauche de s bits, les quatre opérations de base sont :
F F{a,b,c,d,M 3 ,s,ti) dénote a — b + ((a + F(b,c,d) + A i 3 -F U) <3 s),
GG(a,b,c,d,À4J,s,tl ) dénote a — b + ((a + G(b,c,d) + A i 3 + ti) O s),
H H (a,b,c,d,M j ,s,t,) dénote a = b + ((a + H(b,c,d) + M .3 + U ) O s),
lI(a,b,c,d,Al 3 ,s,ti) dénote a = b + ((a + I(b,c,d) + A4 3 + tl) O s).
Les 4 rondes (64 étapes) sont données par5 :
ronde 1 :
FF (A, B, c, D, M[ 0], 7, 0xd76aa478)

FF (D, A, B, c, M[ 1], 12, 0xe8c7b756)
FF (C, D, A, B, M[ 2], 17, 0x242070db)
FF (B, C, D, A, M[ 3], 22, Oxclbdceee)
FF (A, B, c, D, M[ 4], 7, Oxf57c0faf)
FF (D, A, B, C, M[ 5], 12, 0x4787c62a)
FF (C, D, A, B, M[ 6], 17, 0xa8304613)
FF (B, C, D, A, M[ 7], 22, Oxfd469501)
FF (A, B, C, D, M [ 8] , 7, 0x698098d8)
FF (D, A, B, C, M[ 9] , 12, 0x8b44f7af)
FF (c , D, A, B, M[10] , 17, Oxffff5bbl)
FF (B, c, D, A, M[ll] , 22, 0x895cd7be)
FF (A, B, c, D, M[12] , 7, 0x6b901122)
FF (D, A, B, C, M[13] , 12, 0xfd987193)
FF (C, D, A, B, M[14] , 17, 0xa679438e)
FF (B, C, D, A, M [15] , 22, 0x49b40821);
ronde 2 :
GG (A, B, c , D, M[ 1], 5, Oxf61e2562)

5. N o te d u tr a d u c t e u r : M [j] d é n o t e le j e so u s -b lo c .
18.5 MD5 463
GG (D , A, B, c, M[ 6 ] , 9 , 0 x c0 4 0 b 3 4 0 )
GG (C , D, A, B, H t ll], 14, 0x265e5a51)
GG (B , c, D, A, M[ 0 ] , 2 0 , 0 x e9 b6c7aa)
GG (A , B, C, D, M[ 5 ] , 5 , 0 x d 6 2 f1 0 5 d )
GG (D , A, B, c, M [1 0 ], 9 , 0x02441453)
GG (C , D, A, B, M[1 5 ] , 1 4 , 0 x d 8 a le 6 8 1 )
GG (B , c, D, A, M[ 4 ] , 2 0 , 0 x e 7 d 3 fb c 8 )
GG (A , B, C, D, M[ 9 ] , 5, 0 x 2 1 e lc d e 6 )
GG (D , A, B, c, M [1 4 ], 9, 0 x c3 3 7 0 7 d 6 )
GG ( c , D, A, B, M[ 3 ] , 14, 0 x f4 d 5 0 d 8 7 )
GG (B , c , D, A, M[ 8 ] , 20, 0 x 4 5 5 a l4 e d )
GG (A , B, c , D, M [13] , 5 , 0xa9e3e905)
GG (D , A, B, c, M[ 2 ] , 9 , O x fc e fa 3 f8)
GG (C , D, A, B, M[ 7 ] , 1 4 , 0 x 6 7 6 f0 2 d 9 )
GG (B , c , D, A, M [1 2 ], 2 0 , 0 x 8 d 2 a 4 c 8 a );
ronde 3 :
HH (A , B, c, D, M[ 5] 4 , 0 x fffa 3 9 4 2 )
HH (D , A, B, c, M[ 8 ] u , 0x877l f 681)
HH (c , D, A, B, M [ll] 16, 0x6d9d6122)
HH (B , c, D, A, M [14] 2 3 , 0 x fd e 5 3 8 0 c )
HH (A , B, c, D, M[ 1] 4 , 0xa4beea44)
HH (D , A, B, c, M[ 4 ] u , 0 x 4 b d e c fa 9 )
HH (C , D, A, B, M[ 7] 1 6 , O x f6 b b 4 b 6 0 )
HH (B , c, D, A, M [10] 2 3 , 0 x b e b fb c 7 0 )
HH (A , B, c, D, M [13] 4 , 0x 2 8 9b7ec6)
HH (D , A, B, c , M[ 0] u , 0 x e a a l2 7 f a )
HH (c , D, A, B , M[ 3 ] 1 6 , 0 x d 4 e f3 0 8 5 )
HH (B , c, D, A, M[ 6] 2 3 , 0 x 0 4 8 8 ld 0 5 )
HH (A , B, c, D, M[ 9] 4 , 0 x d 9 d 4 d 0 39 )
HH (D , A, B, c , M [12] 11, 0xe6db99e5)
HH (C , D, A, B, M [15] 16, O x lfa 2 7 c f8)
HH (B , c, D, A, M[ 2] 2 3 , 0xc4a c5 6 65 )
ronde 4 :
1 1 (A , B , c , D, M[ 0 ] , 6, O x f4 2 9 2 2 4 4 )
II (D , A, B, c , M[ 7 ] , 1 0 , 0 x 4 3 2 a ff97)
II (c , D, A, B, M [14] , 1 5 , 0xab9423a7)
II (B , C, D, A, M[ 5 ] , 2 1 , 0 x fc 9 3 a 0 3 9 )
II (A , B, c , D, M [12] , 6, 0 x 6 5 5 b 5 9 c3 )
II (D , A, B, C, M[ 3 ] , 1 0 , 0 x 8 f0 c c c 9 2 )
II (C , D, A, B, M [10] , 1 5 , O x ffe ff4 7 d )
II (B , c , D, A, M[ 1 ] , 2 1 , 0 x 8 5 8 4 5 d d l)
II (A , B, c , D, M[ 8 ] , 6, 0 x 6 fa 8 7 e 4 f)
II (D , A, B, c , M [15] , 1 0 , 0 x fe 2 c e 6 e 0 )
464 Chapitre 18 Fonctions de hachage à sens unique.
II (C , D, A, B, M[ 6 ] , 1 5 , 0xa3014314)
II (B , C, D, A, M [13] , 2 1 , 0 x 4 e 0 8 1 1 a l)
II (A , B, c , D, M[ 4 ] , 6, 0 x f7 5 3 7 e 8 2 )
II (D , A, B, c , M [ll] , 10, 0 x b d 3 a f2 3 5 )
II ( c , D, A, B, M[ 2 ] , 1 5 , 0x2ad7d2bb)
II (B , c , D, A, M[ 9 ] , 2 1 , 0xeb86d391)
Les constantes tz furent choisies de la manière suivante :
À l’étape i, L est la partie entière de 232 x abs(sin(*)), où i est exprimé en

radian.
Après tout cela, A, B, C et D sont ajoutées à AA , B B , C C , D D respectivement et

l’algorithme continue avec le bloc suivant de données. Le résultat final est la jointure
de AA, B B , C C , D D .
Sécurité de M D5
Ron R i v e s t décrit les améliorations de M D5 par rapport à M D 4 [1332] :
1. Un quatrième ronde a été ajoutée.
2. Chaque étape a maintenant une constante additive unique.
3. La fonction G de la 2e ronde remplace (X A Y ) V (X A Z) V (Y A Z) par (X A

Z ) V ( f A ~'Z), afin de rendre G moins symétrique.
4. Chaque étape ajoute maintenant le résultat de l’étape précédente. Cela favorise

un « effet d’avalanche » plus rapide.
5. L’ordre d’accès des sous-blocs est changé dans les 2e et 3e rondes afin de rendre
les motifs moins similaires.
6. Le nombre de décalages de chaque ronde a été approximativement optimisé pour

obtenir un effet d ’avalanche plus rapide. Les décalages circulaires sont différents
d’une ronde à l’autre.
Tom BERSON a essayé d ’utiliser la cryptanalyse différentielle contre une seule ronde de
M D5 [151] mais son attaque est loin d’être efficace contre les 4 rondes. Une attaque
nettement mieux réussie de Bert DEN B o e r et Antoon BOSSELAERS peut produire des
collisions en utilisant la fonction de compression de M D5 [460, 1344, 1348]. Cela ne
donne pas des attaques pratiques contre des applications concrètes de M D5 et cela
ne remet pas en cause l’utilisation de M D5 dans les algorithmes de chiffrement à la
L u b y - R a c k o f f (voir § 14.11). Cela veut simplement dire que l’un des principes de
conception de M D 5— concevoir une fonction de compression résistante aux collisions -
a été violé. Même s’il est vrai que « la fonction de compression semble posséder une
faiblesse, mais sans conséquence sur la sécurité de la fonction de hachage en pratique »,
je reste circonspect quant à l’utilisation de M D5
18.6 MD2 465
18.6 M D2
MD2 est encore une autre fonction de hachage à sens unique conçue par Ron
R i v e s t [810,1346]. Elle est utilisée, avec M D 5, dans les protocoles PE M (voir § 24.10).
La sécurité de M D 2 dépend d’une permutation aléatoire de l’ensemble de tous les
octets. Cette permutation est fixée, et dépend des décimales de n. Elle sera noté
Sq,Si, . . . ,5255• Pour calculer l’empreinte d ’un message A4, procédez ainsi :
1° Complétez le message avec i octets de valeur i de sorte que sa longueur en

octets devienne un multiple de 16.
2 ° Accolez une somme de contrôle de 16 octets au message.

3° Initialisez un bloc de 48 octets : X o ,X k, . . . , A 4 7 . Mettez les 16 premiers octets
de X à zéro, copiez les 16 premiers octets du message dans les 16 suivants, et
remplissez les 16 derniers avec le résultat de la combinaison par ou exclusif du
premier tiers de X avec le second tiers de X .
4° Appliquez la fonction de compression :
t= 0
Pour j variant de 0 à 17 et k variant de 0 à 47, effectuer:
t = X k® S t
Xk= t
t = (t + j ) modulo 256
5° Copiez le deuxième morceau de 16 octets du message dans le second tiers de X

et remplissez le troisième tiers de X avec le résultat de la combinaison par ou
exclusif du premier tiers de X avec le second tiers de X .
6° Exécuter l’étape 4■ Répétez les étapes 5 et 4 avec chaque morceau de 16 octets

du message.
7° Les 16 premiers octets de X constituent l ’empreinte du message.
Bien qu’aucune faiblesse n’ait été trouvée dans M D2 (consulter [1273]), il est plus lent
que la plupart des autres fonctions de hachage à sens unique suggérées.
18.7 Algorithme sûr de hachage SHA

L’Institut national des standards et de la technologie américain ainsi que l’Agence
nationale de sécurité américaine ont conçu l’algorithme sûr de hachage (SHA pour
« Secure Hash Algorithm ») pour être utilisé dans le D SA (voir § 20.2) [1174]6. D ’après
le « Fédéral Register » [542] :
« Un standard fédéral de traitement de l’information [américain] (FIPS

pour « Fédéral Information Processing Standard ») est proposé pour le
standard de hachage sûr (SHS). Cette proposition de standard spécifie un
6. Le standard est le « standard d e hachage sûr » (SHS pou r « S ecu re H a sh S ta n d a rd ») ; SH A est

l’algorithm e utilisé dans ce standard.
algorithme de hachage sûr (SH A) pour être utilisé avec le standard de

signature numérique [(DSS)]. De plus, pour les applications ne nécessitant
pas de signatures numériques, le SHA doit être utilisé chaque fois qu’un
algorithme de hachage sûr est requis pour les applications fédérales. »
E t:
« Ce standard spécifie un algorithme de hachage sûr (SH A), qui est né
cessaire pour garantir la sécurité de l’algorithme de signature numérique
(D SA ). Quand un message de n’importe quelle longueur inférieure à 264
est donné en entrée, le SHA produit une sortie de 160 bits appelée mes
sage abrégé7. Le message abrégé est alors fourni comme entrée au DSA
qui calcule la signature du message. Signer le message abrégé plutôt que
le message d’entrée améliore souvent l’efficacité du processus parce qu’ha
bituellement le message abrégé est nettement plus court que le message
d’entrée. Le même message abrégé doit être obtenu par le vérificateur de
la signature quand la version reçue du message est utilisée comme entrée
à la fonction SHA. Le SHA est qualifié de sûr parce qu’il est conçu pour
qu’il soit impossible de retrouver par le calcul un message correspondant
à un message abrégé donné, ou de trouver deux messages différents qui
produiraient le même message abrégé. Tout changement à un message en
transit produira, avec une très haute probabilité, un message abrégé diffé
rent et la vérification de la signature échouera. Le SHA est basé sur des
principes similaires à ceux utilisés par le professeur Ronald L. R i v e s t du
M IT quand il conçut l’algorithme de message abrégé M D 4 [1330] et est
étroitement calqué sur cet algorithme. »
SHA produit des empreintes de 160 bits, ce qui est plus long que ce que produit MD5.
Description du SHA
Au départ, le message est complété de manière à ce que sa longueur en bits soit un
multiple de 512. Le remplissage est exactement le même que celui de M D5 : ajoutez
d’abord un 1 suivi d’autant de 0 que nécessaire pour que 64 bits manquent par rapport
à un multiple de 512 et enfin une représentation en 64 bits de la longueur du message
avant remplissage.
Cinq variables (M D 5 avait 4 variables, mais SHA produit une empreinte de 160 bits)
sont initialisées de la façon suivante :
A = 0x67452301
B = 0xEFCDAB89
C = 0x98BADCFE
D = 0x10 3 2 5 4 7 6
E = 0xC3D2ElF0.
La boucle principale de l’algorithme commence alors. Elle traite le message 512 bits à
la fois et continue tant qu’il y a des blocs de 512 bits.
7. N ote du traducteur : le term e « m e s s a g e a b r ég é » est utilisé ici com m e traduction littérale de
l’expression anglaise « m e s s a g e d tg est ». Il s’ agit en fait de ce qui a été appelé tou t au long de cet
ouvrage une « e m p r e in te ».
18.7 Algorithme sûr de hachage S H A 467
Premièrement, les 5 variables sont copiées dans des variables différentes : A dans AA ,
B dans B B , C dans C C , D dans D D et E dans E E .
La boucle principale a 4 rondes de 20 opérations chacune (M D 5 a 4 rondes de 16
opérations chacune). Chaque opération effectue une opération non linéaire sur trois
des variables A, B , C et D , et effectue des décalages et des additions similaires à ceux
de M D5.
L’ensemble des opérations non linéaires de SHA sont données par :
ft(X ,Y ,Z ) = (X A Y ) V (~>X A Z), pour t entre 0 et 19,

ft(X ,Y ,Z ) — X © Y © Z , pour t entre 20 et 39,
ft(X ,Y ,Z ) = ( X A Y ) V (X A Z) V (Y A Z ), pour t entre 40 et 59,
ft(X ,Y ,Z ) = X © Y © Z, pour t entre 60 et 79.
Cet algorithme utilise également 4 constantes8 :
K t = 0x5A 827999, pour t entre 0 et 19,

K t = 0x6ED9EBAl, pour t entre 20 et 39,
K t — 0x8FlBBCDC,pour t entre 40 et 59,
Kt — 0xCA62ClD6, pour t entre 60 et 79.
Le bloc du message découpé en 16 mots de 32 bits (A4o à A4is) est transformé en

80 mots de 32 bits (Wo à W 79 ) en utilisant l’algorithme suivant9 :
Wt — M-t, pour t — 0 à 15,

W t = Wt- 3 © Wt s © W t- 1 4 © W t- 1 6 , pour t = 16 à 79.
Si t est le numéro de l’opération (de 1 à 80), A4 , représentele j esous-blocdu message

(j allant de 0 à 15), et que Os représente un décalagecirculaire à gauche de s bits,
alors la boucle principale ressemble à :
Pour t variant de 0 à 79,
T E M P = (A o 5) + ft(B ,C ,D ) + E + W t + K t
E —D
D —C
C = (B o 30)
B —A
A = TEM P.
La figure 18.7 illustre une opération Le décalage des variables a le même effet que
l’utilisation de différentes variables à différents endroits dans MD5.
Après tout cela, A, B , C, D et E sont ajoutés à AA , B B , C C , D D et E E res
pectivement et l’algorithme passe au bloc de données suivant. La sortie finale est la
juxtaposition de A A , B B , C C , D D et E E .
8. Si vous vous dem andez d ’où ces constantes viennent: 0x5A827999 — \ A j 4 . 0x6ED9EBAl = v^3/4,
0x8FlBBCDC = \Æ /4 et 0xCA62ClD6 = vT Ô /4 .
9. Une anecdote intéressante : la spécification originale de SH A ne contenait pas le décalage circu
laire à gauche. La m odification « corrige une im perfection technique qui rendait le standard moins sûr
que prévu » [545]. La N SA a refusé de révéler la nature exacte de cette im perfection.
F ig. 18.7 - Une opération de SHA
Sécurité de SHA
SHA est très similaire à M D4. Les changements principaux sont l’addition d’une étape
d’expansion, la sommation de la sortie de l’étape précédente à l’entrée de l’étape sui
vante pour obtenir un effet d ’avalanche. Ron R i v e s t a rendu publics les choix de
conception de M D5 mais les concepteurs de SHA ne l’ont pas fait. Voici les améliora
tions apportées par R lV E S T dans M D 5 par rapport à M D 4 et leur comparaison avec
SH A:
1. « Une quatrième ronde a été ajoutée. » SHA fait de même. Toutefois, la 4e ronde
de SHA utilise la même fonction / que la 2e ronde.
2. « Chaque étape a maintenant une constante additive unique. » SHA garde le

schéma de M D4 en réutilisant la même constante au sein de chaque groupe de
20 opérations.
3. « La fonction G de la 2e ronde remplace (X A Y ) V (X A Z) V (Y A Z) par

( X A i ? ) V (Y A -'Z ), afin de rendre G moins symétrique. » SH A utilise la fonction
de M D 4 : (A A Y ) V (X A Z) V (F A Z)
18.8 R IP E -M D 469
4. « Chaque étape ajoute maintenant le résultat de l’étape précédente. Cela favorise

un effet d’avalanche plus rapide. » Ce changement a également été effectué dans
SHA. La différence dans SHA est qu’une cinquième variable est ajoutée et non
pas B , C ou D qui sont déjà utilisées dans f t. Ce changement subtil rend l’attaque
DEN B o e r - B o s s e l a e r s contre M D5 impossible contre SHA.
5. « L ’ordre d’accès des sous-blocs est changé dans les 2e et 3e rondes afin de rendre
les motifs moins similaires. » SHA est complètement différent, puisqu’il utilise
un code cyclique correcteur d ’erreurs.
6. « Le nombre de décalages de chaque ronde a été approximativement optimisé

pour obtenir un effet d’avalanche plus rapide. Les quatre décalages circulaires
utilisés dans une ronde sont différents de ceux des autres rondes. » SHA utilise
un décalage circulaire constant dans chaque ronde. Le nombre de décalages est
un nombre premier par rapport à la taille des mots, tout comme dans MD4.
Cela conduit à la comparaison suivante: SHA ressemble à M D 5 avec l’addition d’une

transformation d’« expansion », une ronde supplémentaire et un meilleur effet d ’ava
lanche; M D 5 ressemble à M D4 avec un mélange de bit amélioré, une ronde supplé
mentaire et un meilleur effet d ’avalanche.
Il n’y a pas d’attaque cryptographique connue contre SHA. Et comme il produit une
empreinte de 160 bits, il est plus résistant à une attaque exhaustive (y compris l’attaque
des anniversaires) que les autres algorithmes couverts par ce chapitre.
18.8 R IP E -M D
R IP E -M D a été développé par le projet R IP E [1316] de la Communauté européenne
(voir § 25.7). Cet algorithme est une variante de M D4 conçue pour résister à toutes
les attaques cryptanalytiques connues. Les rotations et l’ordre des mots du message
sont modifiés. De plus, deux versions de l’algorithme, qui diffèrent seulement par les
constantes, sont exécutées en parallèle. Après chaque bloc, la sortie des deux versions
est ajoutée aux variables de chaînage. Il semble que cela rende l’algorithme très résistant
à la cryptanalyse.
18.9 HAVAL
H AVAL est une fonction de hachage à sens unique de longueur variable [1648]. C’est
une variante de M D 5. HAVAL manipule les messages par blocs de 1024 bits, deux fois
la taille de M D5. Il utilise des variables de chaînage de 32 bits, deux fois la longueur de
celles de M D5. Il a un nombre variable de rondes, de 3 à 5 (chaque ronde a 16 étapes),
et il peut produire des empreintes de 128, 160, 192, 224 et 256 bits.
HAVAL remplace les fonctions non linéaires simples de M D5 par des fonctions à
7 variables fortement non linéaires. Chaque ronde utilise une seule fonction mais, à
chaque étape, une permutation différente est appliquée aux entrées. Il y a un nouvel
ordre de traitement des blocs du message et chaque étape (sauf la première) utilise une
constante additive différente. Il y a aussi deux rotations.
Le cœur de l’algorithme est10 :
T E M P = (f(j,A ,B ,C ,D ,E ,F ,G ) < 7 ) + (H < 11) + Af[i][r(j)] + K (j);

H = G; G = F ; F = E\ E = D ; D = C ; C = B ; B — A ; A — T E M P .
Le nombre variable de rondes et la longueur variable de sortie donnent 15 versions

différentes de l’algorithme L’attaque de DEN B o e r et B o s s e l a e r s contre M D5 [460]
n’est pas applicable à HAVAL à cause de la rotation appliquée a H .
18.10 Autres fonctions de hachage à sens

unique
Ron R i v e s t a conçu une autre fonction de hachage, appelée MD3. Elle avait plusieurs
imperfections et elle n’est jamais sortie du laboratoire, bien qu’une description ait
récemment été publiée dans [1346].
Un groupe de chercheurs de l ’ University of Waterloo a proposé une fonction de hachage
à sens unique basée sur l’exponentiation itérée dans Z j 2593 [26]. Dans ce schéma, un
message est divisé en blocs de 593 bits. Les blocs sont successivement soumis à I’ex
ponentiation, en commençant par le premier bloc. Chaque exposant est le résultat du
calcul avec le bloc précédent ; le premier exposant est donné par un vecteur d ’initiali
sation.
Ivan D a m g À r d a conçu une fonction de hachage à sens unique basée sur le problème
des empilements (voir § 19.2) [416] ; il peut être cassé en 232 opérations environ [294,
1242, 787].
Les automates cellulaires de Steve W o l f r a m [1611] ont été proposés comme base
pour des fonctions de hachage à sens unique. Une première réalisation [239] n’est pas
sûre [1060, 410]. Une autre fonction de hachage à sens unique, CELLHASH [388, 410] et
une version améliorée S u b h a s h [388, 405, 407] sont basées sur des automates cellulaires
et sont toutes les deux destinées a des réalisations matérielles. B o o g n i s h mélange les
principes de conception de C e l l h a s h avec ceux de M D 4 [405, 409]. S t e p R i g h t U p
peut aussi servir de fonction de hachage à sens unique [405].
Claude ScHNORR a proposé une fonction de hachage à sens unique basée sur la trans
formée de Fourier discrète, appelée F F T H a s h , au courant de l’été 1991 [1402] ; elle
fut cassée quelques mois plus tard par deux groupes indépendants [406, 91]. S c h n o r r a
proposé une version révisée, appelée F F T H a s h II (la version précédente fut rebapti
sée F F T - H a s h I) [1405] qui fut cassée quelques semaines plus tard [1569]. S c h n o r r a
proposé d ’autres modifications [1407, 1408] mais, tel qu’il est maintenant, l’algorithme
est nettement plus lent que les autres de ce chapitre. Une autre fonction du nom de
S L 2 [1534] n’est pas sûre [307].
D ’autres travaux théoriques sur la construction de fonction de hachage à sens unique
à partir de fonctions à sens unique et de permutations à sens unique sont décrits
dans [415, 1147, 1354].
10. N ote du traducteu r: le lecteur intéressé trouvera la description des intervalles p ou r i e t j , ainsi
que la façon de diviser le message M et la signification de la fonction r dans l’ article original [1648].
18.11 Utilisation d’algorithmes de chiffrement par blocs 471
18.11 Utilisation d’algorithmes de chiffre

ment par blocs
Il est possible d’utiliser un algorithme de chiffrement par blocs comme fonction de
hachage à sens unique. L ’idée est que si nous savons que l’algorithme de chiffrement
par blocs est sûr, alors la fonction de hachage à sens unique sera sûre aussi.
La méthode la plus évidente consiste à utiliser l’algorithme en mode C B C ou C FB
avec une clef et un vecteur d’initialisation fixes, et à prendre le dernier bloc de texte
chiffré comme empreinte. Ces méthodes sont décrites dans plusieurs standards utilisant
le D E S : avec les deux modes dans [1156], avec le mode C B C dans [57, 58, 65]. Ce
n’est pas assez pour les fonctions de hachage à sens unique, bien que cela suffise pour
un C A M (voir § 18.14) [33].
Une approche plus intelligente est d ’utiliser les blocs du message comme clef, la valeur
précédente d’empreinte étant l’entrée et l’empreinte courante étant la sortie.
En fait, les fonctions de hachage proposées sont plus complexes. La taille de bloc est
en général la longueur de la clef et la taille de l’empreinte est la taille de bloc. Comme
la plupart des algorithmes de chiffrement par blocs ont 64 bits, plusieurs schémas sont
conçus pour engendrer une empreinte qui a deux fois la taille d’un bloc.
En supposant que la fonction de hachage est correcte, la sécurité du schéma est ba
sée sur celle de la fonction de bloc sous-jacente. Il y a cependant des exceptions. La
cryptanalyse différentielle contre les fonctions de bloc est plus facile quand elle est uti
lisée dans une fonction de hachage que dans un algorithme de chiffrement : la clef est
connue, aussi peut-on appliquer certaines astuces ; une seule paire concordante suffit au
succès de l’attaque ; et vous pouvez générer au tant de texte en clair que vous voulez.
Quelques travaux sur le sujet se trouvent dans [1274, 858, 1324].
Ce qui suit est un résumé des différentes fonctions de hachage à sens unique qui sont
parues dans la littérature [937, 1471, 1273]. Les affirmations concernant les attaques
contre ces schémas font l’hypothèse que les chiffrements par blocs sous-jacents sont
sûrs; autrement dit, que la meilleure attaque contre eux est l’attaque exhaustive.
Une mesure qui s’avère utile en matière de fonctions de hachage à base d’algorithme
de chiffrement par blocs est le ta u x d e hachage, c ’est à dire le nombre de blocs de
n bits du message traités par chiffrement, où n est la taille de bloc dans l’algorithme.
Plus ce taux est grand, plus l’algorithme est rapide11.
Schémas où empreintes et blocs ont même taille

Le schéma général est le suivant (voir la figure 18.8) :
H o — I h , o ù I j{ est un valeur initiale aléatoire,

Hi = E a (B ) 0 C.
A, B et C sont à prendre parmi les termes A4», H i - 1 , (A4,; © H i - j), ou une constante
(supposée être 0). Le message est divisé en morceaux de la taille d’un bloc, les A-fr, qui
sont traités individuellement. Il y a de plus une sorte de renforcement MD, éventuelle
ment la même procédure de remplissage que dans M D5 et SHA.
11. C ette mesure est donnée avec la définition opposée dans [1273], mais la définition donnée ici est
plus intuitive et plus largement utilisée. C ela peut être source de confusion.
F ig . 18.8 - D a v ie s - M eyer
Chacune des trois variables peut prendre une des quatre valeurs possibles, ce qui donne
en tout 64 schémas possibles. Bart P r e n e e l les a tous étudiés [1273].
Quinze d ’entre eux sont trivialement faibles car le résultat n’y dépend pas de l’une
des entrées. Trente sept d’entre eux ne sont pas sûrs pour des raisons plus subtiles. Le
tableau 18.1 donne la liste des douze schéma restants : les quatres premiers résistent à
toutes les attaques (voir la figure 18.9) et les huits autres résistent à toutes sauf une
attaque du point fixe, qui ne vaut pas la peine de s’inquiéter.
Clef
M,
Chiffre
H,.| p
Clef Clef
— *W“ Af, <5
Chiffre Chiffre
F ig . 18.9 - Les quatres fonctions de hachage sûre où empreintes et blocs ont même
taille
Le premier schéma a été décrit dans [1033]. Le troisième a été décrit dans [526, 1111,
1112] et proposé comme standard ISO [1142]. Le cinquième est dû à Cari M e y e r ,
mais connu sous le nom de D a v i e s - M e y e r dans la littérature [1608, 1609, 434, 1033].
Le dixième a été proposé comme un mode fonction de hachage pour LO K I [278].
Les premier, deuxième, troisième, quatrième, cinquième, et onzième schémas ont un
taux de hachage de 1 ; la longueur de la clef est égale à la longueur des blocs. Les autres
ont un taux de k /n où k est la longueur de la clef. Cela signifie que si la clef est plus
courte que les blocs de l’algorithme, alors les blocs de message ne peuvent pas être plus
long que la clef. Il n’est pas recommandé d ’utiliser des blocs de message plus longs que
la clef, même si les blocs de l’algorithme de chiffrement sont plus courts que la clef.
Si l’algorithme par blocs a comme le DES une propriété de complémentation, ou des
clefs faibles, il existe une attaque supplémentaire possible contre les douze schémas.
18.11 Utilisation d’algorithmes de chiffrement par blocs
T a b . 18.1 - Fonctions de hachage sûres où empreintes et blocs ont même taille
H = Ehx_ j (Af*) © M i
H = ( M i © H i-x ) © Al* © l î i -1
H = Eh i_1(Mi) © if i-i © Al*
H = E h,.* (Al* © t fi-i) © Al*
H — E m ,(H î—i ) © H i - i
H — £?M.(Ati © -H*—i) © Al* ffi Hi—i
H — E m %(H i- 1) ffi A li
H = Em ,(Mi ffi Hi-i) © Hi-1
H = E m ,®h (Ali) © Ali
H = (# i-l) © # i-l
H, = EM x<
£ h x__x(M i) © H i-i
H = Eûmh-1 (H i- 1) © M i _________
L’attaque n’est pas très dangeureuse et ne vaut pas la peine de s’inquiéter. Cependant,
vous pouvez la contrecarrer en fixant les bits 2 et 3 de la clef à « 01 » ou « 10 »
[1085, 1113]. Cela réduit bien sûr la longueur de la clef de 2 bits (à 54bits pour leDES
par exemple), et aussi le taux de hachage.
Les schémas suivants, extraits de la littérature, ne sont pas sûrs.
Ce schéma [1293] a été cassé dans [373] :
H = E Mx(H i-\)
D a v i e s et P r ic e ont proposé une variante qu i fait passer le message entier deux fols à
[432, 433]. L ’a ttaque de CO PPER SM ITH m arche sur cette variante
travers l ’algorithm e
sans dem ander beaucoup plus de calculs [373],
Un autre schéma [432, 464] n’est pas sûr non plus [1608] :
H i = E m & H i- x( H )
i-1
Il est m ontré dans [1033] que le schém a suivant n ’est pas sûr (c est une constante) :
Lf* = Ec(M i ffi H i- x) © A f i © Hi- !
Davies-Meyer modifié
L a i et M a s s e y ont modifié la technique de D a v i e s - M e y e r pour pouvoir l’utiliser
avec le chiffre ID E A [941, 937]. ID E A a une taille de bloc de 64 bits et une taille de
clef de 128 bits. Ce schéma est :
Ho = / , où I est une valeur initiale quelconque,

Hi = % _ llM t( E - i ) -
Cette fonction hache un message par blocs de 64 bits et produit une empreinte de 64
bits (voir la figure 18.10).
Il n’existe pas d’attaque connue contre ce schéma qui soit plus facile que l’attaque
exhaustive.
Chiffre
| Clef |
i
t
Airf
F ig . 18.10 - D a v ie s - M eyer modifié
Preneel—Bosselaers-Govaerts—Vandewalle
Cette fonction de hachage, proposée pour la première fois dans [1277], engendre une
empreinte qui a deux fois la longueur de bloc de l’algorithme de chiffrement ; un algo
rithme à 64 bits donne une empreinte de 128 bits.
Avec un algorithme de chiffrement par blocs à 64 bits, ce schéma produit deux em
preintes de 64 bits, Gt et H t, qui sont jointes pour produire une empreinte de 128 bits.
Avec la plupart des algorithmes de chiffrement par blocs, la taille de bloc est de 64
bits. Deux blocs de messages adjacents Lt et llt ayant chacun la taille de la clef sont
hachés ensemble.
Go = I gi où IG est une valeur initiale quelconque,

H0 = I h -, o ù I h e s t u n e a u t r e v a le u r in itia le q u e lc o n q u e ,
Gt = E L,©//,_! (H, ffi © Rt © Gt -1© Ht- 1,
H, = E l ,® r ,(H t-1 © G ,_ i) ffi Li © G\_i ffi H j_i.
L a i a montré des attaques contre ce schéma qui, dans certains cas, rendent l’attaque
des anniversaires facilement applicable [937, 935]. P r e n e e l [1273] et C o p p e r s m i t h
[377] ont également des attaques contre ce schéma. Ne l’utilisez pas.
Quisquater—Girault
Ce schéma, proposé pour la première fois dans [1290], produit également une empreinte
qui a deux fois la taille du bloc de chiffrement. Deux blocs L, et lii, chacun de la taille
de la clef, sont hachés ensemble.
Go — I gi où I g est une valeur initiale quelconque,

Ho = I h , où I r e s t u n e a u t r e v a le u r in it ia le q u e lc o n q u e ,
W i = E l , (G t_ i ffi R t ) ffi R t ffi H t_ i ,
Gj = Efi^W t ffi Lj) ffi G î - i ffi H t—i ffi L , ,
Hj = W , ffi Gt i-
Ce schéma est apparu dans une ébauche de standard ISO de 1989 [760] mais fut
abandonné dans une version ultérieure [761]. Les problèmes de sécurité avec ce schéma
furent identifiés dans [1113, 937, 1273, 377]12. Dans certaines circonstances, l’attaque
des anniversaires est soluble avec une complexité de 232 au lieu de 264, par attaque
exhaustive. N’utilisez pas ce schéma.
12. En fait, la version publiée a été renforcée après que la version présentée à la conférence fut
attaquée.
LOKI à double bloc

Cet algorithme est une variante de Q u i s q u a t e r - G i r a u l t , conçue spécifiquement pour
être utilisée avec L O K I [278]. Les paramètres sont les mêmes que dans Q u i s Q U A T E R -
G ir a u l t .
Go = Ig , où I g est une valeur initiale quelconque,

Ho — Ih , où Ih est une autre valeur initiale quelconque,
W t — Æ ? i , ,© g , i ( G i - 1 © H i ) © H , © H i —1 ,
Gi = £ 'h ,© jî ,_1(Wi ffi Li) ffi Gi- 1 ffi Hi- 1 ffi Li,
Hx = W i ® G t- i .
Une fois de plus, dans certaines circonstances, l’attaque des anniversaires est aisément
soluble [937, 935, 1273, 377, 376]. N’utilisez pas ce schéma.
Davies-Meyer parallèle
Il s’agit encore d ’une tentative d ’algorithme de taux de hachage 1 produisant une
empreinte deux fois plus longue que les blocs [738].
Go = I g , où I g est une valeur initiale quelconque,

H o = I h , où I h est une autre valeur initiale qu elcon qu e,
Gi = ELt®Rz(G i-i ffi Li) ffi Li ffi Hi—1,
Hi = E Lt {H i-! ffi Ri) ffi Ri ffi H i - 1 .
Malheureusement, ce schéma n’est pas sûr non plus [939, 863]. Il s’avère qu’une fonction
d’empreinte de longueur double et de taux de hachage 1 ne peut pas être plus sûre que
D a v i e s - M e y e r [863],
Davies-Meyer en tandem et de front

Une autre manière de contourner les limitations inhérentes aux chiffrements par blocs
avec une clef de 64 bits, est d ’utiliser un algorithme avec une clef de 128 bits et des
blocs de 64 bits, tel qu’ID E A (voir § 13.9). Ces deux schémas produisent une empreinte
de 128 bits et ont un taux de hachage de 1/2 [941, 937].
Dans ce prem ier schém a, d eu x fon ction s D a v ie s —M e y e r m odifiées travaillent en tan
dem (voir la figure 18.11).
Go = Ig , où Ig est une valeur initiale quelconque,

H0 = I h , où I h est une autre valeur initiale quelconque,
W t = EGt- UM i(H i-!),
G t ■= G i - i ffi E M t, w , ( G i —1 ),
Hi = W i ffi H i-i.
Le schéma suivant utilise deux fonctions D a v ie s - M eyer modifiées de front (voir la

figure 18.12).
G 0 = I , où I est une valeur initiale quelconque,

g g
Ho = Ih , o ù Ih est une autre valeur initiale quelconque,

Gi = Gt-i ffi (“ "Gi—i),
Hi ~ H ^ 1 ffi E G , - 1, M , {Ht-i).
F ig . 1 8 .1 1 - D a v ie s - M eyer en tandem
Dans les deux schémas, les deux empreintes de 64 bits G l et IIi sont juxtaposées pour
former une unique empreinte de 128 bits.
Pour autant que l’on sache, ces algorithmes ont la sécurité idéale pour des fonctions de
hachage à 128 bits : trouver un message qui a une empreinte donnée nécessite 2128 tenta
tives, et trouver deux messages qui ont la même empreinte nécessite 264 tentatives— en
faisant l’hypothèse qu’il n’y pas de meilleur moyen d ’attaquer l’algorithme de chiffre
ment par bloc que l’attaque exhaustive, bien entendu.
M D C —2 et M D C —4
M D C -2 et M D C -4 ont été développés par IBM [1085, 1089]. M D C -2 qui est parfois
appelé IscMeyer-Schilling est pris en considération pour devenir un standard AN SI et
ISO [62, 761] ; une variante a été proposée dans [767]. M D C -4 est spécifié pour le
projet R IP E [1316] (voir § 25.7). La spécification utilise le DES comme fonction de
bloc (il faut quatre chiffrements DES pour traiter un seul bloc de message de 64 bits),
bien qu’en théorie, n’importe quel autre algorithme puisse être utilisé.
M D C -2 a un taux de hachage de 1/2 et produit une empreinte qui a deux fois la
longueur d ’un bloc de chiffrement. Il est illustré par la figure 18.13. M D C -4 produit
aussi une empreinte qui a deux fois la longueur d ’un bloc de chiffrement et a un taux
de hachage de 1/4 (voir la figure 18.14.
Ces schémas ont été analysés dans [937, 1273]. Ils sont sûr au vu de la puissance actuelle
F i g . 18.12 - D a v ie s - M eyer de front

F ig . 18.13 - M D C -2
des ordinateurs, mais ils ne sont pas aussi sûrs que ce que leurs concepteurs avaient
estimé. Si l’algorithme de chiffrement est le DES, ils ont été examinés sous l’angle de
la cryptanalyse différentielle [1273].
M DC -2 et M D C -4 sont tous les deux brevetés [226].
AR
La fonction de hachage A R a été développée par A l g o r i t h m i c R e s e a r c h , L t d . et
distribuée par ISO à dans un but informatif uniquement [1141]. Sa structure fonda-
F i g . 18.14 - M D C - 4
Chapitre 18 Fonctions de hachage à sens unique
mentale est une variante de l’algorithme par blocs (le DES en l’occurrence) en mode
C B C . Les deux derniers blocs de texte chiffré, une constante et le bloc de message
courrant sont combinés par ou exclusif puis chiffrés par l’algorithme. L ’empreinte est
constituée des deux derniers blocs de texte chiffré calculés. Le message est traité deux
fois avec deux clefs différentes, la fonction a donc un taux de hachage de 1 / 2 . La pre
mière clef est 0 x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 , la seconde est 0 x 2 A 4 1 5 2 2 F 4 4 4 6 5 0 2 A , et c vaut
0 x 0 1 2 3 4 5 6 7 8 9 A B C D E F . Le résultat est comprimé en une seule empreinte de 1 2 8 bits.
Consulter [752] pour les détails.
Ih = E K { M t © 77,_i © 77,_2) © -A4,
Cela a l’air intéressant, mais ce n’est pas sûr. Après le traitement d ’une somme de
données considérable, il devient possible de trouver facilement des collisions pour cette
fonction de hachage [419].
GOST
Cette fonction vient de Russie, elle est spécifiée dans le standard G O S T R 34.11-94
[659]. Elle utilise l’algorithme de chiffrement par blocs G O S T (voir § 14.1), bien qu’en
théorie elle fonctionnerait avec n’importe quel algorithme par blocs de 64 bits et de
clef de 256 bits. La fonction produit une empreinte de 256 bits.
La fonction de compression / ( A i , , / / , _ i ) (dont les deux paramètres sont formés de 256
bits) est définie ainsi :
1° Générer quatre clefs de chiffrement pour G O S T par une combinaison linéaire

de M i , de / / , _ i et de quelques constantes.
2° Utilisez chaque clef pour chiffrer un différent morceau de 64 bits de 77,_ i en

mode E C B . Stockez les 256 bits résultants dans une variable temporaire S.
3° 77, est une combinaison complexe, bien que linéaire, de S, A4, et //, i .
L’empreinte finale de A4 n’est pas l’empreinte du dernier bloc. Il y a en fait trois variable
de chaînage : H n est l’empreinte du dernier bloc de message, Z est la combinaison par
ou exclusif de tous les blocs de message, et L est la longueur du message. Etant donné
ces variables et le dernier bloc de remplissage A4' accolé à la fin de A4, l’empreinte
finale est la suivante :
H — f ( Z © A f',/(L ,/(A 4 \ 7 7 „)))
La documentation est un peu confuse (et en russe), mais je pense que tout cela est
correct. Dans tous les cas, cette fonction de hachage est destinée au standard russe de
signature numérique (voir § 20.3).
Autres schémas
Ralph M e r k l e a proposé un schéma qui utilise le DES mais il est lent ; il ne traite que
7 bits du message par itération, et chaque itération met en jeu deux chiffrement par
le DES [1081, 1076]. Un autre schéma [1644, 1647] n’est pas sûr [1278] ; il fut proposé
un temps pour devenir un standard ISO.
18.12 Utilisation d’algorithmes à clef publique
18.12 Utilisation d’algorithmes à clef pu

blique
Il est possible d ’utiliser les algorithmes à clef publique en mode de chaînage de blocs
pour une signature numérique. Si vous jetiez la clef privée, casser l’empreinte serait
aussi difficile que de lire le message sans la clef privée.
Par exemple, voici comment le R S A peut être transformé en une fonction de hachage
à sens unique. Si A4 est le message à hacher, n le produit de deux nombres premiers p
et q, et e un autre grand nombre premier par rapport à (p — l)(q — 1), alors la fonction
de hachage H (AI ) sera :
H ( M ) = M c mod n.
Une solution encore plus simple serait d’utiliser un seul nombre premier fort comme
module p. Alors :
H (A4) = A4e mod p.
Casser ce problème est probablement aussi difficile que de trouver le logarithme discret
de e. Si e et p sont assez grands, la fonction de hachage à sens unique est sûre. Le
défaut de cet algorithme est qu’il est nettement plus lent que tous les autres déjà
décrits ci-dessus. Je ne le recommande pas pour cette raison.
18.13 Choix d’une fonction de hachage à

sens unique
Les prétendants semblent être SHA, M D5 et les constructions à base d’algorithmes
de chiffrement par blocs ; les autres n ’ont pas été assez étudiés pour concourir. Je vote
pour SHA. Les empreintes sont plus longues que celles de M D5, il est plus rapide que
les différentes construction à base d’algorithmes de chiffrement par bloc, et il a été
développé par la NSA. J’ai confiance dans les capacités des chercheurs de la NSA en
matière de cryptanalyse, même si leurs résultats ne sont pas rendus publics.
Le tableau 18.2 donne des mesures de vitesse de quelques fonctions de hachage à sens
unique à titre de comparaison uniquement.
18.14 Codes d’authentification de messages

Un code d’authentification de messages, C A M en abrégé, est une fonction de hachage à
sens unique dépendant d ’une clef. Les C A M ont les mêmes propriétés que les fonctions
de hachage à sens unique décrites ci-dessus mais, en plus, elles incluent une clef13. Seul
celui qui possède une clef identique peut vérifier l’empreinte. Elles sont très utiles pour
prouver l’authenticité sans fournir la confidentialité.
Les C A M peuvent servir à l’authentification de fichiers entre des utilisateurs. Elle peut
aussi servir à un seul utilisateur pour vérifier que ses fichiers n’ont pas été altérés, par
un virus par exemple. Un utilisateur pourrait calculer les empreintes de ces fichiers
13. Ce qui ne veut pas dire que vous pouvez révéler la clef d ’un C A M et vous en servir de fonction
de hachage à sens unique.
T a b . 18.2 - Vitesses de chiffrement en continu de quelques fonctions de hachage à sens

unique sur un 486SX à 33 MHz____________________________________________________
Algorithme Longueur de l’empreinte Vitesse de chiffrement
(en mégaoctets par seconde)
D a v i e s - M e y e r de front (avec ID E A ) 128 22
D a v i e s - M e y e r (avec le D ES) 64 9
G OST 256 11
HAVAL (3 rondes) variable 168
M D2 128 23
M D4 128 236
M D5 128 174
N-H ASH (12 rondes) 128 29
N -H ASH (15 rondes) 128 24
R IP E -M D 128 182
SHA 160 75
SN EFRU (4 passes) 128 48
SNEFRU (8 passes) 128 23
avec un C A M et les stocker dans une table. Si l’utilisateur utilisait une fonction de
hachage à sens unique à la place, le virus pourrait calculer la nouvelle empreinte après
infection et remplacer celle de la table. Un virus ne pourrait pas faire cela avec un
C A M parce qu’il ne connaitrait pas la clef.
Un moyen facile de transformer une fonction de hachage à sens unique en un CAM
consiste à chiffrer l’empreinte avec un algorithme à clef secrète.
C A M par chiffrement par blocs

Le moyen le plus simple de réaliser une fonction de hachage à sens unique à clef est de
chiffrer un message avec un algorithme de chiffrement par blocs en mode C FB ou CBC.
L’empreinte est le dernier bloc chiffré, chiffré une fois de plus en mode C F B ou CBC.
Cette méthode est spécifiée dans l’ANSI X 9.9 [65J, l’AN SI X 9.19 [58], l’ISO 8731-
1 [763], l’ISO 9797 [768], et un standard australien [1196]. La cryptanalyse permet de
casser ce schéma quand il a peu de rondes et utilise le DES ou F E A L [1206].
Le problème potentiel de sécurité avec cette méthode est que le destinataire doit avoir
la clef, et que cette clef lui permet de générer des messages de même empreinte qu’un
message donné en déchiffrant à l’envers.
Algorithme d’authenfication de messages

Cet un algorithme est un standard ISO [764]. Il produit une empreinte de 32 bits pour
les unités centrales possédant une instruction de multiplication rapide [429].
v = v <3 1
e= v © w
x = ((((e -f y) modulo 232) V A A C ) x (a; © A U )) modulo 232 — 1
18.14 Codes d’authentification de messages 481
V = ((((e+ x ) modulo 232) V B A D ) x ( y ® M i ) ) modulo 232 — 2
Répéter cela pour chaque bloc de message M i et l’empreinte résultante est la combi
naison par ou exclusif de x et y. Les variables u et e proviennent de la clef. A, B , C
et D sont des constantes.
Cet algorithme est probablement largement utilisé, mais je ne peux pas croire qu’il soit
si sûr. Il y a fort longtemps qu’il a été conçu, et il n’est pas très compliqué.
C A M bidirectionnel
Ce C A M produit des empreintes de longueur double de celle des blocs de l’algorithme
[989]. Commencez par calculer le C A M par chiffrement par blocs en mode C B C ap
pliqué au message. Calculez alors le C A M par chiffrement par blocs en mode C B C
appliqué au message en prenant les blocs dans l’ordre inverse. L ’empreinte du C A M bi
directionnel est obtenu simplement en juxtaposant les deux valeurs. Malheureusement,
cette construction n’est pas sûre [1103].
Méthodes de J u e n e m a n
Ce C A M est aussi appelé code de détection de manipulations congruentielles quadra
tiques (C D M C Q en abrégé) [792, 790]. Divisez tout d’abord le message en blocs de m
bits, et appliquez ceci ensuite :
/ / n = I h °ù I h est la clef secrète,

Hi = ( i ïi - 1 + M {)2 modulo p où p est un nombre premier inférieur à 2m —1
et + dénote l’addition entière.
J u e n e m a n suggère de prendre n = 16 et p — 231 — 1. Dans [792], il suggère de plus de

prendre H i comme clef supplémentaire en faisant commencer le message à H?.
Suite à la découverte de nombreuses attaques du type de celle des anniversaires avec
Don C o p p e r s m i t h , J u e n e m a n a suggéré de calculer le C D M C Q quatre fois, en pre
nant le résultat de chaque itération comme vecteur d’initialisation de la suivante, puis
en juxtaposant les résultats pour obtenir une empreinte de 128 bits [793]. Ceci fut da
vantage renforcé en opérant les quatre itérations en parallèle et en les liant de manière
entrecroisée [789, 791]. Ce schéma a été cassé par C o p p e r s m i t h [380].
Une autre variante [432, 434] remplaçait l’addition par un ou exclusif et utilisait des
blocs de taille bien inférieure à p. H 0 étant fixé, cela devenait une fonction de hachage à
sens unique sans clef. Après que ce schéma ait été attaqué [614], il fut renforcé en tant
que partie intégrante du projet « European Open Shop Information-TeleTrust » [1233],
cité dans C C IT X .509 [309], et adopté dans l’ISO 10118 [760, 761], Malheureusement,
C o p p e r s m i t h a aussi cassé ce schéma [380]. Certaines recherches ont essayé des ex
posants autres que 2 [605], mais aucune n’a été prometteuse.
RIPE-M AC
R I P E M A C a été conçu par Bart P r e n e e l [1273] et adopté par le projet R IP E [1316]
(voir § 18.8). Il est basé sur l’ISO 9797 [768] et utilise le DES comme fonction de
chiffrement de bloc. Il y a deux variantes de R IP E -M A C : l’une utilisant le DES
normal, appelée R IP E —M AC1 et l’autre utilisant le DES triple pour une plus grande
sécurité, appelée R IP E -M AC3. RIPE-JVIAGI utilise un chiffrement DES par blocs

de messages de 64 bits ; R IP E - M A C 3 en utilise trois.
L ’algorithme consiste en trois parties. Au départ, le message est étendu pour rendre la
longueur multiple de 64 bits. Ensuite, le message étendu est divisé en blocs de 64 bits.
Une fonction de compression à clef est utilisée pour hacher ces blocs, sous le contrôle
d’une clef secrète, en un seul bloc de 64 bits. C ’est cette étape qui utilise soit le DES
soit le DES triple. Finalement, la sortie de cette compression est soumise à un autre
chiffrement DES avec une autre clef, dérivée de la clef utilisée pour la compression.
Voyez [1316] pour les détails.
IBC-Hash
IB C -H ash est un autre C A M adopté par le projet R IP E [1316] (voir § 18.8). Il
est intéressant car on peut prouver sa sécurité ; la probabilité d’une attaque réussie
peut être quantifiée. Malheureusement, chaque message doit être haché avec une clef
différente. Le niveau de sécurité choisi impose des contraintes sur la longueur maximale
du message, quelque chose qu’aucune autre fonction de ce chapitre ne fait. Étant donné
ces considérations, le rapport R IP E recommande de n’utiliser IB C -H ash que pour des
longs messages envoyés peut fréquemment.
Le coeur de la fonction réside dans la formule suivante :
H t - ((A41 modulo p) + v) modulo 2"
La clef secrète est la paire p et v , où p est un nombre premier de n bits et v un

nombre aléatoire inférieur à 2n. Les A4, proviennent d’une procédure de remplissage
précisément spécifiée. On peut quantifier les probabilités de casser la fonction, que ce
soit par collision ou en l’inversant, et l’utilisateur peut choisir le niveau de sécurité en
modifiant les paramètres.
C A M à partir d’une fonction de hachage à sens unique

Une fonction de hachage à sens unique peut aussi être utilisée comme C A M [1545].
Faites l’hypothèse qu’Alice et Bernard partagent une clef K et qu’Alice veut envoyer
à Bernard une C A M pour le message A4. Alice joint A4 et A et calcule la fonction de
hachage à sens unique de l’ensemble : H( A ,A4). Cette empreinte est la C A M . Comme
Bernard connaît A , il peut reproduire le résultat d ’Alice. Martin, qui ne connaît pas
A , ne peut pas le faire.
Cette méthode fonctionne avec les techniques de renforcement MD, mais présente de
sérieux problèmes. Martin peut toujours ajouter de nouveaux blocs à la fin du message
et calculer une empreinte de C A M valide. Cette attaque peut s’éviter en mettant
la longueur du message au début, mais P r e n e e l se méfie de ce schéma [1276]. Il
vaut mieux mettre la clef à la fin du message : H (A4, A ), mais cela pose aussi certains
problèmes [1276], Si H est à sens unique, mais pas sans collisions, Martin peut fabriquer
des messages. La meilleure solution est H ( K , A i , K ) ou bien H (A'i ,A4,A2), où K\ et
A 2 sont différentes [1545]. P r e n e e l reste encore méfiant vis à vis de cette dernière
[1276].
Les constructions suivantes paraissent sûres :
H ( K i ,H ( K 2,M))
18.14 Codes d’authentification de messages 483
H(K,H(K,M))
H{K, p, M., K) où p sert à remplir K jusqu’à obtenir un bloc de message.
La meilleure approche consiste à joindre 64 des bits de la clef avec chaque bloc du
message. Cela rend la fonction de hachage moins efficace car les blocs du message sont
plus petits, mais c ’est beaucoup plus sûr [1276].
Une alternative consiste à utiliser une fonction de hachage à sens unique et un algo
rithme de chiffrement à clef secrète. Calculez l’empreinte du fichier, et chiffrez la. Elle
est plus sûre que de chiffrer le fichier et de calculer l’empreinte du fichier chiffré, mais
elle est vulnérable aux mêmes attaques que l’approche H( Â 4 ,K) [1276].
CAM à partir d’un chiffrement en continu

Ce schéma de C A M utilise les chiffrements en continu (voir la figure 18.15) [948]. Un
générateur pseudo-aléatoire de bits cryptographiquement sûr démultiplexe le flux de
message en deux sous-flux. Si le bit de sortie du générateur de bit kz est 1, alors le bit
courant du message m, est envoyé au premier sous-flux; si U vaut 0, est envoyé
au deuxième sous-flux. Les sous-flux sont chacun fournis comme entrée à un R D R L
différent (voir § 16.2). Le résultat de la C A M est donné simplement par les états finaux
des registres à décalage.
F ig. 18.15 - Chiffrement en continu — C A M
Malheureusement, cette méthode n ’est pas à l’épreuve de petits changements dans le

message [1527]. Par exemple, si vous modifiez le dernier bit du message, il suffit de
modifier deux bits de l’empreinte pour en obtenir une fausse; cela est faisable avec
une probabilité raisonnable. Les auteurs présentent une alternative plus sûre et plus
compliquée.
Chapitre 19
Algorithmes à clef publique
19.1 Introduction
Le concept de cryptographie à clef publique fut inventé par Whitfield D i f f i e et Martin
H e l l m a n , et indépendamment par Ralph M e r k l e . L’idée neuve dans le domaine
était que les clefs pouvaient être des paires — une clef de chiffrement et une clef de
déchiffrement — et qu’il était impossible de générer une clef à partir de l’autre (voir
§ 2.5). D i f f i e et H e l l m a n ont présenté ce concept pour la première fois en 1976 à
la « National Computer Conférence » [493] ; quelques mois après, leur article « New
Directions in Cryptography » paraissait dans « IEEE Transactions on Information
Theory » [494]1.
Depuis 1976, de nombreux algorithmes de cryptographie à clef publique ont été propo
sés. Nombre d’entre eux ne sont pas sûrs. Parmi ceux qui sont encore considérés comme
sûrs, nombre d’entre eux ne sont pas pratiques. Soit ils ont une clef exagérément grande,
soit le texte chiffré est nettement plus long que le texte en clair.
Seuls quelques algorithmes sont à la fois sûrs et pratiques. Ces algorithmes sont en
général basés sur l’un des problèmes difficiles décrits dans le paragraphe 11.2. De ces
algorithmes à clef publique sûrs et pratiques, certains ne sont adaptés qu’à la distribu
tion de clefs. D ’autres sont adaptés au chiffrement (et, par extension, à la distribution
de clefs). D ’autres ne sont adaptés qu’aux signatures numériques. Seuls trois algo
rithmes sont adéquats à la fois pour le chiffrement et les signatures numériques : RSA ,
E l G a m a l et R a b i n . T o u s ces algorithmes sont lents. Les vitesses de chiffrement et
de déchiffrement sont nettement plus faibles que pour les algorithmes à clefs secrètes ;
habituellement c’est trop lent pour le chiffrement de données en masse.
Les systèmes hybrides (voir § 2.5) permettent d’augmenter la vitesse : un algorithme
avec une clef secrète aléatoire sert à chiffrer le message, et un algorithme à clef public
sert à chiffrer la clef.
I. D u fait des délais de publication exagérés des « C o m m u n ic a tio n s o f th e A C M », la première

contribution de M e r k l e au dom aine ne parut pas avant 1978 [1073].
486 Chapitre 19 Algorithmes à clef publique
Sécurité des algorithmes à clef publique

Comme les cryptanalystes ont accès à la clef publique, ils peuvent toujours choisir
n’importe quel message à chiffrer. Cela veut dire qu’étant donné C = E k (A4), les
cryptanalystes peuvent deviner la valeur de M et aisément vérifier leur pari. C ’est
un problème sérieux si le nombre de messages en clair possible est assez petit pour
permettre une recherche exhaustive, mais peut être résolu en rajoutant une chaîne de
bits aléatoires au message. Cela signifie que des textes en clair identiques donneront
des textes chiffrés différents (pour plus de détails concernant ce concept, voir § 23.15).
Cela est particulièrement important lorsqu’un algorithme à clef publique sert à chiffrer
une clef de session. Estelle peut générer une base de données de toutes les clefs de session
possibles chiffrées avec la clef publique de Bernard. Cela représente évidemment une
somme énorme de travail et de mémoire, mais pour une clef exportable de 40 bits ou
une clef de 56 bits du DES, c’est beaucoup moins que ce qu’il faudrait pour casser la
clef publique de Bernard. Une fois qu’Estelle aura généré la base de donnée, elle pourra
trouver facilement toutes les clefs de session et lire le courrier électronique de Bernard.
Les algorithmes à clef publique sont conçus pour résister aux attaques à texte en clair
choisi ; leur sécurité dépend à la fois de la difficulté de déduire la clef privée à partir de
la clef publique et de la difficulté de déduire le texte en clair à partir du texte chiffré.
Toutefois, la plupart des algorithmes à clef publique sont particulièrement sensibles à
ce que l’on appelle une attaque à texte chiffré choisi (voir § 1.1).
Dans les système où la signature numérique est l’opération du chiffrement, il est im
possible d’empêcher cette attaque à moins d’utiliser des paires de clefs différentes pour
le chiffrement et la signature numérique.
En conséquence, il est important de considérer le système comme un tout et non pas
seulement comme des parties individuelles. Les bons protocoles à clef publique sont
conçus de telle manière que les différents participants ne déchiffrent pas n’importe quel
message engendré par les autres participants ; la preuve d ’identité est un bon exemple
(voir § 5.2).
19.2 Algorithmes à empilement

Le premier algorithme pour le chiffrement à clef publique généralisé fut développé
par Ralph M e r k l e et Martin H e l l m a n [715, 1080]. Il ne peut être utilisé que pour
le chiffrement bien que S h a m i r ait adapté plus tard le système pour les signatures
numériques [1420]. Les algorithmes à empilement2 tirent leur sécurité du problème
d ’empilement, un problème TVP —co m p le t. Bien qu’on ait découvert après coup que cet
algorithme n’est pas sûr, il vaut la peine d’être examiné parce qu’il montre comment des
problèmes À’ P -co rn p le ts peuvent être utilisés pour la cryptographie à clef publique.
Le problème d ’empilement est un problème simple. Etant donné un tas d’objets, chacun
ayant un poids différent, est-il possible de faire un nouveau tas avec certains de ces
objets de telle manière que le nouveau tas pèse un poids donné ? Plus formellement :
étant donné un ensemble de valeurs, et une somme S, calculer les valeurs
2. N ote du traducteur : la traduction « p ro b lè m e d ’e m p ile m e n t » a été utilisée pour l’expression

anglaise : « k n a p sa ck p ro b lem » que d ’ autres traducteurs ont égalem ent appelé « p ro b lè m e du sa c à
dos » [240].
19.2 Algorithmes à empilement
des bi de telle m anière que :
S — b%Mi + 62 M 2 + ... + bnM n.
Les valeurs des bi étant soit 0 soit 1. Un 1 indique que l’élément est dans le nouveau
tas ; un 0 indique qu’il n’y est pas.
Par exemple, les objets pourraient avoir les poids suivants: 1, 5, 6, 11, 14 et 20. II
est possible de créer un tas qui pèse 22; utilisez les objets pesant 5, 6 et 11. Il est
impossible de créer un tas qui pèse 24. En général, le temps nécessaire pour résoudre
ce problème semble croître exponentiellement avec le nombre d ’objets dans le nouveau
tas.
L ’idée de base de l ’algorithm e à em pilem ent M erkle --H E LLM A N est de coder le mes
sage com m e une solution d ’une suite de problèm es d ’em pilem ent. U n b lo c de texte en
clair de longueur égale au nom bre d ’o bjets dans le tas sélectionnerait des objets (les
bits du texte en cla ir correspondraient aux valeurs des 6, : un 1 signifierait que l ’objet
est présent et u n 0 signifierait que l ’o bjet est absent) et le texte chiffré serait la somme
résultante. L a figure 19.1 illustre u n texte en cla ir chiffré avec un exemple de problèm e
d ’empilement.
Texte en clair: 1 1 1 0 0 1 0 10 1 1 0 0 0 0 0 0 0 0 11 0 0 0
Tas: 1 5 6 11 14 20 1 5 6 11 14 20 1 5 6 11 14 20 1 5 6 11 14 20
Texte chiffré: 1+5+6+20 5+11+14 = 0 = 5+6 =

32 30 0 11
F ig. 19.1 Chiffrement par empilement
Le truc ici est qu’il y a en fait deux problèmes d’empilement, l’un soluble en temps
linéaire, l’autre soluble en temps exponentiel seulement. L’empilement facile peut être
transformé pour créer un empilement difficile. La clef publique est l’empilement difficile,
qui peut être facilement utilisée pour chiffrer des messages mais qui ne peut pas être
utilisée pour déchiffrer des messages. La clef privée est l’empilement facile qui donne
un moyen simple de déchiffrer les messages. Les gens qui ne connaissent pas la clef
privée sont obligés d’essayer de résoudre le problème d ’empilement difficile.
Empilement super-croissant
Qu’est-ce qu’un problème d ’empilement facile? Si la liste des poids est une suite
super-croissante, alors le problème d ’empilement correspondant est facile à résoudre.
Une suite super-croissante est une suite dans laquelle tout terme est plus grand que la
somme de tous les termes qui précèdent. Par exemple, {1,3,6,13,27,52} est une suite
super-croissante tandis que {1,3,4,9,15,25} ne l’est pas.
La solution d ’un empilement super-croissant est facile à trouver. Prenez le poids
total et comparez-le avec le plus grand nombre de la suite. Si le poids total est inférieur
à ce nombre, alors il n’est, pas dans le tas. Si le poids total est supérieur ou égal au
nombre, alors il est dans le tas. Réduisez le poids du tas à créer de ce nombre et passez
au plus grand-nombre suivant de la suite. Répétez cela jusqu’à ce que ce soit terminé.
Si le poids total a été ramené à 0, alors il y a une solution. Si le poids total n’a pas été
annulé, il n’y a alors pas de solution.
Par exemple, considérez un tas de poids total de 70 à créer et une suite de poids
{2,3,6,27,52}. Le poids le plus élevé est 52, ce qui est inférieur à 70, donc 52 est dans
le nouveau tas. Retirer 52 à 70 laisse 18. Le poids suivant est 27 qui est plus grand
que 18 et donc 27 n ’est pas dans le nouveau tas. Le poids suivant 13 est inférieur à
18, donc 13 est dans le nouveau tas. Retirer 13 à 18 donne 5. Le poids suivant est 6.
qui est plus grand que 5, donc 6 n’est pas dans le nouveau tas. Continuer ainsi montre
que 2 et 3 se trouvent aussi dans le nouveau tas et le poids est ramené à 0, ce qui
indique qu’une solution a été trouvée. Si cela avait été un bloc chiffré par empilement
M e r k l e H e l l m a n , alors le texte en clair correspondant au texte chiffré de valeur 70
aurait été 110101.
Avec des suites qui ne sont pas super-croissantes, on ne connaît pas d ’algorithme rapide.
Le seul moyen de déterminer quels sont les objets dans le nouveau tas est de tester
méthodiquement toutes les solutions possibles jusqu’à ce que l’on tombe sur la bonne.
Les algorithmes les plus rapides, prenant en compte les heuristiques nécessaires, sont
exponentiels en fonction du nombre de poids possibles dans le tas. Ajoutez un poids
à la suite des poids et il faut deux fois plus de temps pour trouver la solution. C’est
nettement plus difficile qu’avec une suite super-croissante où, si vous ajoutez un poids
à la suite, cela ne fait qu’une opération de plus.
L ’algorithme M e r k l e H e l l m a n est basé sur cette propriété. La clef privée est une
suite de poids super-croissante pour un problème d ’empilement. La clef publique est une
suite de poids pour un problème d’empilement normal avec la même solution. M e r k l e
et H e l l m a n ont développé une technique pour convertir un problème d’empilement
super-croissant en un problème d ’empilement normal. Ils ont fait cela en utilisant
l’arithmétique modulaire.
Création de la clef publique à partir de la clef privée

Sans entrer dans les détails de la théorie des nombres, voici comment l’algorithme
marche : pour obtenir une suite pour empilement normale, prenez une suite pour empi
lement super-croissante, par exemple {2,3,6,27,52} et multipliez toutes les valeurs par
un nombre n modulo m. Le module doit être un nombre plus grand que la somme de
tous les nombres de la suite, 105 par exemple. Le multiplicateur ne doit avoir de fac
teur en commun avec aucun nombre de la suite, 31 par exemple. La suite d ’empilement
normale serait alors :
(2 x 31) mod 105 = 62

(3 x 31) mod 105 = 93
(6 x 31) mod 105 = 81
(13 x 31) mod 105 = 88
(27 x 31) mod 105 = 102
(52 x 31) mod 105 = 37
L ’empilement difficile est alors {62,93,81,88,102,37}.

La suite pour empilement super-croissante est la clef privée. La suite pour empilement
normale est la clef publique.
19.2 Algorithmes à empilement 489
Chiffrement
Pour chiffrer un message binaire, coupez d’abord le message en morceaux de longueur
égale au nombre d ’objets dans la suite pour empilement. Ensuite, en prenant la conven
tion qu’un 1 indique que l’objet figure dans le tas et qu’un 0 indique que l’objet est
absent, calculez le poids total des tas.
Par exemple, si le message est 011000110101101110, le chiffrement en utilisant la suite
ci-dessus se fait de la façon suivante :
message = 011000 110101 101110
011000 donne 93 + 81 = 174

110101 donne 62 + 93 + 88 + 37 = 280
101110 donne 62 + 81 + 88 + 102 = 333
Le texte chiffré sera alors :
174,280,333
Déchiffrement
Un destinataire légitime de ce message connaît la suite super-croissante originelle, ainsi
que les valeurs n et m utilisées pour la transformer en une suite normale. Pour déchiffrer
le message, le destinataire doit d’abord calculer n ~x tel que n x n-1 = 1 (mod m) et
ensuite multiplier chaque valeur du texte chiffré par n ' 1 mod m pour retrouver les
valeurs du texte en clair.
Pour notre exemple, la suite super-croissante est {2,3,6,13,27,52}, m vaut 105 et n vaut
31. Le message chiffré est 174,280,333. Dans ce cas, n ~ x vaut 61 et les valeurs chiffrées
doivent donc être multipliées par 61 mod 105.
174 x 61 mod 105 = 9 = 3 + 6, ce qui Correspond à 011000

280 x 61 mod 105 = 70 = 2 -f 3 -f 13 + 52, ce qui correspond à 110101
333 x 61 mod 105 = 48 = 2 + 6 + 13 + 27, ce qui correspond à 101110.
Le texte en clair correspondant est 011000 110101 101110.
Réalisations pratiques
Avec une suite pour empilement de six éléments, il n’est pas difficile de résoudre le
problème même si la suite n’est pas super-croissante. Les vrais empilements contiennent
au moins 250 éléments. La valeur de chaque terme de la suite super-croissante est longue
de 200 à 400 bits. Le module est choisi pour avoir une longueur comprise entre 100 et
200 bits. Les réalisations concrètes de l’algorithme utilisent un générateur de séquences
aléatoires pour produire ces valeurs.
Il serait vain d ’essayer de résoudre des empilements tels que ceux-là. Si un ordina
teur peut essayer un million de possibilités par seconde, essayer tous les empilements
possibles prendrait plus de 1046 années. Même un million de machines travaillant en
parallèle ne résoudraient pas le problème avant que le soleil ne se transforme en nova.
Sécurité des empilements

Ce n’est pas un million de machines qui ont cassé le système à empilement mais bien
deux cryptographes. Premièrement, H e r l e s t a m remarqua que souvent un bit du texte
en clair pouvait être retrouvé [727], Ensuite, S h a m i r a montré que l’algorithme pouvait
être cassé dans certaines circonstances [1422, 1423]. Il y eut d ’autres résultats— [1434,
39, 756, 518, 486]— mais aucun ne permettait de casser le système M e r k l e - H e l l m a n
général. Finalement, S h a m i r et Z i p p e l [1427, 1425, 1428] trouvèrent des failles dans
la transformation qui permettait de reconstruire la suite super-croissante à partir de
la suite normale. L’argumentation exacte dépasse le cadre de cet ouvrage, mais un
bon résumé peut être trouvé dans [1243, 1254]. A la conférence où les résultats furent
présentés dans [490, 492], la démonstration de l’attaque fut réalisée sur l’estrade à
l’aide d ’un ordinateur A p p l e II.
Variantes du système à empilement

Depuis que le schéma initial M e r k l e - H e l l m a n a été cassé, de nombreux autres sys
tèmes à empilement ont été proposés : empilements à itérations multiples, empilement
de Graham- Shamir, etc. Ils ont tous été analysés et cassés, en utilisant généralement
les mêmes techniques cryptographiques, et ils empilement encombrent l’autoroute de
la cryptologie [264, 257, 273, 932, 19, 930, 931, 933, 370, 258, 267, 259]. Un bon aperçu
de ces systèmes et de leur cryptanalyse peut être trouvé dans [271, 478, 261, 272].
D ’autres systèmes cryptographiques qui utilisent des idées similaires aux empilements
ont été proposés mais ils ont été également cassés. Le cryptosystème L u - L e e [1000, 17]
a été cassé dans [24, 616, 874] ; une version modifiée [508] n’est pas sûre non plus
[1622]. Les attaques contre le cryptosystème G o o d m a n - M c A u l e y sont décrites dans
[648, 649, 271, 272]. Le cryptosystème P i e p r z y k [1256] peut être cassé par des attaques
similaires. Le cryptosystème NlEM) [749], basé sur des empilements modulaires, a été
cassé dans [349, 788]. Une version plus récente d’empilement à plusieurs étages [7491
n’a pas encore été cassée, mais je ne suis pas optimiste. Une autre variante est décrite
dans [298].
Bien qu’il existe encore une variante de l’algorithme à empilement qui est toujours sûre
à l’heure actuelle— l’empilement C h o r R i v e s t [360], malgré une « attaque spéciali
sée » [745]— la quantité de calculs nécessaires le rend nettement moins utilisable que
les autres algorithmes décrits ici. Une variante du nom de système P O W E R L IN E n’est
pas sûre [969]. Plus important, étant donné la vitesse à laquelle les autres variantes
sont tombées, il ne semble pas prudent d ’avoir confiance en celles-ci.
Brevets
L’algorithme M e r k l e H e l l m a n originel est breveté aux Etats-Unis [723] et dans le
monde entier (voir le tableau 19.1). P K P octroie des licences d ’exploitation de ce brevet
ainsi que d ’autres brevets de cryptographie à clef publique (voir § 25.5). Toute personne
intéressée par l’obtention d’une telle licence doit contacter: Robert B. Fougner,
D ir e cto r o f L ice n sin g , P u b lic Key P artn ers, 310 N Mary Avenue,
Sunnyvale, CA 94086, T e l: +1 (408) 735-5893. Le brevet américain expire le 19
août 1997.
19.3 RSA 491
T ab 19.1 - Brevets pour l ’empilement M erkle H ellm an dans le monde
Pays Numéro Date

Belgique 871039 5 avril 1979
Pays-Bas 7810063 10 avril 1979
Grande-Bretagne 2006580 2 mai 1979
Allemagne 2843583 10 mai 1979
Suède 7810478 14 mai 1979
France 2405532 8 juin 1979
Allemagne 2843583 3 juin 1982
Allemagne 2857905 15 juillet 1982
Canada 1128159 20 juillet 1982
Grande-Bretagne 2006580 18 août 1982
Suisse 63416114 14 janvier 1983
Italie 1099780 28 septembre 1985
19.3 RSA
Peu après l’algorithme à empilement de M e r k l e , le premier algorithme à clef publique
grandeur nature apparut. Il fonctionne pour le chiffrement aussi bien que pour les
signatures numériques: R SA [1339, 1340]. De tous les algorithmes à clef publique
proposés tout au long de ces années, c ’est de loin le plus facile à comprendre et à
réaliser3. C ’est le plus populaire. Baptisé d ’après le nom de ses inventeurs, Ron R i v e s t ,
Adi S h a m i r et Léonard A d l e m a n , il a résisté depuis à des années de cryptanalyse
intensive. Bien que la cryptanalyse n’ait jamais prouvé la sécurité ou la non-sécurité
de R SA , cela inspire un certain niveau de confiance dans l’algorithme.
Le niveau de sécurité du R S A dépend de la difficulté de factoriser des grands nombres.
Les clefs publique et privée sont des fonctions d’une paire de grands nombres premiers
(100 à 200 chiffres ou plus encore). Retrouver le texte en clair à partir d ’une des clefs et
du texte chiffré est supposé équivalent à la factorisation du produit des deux nombres
premiers.
Pour engendrer les deux clefs, choisissez deux grands nombres premiers, p et q. Calculez
le produit :
n - pq.
Choisissez ensuite une clef de chiffrement aléatoire e telle que e et (p — l ) ( ç — 1) soient
premiers entre eux. Finalement, utilisez l’algorithme d’Euclide pour calculer la clef de
déchiffrement d de telle manière que :
ed = 1 (mod (p — l ) ( ç — 1)).
En d ’autres termes :
d — e~ x mod ((p — l ) ( ç — 1)).
Remarquez que d et n sont aussi premiers entre eux. Les nombres e et n forment la
clef publique, le nombre d est la clef privée. Les deux nombres premiers p et g ne sont
plus nécessaires. Ils peuvent être écartés mais jamais révélés.
3. M artin G a r d n e r publia une première description de l’ algorithm e dans sa colonne « M a th em a tica l
G a m es » du S c ie n tific A m e r ic a n [602].
Chapitre 19 Algorithmes à clef publique
Pour chiffrer un message m, découpez celui-ci en blocs numériques tels que chaque
bloc ait une représentation unique modulo n (avec des données binaires, choisissez la
plus grande puissance de 2 inférieure à n). Ainsi, si p et q sont tous deux des nombres
premiers de 100 chiffres, alors n aura tout juste moins de 200 chiffres et chaque bloc de
message m, doit avoir juste moins de 200 chiffres. Le message chiffré c sera constitué de
manière similaire de blocs ct d ’à peu près la même longueur. La formule de chiffrement
est simplement :
Cî = ml mod n.
Pour déchiffrer un message, prenez chaque bloc ct et calculez :
m t = cf mod n.
Puisque (toutes les opérations étant effectuées modulo n) :
cf = ( ml)d = raf* = m *0’- 1h 9 -P + 1 — m l x = m , x l = mi,
la formule ci-dessus permet de retrouver la message. Ceci est résumé par le tableau 19.2.
T ab . 19.2 - Chiffrement R SA
C lef publique :
n produit de deux nombres premiers, p et q (p et q doivent rester secrets)
e premier par rapport à {p — l ) ( ç — 1)
C lef privée :
d = e-1 mod ((p — l ) ( ç — 1))
Chiffrement :
c = me mod n
Déchiffrement :
m = cd mod n
Le message aurait tout aussi bien pu être chiffré avec d et déchiffré avec e ; le choix est
arbitraire. Je n’inclus pas ici la théorie des nombres qui prouve que cela marche; les
textes récents sur la cryptographie couvrent cette théorie en détail.
Un petit exemple contribuera certainement à rendre tout cela plus clair. Si p = 47 et
q — 71 alors :
n = pq = 3337.
La clef de chiffrement e ne doit pas avoir de facteurs communs avec :
(p — l ) ( ç — 1) = 46 = 3220.
Choisissez e (aléatoirement) égal à 79. Dans ce cas :
d = 79“ 1 mod 3220 = 1019.
Ce nombre a été calculé en utilisant l’algorithme d ’Euclide étendu (voir § 11.3). Publiez
e et n et gardez d secret. Jetez p et q.
Pour chiffrer le message :
m = 688232687966683
19.3 RSA 493
divisons-le d’abord en petits blocs. Des blocs de trois chiffres conviendront dans ce
cas-ci. Le message est divisé en 6 blocs rrii tels que :
mi = 688
m2 = 232
m3 = 687
m4 = 966
m5 = 668
me = 3.
Le premier bloc est chiffré par :
68879 mod 3337 = 1570 = <*.
En effectuant la même opération pour tous les blocs, on obtient le message chiffré :
c = 1570 2756 2091 2276 2423 158.
Pour déchiffrer le message, il faut effectuer les mêmes exponentiations mais en utilisant
la clef de déchiffrement 1019. Donc :
15701019 m od 3337 = 688 = m ,.
Le reste du message est obtenu de la même manière.
RSA en matériel
On a beaucoup écrit sur le sujet des réalisations matérielles du R S A [1325,1480,1462,
1327, 1492, 875, 1231, 94, 1415, 1414, 1355, 1342, 371, 1435, 525, 772]. De bons articles
résumés sont [262, 873]. De nombreuses puces différentes qui réalisent le R SA ont été
construites [1321, 256, 1108, 1328, 875, 74, 739, 596, 1286, 1565, 510, 1232], Une liste
partielle des puces R S A actuellement disponibles, extraite de [157, 262], est donnée
par le tableau 19.3. Elles ne sont pas toutes sur le marché.
Vitesse du RSA
A sa vitesse maximum, le R S A est environ 1000 fois plus lent que le DES. La réalisation
matérielle VLSI la plus rapide du R SA avec un module de 512 bits a un débit de 64
kilo-bits par seconde [262]. Il existe aussi des puces qui effectuent le chiffrement R SA
à 1024 bits. Actuellement, des puces qui approcheraient le million de bits par seconde
avec un module de 512 bits sont prévues, elles devraient être disponibles en 1995.
Certains fabricants ont réalisé le R S A dans les cartes à puce; ces réalisations sont plus
lentes.
En logiciel, le DES est environ 100 fois plus rapide que le R SA . Ces nombres pourraient
changer légèrement, avec les changements de technologie mais le R SA n’approchera
jamais la vitesse des algorithmes à clef secrète. Le tableau 19.4 compare les vitesses de
quelques réalisations en logiciel de R S A [929].
T a b . 19.3 Puces R SA existantes
Cycles d ’
Vitesse de horloge par Bits Nombre
Vitesse transmission chiffrement par de
Société d ’horloge par 512 bits de 512 bits Technologie puce transistors
Alpha Techn. 25 MHz 13 K 0,98 M 2g 1024 180 000
A T& T 15 MHz 19 K 0,4 M l,5 p 298 100000
British Telecom 10 MHz 5,1 K 1M 2,5p 256 —
Business Sim. Ltd. 5 MHz 3,8 K 0,67 M Réseau logique 32 —
Calmos Syst. Inc. 20 MHz 28 K 0,36 M 2p 593 95 000

CNET 25 MHz 5,3 K 2,3 M lp 1024 100000
Cryptech 14 MHz 17 K 0,4 M Réseau logique 120 33 000
Cylink 16 MHz 6,8 K 1,2 M l,5 p 1024 150 000
Pijnenburg 25 MHz 50 K 0,256 M lp 1024 400 000
Sandia 8 MHz 10 K 0,4 M 2p 272 86 000
Siemens 5 MHz 8,5 K 0,03 M lp 512 60 000
T a b . 19.4 -Vitesses de R SA pour différentes longueurs de module avec une clef pu
blique de 8 (sur une station SP A R C II,)
Chiffrement 0,03 s 0,05 s 0,08 s
Déchiffrement 0,16 s 0,48 s 0,93 s
Signature 0,16 s 0,52 s 0,97 s
Vérification 0,02 s 0,07 s 0,08 s
Optimisation en logiciel
Le chiffrement par R S A est bien plus rapide si vous choisissez bien la valeur de e. Les
choix les plus courants sont 3, 17 et 65537 (216 + 1 )4. X .509 recommande 65537 [309],
PE M recommande 3 [83], et P K C S # 1 (voir § 24.14) recommande 3 ou 65537 [919].
Aucun problème de sécurité n’interdit de prendre l’une de ces trois valeurs pour e (à
condition de combler le message par remplissage avec des valeurs aléatoires— voir le
paragraphe suivant), même si tout un groupe d ’utilisateurs utilise la même valeur.
Les opérations avec la clef privée peuvent s’exécuter plus rapidement grâce au théorème
du reste chinois si vous conservez les valeurs de p et q, ainsi que d ’autres telles que
d mod (p — 1), d mod ( q — 1) et q 1 mod p [1294, 1287]. Ces nombres supplémentaires
se calculent facilement à partir des clefs publique et privée.
Sécurité de RSA
La sécurité de R S A dépend entièrement du problème de la factorisation de grands
nombres. Techniquement, ce n’est pas vrai. Il a été conjecturé que la sécurité de RSA
dépend du problème de la factorisation de grands nombres. Il n’a jamais été prouvé
mathématiquement que vous devez factoriser n pour calculer m à partir de c et e. Il est
concevable qu’un tout autre moyen de cryptanalyser R S A soit découvert. Toutefois,
4. Les représentations binaires de ces nombres ne présentent que deux 1, aussi le calcul de leur
puissances ne requiert que 17 m ultiplications.
19.3 RSA 495
si cette nouvelle voie permettait aux cryptanalystes de retrouver d, cela pourrait aussi
être utilisé comme une nouvelle voie pour la factorisation de grands nombres. Je ne me
tracasserais pas trop à ce propos.
Il est aussi possible d’attaquer R SA en essayant de deviner la valeur de (p — 1)(q — 1).
Cette attaque n’est pas plus facile que la factorisation de n [1618].
Pour les ultra-sceptiques, il y a des variantes de R S A qui ont été prouvées aussi difficiles
que la factorisation (voir § 19.5). Voyez également [37], qui montre que même retrouver
un seul bit d’information à partir d’un texte chiffré par R SA est aussi difficile que de
déchiffrer le message en entier.
Factoriser n est l’attaque la plus évidente. Les adversaires auront la clef publique e et
le module n. Pour trouver la clef de déchiffrement, d, ils doivent factoriser n. Le para
graphe 11.4 décrit l’état de l’art de la technologie de la factorisation. Actuellement, des
nombres de 129 chiffres sont à la pointe de ce qui se fait en technologie de factorisation.
n doit donc être supérieur à cela. Lisez également le paragraphe 7.2 sur la longueur
des clefs publiques.
II est certainement possible pour un cryptanalyste d ’essayer toutes les valeurs possibles
de d jusqu’à tomber sur la bonne. Cette attaque exhaustive est encore moins efficace
que d’essayer de factoriser n.
De temps en temps des gens prétendent avoir trouvé un moyen facile de casser RSA,
mais leurs revendications ne durent pas. Par exemple, William P a y n e proposait en
1993 une méthode basée sur le petit théorème de F e r m â t [1244]. Malheureusement,
cette méthode est aussi plus lente que la factorisation du module.
Il y a une autre inquiétude. La plupart des algorithmes usuels de calcul de nombres pre
miers p et q sont, probabilistes ; que se passe-t-il si p ou g est composé? Premièrement,
vous pouvez les rendre les chances que cela arrive aussi minces que vous le désirez.
Et si cela arrive, il y a de grandes chances que le chiffrement et le déchiffrement, ne
fonctionnent pas normalement— vous le remarquerez tout de suite. U y a très peu de
nombres sur lesquels les algorithmes probabilistes de test de primalité échouent, on les
appelle les nombres de Carmichael. Us sont excessivement rares, mais ils ne sont pas
sûrs [748]. Honnêtement, je ne m ’en inquiéterais pas.
Attaque à texte chiffré choisi contre le RSA

Certaines attaques tirent profit de la réalisation de R S A ; elles ne sont pas dirigées
contre l’algorithme lui-même, mais contre le protocole. Ils est important de réaliser
qu’il ne suffit pas d’utiliser le R SA , les détails comptent.
S c é n a r i o 1 : Estelle, qui écoute la ligne de communication d’Alice, s’arrange pour
collecter un message c, chiffré par R S A avec sa clef publique. Estelle veut être capable
de lire le message. Mathématiquement, elle veut m tel que :
m = cd.
Pour retrouver m, elle choisit d’abord un nombre aléatoire r, tel que r soit, inférieur à
n. Elle obtient la clef publique d ’Alice, e. Ensuite elle calcule :
x = re mod n
y = xc m od n
t — r 1 mod n.
Si x = re mod n, alors r = x d mod n. Et donc, t = x ~ d mod n.

Maintenant, Estelle fait signer y par Alice avec sa clef privée, déchiffrant ainsi y. Alice
doit signer le message, pas l’empreinte du message. Rappelez-vous qu’Alice n ’a jamais
vu y avant. Alice envoie à Estelle :
u = y d mod n.
Maintenant, Estelle calcule :
tu mod n — x ~dyd mod n = x ~ dx dcd mod n = cd mod n = m.
Ce qui lui permet de disposer maintenant de m.

S cén ario 2 : Ivan est un notaire informatisé. Si Alice veut un document notarié, elle
l’envoie à Ivan. Ivan le signe avec une signature numérique R SA et le renvoie5.
Martin veut faire signer par Ivan un message qu’autrement ce dernier refuserait de
signer. Peut-être ce message a-t-il une datation factice, ou peut-être que ce message est
une mascarade. Peu importe la raison, Ivan ne signerait jamais ce message s’il avait le
choix. Appelons ce message m'.
Martin choisit une valeur arbitraire x et calcule y — x e mod n. Il peut aisément obtenir
e ; c ’est la clef publique d ’Ivan et elle doit être publique pour permettre la vérification
de sa signature. Ensuite il calcule m = ym! mod n et envoie m à Ivan pour qu’il le
signe. Ivan renvoie rnd mod n. A présent, Martin calcule ( (rad mod ti)x~1) mod n qui
est égal à m'd mod n et constitue donc une signature de m'.
En fait, il y a diverses manières pour Martin de réaliser la même chose [425, 464, 484]. La
faiblesse qu’elles exploitent toutes est. le fait que l’exponentiation préserve la structure
multiplicative de l’entrée. C ’est-à-dire :
{xm )d mod n — x dm d mod n.
S cén ario 3 : Estelle veut qu’Alice signe « 1 3 . Elle engendre deux messages m i et «2
tels que :
m 3 s m im 2 (mod n).
Si elle arrive à faire signer m 1 et m 2 par Alice, Estelle peut calculer la signature de
m3 :
md = (md mod n)(md mod n) mod n.
M o ra lité : N’utilisez jamais le R SA pour signer un document quelconque qui vous est
présenté par un inconnu. Le bloc de formatage de la norme ISO 9796 empêche cette
attaque.
Attaque par module commun contre le RSA

Rendons la vie plus facile et donnons le même n à tout le monde. Ils peuvent avoir
des valeurs différentes pour e et d, mais la même valeur de n. Malheureusement, cela
5. O n n ’ utilise pas de fonction de hachage à sens unique ici ; Ivan chiffre le message en son intégralité
avec sa clef privée.
19.3 RSA
ne fonctionne pas. Le défaut le plus évident est que si le même message est chiffré
avec deux clefs différentes (toutes les deux avec le même module), et que ces deux clefs
sont premières entre elles (ce qu’elles sont en général), alors le texte en clair peut être
retrouvé sans aucune des deux clefs de déchiffrement [1463].
Soit A4 le message en clair. Les deux clefs de chiffrement sont ei et 6 2 . Le module
commun est n. Les deux messages chiffrés sont :
C\ --- A4ei mod n
Ci — A4 62 mod n.
Le cryptanalyste connaît n, ej, e2, Cj et C2. Voici comment il peut retrouver A4.
Comme rq et e 2 sont premiers entre eux, l’algorithme d’Euclide permet de trouver r
et s tels que :
r x ei + s x e 2 = 1 .
En faisant l’hypothèse que r est négatif (soit r soit s doit l’être), alors l’algorithme
d’Euclide peut être utilisé à nouveau pour calculer C ÿ1. Donc :
(C f1)~r x C2 = A4 mod n.
Il existe deux autres attaques, plus subtiles, contre un tel système. L ’une utilise une
méthode probabiliste de factorisation de n. L’autre utilise un algorithme déterministe
pour calculer la clef privée de quelqu’un sans factoriser le module. Les deux attaques
sont décrites en détail dans [452].
Moralité : Ne partagez jamais n parmi un groupe d’utilisateurs.
Attaque par petit exposant de chiffrement contre le RSA

Le chiffrement et la signature sont plus rapides si vous prenez une petite valeur pour e,
mais cela risque de ne pas être sûr [705]. Si vous chiffrez e ( e + l ) / 2 messages linéairement
dépendants avec des clefs publiques différentes mais la même valeur de e, il est possible
d’attaquer le système. S’il n’y a pas autant de messages, ou s’ils sont indépendants, il
n’y a pas de problème. Si les messages sont identiques, alors e suffisent. La solution la
plus facile consiste à combler les messages par remplissage avec des valeurs aléatoires
indépendantes. Cela évite aussi d ’avoir A4e mod n — A4e. La plupart des réalisation
de R SA , telles que P E M et P G P (voir § 24.10 et 24.12) par exemple, font cela.
Moralité : Comblez les messages par remplissage avec des valeurs aléatoires avant de
les chiffrer, assurez vous que A4 a au moins même taille que n.
Attaque par petit exposant de déchiffrement contre le RSA

Une autre attaque, de Michael W i E N E R permet de retrouver d quand d est inférieur au
quart de la longueur du module et e est inférieur à n [1598]. Ceci n’arrive que rarement
si e et d sont choisis aléatoirement, et ne peut pas arriver si e est petit.
Moralité : Choisissez une grande valeur pour d.
498 Chapitre 19 Algorithmes à clef publiqw
Leçons apprises
M o o r e énumère plusieurs restrictions de l’utilisation du R S A basées sur ces attaques
réussies [1 1 2 0 , 1 1 2 1 ]:
- La connaissance d ’une paire chiffrement-déchiffrement d ’exposants pour un mo

dule donné permet à l’attaquant de factoriser le module.
- La connaissance d’une paire chiffrement-déchiffrement d ’exposants pour un mo

dule permet à l’attaquant de calculer d ’autres paires chiffrement-déchiffrement
sans devoir factoriser n.
- Un module commun ne peut pas être utilisé dans un protocole qui utilise le RSA
dans un réseau de communication6.
Les messages doivent être comblés par remplissage avec des valeurs aléatoires
pour empêcher les attaques par petit exposant de chiffrement.
- L’exposant de déchiffrement choisi pour un protocole doit être grand.
Rappelez-vous qu’il n’est pas suffisant d ’avoir un algorithme cryptographique sûr. Tou
le cryptosystème doit être sûr et le protocole cryptographique aussi. S’il y a la moindri
faille dans une de ces trois zones, le système entier n’est pas sûr.
Attaque sur le chiffrement et la signature par RSA

Il est sensé de signer un message avant de le chiffrer (voir § 2.7), mais tout le mondi
ne suit pas cette pratique. Avec le R SA , il existe une attaque contre les protocoles qu
chiffrent avant de signer [49].
Alice veut envoyer un message à Bernard. Elle commence par le chiffrer avec la cle
publique de Bernard, puis le signe avec sa clef privée. Son message chiffré et sigm
ressemble à ceci :
(A4eB mod riB)dA m od n a
Voilà comment Bernard peut prétendre qu’Alice lui a envoyé A4' et non A4. Comm
Bernard connaît la factorisation de % (c’est son module), il peut calculer les loga
rithmes discrets modulo n s- H lui suffit alors de trouver x tel que
,x = A4 mod ng.
A41
Il publie alors x e s comme étant sa nouvelle clef publique en gardant tib comme module
Il peut ainsi prétendre que Alice lui a envoyé le message A4' chiffré avec ce nouve
exposant.
Cette attaque est particulièrement pénible dans certaines circonstances. Une fonctio]
de hachage ne résoud pas le problème. Cependant, imposer à chaque utilisateur ui
exposant de chiffrement fixe le résoud.
6. Ceci doit être évident à partir des deux points précédents.

19.4 P o h l ig - H ellm an 499
Standards
RSA est un standard de facto pratiquement dans le monde entier. L ’Organisation
internationale de normalisation a pratiquement créé un standard R S A de signatures
numériques; le R S A figure en annexe de l’IS O /IE C 9796 [767]. La communauté
bancaire française a standardisé le R SA [514] ainsi que les australiens [1198]. Les Etats-
Unis n’ont actuellement pas de standard de cryptographie à clef publique à cause des
pressions de la N SA et de problèmes de brevets. De nombreuses sociétés américaines
utilisent PK C S (voir § 24.14) qui est un produit de R S A D a r a S e c u r i t y , In c . Une
ébauche de standard bancaire ANSI s’appuie sur RSA.
Brevets
L’algorithme R SA est breveté aux États-Unis [1341]. Il n’est breveté dans aucun autre
pays. P K P offre des licences d ’exploitation de ce brevet ainsi que pour d’autres bre
vets de cryptographie à clef publique (voir § 25.5). Le brevet américain expire le 20
septembre 2 0 0 0 .
19.4 Pohlig—Hellman
Le schéma de chiffrement P o h l i g - H e l l m a n [1263] est similaire au R SA . Ce n’est
pas un algorithme à clef secrète puisque des clefs différentes sont utilisées pour le
chiffrement et le déchiffrement. Ce n’est pas un schéma à clef publique car les clefs
se déduisent facilement l’une de l’autre, les clefs de chiffrement et de déchiffrement
doivent être toutes deux gardées secrètes.
Comme pour le R SA ,
C = A4e mod n
M . = C d mod n,
tel que :
ed = 1 (mod « un nombre compliqué »).
Contrairement au R SA , n n’est pas défini en fonction de deux grands nombres pre

miers ; il doit faire partie de la clef secrète. Si quelqu’un avait e et n, il pourrait calculer
i. Sans la connaissance de e ou d, un adversaire serait obligé de calculer
e = (logM C) mod n.
Vous avons déjà vu que c’était un problème difficile.
Brevets
^'algorithme P o h l i g H e l l m a n est breveté aux États-Unis [724] et au Canada. P K P
ictroie des licences d’exploitation de ce brevet, ainsi que d ’autres brevets de crypto
graphie à clef publique (voir § 25.5).
19.5 Rabin
La sécurité du schéma de R a b in [1294, 1603] dépend de la difficulté de calculer des
racines carrées modulo un nombre composite. Ce problème est équivalent à la factori
sation.
Tout d’abord, choisissez deux nombres premiers, p et q, tout deux congrus à 3 modulo 4.
Ces nombres premiers forment la clef privée ; n = pq est la clef publique.
Pour chiffrer un message, A4 (A4 doit être inférieur à n), calculez simplement
C --- A42 mod n.
Déchiffrer un message est aussi facile, mais un peu plus embêtant. Comme les desti
nataires connaissent p et q. ils peuvent résoudre les deux congruences en utilisant le
théorème du reste chinois. Calculez :
Toi = c ( p + D / 4 m o d p
m 2 — (p ~ C ^ +l)>A) mod p
m 3 = c (9 + D /4 m o d g
7714 — (ç — C(9+1)/4) mod q.
Prenez alors des entiers a et b tels que a = q i q 1 mod p) et b = p(p~* mod q).Les
quatres solutions possibles sont les suivantes :
A4i = ( ami + bm3) mod n

M .2 — {ami + bm±) mod n
A43 = (am 2 + bm3) mod n
A44 = (am2 + brri/f) mod n.
L’un de ces 4 résultats, A4i, A42, A43 ou A44, est égal à A4. Si le message estdu
texte en anglais, il serait facile de choisir le bon A4*. D ’autre part, si le message est
une chaîne aléatoire de bits (pour la génération de clefs, par exemple) ou une signature
numérique, il n’y a aucun moyen de savoir quel A4* est correct. Un moyen de résoudre
ce problème est d ’ajouter une entête connue au début du message.
Williams
W illia m s a redéfini les schémas de R a b in pour éliminer leurs limitations [1603]. Dans
son schéma, p et q sont sélectionnés tels que :
p= 3 (m od 8)
q= 7 (mod 8)
et
N = pq.
Il y a également un petit entier S , tel que J(S,N) = —1 dans lequel « J » dénote le
symbole de Jacobi (voir § 11.3). Les valeurs N et S sont publiques. La clef secrète est
k telle que :
k = \ x (^ x (p - i ) x (q - i ) + i)-
19.6 E lG a m a l 501
Pour chiffrer un message A l, calculez cj tel que J (A l,N ) — (—l ) Cl. Ensuite, calculez
M ' = ( S Cl x A l) mod N . Comme pour le schéma de R a b i n , C = A l '2 mod N . Et
C2 = A 1' mod 2. Le message chiffré final est le triplet :
(C,C!,C2).
Pour déchiffrer C, le destinataire calcule A i ” en utilisant :
Ck = ± A t " (mod N).
Le signe correct étant donné par c2. Finalement,
A l = (S ~Cl x ( - 1 ) C1 x A i ” ) mod N.
W il l ia m s a modifié ce schéma dans [1605, 1606, 1607]. Au lieu de mettre le message

au carré, mettez-le au cube. Les grands nombres premiers doivent être congrus à 1
modulo 3 ; sinon la clef publique et la clef privée sont les mêmes. Mieux encore, il n’y
a qu’un déchiffrement possible pour chaque chiffrement.
Par rapport au R SA , R a b i n et W il l ia m s ont tous deux l’avantage d ’avoir été prouvés
aussi sûrs que la factorisation. Toutefois, ils ne sont absolument pas sûrs dans le cas
d’une attaque à texte chiffré choisi. Si vous avez l’intention d’utiliser ces schémas dans
des situations où un attaquant peut monter une telle attaque (par exemple, dans un
algorithme de signature numérique où l’attaquant peut choisir les messages qu’il fait
signer), assurez-vous d ’utiliser une fonction de hachage à sens unique avant de signer.
Malheureusement, une fois que vous ajoutez une fonction de hachage à sens unique au
système, il n’est plus aussi sûr que la factorisation [630], bien que d’un point de vue
pratique, l’ajout de la fonction de hachage ne peut pas affaiblir le système.
D’autres variantes de R a b i n se trouvent dans [983, 910, 696, 698, 1441, 999]. Une
variante à deux dimensions est décrite dans [867, 889].
19.6 ElGamal
Les schémas E l G a m a l [520, 521] peuvent être utilisés à la fois pour les signatures
numériques et pour le chiffrement. Il tire sa sécurité de la difficulté de calculer des
logarithmes discrets.
Pour engendrer une paire de clefs, choisissez d ’abord un nombre premier p et deux
nombres aléatoires g et x, tels que g et x soient tous deux inférieurs à p. Ensuite
calculez :
y — gx mod p.
La clef publique est faite de y, g et p. Les valeurs de g et p peuvent être toutes deux
partagées par un groupe d ’utilisateurs. La clef privée est x.
Signatures ElGamal
Pour signer un message A4, choisissez d ’abord un nombre aléatoire k, tel que k et p — 1
soient premiers entre eux. Ensuite calculez :
a = gk mod p
et utilisez l’algorithme d ’Euclide étendu pour trouver la valeur de b qui satisfait l’équa
tion suivante :
AA = (xa -f kb) mod (p — 1).
La signature est la paire : a et b. La valeur aléatoire k doit être tenue secrète.
Pour vérifier une signature, il faut confirmer que :
yaab mod p = gM mod p.
Cela est résumé par le tableau 19.5.
Tab. 19.5 - Signatures E l G a m a l
C l e f p u b liq u e :
p premier (peut être partagé par un groupe d ’utilisateurs)
g < p (peut être partagé par un groupe d’utilisateurs)
y — gx mod p
c l e f p r iv é e :
x < p
S ig n a tu r e :
k choisi aléatoirement et premier avec p — 1
a (signature) = gk mod p
b (signature) tel que AA = (xa + kb) mod (p - 1)
V é r if ic a t i o n :
La signature est valide si y aab mod p = gM mod p.
Il faut prendre une nouvelle valeur de k à chaque chiffrement et à chaque signature,

et cette valeur doit être choisie aléatoirement. Si jamais Estelle récupère une valeur
de k que Alice a utilisé, elle peut retrouver la clef privée x d ’Alice. Si jamais Estelle
récupère deux messages signés ou chiffrés avec la même valeur de k, elle peut retrouver
x.
Par exemple, choisissez p = 11 et g = 2. Choisissez la clef privée x = 8. Calculez :
y — gx mod p = 28 mod 11 = 3.
La clef publique est faite de y = 3, p = 2 et p = 1 1.

Pour authentifier A4 — 5, choisissez d’abord un nombre aléatoire k = 9. Confirmez que
pgcd(9,10) = 1. Calculez :
a = gk mod p = 29 mod 11 = 6
et utilisez l’algorithme d ’Euclide étendu pour résoudre :

JA = (ax + kb) mod (p — 1)
5 = ( 8 x 6 + 9 x 6 ) mod 10.
La solution est b = 3 et la signature est la paire a — 6 et b — 3.

Pour vérifier la signature, confirmez que :
y aab mod p = gM mod p
3663 mod 11 = 25 mod 11.
19.6 E lG a m al 503
Une variante de E l G a m a t , pour les signatures est décrite dans [1382]. Thomas B e t h
a inventé une variante du schéma E l G a m a l adaptée aux preuves d ’identité [153]. Il
existe des variantes pour la validation de mots de passe [317], et pour l’échange de clefs
[773]. Et il en existe bien d ’autres (voir § 20.4).
Chiffrement ElGamal
Une modification du schéma E l G a m a l permet le chiffrement. Pour chiffrer un message
A4, choisissez d ’abord un nombre aléatoire k tel que k et p — 1 soient premiers entre
eux. Ensuite calculez :
a = gk mod p
b = y kM. mod p.
La paire a et b forme le texte chiffré. Remarquez que la taille du texte chiffré est le
double de celle du texte en clair.
Pour déchiffrer a et 6, calculez :
A4 = b /a x mod p.
Puisque ax = gkx (mod p) et que b/ax = ykM / a x = gxkM / g xk = A4 (mod p), tout
est en ordre(voir le tableau 19.6). C ’est vraiment la même chose que dans l’échange
de clefs deD if f ie - H e l l m a n (voir § 22.1), ceci près que y fait partie de la clef, et que
le chiffrement est multiplié par y k.
Tab. 19.6 - Chiffrement E l G a m a l
C l e f p u b liq u e :
p premier (peut être partagé par un groupe d’utilisateurs)
g < p (peut être partagé par un groupe d’utilisateurs)
y — gx mod p
C l e f p r iv é e :
x < p
C h iff r e m e n t :
k choisi aléatoirement et premier avec p — 1
a (texte chiffré) = gk mod p
b (texte chiffré) = y kA4 mod p
D é c h iff r e m e n t :
A4 (texte en clair) = b/ax mod p
Vitesse
Le tableau 19.7 donne des exemples de vitesses de réalisations logicielles de E l G am al
[929].
T a b . 19.7 - Vitesses de E l G a m a l pour différentes longueurs de module avec des ex

posants de 160 bits (sur une station SP A R C II)
Chiffrement, 0,33 s 0,80 s 1,09 s
Déchiffrement 0,24 s 0,58 s 0,77 s
Brevets
E l G a m a l n’est pas breveté. Mais, avant de démarrer une réalisation de cet algorithme,
tenez compte du fait que P K P considère que cet algorithme est couvert par le brevet
du système DlFFiE-HELLMAN [720]. Cependant, ce brevet expire le 29 avril 1997, ce
qui fera de E l G a m a l le premier algorithme cryptographique à clef publique adapté
au chiffrement et aux signatures numériques qui ne soit pas couvert par un brevet aux
Etats-Unis. Je suis impatient de voir cela.
19.7 McEliece
En 1978, Robert M c E l ie c e a développé un cryptosystème à clef publique basé sur la
théorie des codes algébriques [1049]. L’algorithme fait usage de l’existence d’une classe
de codes correcteurs d’erreurs, connus sous le nom de codes de G o p p a . Son idée est
de construire un code de G o p p a et de le déguiser en code linéaire général. Il existe un
algorithme rapide pour décoder un code de G o p p a , mais décoder des codes linéaires
généraux est un problème N P - c o m p l e t . Une bonne description de cet algorithme peut
être trouvée dans [1243] ; consultez aussi [1533]. Ce qui suit est un bref résumé.
Soit dff(x,y) la distance de H a m m i n g entre x et y. Les nombres n, k et t sont des
paramètres du système.
La clef privée a trois parties : G' une matrice génératrice k x n pour un code de G o p p a
qui peut corriger t erreurs, P une matrice de permutation n x n, S une matrice non
singulière k x k.
La clef publique est une matrice G, k x n telle que: G = SG ’P.
Les messages en clair sont des chaînes de k bits sous la forme de vecteurs àk éléments
de Z /2 .
Pour chiffrer un message, choisissez un vecteur aléatoire à n éléments deZ j 2, z avec
une distance de H a m m i n g inférieure ou égale à t.
c = mG + z
Pour déchiffrer le texte chiffré, calculez d ’abord c' = cP 1. Ensuite, en utilisant l’algo
rithme de décodage des codes de G o p p a , trouvez m 't e l que d //( m , G ,c, ) soit inférieure
ou égale à t. Finalem ent, calculez m = m 'S _1.
Dans son article originel, M c E l ie c e suggère d ’utiliser n = 1024, t = 50 et k = 524.
C ’est le minimum requis pour la sécurité.
Bien que cet algorithme fût l’un des premiers algorithmes à clef publique et qu’il n’y
ait pas de résultats cryptanalytiques contre cet algorithme, il n’obtint jamais une large
19.8 Cryptosystèmes à courtes elliptiques 505
diffusion dans la communauté cryptographique. Ce schéma est de deux à trois ordres

de grandeurs plus rapide que le R S A mais il pose différents problèmes. La clef publique
est énorme : 219 bits de long. L’expansion des données est importante : le texte chiffré
est deux fois plus long que le texte en clair.
Certaines tentatives de cryptanalyse de ce système sont décrites dans [12, 954, 1530,
311]. Aucune d ’entre elles ne fut victorieuse, bien que la similarité entre l’algorithme
de M c E l ie c e et les empilements ait inquiété certains.
En 1991, deux cryptographes de l’ex-Union soviétique, K o r z h ik et T u r k in ont pré
tendu avoir cassé le système avec certains paramètres [882]. Leur article ne contient au
cune preuve et beaucoup de cryptographes doutent de leur résultat. Une autre attaque
russe, qui ne peut pas s’utiliser directement contre le système M c E l ie c e , est décrite
dans [1453, 1454], Des extensions de M c E l ie c e sont présentés dans [426, 1237, 986].
Autres algorithmes basés sur les codes correcteurs d’erreurs li

néaires
L’algorithme de NlEDERREiTER [1166] est étroitement lié à l’algorithme de M c E l i e c e ,
et fait l’hypothèse que la clef publique est une matrice aléatoire de vérification de parité
d’un code correcteur. La clef privée est un algorithme efficace de décodage pour cette
matrice.
Un autre algorithme, servant à l’identification et aux signatures numériques, est basé
sur le syndrome du décodage [1504] ; consultez [311] pour les commentaires. Un dernier
algorithme basé sur les codes correcteurs d ’erreurs [1623] n’est pas sûr [699, 51, 52,1531,
53].
19.8 Cryptosystèmes à courbes elliptiques

Les courbes elliptiques ont été étudiées pendant de nombreuses années et il existe
un volume important de publications à ce sujet. En 1985, Neal K o b l i t z et V.S.
M il l e r ont proposé indépendamment de les utiliser pour des cryptosystèmes à clef
publique [868, 1101]. Ils n ’ont pas inventé un algorithme cryptographique qui utilise
les courbes elliptiques mais ils ont réalisé des algorithmes à clef publique existants, tel
que D if f ie H e l l m a n , à l’aide de courbes elliptiques.
Les courbes elliptiques sont intéressantes parce qu’elles fournissent un moyen de cons
truire des « éléments » et des « règles de combinaison » qui produisent des groupes.
Ces groupes ont suffisamment de propriétés familières pour construire des algorithmes
cryptographiques mais ils n’ont pas certaines propriétés qui faciliteraient la cryptana
lyse. Par exemple, il n’y a pas de bonne notion de continuité. C ’est-à-dire qu’il n’y
a pas d ’ensemble de petits éléments en fonction desquels un élément quelconque au
rait une bonne chance de pouvoir être exprimé par un algorithme simple. D ’où le fait
que les algorithmes de calcul indiciel de logarithmes discrets (« index calculus discrète
logarithm algorithms ») ne marchent pas. Voyez [1101] pour plus de détails.
Les courbes elliptiques sur les corps finis Z j2 n sont particulièrement intéressantes.
Les processeurs arithmétiques pour les corps sous-jacents sont faciles à construire et
relativement simples à réaliser pour des valeurs de n dans l’intervalle de 130 à 200. Ces
systèmes ont le potentiel de fournir des cryptosystèmes à clef publique plus rapides
avec des clefs plus petites. D e nombreux algorithmes à clef publique, tels que DlFFiE-
H e l l m a n , E l G a m a l et S c h n o r r , peuvent être réalisés à l’aide de courbes elliptiques
sur des corps finis.
Les mathématiques de ces systèmes sont complexes et dépassent le cadre de ce livre.
Ceux qui sont intéressés par le sujet sont invités à lire les deux références men
tionnées ci-dessus et l’excellent livre de Alfred M e n e z e s [1068]. Deux analogues
de R SA fonctionnent avec les courbes elliptiques [890, 457]. D ’autres articles sont
[27, 129, 1069, 871, 159, 872, 892, 30, 895, 357, 1070, 29, 915, 916, 913]. Les cryptosys
tèmes à courbes elliptiques à clefs de petite taille sont examinés dans [702]. Le « Fa s t
E l l ip t ic E n c r y p t i o n » (F E E ) de N e x t C o m p u t e r , I n c . utilise des courbes ellip
tiques [392]. Le FEE présente l’avantage de pouvoir utiliser n’importe quelle chaîne
de caractères facile à retenir comme clef privée. Il y a aussi des cryptosystèmes à clef
publique qui utilisent des courbes hyperelliptiques [870, 869, 1447, 1222].
19.9 LUC
Quelques cryptographes ont développé des généralisations de R SA qui utilisent diffé
rents polynômes à la place de l’exponentiation. Une variante appelée K r a v i t z - R e e d ,
utilisant des polynômes binaires irréductibles [897], n’est pas sûre [454, 591]. Winfried
M ü l l e r and Wilfried N ô b a u e r utilisent les polynômes de D i c k s o n [1133, 1134, 976].
Rudolf L i d l et N ô b a u e r ont inspecté sa sécurité [1178, 1179]. (La génération de
nombres premiers avec les fonction de L u c a s est commentée dans [980, 978, 979, 600].)
Malgré tous ces travaux antérieurs, un groupe de chercheurs de la Nouvelle-Zélande
ont tenté en 1993 de breveter ce schéma, lui donnant le nom de LUC [1493, 523, 1494].
Le ne nombre de L u c a s Vn(AA,\) est, défini par:
Vn( M , 1 ) = - Un _ 2 (A 4 ,l)
Tout le reste de la théorie de nombres de L u c a s est ignorée ici. Une bonne approche
mathématique des suites de L u c a s se trouve dans [1318, 1319]. Une description parti
culièrement soignée des mathématiques de LU C est donnée dans [1501, 709].
Dans tous les cas, pour générer une paire clef publique/clef privée, commencez par
choisir deux grands nombres premiers p et q. Calculez n = pq. La clef de chiffrement e
est un nombre aléatoire premier avec p — 1, q — 1 , p + 1 et q + 1.
Il y a quatre clefs de déchiffrement possibles (ppcm désigne le plus petit commun
multiple) :
d= e~ l mod (ppcm(p -f 1,q + 1))

d= e ~ 1 mod (ppcm(p + 1,q — 1))
d= e ~ x mod (ppcm(p — 1,ç + 1))
d= e-1 mod (ppcm(p — 1,q — 1))
La clef publique est formée de d et n, la clef privée de e et n. Jetez p et q. Pour chiffrer

un message AA (AA doit être inférieur à n), calculez :
C = Ve(JA,\) (mod n)
19.10 Automates finis 507
et pour déchiffrer :
M = V d(M ,l) (mod n)
Au mieux, LU C est aussi sûr que R SA . Et un résultat récent, non encore publié,
montre comment casser LU C au moins dans certaines réalisations. Je ne lui fait pas
confiance.
19.10 Automates finis

Le cryptographe Tao R e n j i a développé un algorithme à clef publique basé sur les
automates finis [1312, 1313, 1314, 1315, 667]. De même qu’il est difficile de factoriser
le produit de deux grands nombres premiers, il est difficile de factoriser la composition
de deux automates finis, spécialement quand l’un d’eux (ou les deux) n’est pas linéaire.
La majorité de ces recherches a été menée en Chine dans les années 1980 et publiée en
chinois. R e n j i commence à l’écrire en anglais. Son résultat principal dit que certains
automates non linéaires (les automates quasi-linéaires) possèdent des inverses faibles
si et seulement s’ils ont une certaine structure de matrice à échelons. Cette propriété
disparaît s’ils sont composés avec un autre automate, même linéaire. Dans l’algorithme
à clef publique, la clef privée est composée d’un automate quasi-linéaire inversible et
d’im automate linéaire, et la clef publique correspondante est obtenue en les multipliant
terme à terme. Les données sont chiffrées en les passant à travers l’automate publique,
et déchiffrées en les passant à travers les inverses de ses composantes (dans certains
cas, à condition qu’ils aient été positionnés des états initiaux appropriés). Ce schéma
fonctionne à la fois pour le chiffrement et pour les signatures numériques.
La performance de ces systèmes se résume ainsi : comme le système M c E l i e c e , ils sont
beaucoup plus rapides que le R S A , mais nécessitent des clefs plus longues. La longueur
de clef donnant une sécurité similaire au R SA à 512 bits est de 2792 bits, et de 4152
bits pour le R S A à 1024 bits. Dans le premier cas, ce système chiffre 20 869 octets de
données par seconde et déchiffre 17117 octets de données par seconde sur un 80486 à
33 MHz.
R en ji a publié trois algorithmes. Le premier, FAPK C 0, est un système affaibli qui
utilise des composantes linéaires, et est avant tout illustratif. Deux systèmes sérieux,
FAPKC1 et FA P K C 2 utilisent une composante linéaire et une composante non li
néaire chacun. Le deuxième est plus compliqué et a été développé de manière à per
mettre les opérations à base d ’identification.
Quand à leur solidité, une somme de travail assez importante leur a été dédiée en Chine
(où il y a maintenant plus de 30 instituts publiant des articles de cryptographie). On
peut apprécier d’après l’imposante littérature en chinois que le problème a été étudié.
Un charme éventuel de FA PK C 1 et F A PK C 2 est qu’ils ne sont encombrés d’aucun
brevet américain. Aussi, quand le brevet de D if f ie - H e l l m a n expirera en 1997, ils
feront sans doute partie du domaine publique.
Chapitre 20
Algorithmes de signature
numérique à clef publique
20.1 Algorithme de signature numérique

DSA
En août 1991, l’Institut national des standards et de la technologie américain NIST
(« National Institute of Standards and Technology ») proposa l’algorithme de signa
ture numérique D SA (« Digital Signature Algorithm ») pour le nouveau standard
de signature numérique DSS (« Digital Signature Standard »). D ’après le « Fédéral
Register » [541] :
« Un standard fédéral de traitement de l’information FIPS (« Fédéral

Information Processing Standard ») est proposé pour le standard de signa
ture numérique DSS. Cette proposition de standard spécifie un algorithme
de signature numérique à clef publique (D S A ) approprié pour les appli
cations de signature numérique fédérales. Le DSS proposé utilise une clef
publique pour permettre à un destinataire de vérifier l’intégrité des données
et de vérifier l’identité de l’expéditeur des données. Le DSS peut aussi être
utilisé par une tierce personne pour établir l’authenticité d’une signature
et des données qui y sont associées.
« Cette proposition de standard adopte un schéma de signature à clef
publique qui utilise une paire de transformations pour engendrer et vérifier
la valeur numérique appelée signature. »
Et:
« La proposition de FIPS est le résultat de l’évaluation d ’un certain

nombre d’alternatives de techniques de signature numérique. En faisant
son choix, le N IST s’est conformé au mandat contenu dans la section 2
du « Computer Security Act » de 1987 indiquant que le N IST développe
des standards pour « . . . garantir de manière rentable la sécurité et la confi
dentialité des informations fédérales et, parmi les technologies offrant un
510 Chapitre 20 Algorithmes de signature numérique à clef publique
niveau de protection comparable, choisir l’option avec les meilleures carac

téristiques opérationnelles et pratiques. »
Parmi les facteurs considérés durant ce processus, il y avait le niveau de
sécurité offert, la facilité de réalisation à la fois matérielle et logicielle, la
facilité d’exportation hors des Etats-Unis, les brevets applicables, l’impact
sur la sécurité nationale et la préservation de la loi, et le niveau d’efficacité
à la fois pour les fonctions de signature et de vérification.
Un certain nombre de techniques furent considérées comme fournissant
la protection appropriée pour les systèmes fédéraux. La technique sélection
née présente les avantages suivants :
- Le N IST escompte qu’elle sera disponible gratuitement. Un plus large
usage de cette technique résultant de sa disponibilité dans le domaine
public devrait être bénéfique au gouvernement et au public.
- La technique sélectionnée permet des réalisations efficaces des opéra
tions de signature dans des applications de cartes à puce. Dans ces
applications, les opérations de signature sont effectuées avec les mo
destes ressources en calcul de la carte à puce, tandis que le processus de
vérification est réalisé dans un environnement plus riche en ressources
de calculs tels qu’un ordinateur personnel, un module cryptographique
matériel, ou un ordinateur central. »
Avant que cela ne devienne trop confus, laissez-moi revoir la nomenclature : D SA est
l’algorithme, DSS est le standard. Le standard utilise l’algorithme. L’algorithme fait
partie du standard.
Réactions à l’annonce
L’annonce du N IST a déclenché un maelstrôm de critiques et d’accusations. Mal
heureusement, toutes plus politiques qu’académiques. R S A D a t a S e c u r i t y , In c .,
pourvoyeur de l’algorithme R SA , conduisit les critiques contre le DSS, exigeant que le
R S A soit utilisé dans le standard comme algorithme, et pas un autre. R SA D SI gagne
beaucoup d ’argent en vendant des licences d’exploitation de l’algorithme R SA , et un
standard de signature numérique exempt de droits affecterait directement ses revenus
de base1.
Avant que l’algorithme ne soit annoncé, R SA D SI fit campagne contre un « module
commun », qui aurait donné la possibilité au gouvernement de falsifier des signatures.
Quand l’algorithme fut annoncé sans ce « module commun », R SA D S I l’attaqua sur
d’autres bases [161], à la fois dans des lettres adressées au N IST et dans la presse2.
De nombreuses grandes sociétés de logiciel qui avaient déjà acquis une licence pour
l’algorithme R S A s’opposèrent au DSS. En 1982, le gouvernement américain sollicita
des algorithmes à clef publique pour un standard [539]. Après cela, il n ’y eut plus le
moindre signe de vie du N IST durant neuf ans. Des sociétés telles qu’IBM , A p p l e ,
N o v e l l , L o t u s , N o r t h e r n T e l e c o m , M i c r o s o f t , D EC et S u n avaient déjà investi
1. Notez que le D S A pourrait enfreindre certains brevets; j ’y reviendrai

2. Q uatre lettres adressées au N IS T furent publiées dans [1337]. Q uand vous les lisez, gardez à
l’esprit qu ’au moins deux des auteurs, R . RlVEST et M. HELLMAN, ont un intérêt financier à ce que le
D SS ne soit pas accepté.
20.1 Algorithme de signature numérique D S A 511
des montants importants dans la réalisation de l’algorithme RSA . Ils ne voulaient pas
perdre cet investissement.
En tout, le N IST avait reçu 109 commentaires à la fin de la première période d’éva
luation, le 28 février 1992.
Parcourons une à une les critiques contre le D SA :
1. Le D S A ne peut pas être utilisé pour le chiffrement ou la distribution de clefs.

C ’est vrai, mais ce n’est pas son objet. C ’est un standard de signature. Il devrait
y avoir un standard N IST de chiffrement à clef publique. Le N IST cause un
grave préjudice au peuple américain en ne mettant pas sur pieds un standard de
chiffrement à clef publique. Il est suspect que le N IST ait proposé un standard
de signature numérique qui ne puisse pas être utilisé pour le chiffrement3. Cela
ne veut pas dire qu’un standard pour la signature numérique est inutile.
2. Le D SA a été développé par la N SA, et il peut y avoir une brèche secrète dans
l’algorithme.
La plupart des premiers commentaires relevaient de la paranoïa: « Le refus du
N IST de fournir l’information sans justification apparente n’inspire pas confiance
dans le DSS, mais renforce l’inquiétude quant à l’existence d’un dessein caché
telle la mise en place d’un cryptosystème à clef publique national qui puisse
être cassé par le N IST et/ou la NSA. » [161]. Il y eut une objection sérieuse
concernant la sécurité du DSS soulevée par Arjen L e n s t r a et Stuart H a b e r
des laboratoires « B e l l c o r e ». Elle sera présentée plus avant dans le texte.
3. Le D SA est plus lent que le R S A [809].

C ’est vrai, plus ou moins. Les vitesses de génération de signature sont les mêmes
mais la vérification de signature peut être 10 à 40 fois plus lente avec le D SA. La
génération de clefs est plus rapide que celle du R SA . La génération de clef est
hors de propos ; un utilisateur fait cela rarement. D ’autre part, la vérification de
signature est ]’opération la plus usitée.
Le défaut de cette critique est qu’il y a plusieurs moyens de jouer avec les pa
ramètres de test en fonction du résultat que l’on veut obtenir. Les précalculs
peuvent accélérer la génération de signatures du D SA mais ils ne sont pas tou
jours réalisables. Les défenseurs du R S A utilisent des nombres optimisés pour
rendre leurs calculs plus faciles; les défenseurs du D S A utilisent leurs propres
optimisations. Dans tous les cas, les ordinateurs vont toujours de plus en plus
vite. Bien qu’il y ait une différence, dans la plupart des applications ce n’est pas
notable.
4. Le R SA est un standard de facto.

Il y a deux exemples d’une telle plainte. L’une émane de Robert FOLLETT, di
recteur du programme des standards d’IBM [572] :
« IBM s’inquiète du fait que le N IST ait proposé un standard avec un

schéma de signature numérique différent plutôt que d’adopter un stan
dard international. Nous avons été convaincus par les utilisateurs et les
3. E t pourtant, il peu t quand m êm e l’être — voir § 23.3.

organisations d’utilisateurs que des standards internationaux utilisant

le R S A seraient un prérequis pour la vente de produits de sécurité dans
un avenir très proche. »
L ’autre est de Les S h r o y e r , vice-président et directeur des services informatiques

et des télécommunications chez MOTOROLA [1450] :
« Nous devons avoir un standard de signature unique, robuste et politi

quement accepté qui soit utilisable à travers le monde, entre américains
et n on- Américains, et entre MOTOROLA et des entités non-M oTOROLA.
L’absence d’une autre technologie de signature numérique viable du
rant ces huit dernières années a fait de R S A un standard de facto ...
M o t o r o l a et de nombreuses autres sociétés ... ont dépensé des mil
lions de dollars pour le R SA . Nous sommes inquiets de l’interfonction-
nement et du soutien de deux standards différents car cette situation va
occasionner des surcoûts, des retards de diffusion et des complications
... »
De nombreuses sociétés voulaient que le N IST adopte IS O /IE C 9796, le stan

dard international de signature numérique qui utilise le R S A [767]. Bien que ce
soit une objection valable, ce n’est pas une justification suffisante pour en faire un
standard. Un standard exempt de droits servirait au plus haut point les intérêts
du public américain.
5. Le processus de sélection du D SA n’était pas public; il n’a pas bénéficié d’un

temps suffisant pour l’analyse.
Tout d’abord, le N IST prétendit avoir conçu le D SA ; ensuite ils admirent que la
N SA les avait aidés. Finalement, ils confirmèrent que la N SA avait conçu l’algo
rithme. Cela inquiétait nombre de gens auxquels la NSA n ’inspire pas confiance.
Même ainsi, l’algorithme est public et disponible pour analyse; et le N IST a
prolongé la période d’analyse et de commentaires.
6. Le D S A peut enfreindre d ’autres brevets.

C ’est possible. Ce sera discuté plus en détail dans la section sur les brevets.
7. La taille de clef est trop petite.

C ’était la seule critique valable contre le DSS. La réalisation originale prévoyait
un module de 512 bits [1176]. Comme la sécurité de l’algorithme dépend de la
difficulté de calculer des logarithmes discrets modulo le module, c ’était inquiétant
pour la plupart des cryptographes. Il y a eu des avancées dans le domaine du
calcul des logarithmes discrets sur un corps fini et un module de 512 bits est trop
court pour une sécurité à long terme (voir § 7.2). D ’après Brian LaMacchia et
Andrew O d l y z k o , « ... même des nombres premiers de 512 bits semblent n’offrir
qu’une sécurité marginale ... » [945]. Ce n’est pas tout à fait correct — 512 bits
offrent une sécurité suffisante aujourd’hui. Mais si votre sécurité doit s’étendre
dans la futur, ce n’est pas sûr. En réponse à cette critique, le NIST a rendu
variable la taille de clef de 512 à 1024 bits. Nous y reviendrons plus en détail.
Le standard a finalement vu le jour le 19 mai 1994 [1174], Le décret d ’adoption précisait

[540] :
« Ce standard s’applique à tous les départements et instituts fédéraux pour
la protection d’informations non classées... Ce standard doit être inclus
dans la conception et la réalisation de schémas de signature à clef publique
utilisés par les département et instituts fédéraux ou par d’autres organismes
sous contrat avec eux. L’adoption et l’utilisation de ce standard est ouverte
aux organismes privés ou commerciaux. »
Avant d’inclure ce standard dans votre prochain produit, lisez un peu plus loin la partie
concernant les problèmes de brevet.
Description de l’algorithme
Le DSA est une variante des algorithmes de signature S c h n o r r et E l G a m a l qui est
entièrement décrite dans [1174]. L’algorithme utilise les paramètres suivants:
•p — un nombre premier de L bits de long, où L est compris entre 512 et
1024 et est un multiple de 64.4
q = un facteur premier de p — 1, long de 160 bits.
g = /j(p-i)/<7 mod p, où h est n’importe quel nombre inférieur à p — 1 tel
que h^p~ l^'q mod p soit plus grand que 1.
x = un nombre inférieur à q.
y = gx mod p.
De plus, l’algorithme utilise une fonction de hachage à sens unique: H (x). Pour le
DSS, c ’est l’algorithme de hachage sûr (« Secure Hash Algorithm ») décrit par le
paragraphe 18.7.
Les trois premiers paramètres p, q et g sont publics et peuvent êtrecommuns à un
réseau d’utilisateurs. La clef privée est x et la clef publique est y.
Pour signer un message M. :
1° Alice engendre un nombre aléatoire k inférieur à q.
2° Alice engendre
r = ( gk mod p) mod q
s = ( k~ 1 ( H ( M ) + xr)) mod q.
Les paramètres r et s forment sa signature ; elle les envoie à Bernard.

3° Bernard vérifie la signature en calculant:
w = s-1 mod q
u\ = (H (M ) x w ) mod q
u2 = rw mod q
v = ((g,“ 1 x yU2) mod p) mod q.
4. Dans le standard original, la longueur de p était fixée à 512 bits [1176]. C e fut la source de
nombreuses critiques et le N IS T du changer [1174],
Si v = r, alors la signature est vérifiée.
Les preuves des relations mathématiques sont fournies dans [1174]. Voyez le ta
bleau 20.1 pour un résumé.
T a b . 20.1 - Signatures DSA
C lef publique :
p nombre premier de 512 à 1024 bits
q facteur premier de p — 1 de 160 bits
g= mod p, où h est inférieur à p — 1 et (hSp O/ç mod p) > 1
(p, q et g peuvent chacun être partagés par un groupe d ’utilisateurs)
y = gx mod p
C lef privée :
x < q (un nombre de 160 bits)
Signature :
k choisi aléatoirement et inférieur à q
r (signature) = ( gk mod p) mod q
s (signature) = (fc- 1 (i/(m ) + xr)) mod q
Vérification :
w = s ~ l mod q
Ui = ( H (m ) x w) mod q
u2 = rw mod q
v = (( gUl x y U2) mod p) mod q
Si v = r, alors la signature est vérifiée.
Vitesse et précalculs
Le tableau 20.2 donne quelques vitesses de logiciels réalisant le DSA.
20.2 - Vitesses du D S A pour différentes longueurs de module avec un exposant

T a b .
de 160 bits (sur une station S P A R C II )
Les réalisations concrètes du D SA peuvent être accélérées grâce aux précalculs. Notez
que la valeur de r ne dépend pas du message. Vous pouvez créer une chaîne de valeurs
aléatoires k et précalculer la valeur r pour chacune d’entre elles. Vous pouvez aussi
précalculer A;'1 pour chacune de ces valeurs k. Ensuite, quand un message arrive, vous
pouvez calculer s pour des r et fc-1 donnés.
Ce précalcul accélère considérablement le D SA. Le tableau 20.3 donne une comparaison
des temps de calcul pour le D S A et le R S A pour une réalisation en carte à puce [I486].
Génération des nombres premiers pour le DSA

L enstra et H aber remarquèrent que certains modules sont nettement plus faciles
T ab. 20.3 - Comparaison des temps de calcul pour le R SA et le D SA
D SA RSA D SA
avec p, q
et g communs
Calculs généraux hors-carte (P) sans objet hors-carte (P)
Génération de clef 14 s hors-carte (S) 4s
Précalcul 14 s sans objet 4s
Signature 0,03 s 15 s 0,03 s
Vérification 16 s 1,5 s 10 s
1-5 s hors-carte (P) 1-3 s hors-carte (P)
Les calculs hors-carte furent effectués sur un ordinateur personnel avec un processeur
80386 cadencé à 33 MHz. « (P) » indique les paramètres publics hors-carte et « (S) »
indique les paramètres secrets hors-carte. Les deux algorithmes ont été testés avec un
module de 512 bits.
à casser que les autres [961]. Si quelqu’un utilisait l’un de ses modules « faibles »,
ses signatures pourraient être facilement falsifiées. Ce n’est pas un problème pour deux
raisons : primo, les modules pour lesquels cette propriété est vraie sont faciles à détecter.
Secundo, ces modules sont si rares que les chances d’en utiliser lors du choix aléatoire
d’un module sont négligeables — plus petites en fait que les chances d’engendrer un
nombre composé par une méthode probabiliste de génération de nombres premiers.
Dans [1174], le N IST recommande la méthode suivante de génération des deux nombres
premiers p et q tels que q divise p 1. Le nombre premier p a une longueur de 512 à
1024 bits multiple de 64. Le nombre premier g a 160 bits de long. Soit L — 1 = 160n + b
où L est la longueur de p, n et b sont deux nombres, et b est inférieur à 160.
1° Choisissez une chaîne arbitraire d’au moins 160 bits et appelez-la S. Soit g la
longueur de S en bits.
2° Calculez U = S H A (S ) © S H A ((S + 1) mod 29), où S H A est l’algorithme de
hachage sûr (voir § 18.7).
3° Formez q à partir de U en mettant le bit le plus significatif et le bit le moins
significatif tous deux à 1.
4° Vérifiez si q est un nombre premier.
5 ° Si q n’est pas un nombre premier, retournez à l’étape 1.

6° Posez C = 0 et N = 2.
7° Pour k = 0,1,...,n, on a 14 = S H A ((S 4- N + k) mod 29).
8° Calculez
W = V0 + Ri x 2160 + ... + Vn- i x 2(n“ 1)* 160 + (14 mod 2 b) x 2nxl6Q
et
X = W + 2 l ~ 1.
Remarquez que X est un nombre de L bits.

9° Calculez p = X — ((X mod 2q) — 1). Remarquez que p est congru à 1 modulo
2q.
10° Si p < 2 L Ï, alors allez à l’étape 13.
11 ° Vérifiez si p est premier.
12° Si p est premier, allez à l’étape 15.
13 ° Posez C = C + 1 et N = N + n + 1.
14° Si C = 4 096, alors allez à l’étape 1 , sinon allez à l’étape 7.
15° Sauvegardez les valeurs de S et C utilisées pour engendrer p et q.
Dans [1174], la variable S est appelée le « germe », C le « compteur », et N l’« offset ».

La raison d’être de cet exercice est qu’il existe un moyen public d’engendrer p et q.
Rappelez-vous les gens qui s’inquiétaient du fait que des valeurs « faibles » pour p et q
permettraient de casser le DSA plus facilement. Pour toute utilisation pratique, cette
méthode évite cela. Si quelqu’un vous donne p et q, vous pouvez vous demander d’où ils
viennent. Par contre, si quelqu’un vous donne les S et les C qui ont permis d’engendrer
les p et les q aléatoires, vous pouvez par vous-même refaire les calculs. L ’utilisation de
S H A , une fonction de hachage à sens unique, évite que quelqu’un puisse remonter les
calculs à partir de p et g pour générer S et C.
La sécurité est meilleure que celle que vous auriez avec le R SA . Avec le R SA , les
nombres premiers sont gardés secrets. Quelqu’un peut engendrer un nombre premier
factice ou un nombre ayant une forme spéciale qui facilite la factorisation. À moins que
vous ne connaissiez la clef privée, vous ne le sauriez pas. Ici, même si vous ne connaissez
pas la clef privée, vous pouvez vérifier que p et q ont été engendrés aléatoirement.
Chiffrement ElGamal à l’aide du DSA

Selon certaines allégations, le D SA plaisait au Gouvernement américain parce que
ce n ’était qu’un algorithme de signature numérique qui ne pouvait pas servir pour le
chiffrement. Bien que cela soit vrai, il est possible d’utiliser un appel à la fonction DSA
p ou r réaliser un chiffrement E l G a m a l .
Faites l’hypothèse que l’algorithme D SA est réalisé par une fonction qui peut être
appelée par :
D SA sign ( p , q , g , k , x , h , r , s ) .
Vous fournissez les nombres p, q, g, k, x et h et la fonction fournit comme résultat les

paramètres r et s.
P ou r réaliser le chiffrem ent E l G a m a l d ’un m essage m avec la c le f pu bliqu e y, choisissez
un n om bre aléatoire k et appelez :
D S A s ig n (p ,p ,g ,k ,0 ,0 ,r ,s ).
La valeur de r fournie est a dans le schéma E l G a m a l . Jetez s. Ensuite appelez :
D S A s ig n (p ,p ,y ,k ,0 ,0 ,r , s ) .
Renommez la valeur r en u ; jetez s. Appelez :
D S A s ig n (p ,p ,m ,l,u ,0 ,r ,s ).
Jetez r. La valeur de s fournie est b du schéma E l G a m a l . V o u s avez maintenant le

texte chiffré constitué de a et b.
Le déchiffrement est tout aussi simple. Utilisez la clef secrète x et les messages chiffrés
a et b. Appelez :
D S A s ig n ( p ,p ,a ,x ,0 ,0 ,r ,s ) .
La valeur de r est ax mod p. Appelez-la e. Ensuite appelez :
D S A s i g n ( p ,p ,l ,e ,b ,0 ,r ,s ) .
La valeur s est le texte en clair du message : m.

Cette méthode ne marchera pas avec toutes les réalisations du D SA , dont certaines
peuvent fixer les valeurs de p et ç, ou la longueur de certains autres paramètres.
Toutefois, si la réalisation est suffisamment générale, il y a un moyen de chiffrer avec
une fonction de signature numérique.
Chiffrement RSA à l’aide du DSA

Le chiffrement R S A est encore plus facile à réaliser. Avec un module n, un message m
et une clef publique e, appelez :
D S A s ig n (n ,n ,m ,e ,0 ,0 ,r ,s ).
La valeur r fournie est le texte chiffré.

Le déchiffrement R S A est la même chose :
D S A s ig n (n ,n ,m ,d ,0 ,0 ,r ,s ).
La valeur de r est le texte en clair.
Sécurité du DSA
Avec 512 bits, le D S A n’était pas assez solide pour la sécurité à long terme. Avec 1024
bits, il l’est.
L’Agence nationale de sécurité américaine, dans une première interview à ce sujet, ré
pondit à Joe A b e r n a t h y du Houston Chronicle aux allégations concernant l’existence
d’une brèche secrète dans le DSS [367] :
« En ce qui concerne la présumée brèche secrète dans le DSS, nous

trouvons les termes « brèche secrète » quelque peu trompeurs puisqu’ils
impliquent que des messages envoyés par le DSS sont chiffrés et que par
une brèche secrète quelqu’un pourrait d’une certaine façon déchiffrer (lire)
le message à l’insu de l’expéditeur.
« Le DSS ne chiffre aucune donnée. Le vrai problème est de savoir si le
DSS est susceptible d’être utilisé par quelqu’un pour falsifier une signature
et ainsi discréditer tout ie système. Nous affirmons catégoriquement que les
probabilités que quiconque — y compris la N SA — falsifie une signature
avec le DSS quand il est correctement utilisé et réalisé sont infinitésimales.
« De plus, la présumée vulnérabilité par brèche secrète est vraie pour
n’importe quel système d’authentification à clef publique, y compris le
RSA . Faire croire d ’une certaine façon que cela n’affecterait que le DSS
(un argument répandu dans la presse) est totalement trompeur. C ’est un
problème qui dépend de la réalisation et de comment on sélectionne les
nombres premiers. Nous attirons votre attention sur la récente conférence
EUROCRYPT, pendant laquelle fut organisée une tribune sur le problème
des brèches secrètes dans le DSS. L ’un des chercheurs de B e l l c o r e qui
avait initialement allégué de l’existence d ’une brèche secrète faisait partie de
la tribune et il nous a semblé que les participants à la tribune — y compris
celui de B e l l c o r e — conclurent que la présumée brèche secrète n’était
pas un problème pour le DSS. De plus, le consensus semblait général sur
le fait que le problème de la brèche secrète était insignifiant et qu’il avait
été exagéré par la presse. Toutefois, pour essayer de répondre à l’allégation
concernant la brèche secrète, à la demande du N IST, nous avons conçu
un processus de génération des nombres premiers qui garantira que l’on
puisse éviter le choix des relativement rares nombres premiers faibles qui
auraient entraîné une faiblesse dans l’utilisation du DSS. De plus, le N IST
a l’intention de permettre des tailles de module allant jusqu’à 1024, ce qui
en soi élimine la nécessité d ’utiliser le processus de génération de nombres
premiers pour éviter les nombres premiers faibles. Un point supplémentaire
très important qui passe souvent inaperçu est qu’avec le DSS les nombres
premiers sont publics et donc sujets à l’examen public. Tous les systèmes à
clef publique ne fournissent pas cette possibilité d’examen.
« L’intégrité de tout système de sécurité de l’information dépend de
l’attention apportée à une réalisation correcte. Avec la myriade de vulnéra
bilités possibles compte tenu des différences entre les utilisateurs, la NSA
a toujours insisté sur les centres de confiance centralisés comme moyen de
minimiser les risques dans le système. Bien que nous ayons apporté des mo
difications techniques au DSS pour satisfaire les requêtes du N IST pour
une approche plus décentralisée, nous insistons quand même sur la partie
de la note du « Fédéral Register » pour le DSS qui indique :
« Bien que le but de ce standard soit de spécifier les exigences
générales de sécurité pour engendrer des signatures numériques,
la conformité à ce standard ne garantit pas la sécurité d ’une réa
lisation particulière. Les autorités responsables de chaque agence
ou département doivent veiller à ce que la réalisation globale offre
un niveau de sécurité acceptable Le NIST collaborera avec les
utilisateurs gouvernementaux pour veiller à la bonne qualité des
réalisations. »
Finalement, nous avons lu tous les arguments concernant les insécurités po
tentielles avec le DSS et nous restons sceptiques sur leur validité. Le DSS
a fait l’objet d’une évaluation en profondeur par la NSA, qui a conduit
notre directeur des systèmes de sécurité de l’information à l’adopter pour
signer des données non classées traitées par certains systèmes d ’espionnage,
et même pour signer des données classées dans des systèmes choisis. Nous
pensons que cette approbation parle en faveur de l’absence de toute attaque
crédible contre l’intégrité offerte par le DSS, pour autant qu’il soit correc
tement utilisé et réalisé. En fonction des exigences techniques et de sécurité
du gouvernement américain pour les signatures numériques, nous pensons

que le DSS est le meilleur choix. En fait, le DSS est utilisé dans un pro
jet pilote pour le système de messagerie de la défense [« Defense Message
System »] afin de garantir l’authenticité de messages électroniques pour des
informations vitales de commandement et de contrôle. Le prototype initial
inclut la participation de l’état-major, les services de l’armée, des agences
de la défense et il est réalisé en collaboration avec le N IST. »
Je ne vais pas épiloguer sur l’honnêteté de la N SA. Prenez leurs commentaires comme
bon vous semble.
Attaques contre k
Chaque signature requiert une nouvelle valeur de k, et cette valeur doit être choisie
aléatoirement. Si jamais Estelle récupère une valeur de k que Alice a utilisé, éventuel
lement en exploitant certaines propriétés du générateur de nombres aléatoires qui a
produit k, elle peut retrouver la clef privée x d’Alice. Si jamais Estelle récupère deux
messages signés ou chiffrés avec la même valeur de k, elle peut retrouver x (même sans
connaître cette valeur de k). Et avec x, Estelle peut falsifier la signature d’Alice de
manière indétectable. Dans toute réalisation du D SA, un bon générateur de nombres
aléatoires est essentiel pour la sécurité du cryptosystème [1475].
Danger d’un module commun

Même si le DSS ne spécifie pas un module commun à partager entre tout le monde, dif
férentes réalisations le peuvent. Par exemple, le service des impôts américain (1RS pour
« Internai Revenue Service ») envisage d’utiliser le DSS pour la soumission électro
nique des déclarations de revenu. Que se passera-t-il s’ils obligent tous les contribuables
du pays à utiliser les mêmes p et g? Même si le standard ne requiert pas un module
commun, cette réalisation accomplit la même chose. Le danger d’un module commun
est qu’il devient une cible tentante. Il est trop tôt pour savoir quelle réalisation du
DSS sera adoptée mais il y a certaines raisons de s’inquiéter.
Canal subliminal dans le DSS

Gus S i m m o n s a découvert un canal subliminal dans le DSS [1475, 1478] (voir § 23.3).
Ce canal subliminal permet aux gens de cacher un message secret dans leur signa
ture et ce message peut seulement être lu par une autre personne qui connaît la clef.
D’après S i m m o n s , c’est une « coïncidence remarquable » que « les limitations quant
à l’introduction d’un canal subliminal, apparemment inhérentes au schéma E l G a m a l ,
peuvent toutes être surmontées » dans le DSS, et que le DSS « offre l’environnement
le plus propice aux communications subliminales découvert à ce jour. » Le N IST et la
NSA n’ont pas fait de commentaires à propos de ce canal subliminal ; personne ne sait
même s’ils étaient au courant de son existence. Comme ce canal subliminal permet à
un réalisateur peu scrupuleux de laisser fuir un morceau de la clef privée avec chaque
signature, il est important de ne jamais utiliser une réalisation du DSS si l’on n’a pris
confiance en celui qui l’a faite.
Brevets
David K r a v i t z , qui a travaillé à la N SA, détient un brevet sur le DSS [898]. D’après
le N IST [541] :
« Le N IST a l’intention de rendre cette technique DSS disponible dans

le monde entier, sans perception de droits, dans l’intérêt du public. Nous
pensons que cette technique est brevetable et qu’aucun autre brevet ne
s’applique au DSS, mais nous ne pouvons pas donner des garanties fermes
de cela avant l’émission du brevet. »
Même ainsi, trois détenteurs de brevets prétendent que le DSA enfreint leur propre
brevet: D i f f i e H e l l m a n (voir § 22.1) [720], M e r k l e - H e l l m a n (voir § 19.2) [723]
et S c h n o r r (voir § 21.3) [1404].
Le brevet de S C H N O R R est le plus névralgique. Les deux autres expirent en 1997 ;
celui de S C H N O R R est valable jusqu’en 2008. L’algorithme de S C H N O R R n’ayant pas
été développé avec l’argent du Gouvernement américain, contrairement aux brevets
de P K P , le Gouvernement américain n’a aucun droit sur le brevet de S C H N O R R , et
celui-ci a breveté son algorithme dans le monde entier. Même si une cour de justice
tranche en faveur du D S A , il n’est pas évident que les autres cours de justice de par le
monde en feront autant. Est-ce qu’une société internationale va adopter un standard
qui pourrait être légal dans un pays mais qui enfreindrait un brevet dans un autre ? Ce
problème mettra du temps à être résolu ; au moment d’écrire ces lignes, il n’est même
pas encore résolu aux Etats-Unis.
En juin 1993, le N IST a proposé d’octroyer une licence d’exploitation exclusive du
brevet du D SA à P u b l i c K e y P a r t n e r s [544]. Cet accord a été démenti suite à un
tollé général et le standard a vu le jour sans qu’il n’y ait d ’accord. Le N IST a déclaré
[540] :
« ...Le N IST a fait suivre les protestations concernant d’éventuelles infrac

tions de brevet, et a conclu qu’il n’y avait pas de protestation justifiée. »
Le standard est officiel, les poursuites judiciaires sont menacées, et personne ne sait
que faire. Le N IST a déclaré qu’il viendrait en aide aux personnes poursuivies pour
infraction de brevet, si elles utilisent le D SA pour remplir un contrat gouvernemental. Il
semble que les autres doivent se débrouiller eux-mêmes. L’AN SI a ébauché un standard
bancaire utilisant le D SA [63]. Le NIST travaille à la standardisation du DSA à
l’intérieur du gouvernement. S h e l l a fait du D S A son standard international. Je ne
connais aucune autre proposition de standard utilisant le DSA.
20.2 Variantes de DSA

Cette variante rend le calcul du signataire plus facile en ne l’obligeant pas à calculer k 1
[1144]. Tous les paramètres sont identiques à ceux de DSA. Pour signer un message AA,
Alice génère deux nombres aléatoires k et d, tous les deux inférieurs à q. La signature
est donnée par :
r = (gk mod p) mod q

s = (H (A 4) + xr) x d mod q
20.2 Variantes de D S A 521
t = kd mod q
Bernard vérifie la signature en calculant :
w = t /s mod q
ui = (H(A4) x w ) mod q
u2 = rw mod q
Si r — {{gUl x y u'2) mod p) mod q, alors la signature est vérifiée.

La variante suivante rend le calcul plus facile pour le vérificateur [1048, 1631]. Tous les
paramètres sont identiques à ceux de DSA. Pour signer un message A4, Alice génère
un nombre aléatoire k inférieur à q. La signature est donnée par :

s = k x ( H ( M ) + ær)_1 mod q
Bernard vérifie la signature en calculant :
Ui = ( H (A4 ) x s) mod q
u2 = sr mod q
Si r = (( gUl x y U2) mod p ) mod q, alors la signature est vérifiée.

Une autre variante permet de vérifier plusieurs signatures à la fois [1144], Si elles
sont valides c ’est fini. Si une des signatures n’est pas valide, il reste à la trouver.
Malheureusement, cette vaiiante n’est pas sûre ; le signataire, aussi bien que le vérifi
cateur, peut facilement créer un ensemble de fausses signatures dont l’ensemble passe
la vérification avec succès [984],
Il existe aussi une variante de D SA pour la génération des nombres premiers, dans
laquelle q et les autres paramètres de la génération sont codés dans p. On ne sait pas
encore si ce schéma réduit la sécurité de DSA.
1° Choisissez une chaîne aléatoire S d’au moins 160 bits. Soit g sa longueur en
bits.
2° Calculez U = SH A (S) ® S H A ((S + 1) mod 2S), où S H A est l’algorithme de
hachage sûr (voir § 18.7).
3° Formez q à partir de U en mettant le bit le plus significatif et le bit le moins
significatif tous deux à 1.
4° Vérifiez si q est un nombre premier.
5° Si q n’est pas un nombre premier, retournez à l’étape 1.
6° Mettez q, S, C et SH A (S ) bout à bout pour former p, où C est un mot de 32
zéros.
7° p = p — (p mod q) + 1.
8° p = p + q.
9° Si la partie de p correspondante à C est 0x7FFFFFFF, retournez à l’étape 1.

10° Vérifiez si p est un nombre premier.
11° Si p n’est pas un nombre premier, retournez à l’étape 7.
L’avantage de cette variante est d’éviter le stockage des valeurs de C et S1 utilisées

pour générer p et q ; elles se lisent dans p. Pour les applications avec peu de mémoire,
comme les cartes à puces, cela peut s’avérer très intéressant.
20.3 Algorithme de signature numérique

GOST
Ceci est un standard de signature numérique russe, appelé officielement GOST
R 34.10-94 [658].
L’algorithme ressemble beaucoup au D SA , et utilise les paramètres suivants:
p = un nombre premier de longueur comprise entre 509 et 512 bits, ou

bien entre 1020 et 1024 bits.
q — un facteur premier de p — 1 de 254 à 256 bits.
a = un nombre inférieur à p — 1 tel que aq mod p = 1.
x — un nombre inférieur à q.
y = ax mod p.
L’algorithme utilise aussi une fonction de hachage: H (x). Le standard spécifie l’emploi
de G O S T R 34.11-94 (voir § 18.11), une fonction basée sur l’algorithme à clef secrète
G O S T (voir § 14.1) [659].
Les trois premiers paramètres, p, q et a, sont publics et peuvent être partagés par les
utilisateurs d’un réseau. La clef privée est x ; la clef publique est y.
Pour signer un message AA,
1° Alice génère un nombre aléatoire k inférieur à q.

2° Alice génère:
r = ( ak mod p) mod q
s - (xr + k x H (A4)) mod q.
Si H (A4) mod q = 0, Alice fait comme s ’il valait 1. S ir — 0, elle recommence

avec une autre valeur de k. La signature est composée de deux nombres : r mod
2256 et s mod 2256. Elle les envoie à Bernard.
3° Pour vérifier la signature, Bernard calcule :
v = H (A 4 )q~ 2 mod q
Z\ — sv mod q
z2 = ((q — r) x u) mod q
u = ((aZl x y 22) mod p) mod q.
20-4 Schémas de signature numérique à base de logarithmes discrets 523
Si u = r, alors la signature est vérifiée.
La différence entre ce schéma et le DSA est qu’on pose s = (&” 1 x (xr + H (A 4))) mod q
dans le DSA, ce qui conduit à une équation de vérification différente. Il est curieux de
fixer la longueur de q à 256 bits. La plupart des cryptographes occidentaux s’étalent
mis d ’accord sur les alentours de 160 bits. C ’est peut-être une manière de penser russe
qui veut un maximum de sécurité.
Le standard est en utilisation depuis 1995, et n’est pas classé « pour utilisations spé
ciales », quoi que cela puisse vouloir dire.
20.4 Schémas de signature numérique à

base de logarithmes discrets
E l G a m a l , S c h n o r r (voir § 21.3) et DSA sont des schémas de signature numérique
très similaires. En fait, ce sont trois exemples d’un schéma général de signature numé
rique basé sur le problème des logarithmes discrets. Ces trois schémas et bien d’autres
font partie de la même famille [742, 743, 700, 1189].
Choisissez un grand nombre premier p , et prenez q égal à p — 1 ou à un grand facteur
premier de p — 1. Choisissez alors un nombre g entre 1 et p tel que gq = 1 (mod p).
Tous ces nombres sont publics et peuvent être partagés par un groupe d ’utilisateurs.
La clef privée x est inférieure à ç. La clef publique est y = gx mod q.
Pour signer un message A4, commencez par tirer un nombre aléatoire k inférieur à q
et premier avec q. Si q est premier, n ’importe quel k inférieur à q convient. Calculez
d’abord :
r = gk mod p
L’équation de signature généralisée devient maintenant :
ak = b + e x mod q
Les coefficients a, b et c sont à prendre parmi une variété de termes. Chaque ligne du
tableau 20.4 correspond à six possibilités (selon les six permutations de a,b,c).
Tab. 20.4 Permutations possibles de a,b,c (s est la signature et on pose r' = r mod q)
±r' ±s M
± r 'M ±5 1
±r'A4 ±sM 1
±r'A4 ir 's 1
±sA4 ± r 's 1
Pour vérifier la signature, le destinataire doit s’assurer que :
r“ = gbyc mod p
Ceci s’appelle l’équation de vérification

Le tableau 20.5 donne les équations de signature et les équations de vérification cor
respondantes que l’on peut obtenir uniquement avec la première ligne du tableau 20.4
sans tenir compte des ± . Cela fait six schémas de signature différents. En ajoutant
des signes négatifs, on arrive à un total de 20 "schémas. En utilisant les autres valeurs
possibles pour o, b et c, on obtient 120 schémas en tout.
T a b . 20.5 - Schémas de signature numérique à base de logarithmes discrets
Equation de signature Equation de vérification

(1) r'k - - s + fA x mod p rT -= gsyM mod p
(2) r'k - - A4 + sx mod p rT - =gMys mod p
(3) sk = r' + A4a: mod p rs =--gr'yM mod p
(4) sk — A4 + r'x mod p rs =: g M y r> mod p
(5) A4 k = s + r'x mod p
rM
= gsyr' mod p
(6) M k = r' + sx mod p
rM
= </ys mod p
E l G a m a l [520, 521] et le D SA [1174] sont essentiellement basés sur l’équation (4).

D’autres schémas sont basés sur l’équation (2) [28, 1631]. S C H N O R R [1401, 1403] est
étroitement lié à l’équation (5), c ’est aussi le cas d ’un autre schéma [1188]. Une modi
fication de l’équation (1) conduit au schéma proposé dans [1632]. Les autres équations
sont nouvelles.
Il y a plus. Vous pouvez transformer chacun de ces schémas à la manière du D SA en
définissant r ainsi:
Gardez la même équation de signature, et modifiez l’équation de vérification ainsi :
ui - o _16 mod q
U2 = o _1c mod q
r — (gUly u2 mod p) mod q
(r mod q)a = gby c mod p.
Il existe deux possibilités dans cette veine [742, 743], que vous pouvez appliquez à
chacun des 120 schémas, ce qui nous mène à un total de 480 schémas de signature
numérique à base de logarithmes discrets.
Mais attendez— il y a plus. Des généralisations et des variations supplémentaires per
mettent de créer plus de 13000 variantes (elles ne sont pas toutes très efficaces)
[742, 743].
Un des intérêts de R SA pour les signatures numériques est ce qui s’appelle la ré
cupération de message. En vérifiant une signature R SA , vous calculez A4. Vous
comparez alors le message A4 calculé et le message reçu et vérifiez ainsi la validité
de la signature. Avec les schémas précédents, vous ne pouvez pas récupérer A4 quand
vous calculez la signature ; vous avez besoin d ’un candidat A4 que vous utilisez dans
l’équation de vérification. Il se trouve qu’il est possible de construire une variante à
récupération de message pour tous les schémas de signature précédents.
Pour signer, commencez par calculer
r — mgk mod p,
20.5 O n g - S c h n o r r - S h a m ir 525
remplacez ensuite A4 par 1 dans l’équation de signature. Vous pouvez alors construire
l’équation de vérification qui permet de calculer A4 directement.
Vous pouvez faire de même avec les schémas à la manière D SA :
r = (mgk mod p) mod q
Toutes les variantes sont aussi sûres les unes que les autres, il est donc sensé de choisir
un schéma qui facilite les calculs. C ’est le calcul des inverses qui ralentit le plus ces
schémas. Il se trouve que l’un des schémas permet de calculer à la fois l’équation
de signature et l’équation de vérification sans inverse et de récupérer le message. Il
s’appelle le schéma P-N EW [1189].
r = mg~k mod p
s =r k — r'x mod q
A4 est récupéré (et la signature est vérifiée) ainsi :
A4 = gsyT r mod p
Certaines variantes permettent de signer deux ou trois blocs de message à la fois [742] ;
d’autres variantes peuvent servir pour les signatures en aveugle [743].
Ceci est un travail de recherche rem arquable. U n m od èle cohérent p erm et d e décrire
tous les différents schém as de signature num érique à base de logarithm es discrets. A
mon avis, cela m et fin aux querelles d e brevets entre SCHNORR [1404] et DSA [898] :
DSA n ’est dérivé ni de SCHNORR, ni d e E l G a m a l . C e sont trois cas particuliers de
cette con stru ction générale, qui n ’est pas brevetée.
20.5 Ong—Schnorr—Shamir
Ce schéma de signature utilise des polynômes modulo n [1229, 1230]. Choisissez un
grand entier n (il n’est pas nécessaire de connaître la factorisation de n). Ensuite
choisissez un nombre entier aléatoire /c, tel que k e t n soient premiers entre eux. Calculez
h tel que :
h — —k ~ 2 mod n = —(A;- 1 )2 mod n.
La clef publique est faite de h et n ; k est la clef privée.

Pour signer un message A4, engendrez premièrement un nombre aléatoire r tel que r
et n soient premiers entre eux. Ensuite calculez :
51 = 1/2 x (A4 jr + r) mod n

5 2 = k /2 x (A 4 /r — r) mod n.
La paire Si et S 2 est la signature.

Pour vérifier une signature, confirmez que :
(S f + h x S2) A4 (mod n).
La version du schéma décrite ici est basée sur des polynômes quadratiques. Quand il
fut proposé dans [1227], une récompense de 100 $ était offerte pour une cryptanalyse
réussie. Il a été prouvé qu’il n’est pas sûr [1265, 22] mais les auteurs ne se sont pas
découragés. Ils proposèrent une version modifiée basée sur des polynômes cubiques qui
n’est pas sûre non plus [1265]. Les auteurs proposèrent alors une version quartique qui
fut également cassée [527, 1265]. Une variante qui évite ces problèmes est décrite dans
[1143].
20.6 ESIGN
ESIGN est un schéma de signature numérique conçu par N T T J a p o n [1213, 585].
D’après ces auteurs, il est au moins aussi sûr et nettement plus rapide que le R SA et
le D SA, avec des longueurs de clef et de signature similaires.
La clef privée est une paire de grands nombres premiers p et q. La clef publique est n
tel que
n = p2 q.
H (x) est une fonction de hachage qui opère sur un message m de sorte que H (A4) soit
compris entre 0 et A4 II y a aussi un paramètre de sécurité k qui sera décrit plus loin.
1° Alice choisit un nombre aléatoire x, tel que x soit inférieur à pq.

2° Alice calcule:
w, le plus petit nombre plus grand que (H(m ) — x k mod n)/pq

s = x + (( w /k x k~ x) mod p)pq.
3° Alice envoie s à Bernard.

4° Pour vérifier la signature, Bernard calcule sk mod n. Il calcule aussi a, qui est
le plus petit nombre plus grand que le nombre de bits de n divisé par 3. Si H(m)
est inférieur ou égal à sk mod n, et si sk mod n est inférieur à H (rn )+ 2 a, alors
la signature est considérée valable.
Cet algorithme peut être accéléré par précalcul. Ce précalcul peut être effectué à tout
moment et n’a rien à voir avec le message à signer. Après avoir choisi x , Alice peut
scinder l’étape 2 en deux étapes partielles. La première peut être précalculée.
2° (a) Alice calcule :
u — x k mod n
v = 1/(k x k~ l) mod p.
2° (b ) Alice calcule :
w — le plus petit entier qui est plus grand que ( H (m) — u)jpq
s = x + (wv mod p)pq.
Pour la taille des nombres généralement utilisés, ce précalcul accélère le processus de

signature par un facteur 10- Presque tout le travail difficile est fait pendant l’étape
de précalcul. Une présentation des opérations d ’arithmétique modulaire qui peuvent
être utilisées pour accélérer l’algorithme ESIGN est donnée dans [1627, 1626]. Cet
algorithme a également été étendu pour marcher avec des courbes elliptiques [1214].
20.7 Automates cellulaires 527
Sécurité d’ESIGN
Quand cet algorithme fut originellement proposé, k valait 2 [1223]. Il fut alors rapide
ment cassé par Ernie B r i c k e l l et John D e L a ü R E N T I S [265], qui ont ensuite étendu
leur attaque au cas k = 3. Une version modifiée de l’algorithme [1211] fut cassée par
S h a m i r [1212]. La variante proposée par [1212] fut cassée dans [1560]. ESIGN est le
représentant actuel de cette famille d’algorithmes. Une autre attaque nouvelle [974] ne
marche pas contre la variante d’ESIGN.
Les auteurs recommandent actuellement les valeurs suivantes pour k : 8, 16, 32, 64,
128, 256, 512 et 1024. Ils recommandent également que p et q aient au moins 192 bits
chacun, ce qui donne une longueur d ’au moins 576 bits pour n. (Je pense que n devrait
être deux fois plus long.) Avec ces paramètres, les auteurs font l’hypothèse qu’ESlGN
est aussi sûr que R SA ou R a b i n . Leurs analyses montrent des comparaisons de vitesse
avec R S A , E l G a m a l et D SA qui leur sont favorables [584],
Brevets
ESIGN est breveté aux États-Unis [1216], au Canada (brevet n° 255 784), en Angle
terre, en France, en Allemagne et en Italie. Toute personne désireuse d’obtenir une
licence d ’exploitation pour cet algorithme doit contacter: Intellectual Property
Department, NTT, 1-6 Uchisaiwai-cho, 1-chome, Chiyada-ku, 100 Japan.
20.7 Automates cellulaires

Une nouvelle idée originale, étudiée par G u a M [666], est d’utiliser des automates cellu
laires dans les cryptosystèmes à clef publique. Ce système est encore bien trop nouveau
et n’a pas été étudié exhaustivement mais une analyse préliminaire suggère qu’il pour
rait avoir une faiblesse cryptographique similaire à une faille rencontrée dans d’autres
cas [564]. Toutefois, c’est un domaine de recherche prometteur. Le propre des auto
mates cellulaires est que, même s’ils peuvent être inversés, il est impossible de calculer
l’état précédent d’un état arbitraire en renversant les règles pour trouver le successeur.
Cela ressemble fortement à une fonction à sens unique à brèche secrète.
20.8 Les autres algorithmes à clef publique

De nombreux autres algorithmes à clef publique ont été proposés et cassés au fil des
ans. L’algorithme M a t S IJM O T O I m a i [1029] fut cassé dans [453], L ’algorithme C a d e
fut proposé la première fois en 1985, cassé en 1986 [774] et renforcé la même année [290].
En plus de ces attaques, il existe des attaques générales pour décomposer des polynômes
sur des corps finis [607]. Tout algorithme dont la sécurité dépend de la composition
de polynômes sur des corps finis doit être considéré avec scepticisme, si ce n’est même
avec méfiance.
L’algorithme Y a g i s a w a combine l’exponentiation modulo p avec l’arithmétique mo
dulo p — 1 [1625] ; il fut cassé dans [260]. Un autre algorithme à clef publique, proposé
par T s u j i i , K u r o s a w a , I t o h , F u j i o k a et M a t s u m o t o [1556] n’est, pas sûr [959].
Un troisième système, L u c c io M a z z o n e [1003], n’est pas sûr [719]. Un schéma de
signature basé sur les permutations birationnelles [1432] a été cassé le lendemain de sa
528 Chapitre 20 Algorithmes de signature mimétique à clef publique
présentation [385]. Tatsuaki O kam o to a plusieurs schémas de signature à son actif:

l’un d ’eux est prouvé aussi difficile que le calcul des logarithmes discrets, et un autre
est prouvé aussi difficile que le calcul des logarithmes discrets et la factorisation [1214].
D ’autes schémas similaires sont décrits dans [710].
Gustavus S im m ons suggéra d ’utiliser les J-algèbres comme base pour des algorithmes
à clef publique [1461, 152]. Cette idée fut abandonnée après que des méthodes efficaces
de factorisation des polynômes furent inventées [963]. Des semi-groupes de polynômes
spéciaux ont été également étudiés [1621, 973] mais jusqu’à présent il n’en est rien sorti.
Harald N ied e r r e it e r . a proposé un algorithme à clef publique basé sur des suites de
registres à décalage [1167]. Un autre est basé sur les mots de Lyndon [1482] et un autre
sur le calcul propositionnel [818]. Un algorithme à clef publique récent tire sa sécurité
du problème de recouvrement de matrice [89]. Tatsuaki O k am o to et Kazuo O hta
comparent de nombreux algorithmes de signature numérique dans [1220].
Les perspectives de créer des algorithmes à clef publique radicalement nouveaux et dif
férents semblent bien faibles. En 1988, D i f f i e remarqua que la plupart des algorithmes
à clef publique sont basés sur l’un des trois problèmes difficiles suivants [490, 492] :
: Étant donné un ensemble de nombres uniques,
1. L e p r o b lè m e d e s e m p ile m e n t s
trouver un sous-ensemble dont la somme est TV.
2. L e c a lc u l d e lo g a r it h m e s d is c r e t s : Si p est un nombre premier et g et M

sont des entiers, trouver x tel que gx = M (mod p).
3. L a fa c t o r is a t io n : Si TV est le produit de deux nombres premiers :
a. factoriser TV,
b . étant donné les entiers M et C , trouver d tel que M d = C (mod TV),
c. étant donné les entiers e et C, trouver M tel que M e = C (mod TV),
d. étant donné l’entier x, décider s’il existe un entier y tel que x = y 2 (mod TV).
D ’après D iffie [490, 492], le problème du logarithme discret fut suggéré par J. G ill ,
le problème de factorisation par K n u t h et le problème des em pilem ents par D iffie
lui-même.
Cette étroitesse des fondements mathématiques de la cryptographie à clef publique est
dérangeante. Une percée pour le problème de la factorisation ou celui des logarithmes
discrets peut rendre des classes entières d ’algorithmes à clef publique non sûrs. Une telle
percée a déjà eu lieu pour le problème des empilements. D i f f i e remarque [490, 492]
que ce risque est atténué par deux facteurs :
« Les opérations dont la cryptographie à clef publique dépend actuelle
ment — multiplication, exponentiation et factorisation — sont toutes des
phénomènes arithmétiques fondamentaux. Elles ont été l’objet d’analyses
mathématiques intenses pendant des siècles, et l’attention croissante qui a
résulté de leur utilisation dans les cryptosystèmes à clef publique a dans
l’ensemble renforcé plutôt que diminué notre confiance.
« Notre capacité d ’effectuer des opérations arithmétiques sur des grands
nombres a augmenté continûment et nous permet maintenant de réaliser
nos systèmes avec des nombres suffisamment grands pour n’être plus vul
nérables qu’à des percées foudroyantes en factorisation, en logarithmes ou
en extraction de racines. »
20.8 Les autres algorithmes à clef publique 529
Comme nous l’avons vu, les algorithmes à clef publique basés sur ces problèmes ne sont
pas tous sûrs. La force de tout algorithme à clef ne publique dépend pas seulement
la complexité calculatoire du problème sur lequel il est basé ; la difficulté calculatoire
d’un problème n’implique pas forcément un algorithme fort. Adi S h a m i r énumère trois
raisons pour lesquelles il en est ainsi [1422] :
1. La théorie de la complexité traite en général des instances isolées de

problèmes. Un cryptanalyste a en général à résoudre une grande quan
tité de problèmes statistiquement reliés plusieurs textes chiffrés avec
la même clef.
2. La complexité calculatoire d ’un problème est typiquement mesurée par
son comportement en pire cas ou en cas moyen. Pour qu’un problème
soit utile à un chiffrement, il doit être difficile à résoudre dans presque
tous les cas.
3. Un problème arbitrairement difficile ne peut pas nécessairement être
transformé en cryptosystème, et il doit être possible d’insérer une
brèche secrète dans le problème de telle manière qu’il y ait un rac
courci grâce à celle-ci et seulement grâce à elle.
Chapitre 21
Schémas d’identification
21.1 Feige—Fiat—Shamir
Le schéma d’authentification et de signature numérique d’Amos F i a t et Adi S h a m i r
est décrit dans [568, 569]. Uriel F e i g e , A. F i a t et A. S h a m i r ont transformé l’al
gorithme en un système de preuve d ’identité à divulgation nulle [546, 547]. C ’est le
système de preuve d ’identité à divulgation nulle le mieux connu.
Le 9 juillet 1986, les trois auteurs ont soumis une demande de brevet américain [1433].
À cause des applications militaires potentielles, la demande fut examinée par les mili
taires. L ’Office des brevets américain avait six mois pour répondre par une autorisation
de divulgation. Le 6 janvier 1987, trois jours avant l’expiration du délai, l’Office des
brevets et marques a interdit la divulgation à la demande de l’armée. Us affirmèrent
que « ... la divulgation ou la publication des informations à ce su jet... seraient nuisibles
à la sécurité nationale [américaine] ...» L’ordre fut donné aux auteurs de notifier à tous
les Américains auxquels les résultats de la recherche avaient été divulgués que toute
divulgation non autorisée pouvait entraîner un emprisonnement de deux ans et/ou une
amende de 10000 $. De plus, les auteurs devaient indiquer au commissaire de l’Office
des brevets et marques le nom de tous les ressortissants étrangers à qui l’information
avait été communiquée.
C’était ridicule. Pendant toute la seconde moitié de 1986, les auteurs avaient présenté
leurs travaux à des conférences en Israël, en Europe et aux Etats-Unis. Les auteurs
eux-mêmes n’étaient pas citoyens américains; tout le travail de recherche avait été
effectué au W e i z m a n n I n s t i t u t e en Israël.
Le mot s’était répandu dans la communauté académique et la presse. Dans les deux
jours l’interdiction de divulgation fut annulée; SHAMIR et d ’autres croient que la NSA
a tiré les ficelles de cette annulation bien qu’il n’y ait eu aucun commentaire officiel.
Vous trouverez plus de détails concernant cette aventure dans [947].
Schéma d’identification Feige—Fiat-Shamir simplifié

Avant d ’émettre quelque clef privée que ce soit, l’arbitre choisit un module aléatoire n
qui est le produit de deux grands nombres premiers. Dans la vie réelle, n doit être long
d’au moins 512 bits et probablement plus près des 1024 bits. Cet n peut être partagé
532 Chapitre 21 Schémas d’identification
par un groupe de prouveurs1.

Pour engendrer la clef publique et la clef privée de Patricia, un arbitre de confiance
choisit un nombre v, tel que v soit un résidu quadratique modulo n. En d ’autres termes,
choisissez v tel que x 2 = v (mod n) ait une solution et u-1 modulo n existe. C ’est la
clef publique. Ensuite, calculez le plus petit s tel que s = V v " 1 (mod n). C’est la clef
privée.
Le protocole d’identification peut alors se dérouler comme suit :
1° Patricia choisit un nombre aléatoire r tel que r soit inférieur à n. Elle calcule
ensuite x = r 2 mod n et envoie x à Victor.
2° Victor envoie un bit aléatoire b à Patricia.

3° Si b = 0, Patricia envoie r à Victor.
Si b = 1, Patricia envoie y = (r x s) mod n à Victor.
4° Si b = 0, Victor vérifie que x = r 2 mod n, ce qui prouve que Patricia connaît

t/x .
Si 6 = 1 , Victor vérifie que x — ( y 2 x u) mod n, ce qui prouve que Patricia
connaît \fv~~1.
Ce protocole est une a ccré d ita tio n simple. Patricia et Victor répètent ce protocole
t fois, jusqu’à ce que Victor soit convaincu que Patricia connaît s. Il s’agit de la tech
nique « couper-et-choisir ». Si Patricia ne connaît pas s, elle peut choisir r de manière
à tromper Victor s’il lui envoie un 0, ou elle peut choisir r de manière à tromper Victor
s’il lui envoie un 1. Mais elle ne peut pas faire les deux. Les chances de tromper Victor
une fois sont de 50 %. Les chances de le tromper t fois sont de 1 contre 2*.
Un autre moyen d ’attaquer le protocole serait pour Victor de se faire passer pour
Patricia. Il peut démarrer le protocole avec un autre vérificateur, Valérie. A l’étape 1,
au lieu de choisir un r aléatoire, il pourrait juste réutiliser un vieil r qu’il a vu Patricia
utiliser. Toutefois, les chances que Valérie choisisse le même b à l’étape 2 que celui
choisi par Victor dans le protocole avec Patricia sont de 1 contre 2. Donc, les chances
de tromper Valérie sont de 50 %. Les chances de la tromper t fois sont de 1 contre 2É.
Pour que cela marche, il est impératif que Patricia ne réutilise pas un r. Si elle le faisait,
et si Victor lui envoyait l’autre valeur de bit à l’étape 2, Victor aurait alors les deux
réponses de Patricia. Il ne lui resterait alors qu’à en collecter t pour se faire passer
pour Patricia.
Schéma d’identification Feige—Fiat—Shamir

Dans leurs articles [546, 547], F e i g e , F i a t et S h a m i r montrent comment un montage
parallèle peut augmenter le nombre d ’accréditations par rondes et réduire ainsi les
interactions entre Victor et Patricia.
Au départ, engendrez n comme ci-dessus, c ’est-à-dire comme un produit de deux grands
nombres premiers. Pour engendrer les clefs publique et privée de Patricia, choisissez
d’abord k nombres différents: Vi,V2,...,Vk, où Vi est un résidu quadratique modulo n.
En d ’autres termes, choisissez Vi tel que x 2 = vt (mod n) ait une solution et vf 1 mod n
1. Les ca lcu ls son t plus fa ciles si n est u n en tier d e B lu m , m ais c e n ’est p as nécessaire p o u r la
sécurité.
21.1 F e ig e - F ia t S h a m ir 533
existe. Cette chaîne Vi,V2 ,.-,Vk est la clef publique. Ensuite calculez les plus petits Si
tels que s, = yjv ^ 1 (mod n). Cette chaîne Si,S2, -isfc est la clef privée.
Et le protocole se déroule comme suit :
1° Patricia choisit un nombre aléatoire r inférieur à n. Ensuite, elle calcule x —
r 2 mod n et envoie x à Victor.
2° Victor envoie une chaîne aléatoire binaire de k bits: bi,l>2 ,...,bk à Patricia.
3° Patricia calcule y = r x (s ,1 x sî? x ••• x s*fc) mod n. Elle multiplie les valeurs
des Si entre elles sur la base de la chaîne binaire que Victor lui a envoyée. Si
le premier bit de Victor est 1, alors si fait partie du produit, si le premier bit
de Victor est 0 alors si ne participe pas au produit. Elle envoie y à Victor.
4° Victor vérifie que x = y 2 x (v*1 x v ^2 x ... x v£h) mod n. Il multiplie les valeurs
des Si entre elles sur la base de la chaîne binaire. Si le premier bit est 1, s%
participe au produit ; si le premier bit est 0, s x ne participe pas au produit.
Patricia et Victor répètent ce protocole t fois jusqu’à ce que Victor soit certain que
Patricia connaît Si,S2 ,—,Sk-
Les chances que Patricia puisse rouler Victor sont de 1 contre 2kt, où t est le nombre de
fois qu’ils répètent le protocole. Les auteurs recommandent un rapport de probabilités
de 1 contre 220 et suggèrent d ’utiliser k = 5 et t = 4. Si vous êtes plus paranoïaque,
augmentez ces nombres.
Un exemple
Voyons ce protocole en action sur des petits nombres.
Si n = 35 (les deux nombres premiers sont 5 et 7), les résidus quadratiques possibles
sont :
1 : x 2 = 1 (mod 35) a comme solutions : x = 1,6,29 ou 34.
11: x 2 = 11 (mod 35) a comme solutions: x = 9,16,19 ou 26.
14 : x 2 = 14 (mod 35) a comme solutions : x = 7 ou 28.
29: x 2 = 29 (mod 35) a comme solutions: x = 8,13,22 ou 27.
Les inverses modulo 35 et leurs racines carrées sont :
V v~* s = \/v~l
1 1 1
4 9 3
9 4 2
11 16 4
16 11 9
29 29 8
Remarquez que 14,15,21,25 et 30 n’ont pas d ’inverses modulo 35, parce qu’ils ne sont
pas premiers par rapport à 35. Cela a un sens, puisqu’il doit y avoir (5—1) x'(7—1)/4 = 6
résidus quadratiques modulo 35 (voir § 11.3).
Ainsi, Patricia reçoit la clef publique constituée de k = 4 valeurs : {4,11,16,29}. La clef
privée correspondante est {3,4,9,8}. Voici une ronde du protocole:
1° Patricia choisit le nombre aléatoire r = 16, calcule 162 mod 35 = 11 et envoie

ce dernier à Victor.
2° Victor envoie à Patricia une chaîne binaire aléatoire {1,1,0,1}.
3° Patricia calcule 16 x ((31) x (41) x (9°) x (81)) mod 35 = 31 et envoie le résultat
à Victor.
4° Victor vérifie que 312 x ((41) x (111) x (16°) x (291)) mod 35 = 11.
Patricia et Victor répètent le protocole, chaque fois avec un nombre r aléatoire différent,
jusqu’à ce que Victor soit satisfait.
Avec des petites valeurs comme celles-ci, il n’y a pas vraiment de sécurité, Mais quand
n a 512 bits ou plus de long, Victor ne peut rien apprendre de la clef secrète de Patricia,
excepté le fait qu’elle la connaît.
Améliorât ions
Il est possible de cacher des informations d ’identification dans le protocole. Faites
l’hypothèse que / est une chaîne binaire représentant l’identification de Patricia: son
nom, son adresse, son numéro de sécurité sociale, sa taille de chapeau, sa limonade
préférée, etc. Utilisez une fonction de hachage à s*3ns unique H {x) pour calculer H (I ,j )
où j est un petit nombre aléatoire joint à I. Trouvez un ensemble de plusieurs j tels
que H (I ,j) soit un résidu quadratique modulo n. Ces j deviennent Vi,V2 ,-,V k- La clef
publique de Patricia est maintenant / et la liste des j . Elle envoie / et la liste des j à
Victor avant l’étape 1 du protocole et Victor engendre Vi,V2 ,---,Vk à partir de H (I,j).
Ainsi, après que Victor ait terminé avec succès le protocole avec Patricia, il est sûr
que quelqu’un qui connaît la factorisation du module a certifié l’association entre I et
Patricia en lui donnant les racines carrées des v1 dérivés de I. (Voyez le paragraphe 5.2
concernant le contexte du protocole.)
Les auteurs, F e i g e , F i a t et S h a m i r incluent également les remarques suivantes concer
nant la réalisation concrète [546, 547] :
« Pour des fonctions de hachage non parfaites, il est conseillé de rendre I

aléatoire en joignant une longue chaîne aléatoire R. Cette chaîne est choisie
par l’arbitre et révélée à Victor avec I.
« Dans des réalisations typiques, k doit être compris entre 1 et 18. Des
valeurs plus grandes de k peuvent réduire le temps et la complexité des
communications en réduisant le nombre de rondes.
« La valeur de n doit au moins avoir 512 bits.
« Si tous les utilisateurs choisissent leur propre n et le publient dans un
fichier public de clefs, ils peuvent se passer d’un arbitre. Toutefois, cette
variante similaire au R SA rend le schéma nettement moins pratique. »
21.1 Fe ig e F ia t - S h a m ir 535
Schéma de signature Fiat—Shamir

Pour transformer ce schéma d’identification en un schéma de signature, il suffit de
transformer Victor en une fonction de hachage. Le premier avantage du schéma de
signature numérique F iat —SHAMIR par rapport au R S A est qu’une signature typique
ne requiert que 1 % à 4 % de multiplications modulaires. Il est donc nettement plus
rapide. Pour ce protocole, nous utiliserons les noms d ’Alice et Bernard.
La mise en place est la même que pour le protocole d’identification. Choisissez un entier
n produit de deux grands nombres premiers. Engendrez la clef publique vi,V2 ,...,Vk et
la clef privée si,s 2,...,sk telle que sx = v f 1 ( mod n).
1° Alice choisit t nombres aléatoires plus petits que n : r\,r2 ,...,rt et calcule X\,
x 2, xt tels que Xi = r\ mod n.

2° Alice calcule l’empreinte de la juxtaposition du message et de la chaîne des Xi
pour engendrer le flux de bits: H (m ,x i,x 2 ,...,xt). Elle utilise les k x t bits de
cette chaîne comme valeurs de bij où i va de 1 à t et j va de 1 à k.
3° Alice calcule y i,y 2 ,...,yt tels que:
yi x (sj41 x s*12 x — x sfcfc) mod n.
Elle multiplie les valeurs des Si ensemble en fonction des valeurs aléatoires hl3.
Si bu vaut 1, alors si fait partie du produit; si blt vaut 0, alors s i ne fait pas
partie du produit.
4 ° Alice envoie à Bernard m, toutes les valeurs des bits bij et toutes les valeurs
des yi. Il a déjà la clef publique d’Alice: îq,i;2 ,...,nfc.
5° Bernard calcule zi,z 2 l...,zt tels que:
Zi — yf x (v\ %1 x v*2 2 x ... x mod n.
Une fois de plus, Bernard effectue les multiplications en fonction des valeurs
des bij. Remarquez que les zt doivent être égaux aux x.t.
6° Bernard vérifie que les premiers k x t bits de H(rn,zi,z 2 ,...,zt) sont les valeurs
b^ qu’Alice lui a envoyées.
Tout comme pour le schéma d’identification, la sécurité de ce schéma de signature

est proportionnelle à 1/ 2 kt. Il dépend aussi de la difficulté de factoriser n. F i a t et
S h a m i r indiquent qu’il est plus facile de commettre une fausse signature quand la
complexité de factoriser n est nettement inférieure à 2kt. Et, à cause des attaques des
anniversaires (voir § 18.1), ils recommandent que k x t soit augmenté de 20 à 72 au
moins. Ils suggèrent k = 9 et t — 8.
Schéma de signature Fiat—Shamir amélioré

Silvio M i c a l i et Adi S h a m i r ont amélioré ie protocole F i a t - S h a m i r dans [1094], Ils
choisissent les k premiers nombres premiers pour v\,v2 ,—,Vk- Donc,
îq = 2,v2 = 3,^3 = 5, etc.

C’est la clef publique.

La clef privée Si,S2 ,---,Sk est une racine carrée aléatoire, déterminée par:
st = J v t 1 (mod n).
Dans cette version, tout le monde doit avoir un n différent. Cette modification rend la
vérification de signatures plus aisée. Cela n’affecte pas le temps requis pour engendrer
les signatures ni la sécurité de ces signatures.
Autres améliorations
Il existe également un schéma d ’identification à N participants basé sur l’algorithme
F i a t S h a m i r [268]. Deux autres améliorations du schéma F i a t S h a m i r ont été pro
posées dans [1228]. D ’autres variantes sont décrites dans [1370].
Schéma d’identification Ohta—Okamoto

Ce protocole est une modification du F e i g e - F i a t S h a m i r , dont la sécurité dépend
de la difficulté de la factorisation [1207, 1208]. Les mêmes auteurs ont également décrit
un schéma de signature multiple (voir § 23.1) par lequel un certain nombre de gens
peuvent signer un message séquentiellement [1209]. Ce schéma a été proposé pour les
réalisations de cartes à puce [852].
Brevets
F iA T - S h a m i r est breveté [1433]. Toute personne intéressée par une licence d’ex
ploitation de l’algorithme doit contacter: Yeda Research and Development, The
Weizmann Institute of Science, Rehovot 76100, Israël.
21.2 Guillou—Quisquater
F i a t S h a m i r fut le premier système pratique de preuve d ’identité à divulgation nulle.
Il minimisait les calculs requis pour les échanges en augmentant le nombre d ’itérations
du protocole et le nombre d ’accréditations par itération. Pour certaines réalisations,
telles que les cartes à puce, ce n’est pas l’idéal. Les échanges avec le monde extérieur
sont coûteux et la place nécessaire pour stocker chaque accréditation peut rapidement
consommer les ressources restreintes de la carte à puce.
G u i l l o u et Q u i s q u a t e r ont développé un algorithme d’identification à divulgation
nulle plus adapté à de telles situations [671, 1291]. Le nombre d’échanges entre Patricia
et Victor et le nombre d ’accréditations en parallèle pour chaque échange sont tout
deux maintenus à leur strict minimum : il n’y a qu’un échange d ’une accréditation pour
chaque preuve. La quantité de calcul nécessaire pour le schéma G u i l l o u -Q U ISQ U A T E R
est, pour le même niveau de sécurité, supérieure d ’un facteur 3 à celle requise pour le
schéma F i a t - S h a m i r .
Tout comme le F i a t - S h a m i r , cet algorithme d ’identification peut être transformé en
un algorithme de signature numérique.
21.2 G u i l l o u - Q u is q u a t e r 53 7
Schéma d’identification Guillou—Quisquater

Patricia est une carte à puce qui veut prouver son identité à Victor. L ’identité de
Patricia est un ensemble de références : une chaîne de données contenant le nom de
la carte, la période de validité, un numéro de compte en banque, et toute autre in
formation que l’application justifie. Cette chaîne de bits, appelée J 2, est analogue à
la clef publique. D ’autres informations publiques, partagées par toutes les « Patricia »
qui pourraient utiliser cette application, sont un exposant v et un module n, où n est
le produit de deux nombres premiers secrets. La clef privée est B , calculée telle que
JBV = 1 (mod n).
Patricia envoie ses références J à Victor. Maintenant elle veut prouver à Victor que
ces références sont bien les siennes. Pour ce faire, elle doit convaincre Victor qu’elle
connaît B. Voici le protocole:
1° Patricia choisit un nombre entier aléatoire r tel que r soit compris entre 1 et
n — 1. Elle calcule T = rv mod n et envoie celui-ci à Victor.
2° Victor choisit un nombre, entier aléatoire d tel que d soit entre 0 et v — 1. Il

envoie d à Patricia.
3° Patricia calcule D — rB d mod n et l’envoie à Victor.
4° Victor calcule T ' = D vJd mod n. Si T = T' (mod n)l ’authentification est
réussie.
Les mathématiques ne sont pas si compliquées que cela :
T ’ = D vJd = (rB d)v Jd = rvB dvJd = rv(J B v)d = rv ~ T (mod n),
puisque que B a été construite pour satisfaire :
JBV - 1 (mod n).
Schéma de signature Guillou—Quisquater

Ce schéma d ’identification peut être converti en un schéma de signature, également
adapté aux cartes à puce [672, 673].
La mise en place de la clef publique et celle de la clef privée sont les mêmes que
précédemment. Voici le protocole :
1° Alice choisit un nombre entier aléatoire r, tel que r soit compris entre 1 et
n — 1. Elle calcule T — rv mod n.
2° Alice calcule d = H ( M ,T ), où M est le message à signer et H (x) est une
fonction de hachage à sens unique. La valeur d produite par la fonction de
hachage à sens unique doit être comprise entre 0 et v — 1 [1291]. Si la valeur
produite par la fonction de hachage n’est pas comprise dans cet intervalle, elle
* doit être réduite modulo v.
2. En fait, ces références peuvent constituer une chaîne plus longue et, dans ce cas, la valeur de
J sera la valeur de l’empreinte de l ’identité. C ette com plexité supplém entaire ne m odifie toutefois en
rien le protocole.
3° Alice calcule D = rB d mod n. La signature est constituée du message AA, des

deux valeurs calculées d et D et de ses références J.
4° Bernard calcule T ' = D vJd mod n. H calcule ensuite d' = H(AA,T'). Sid = d',
Alice doit connaître B et sa signature est valide.
Multisignatures
Que se passe-t-il si plusieurs personnes veulent signer le même document? Il y a une
solution facile — chacune d’entre elles signe séparément — mais ce schéma de signature
peut faire mieux que cela. Dans l’exemple suivant, Alice et Bernard signent le même
document et Christine vérifie les signatures, mais n’importe quel nombre de personnes
peuvent être impliquées dans le processus. Comme précédemment, Alice et Bernard
ont leurs propres valeurs uniques J et B : Ja et Jb , et B a et B b - Les valeurs n et n
sont communes à tout le monde dans le système.
1° Alice choisit un nombre entier aléatoire va tel que ta soit compris entre 1 et
n — 1. Elle calcule Ta = r\ mod n et envoie Ta à Bernard.
2° Bernard choisit un nombre entier aléatoire r s tel que ru soit compris entre 1
et n — l. Il calcule Tb = r g mod n et envoie Tb à Alice.
3° Alice et Bernard calculent T = T aT b mod n
4° Alice et Bernard calculent d = H{AA,T), où Ad est le message à signer et H(x)
une fonction de hachage à sens unique. La valeur d produite par la fonction de
hachage à sens unique doit être comprise entre 0 et v — 1 [722], Si la valeur
produite par la fonction de hachage n’est pas comprise dans cet intervalle, elle
doit être réduite modulo v.
5° Alice calcule D a = ta B a mod n.

6° Bernard calcule D b — r s B g mod n.
7° Alice et Bernard calculent D = D a L>b mod n. La signature est constituée du
message AA, des deux valeurs calculées d et D , et de leurs références à tous les
deux, Ja et Jb -
8° Christine calcule J = Ja Jb mod n.
9° Christine calcule T ' — D vJ d mod n. Elle calcule ensuite d' — H{AA,T'). Si
d = d', alors la multisignature est valide.
Ce protocole peut être étendu à n’importe quel nombre de participants. Quand plu
sieurs personnes signent, ils multiplient tous les Tt individuels à l’étape 3 et leurs £)f
individuels à l’étape 7. Pour vérifier une multisignature, il faut multiplier tous les J,
des signataires à l’étape 8. Soit les signatures sont toutes valides, soit il y en a au moins
une fausse.
21.3 Schnorr
Le schéma d ’authentification e t de signature de Claus S c h n o r r [1401, 1403] tire sa
sécurité de la difficulté de calculer des logarithmes discrets. Pour engendrer une paire
21.3 S ch n orr 539
de clefs, choisissez deux nombres premiers p et q tels que q est un facteur premier de
p — 1. Ensuite, choisissez un a qui ne soit pas égal à 1 et tel que aq = 1 (mod p).
Tous ces nombres peuvent être communs à un groupe d’utilisateurs et peuvent être
librement publiés.
Pour engendrer une paire « clef publique — clef privée » particulière, choisissez un
nombre aléatoire inférieur à q. C ’est la clef privée s. Ensuite calculez v = a~s mod p.
C’est la clef pubüque.
Protocole d’authentification
1° Patricia choisit un nombre aléatoire r inférieur à q et calcule x — ar mod p.
C ’est l!éta.pe de prétraitement qui peut être réalisée bien longtemps avant que
Victor ne soit présent. Patricia envoie x à Victor.
2° Victor envoie à Patricia un nombre aléatoire e compris entre 0 et 2* — 1 (je
parlerai de t plus loin).
3° Patricia calcule y = (r + s X e) mod q et envoie y à Victor.
4° Victor vérifie que x — ayve mod p.
La sécurité est basée sur le paramètre t. La difficulté de casser l’algorithme est de

l’ordre de 2*. S c h n o r r recommande que p ait environ 512 bits et q environ 140 bits.
La valeur de t compatible avec ce niveau de sécurité est t = 72, que S c h n o r r estime
assez sûre.
Protocole de signature numérique

S c h n o r r peut aussi servir dans un protocole de signature d’un message Ai. La paire
« clef publique — clef privée » est la même mais nous ajoutons maintenant une fonction
de hachage à sens unique H {Ai).
1° Alice choisit un nombre aléatoire r inférieur à q et calcule x = ar mod p. Ce

calcul est l’étape de prétraitement.
2° Alice joint le message à x et calcule l’empreinte du résultat:
e = H(M,x).
Alice calcule y = (r + se) mod q. La signature est composée de e et y ; elle

envoie ces valeurs à Bernard.
3° Bernard calcule z — avve mod p. Il confirme ensuite que l’empreinte du mes
sage joint à z donne bien e :
e — H(M,z).
Si tel est le cas, il considère la signature comme valide.
Dans son article, Sch n o rr cite les nouveautés suivantes de son algorithme :
« La plupart des calculs pour la génération de signature peuvent être effec

tués lors d’une étape de prétraitement, indépendante du message à signer.
Ce calcul peut donc être fait sur le temps d ’inoccupation du processeur
et il n’affecte pas la vitesse de signature. Une attaque contre cette étape

de prétraitement est décrite dans [447] mais je ne pense pas qu’elle soit
pratique.
« À niveau de sécurité identique, la longueur des signatures est plus petite
p o u r S c h n o r r que p o u r R SA . P a r exem ple, avec u n q de 140 bits, les
signatures n ’ont que 212 bits de long, m oins de la m oitié de la longueur des
signatures R SA . L e s signatures S c h n o r r sont également nettem ent plus
courtes que les signatures E l G am al. »
Bien sûr les considérations pratiques amènent parfois à abaisser encore le nombre de
bits nécessaires à la sécurité de certains schémas : par exemple un schéma d ’identifica
tion où le tricheur doit effectuer une attaque en ligne en quelques secondes seulement
par rapport à un schéma de signature où le tricheur peut effectuer des années de calcul
avant de montrer sa fausse signature.
Une modification de cet algorithme, décrite dans [269] et réalisée par Emie B r i c k e l l
et Kevin McCuRLEY, améliore sa sécurité.
Brevets
Sch n o r rest breveté aux États-Unis [1404] et dans de nombreux autres pays. En 1993,
P K P a acquis les droits internationaux sur ce brevet (voir § 25.5). Le brevet américain
expire le 19 février 2008.
21.4 Convertir un schéma d’identification

en un schéma de signature numérique
Il y a une méthode générale pour transformer un schéma d ’identification en un schéma
de signature numérique : remplacez Victor par une fonction de hachage à sens unique.
Le message n’est pas haché avant d’être signé ; au lieu de cela, le hachage est incorporé
dans l’algorithme de signature. En principe, n ’importe quel schéma d’identification
permet de faire cela.
Chapitre 22
Algorithmes d’échange de clefs
22.1 Diffie—Hellman
D i f f i e - H e l l m a n est le premier algorithme à clef publique qui fut inventé [494], Sa
sécurité dépend de la difficulté de calculer des logarithmes discrets sur un corps fini par
rapport à la facilité de calcul d ’exponentielles dans le même corps. D i f f i e —H e l l m a n
peut être utilisé pour la distribution de clefs mais il ne peut pas être utilisé pour
chiffrer et déchiffrer des messages. Alice et Bernard peuvent utiliser cet algorithme
pour engendrer une clef secrète.
Les mathématiques sont simples. Au départ, Alice et Bernard se mettent d’accord sur
deux grands entiers, n et g, de telle manière que g soit primitif par rapport à n. Ces
deux entiers n’ont pas à être secrets ; Alice et Bernard peuvent convenir de ces nombres
sur un canal non sûr. Ils peuvent même être communs à un groupe d’utiüsateurs. Peu
importe.
Le protocole se déroule ainsi :
1° Alice choisit un grand nombre entier aléatoire x et envoie à Bernard le résultat
du calcul:
X — gx mod n.
2° Bernard choisit un grand nombre entier aléatoire y et à Alice le résultat du

calcul :
Y = gv mod n.
3° Alice calcule:
k - Y œ mod n.
4 ° Bernard calcule :
k' — X v mod n.
Les valeurs k et k' sont toutes deux égales à gxy mod n. Personne ne peut en écoutant
la communication calculer cette valeur; celui qui écoute ne connaît que n, g, X et
Y . À moins qu’il ne puisse calculer le logarithme discret et retrouver x ou y, il ne
peut résoudre le problème. Ainsi k est la clef secrète qu’Alice et Bernard ont calculée
indépendamment.
542 Chapitre 22 Algorithmes d’échange de clefs
Le choix de g et n peut avoir un impact substantiel sur la sécurité de ce système. Le

nombre (n —1)/2 doit être premier [1263]. Plus important, n doit être grand, la sécurité
du système dépend de la difficulté de factoriser des nombres de la taille de n. Et g doit
être n’importe quelle racine primitive modulo n ; rien d’empêche de prendre la plus
petite valeur de g qui convient (c’est généralement un nombre à un chiffre)1.
Diffie—Hellman avec trois participants et plus

Le protocole d ’échange de clefs D i f f i e - H e l l m a n peut être facilement étendu à trois
personnes et plus. Alice, Bernard et Christine engendrent ensemble une clef secrète.
1° Alice choisit un grand nombre entier aléatoire x et envoie X — gx mod n à

Bernard.
2° Bernard choisit un grand nombre entier aléatoire y et envoie Y — gy mod n

Christine.
3° Christine choisit un grand nombre entier aléatoire y et envoie Z — gz mod n

Alice.
4° Alice envoie Z' = Z x mod n à Bernard.
5° Bernard envoie X ' = X v mod n Christine.
6° Christine envoie Y ' = Y z mod n Alice.
7° Alice calcule k = Y'x mod n.
8° Bernard calcule k = Z 'v mod n.
9° Christine calcule k = X ' z mod n.
La clef secrète, k, est égale à gxyz mod n, et quiconque d’autre écoute la communication
ne peut calculer cette valeur. Le protocole peut être aisément étendu à quatre personnes
et plus ; il suffit d’ajouter les calculs des participants supplémentaires et les rondes de
calcul additionnelles.
Extension de Diffie—Hellman
Cet algorithme marche aussi dans les anneaux commutatifs [1263]. S h m u l e y et Kevin
M cC urley ont étudié une variante de l’algorithme dans laquelle le module est un
nombre composé [1448, 1046]. V.S. M i l l e r et Neal K o b l i t z ont étendu l’algorithme
aux courbes elliptiques [1101, 868]. Taher E l G a m a l a utilisé l’idée de base pour dé
velopper un algorithme de chiffrement et de signature numérique (voir § 19.6).
Cet algorithme marche également dans le corps de Galois Z / 2 k [1448, 1046]. Certaines
réalisations suivent cette approche [884,1633,1634] parce que les calculs sont nettement
plus rapides. Toutefois, les calculs cryptanalytiques sont aussi nettement plus rapides
et il est donc important de choisir un corps assez grand pour assurer la sécurité.
1. En fa it, il n ’est p as n écessaire q u e g so it un e racin e p rim itiv e m o d u lo n , m ais q u e le so u s-g rou p e

m u ltip lic a tif q u ’il gén éré m o d u lo n so it g ra n d .
22.1 D if f ie - H ellm an 543
Hugues
Cette variante permet à Alice de générer une clef et de l’envoyer à Bernard [747].
1° Alice choisit un grand nombre aléatoire x et génère :
k = gx mod n.
2° Bernard choisit un grand nombre aléatoire y et envoie à Alice le résultat du

cia,cul :
Y = gv mod n.
3° Alice envoi à Bernard le résultat du clacul:
X — Y x mod n.
4° Bernard calcule:
z ~ j/-1 mod n
k' = X z mod n.
Si tout se passe bien, k = k'.

L’avantage de ce protocole par rapport à D i f f i e - H e l l m a n est qu’il est possible de
calculer k avant toute interaction, et Alice peut chiffrer un message avant de contacter
Bernard. Elle peut l’envoyer à plusieurs personnes, et interagir ensuite avec eux pour
échanger individuellement la clef.
Échange de clefs sans échanger de clef

À l’intérieur d ’une communauté d ’utilisateurs, chacun d ’eux pourrait publier une clef
publique X = gx mod n dans une base de données partagée. Si Alice veut communiquer
avec Bernard, il lui suffit de consulter la clef publique de Bernard et de générer leur
clef secrète. Elle peut alors chiffrer un message avec cette clef et l’envoyer à Bernard.
Bernard consultera alors la clef publique d ’Alice pour générer 1a, clef secrète et déchiffrer
le message.
Chaque paire d’utilisateurs possède une unique clef secrète, et aucune communication
préalable n’est nécessaire. Les clefs publiques doivent être certifiées pour empêcher l’at
taque consistant à altérer la base de données et devraient être changées régulièrement.
À part cela, c ’est une idée assez astucieuse.
Brevets
L’algorithme d’échange de clefs D i f f i e - H e l l m a n est breveté aux Etats-Unis [720] et
au Canada [721], Un groupe appelé « P u b l i c K e y P a r t n e r s » (P K P ) octroie des
licences d ’exploitation de ce brevet en même temps que d ’autres brevets de cryptogra
phie à clef publique (voir § 25.5). Le brevet américain expire le 29 avril 1997.
Chapitre 22 Algorithmes d’échange de clefs
22.2 Protocole point à point

L ’échange de clefs suivant D i f f i e - H e l l m a n est vulnérable à l’attaque de l’intercep-
teur. Un moyen de contourner ce problème est d’amener Bernard et Alice à signer leurs
messages l’un l’autre [498].
Ce protocole fait l’hypothèse que Alice détient un certificat de la clef publique de
Bernard et que Bernard détient un certificat de la clef publique d ’Alice. Ces certificats
ont été signés par une autorité de confiance extérieure au protocole. Voici comment
Alice et Bernard génèrent une clef secrète k :
1° Alice génère un nombre aléatoire x et l’envoie à Bernard.

2° Bernard génère un nombre aléatoire y. 17 calcule leur clef secrète k selon le
protocole D i f f i e - H e l l m a n . Il signe x et y et chiffre le résultat avec k. Il
envoie le résultat et y à Alice:
y ,E k(SB {x,y)).
3° Alice calcule k à son tour. Elle déchiffre le reste du message de Bernard et

vérifie sa signature. Elle envoie alors à Bernard un message consistant de x et
y signé, puis chiffré avec leur clef partagée :
E k(SA (x,y)).
4° Bernard déchiffre le message et vérifie la signature d’Alice.
22.3 Protocole à trois passes de Shamir

Ce protocole, inventé par S h a m i r mais jamais publié, permet à Alice et Bernard de
communiquer confidentiellement sans aucun échange préalable de clefs secrètes ou de
clefs publiques [1014].
Il fait l’hypothèse de l’existence d ’un algorithme de chiffrement à clef secrète qui est
commutatif, c ’est-à-dire:
EA (E B( M ) ) = E b (Ea (M )).
La clef secrète d’Alice est A ; la clef secrète de Bernard est B. Alice veut envoyer un
message, A4, à Bernard. Voici le protocole :
1° Alice chiffre A i avec sa clef secrète et envoie le texte chiffré à Bernard
Ci = E a ( M ) .
2° Bernard chiffre Ci avec sa clef secrète et envoie le texte chiffré à Alice
C2 = E b ( E a ( M ) ) .
3° Alice déchiffre C2 avec sa clef secrète et envoie le texte chiffré à Bernard
C3 = D a (E b (Ea (A4))) = D a {Ea {E b {M ))) = E b {M ).

22.4 COM SET 545
4° Bernard, déchiffre C3 avec sa clef secrète pour finalement retrouver le texte du

message en clair.
Les masques jetables sont commutatifs et offrent la sécurité parfaite mais ils ne peuvent
pas être utilisés pour ce protocole. Avec la technique du masque jetable, les trois
messages seraient :
Cx = M® A
C2 = M e A ® B
C 3 = M 0 B.
Estelle, qui peut enregistrer ces trois messages quand ils transitent entre Alice et
Bernard, peut simplement les combiner par ou exclusif pour retrouver le message :
Ci ® C 2 0 C 3 = ( M 0 A) © ( M 0 A © B ) © ( M © B ) = AA.
Manifestement, cela ne marche pas.

S h a m i r décrit un algorithme de chiffrement qui est adapté à ce protocole ; celui-ci est
similaire au R SA . Soit p un grand nombre premier tel que p — 1 a un grand facteur
premier (afin d ’éviter le calcul facile du logarithme discret modulo p). Choisissez une
clef de chiffrement e et une clef de déchiffrement d tout comme vous les choisiriez pour
le RSA. La clef de chiffrement e doit être première par rapport à p — 1. Calculez d en
utilisant l’algorithme d’EüCLiDE de telle manière que de = 1 (mod p — 1).
Pour chiffrer un message calculez :
C — AAe mod p.
Pour déchiffrer un message calculez :
AA = Cd mod p.
D ne semble pas y avoir de moyen pour Estelle de retrouver le message AA sans devoir
calculer le logarithme discret mais, comme tant d’autres choses en cryptographie à clef
publique, cela n’a jamais été prouvé.
Ce protocole offre quelque chose que le chiffrement à clef publique simple n’offre pas. Il
permet à Alice d’amorcer une communication avec Bernard sans connaître aucunes de
ses clefs. Si Alice voulait utiliser un algorithme à clef publique, elle devrait connaître
la clef publique de Bernard. Avec le protocole à trois passes de S H A M I R , elle lui en
voie seulement un message chiffré. La même chose avec un algorithme à clef publique
ressemble à ceci :
1° Alice demande à Bernard (ou au C D C ) sa, clef publique.

2° Bernard (ou le CDCJ envoie à Alice sa clef publique.
3° Alice chiffre AA avec la clef publique de Bernard et lui envoie le résultat.
Le protocole de Sham ir est vulnérable à l’attaque de l’intercepteur.
22.4 COM SET

C O M S E T (pour « COMmunications SETup ») est un protocole d’identification mu
tuelle et d’échange de clefs développé pour le projet R IP E [1316] (voir § 25.7). En
utilisant la cryptographie à clef publique, il permet à Alice et Bernard de s’identifier

l’un à l’autre par eux-mêmes et aussi d’échanger une clef secrète.
Les principes mathématiques sous-jacents à C O M S E T sont basées sur le schéma de
R a b in [1294] (voir § 19.5). Le schéma lui-même a été proposé à l’origine dans [230].
Voyez [1316] pour plus de détails.
22.5 Échange de clefs chiffré

Le protocole d’échange de clefs chiffré (E K E pour « Encrypted Key Exchange ») a
été conçu par Steve B e l l o v i n et. Michael M e r r i t t [116]. Il offre la confidentialité et
l’authentification sur un réseau d’ordinateurs, en utilisant à la fois la cryptographie
à clef secrète et la cryptographie à clef publique de façon originale : une clef secrète
partagée est utilisée pour chiffrer une clef publique engendrée aléatoirement.
Protocole EKE basique

Alice et Bernard (deux utilisateurs, un utilisateur et un ordinateur central, ou toute
autre combinaison) partagent un mot de passe commun P. En utilisant le protocole
suivant, ils peuvent s’authentifier l’un à l’autre et engendrer une clef commune de
session, K .
1° Alice engendre une clef publique aléatoire, K ' . Elle chiffre celle-ci à l’aide d’un
algorithme à clef secrète et de la clef P : E p(K' ) . Elle envoie à Bernard:
Alice, Ep(K').
2° Bernard connaît P. Il déchiffre le message pour obtenir K ' . Ensuite, il engendre

une clef de session aléatoire, K , et la chiffre avec la clef publique qu ’il vient de
recevoir d’Alice et la clef secrète P :
E p (EK'(K)).
Il envoie le résultat à Alice.

3° Alice déchiffre le message pour obtenir K . Elle engendre une chaîne aléatoire
R a et la chiffre avec K et envoie le résultat à Bernard:
E k ( R a ).
4° Bernard déchiffre le message pour obtenir Ra- Il engendre une autre chaîne
aléatoire R p, chiffre les deux chaînes avec K et envoie le résultat à Alice :
E k {R a ,R b )-
5° Alice déchiffre le message pour obtenir R a et R p. En faisant l’hypothèse que

la R a qu’elle, a reçue de Bernard est la même que celle qu’elle a engendrée à
l’étape 3, elle chiffre R b avec K et l’envoie à Bernard:
E r (R b )-
22.5 Échange de clefs chiffré
6° Bernard déchiffre le message pour obtenir R s - En faisant l’hypothèse que la

R b qu’il a reçue d’Alice est la même que celle qu’il a engendrée à l’étape 4, le
protocole est terminé. Les deux participants peuvent communiquer en utilisant
la clef de session K .
À l’étape 3, Alice et Bernard connaissent tous deux K ' et K . K est la clef de session
et elle peut être utilisée pour chiffrer tous les autres messages entre Alice et Bernard.
Estelle, qui est entre Alice et Bernard, connaît seulement Ep( K' ) , E p (E k '(K)) et
quelques messages chiffrés avec K. Dans d’autres protocoles, Estelle peut essayer de
deviner P (les gens utilisent de mauvais mots de passe tout le temps et, si Estelle
est maligne, elle peut faire certains paris judicieux) et ensuite essayer ses paris. Dans
ce protocole, Estelle ne peut pas tester ses paris sans casser également l’algorithme
à clef publique. Et si K ' et K sont choisis aléatoirement, cela peut être un problème
insurmontable.
La portion « défi réponse » du protocole, de l’étape 3 à l’étape 6, valide le protocole.
Les étapes 3 à 5 prouvent à Alice que Bernard connaît K ; les étapes 4 à 6 prouvent à
Bernard qu’Alice connaît K . L’échange de datations du protocole K e r b e r o s accomplit
la même chose.
EKE peut être réalisé grâce à plusieurs algorithmes à clef publique : R SA , E l G a m a l ,
D iffie -H e l l m a n . Il y a des problèmes de sécurité dans les réalisations utilisant l’al
gorithme des empilements (mis à part les problèmes inhérents à cet algorithme) : la
distribution normale des messages de texte chiffré vient à l’encontre des bien-faits de
EKE.
Réalisation d’EKE à l’aide du RSA

L’algorithme R S A semble être le candidat idéal pour cette application, mais il pose
quelques problèmes subtils. Les auteurs recommandent de ne chiffrer que l’exposant de
chiffrement à l’étape 1 et d ’envoyer le module en clair. Une explication du raisonnement
sous-jacent à cette recommandation, ainsi que d ’autres subtilités liées à l’utilisation du
RSA sont décrites dans [116].
Réalisation d’EKE à l’aide d’ElGamal

Réaliser E K E à l’aide d’ELGAMAL est évident, il y a même une simplification du
protocole basique. En utilisant les notations du paragraphe 19.6, g et p font partie de
la clef publique et sont communs à tous les utilisateurs. La clef privée est un nombre
aléatoire r. La clef publique est gr mod p. Le message qu’Alice envoie à Bernard à
l’étape 1 devient :
Alice, gr mod p.
Remarquez que cette clef publique n’a pas à être chiffrée avec P. Ce n’est pas vrai en
général mais c ’est vrai pour l’algorithme E l G a m a l . Les détails sont donnés dans [116].
Bernard choisit un nombre aléatoire R (c’est pour l’algorithme E l G a m a l et c’est
indépendant des nombres aléatoires choisis pour E K E ) et le message qu’il envoie à
Alice à l’étape 2 devient :
Ep(gR mod p, KgRr mod p).
Voyez le paragraphe 19.6 pour les restrictions dans le choix des variables d’ELGAMAL.
Réalisation d’EKE à l’aide de Diffie-Hellman

Avec le protocole D iF F t E H e l l m a n , K est engendrée automatiquement. Le protocole
final est encore plus simple. Une valeur pour g et n est choisie pour tous les utilisateurs
du réseau.
1° Alice choisit un nombre aléatoire ta et envoie à Bernard :
Alice, gTA mod n.
Avec D i f f i e - H ellm an , Alice n’a, pas à chiffrer son premier message avec P.
2° Bernard choisit un nombre aléatoire rg et calcule:
K = grAXrB mod n.
I
Il engendre une chaîne aléatoire R g, puis calcule et envoie à Alice:
E P(grB mod n),EK (RB).
3° Alice déchiffre la première moitié du message de Bernard pour obtenir gTB mod
n. Ensuite, elle calcule K et utilise K pour déchiffrer R g . Elle engendre une
autre chaîne aléatoire R a , chiffre les deux chaînes avec K et envoie le résultat
à Bernard:
E k {R a ,R b )-
4° Bernard déchiffre le message pour obtenir R a et R g . En faisant l ’hypothèse

que la valeur de Rg qu’il a reçue d’Alice est la même que celle qu’il a envoyée
à Alice à l’étape 2, ü chiffre R a avec K et envoie le résultat à Alice:
E k (R a ).
5° Alice déchiffre le message pour obtenir R a - En faisant l ’hypothèse que la valeur

de R a qu’elle a reçue de Berna,rd est la même que celle qu’elle a envoyée à
l ’étape S, le protocole est terminé. Les deux participants peuvent communiquer
grâce à la clef de session K .
EKE renforcé
B e l l o v i n et M e r r i t t suggèrent une amélioration de la portion « défi - réponse » du
protocole afin d ’éviter une attaque possible si un cryptanalyste est entré en possession
d’une vieille valeur de K .
Voyez le protocole de base EKE. A l’étape 3, Alice engendre un autre nombre aléatoire,
S a et envoie à Bernard :
E k (R a ,Sa )•
À l’étape 4, Bernard engendre un autre nombre aléatoire S g et envoie à Alice :
E k { R a ,R b ,Rg ) -
22.5 Échange de clefs chiffré 549
Alice et Bernard peuvent maintenant tous deux calculer la vraie clef de session S a ffi S p .
Cette nouvelle clef est utilisée pour tous les futurs messages entre Alice et Bernard ; K
n’est utilisée que comme clef d ’échange de clef.
Voyons maintenant le niveau de protection offert. Si Estelle entre en possession de S,
cela ne lui donne aucune information sur P car P n’est jamais utilisé pour chiffrer quoi
que ce soit qui conduise directement à S. Une attaque cryptanalytique contre K n’est
pas possible ; K est seulement utilisée pour chiffrer des données aléatoires et S n’est
jamais chiffré seul.
EKE augmenté
Le protocole E K E présente un sérieux défaut : les deux parties doivent posséder P. La
plupart des systèmes d’authentification à mot de passe stockent une empreinte du mot
de passe de l’utilisateur et non le mot de passe lui-même (voir § 3.2). Le protocole EKE
augmenté (A -E K E ) utilise une empreinte du mot de passe de l’utilisateur comme clef
de surchiffrement dans la variante D i f f i e - H e l l m a n de EKE. L ’utilisateur envoie alors
un message supplémentaire basé sur le mot de passe originel, qui certifie l’authenticité
de la nouvelle clef de session choisie.
Voici comment cela fonctionne. Alice et Bernard veulent s’identifier l’un l’autre et
générer une clef de session commune. Ils se mettent d ’accord sur un schéma de signature
numérique où tout nombre est susceptible de servir de clef privée, et où la clef publique
s’obtient à partir de la clef privée. E l G a m a l et R S A conviennent parfaitement. La
clef privée P ' sera le mot de passe d’Alice ou seulement une empreinte de celui-ci.
1° Alice choisit un exposant aléatoire ta et envoie :
Ep'{gTA m od n ).
2° Bernard, qui ne connaît que P ' et ne peut pas en déduire P , choisit r& et
envoie :
Ep'(gTB mod n).
3° Alice et Bernard peuvent tovs les deux calculer la clef de session K =

gTAyrB moci n Finalement, Alice prouve qu’elle connaît P lui même, et pas
seulement P ', en envoyant :
E k (Sp (K)).
Bernard qui connaît à la fois K et P' peut déchiffrer et vérifier la signature. Seule
Alice a pu envoyer ce message puisqu’elle est la seule à connaître F ; un intrus qui
obtiendrait une copie du fichier de mots de passe de Bernard peut essayer de deviner
P, mais ne peut pas signer la clef de session.
Le schéma A -E K E ne fonctionne pas avec la variante à clef publique de E K E puisque
l’un des participants y choisit la clef et l’impose à l’autre. Cela permet une attaque de
l’intercepteur par un attaquant qui a intercepté P.
Applications d’EKE
B e l l o v i n et M e r r i t t suggèrent que ce protocole peut être utilisé pour des téléphones
publics sûrs [116] :
« Faisons l’hypothèse que des téléphones publics chiffrés sont installés.
Si quelqu’un veut utiliser l’un de ces téléphones, un moyen d’entrer de

l’information doit être fourni. Les solutions conventionnelles ... nécessitent
que l’appelant dispose d ’une clef physique, ce qui n’est pas souhaitable
dans de nombreuses situations. E K E permet d’utiliser un mot de passe
court entré par le clavier, mais utilise une clef de session nettement plus
longue pour l’appel.
« E K E serait aussi utile pour les téléphones cellulaires. La fraude a
été un problème dans l’industrie des téléphones cellulaires ; E K E permet
de s’en prémunir (et d’assurer la confidentialité de l’appel) en rendant le
téléphone inutilisable si un P IN 2 n’a pas été entré. Comme le PIN n’est
pas stocké dans le téléphone, il n’est pas possible d ’en récupérer un à partir
d’un combiné volé. »
La force principale d’E K E est que la cryptographie à clef secrète et la cryptographie

à clef publique sont utilisées ensemble de façon à se renforcer mutuellement :
« D ’un point de vue général, EK E fonctionne comme un amplificateur

de confidentialité. En effet, il peut être utilisé pour renforcer des systèmes à
clef secrète et à clef publique, comparativement faibles, quand ceux-ci sont
utilisés ensemble. Considérez, par exemple, la taille de clef nécessaire pour
garantir la sécurité quand on utilise un échange de clef exponentiel. Comme
L a M a c c h i a et O d l y z k o l’ont montré [945], même des tailles de modules
que l’on croyait sûres (à savoir 192 bits) sont vulnérables à une attaque qui
ne requiert que quelques minutes de temps d’ordinateur. Mais leur attaque
n’est pas réalisable si l’on doit d’abord deviner un mot de passe avant de
l’appliquer.
« Réciproquement, la difficulté de casser l’échange de clef exponentiel
peut être utilisée pour empêcher les paris sur les mots de passe. La faisa
bilité des attaques qui devinent les mots de passe dépend de la vitesse à
laquelle on peut vérifier un pari. Si effectuer une telle vérification néces
site la résolution d ’un échange de clef exponentiel, le temps total, sinon la
difficulté conceptuelle, augmente hors de proportion. »
EKE est breveté [117].
22.6 Négociation de clef fortifiée

Ce schéma a aussi pour but de protéger la négociation de clefs contre les mots de passe
faibles et les attaques de l’intercepteur [48, 994]. Il utilise une fonction de hachage à
sens unique de deux variables possédant une propriété très spéciale : elle offre beaucoup
de collisions sur la première variable et en pratique aucune sur la seconde :
H'(x,y) = H(H(k,x) mod 2m,x )

où H{k,x) est fonction de hachage ordinaire appliquée h, k et x.
Alice et Bernard partagent un mot de passe secret P, et viennent juste d’échanger une
clef de session K avec le protocole de D i f f i e - H e l l m a n . Ils utilisent P pour vérifier
2. N ote du traducteur : PIN est l’abréviation de « P e r s o n a l Id e n tific a tio n N u m b er » pou r « n u m éro
d ’id en tific a tio n p e r s o n n e l ».
22.7 Distribution de clef de conférence et diffusion de secret 551
qu’ils ont la même clef de session (et qu’Estelle n’est pas en train de tenter une attaque
de l’intercepteur), sans dévoiler P à Estelle.
1° Alice envoie à Bernard

H' (P, K).
2° Bernard calcule H' (P, K) et compare son résultat avec ce qu’il a reçu. S ’ils sont
identiques, il envoie à Alice
H ' ( H ( P , K ))
3° Alice calcule H' (H( P, K) ) et compare son résultat avec ce qu’elle a reçu.
Si Estelle tente l’attaque de l’intercepteur, elle utilise une clef K i avec Alice et une clef
K 2 avec Bernard. Pour tromper Bernard à l’étape 2, il faut qu’elle devine le mot de
passe et qu’elle envoie H'(P,K-i) à Bernard. Avec une fonction de hachage classique,
elle peut essayer les mots de passe usuels pour deviner le bon et réussir à infiltrer le
protocole. Mais avec cette fonction de hachage, il existe beaucoup de mots de passe
susceptibles de produire la même valeur quand ils sont hachés avec K\. Aussi, quand
elle trouve un mot de passe qui convient, elle a de grande chances de ne pas avoir le
bon, et Bernard ne se laissera pas duper.
22.7 Distribution de clef de conférence et

diffusion de secret
Alice veut diffuser un message A4 à partir d ’un seul émetteur. Toutefois, elle ne veut
pas qu’il soit intelligible pour tous les auditeurs. En fait, elle souhaite que seul un
ensemble restreint d’auditeurs puissent être en mesure de reconstruire A4. Pour toute
autre personne, cela doit être du charabia.
Alice peut partager une clef différente (secrète ou publique) avec chaque auditeur. Elle
chiffre le message avec une clef aléatoire K . Ensuite, pour chaque auditeur choisi, elle
chiffre une copie de K avec la clef partagée avec l’auditeur. Finalement, elle diffuse le
message chiffré et toutes les copies de K chiffrées. Bernard, qui écoute, soit essaie de
déchiffrer toutes les K chiffrées avec sa clef secrète et cherche un résultat correct ; soit
cherche son nom suivi de la clef chiffrée, si Alice ne se préoccupe pas du fait que l’on
puisse savoir à qui elle diffuse le message. La cryptographie à clefs multiples convient.
Une autre méthode est suggérée dans [356]. Au départ, chaque auditeur partage une
clef secrète avec Alice, celle-ci étant plus grande que tout message chiffré diffusé. Toutes
les clefs doivent être deux à deux premières entre elles. Elle chiffre le message à l’aide
d’une clef aléatoire K . Ensuite, elle calcule un entier R tel que R soit congru à K
modulo chaque clef secrète autorisée à lire le message, et congru à 0 modulo chaque
clef secrète non autorisée.
Par exemple, si Alice veut envoyer le message à Bernard, Christine et Etienne mais
pas à David et Francis, elle chiffre le message avec K et calcule ensuite R tel que :
R = K (mod K b )
R = K (mod K c )
R = 0 (mod K d )
R = K (mod K e )
R = 0 (mod K f )-
C ’est un problème d ’algèbre facile, qu’Alice peut certainement résoudre. Quand les
auditeurs reçoivent la transmission, ils calculent la clef reçue modulo leur clef secrète.
S’ils sont autorisés à lire le message, ils récupèrent la clef K . Sinon, ils ne récupèrent
rien du tout.
Une troisième façon d ’opérer, en utilisant un schéma à seuil (voir § 3.7) est suggérée par
Shimshon B e r k o v i t z dans [148]. Comme pour les autres, chaque auditeur potentiel
reçoit une clef secrète. Cette clef est une part dans un schéma à seuil qui n’est pas
encore mis en place. Alice garde quelques clefs secrètes pour elle-même afin de rajouter
un peu de caractère aléatoire au système. Faisons l’hypothèse qu’il y a A; personnes qui
écoutent.
Alors pour diffuser A4, Alice chiffre A4 avec la clef K et fait ce qui suit :
1° Alice choisit un nombre aléatoire j . Ce nombre sert à cacher combien d’audi

teurs sont visés par le message. Il n’a pas à être très grand; il peut être même
aussi petit que 0 .
2° Alice crée un schéma à seuilfk -f j + 1 , 2k + j 4-1) avec :
K comme clef secrète ;

les clefs secrètes des auditeurs visés comme parts ;
les clefs secrètes des auditeurs non visés ne sont pas des parts ;
j parts choisies aléatoirement, différentes de toutes les clefs secrètes.
3° Alice émet k + j parts choisies aléatoirement, aucune d ’entre elles n’étant une
part décrite à l’étape 2 .
4° Tous les auditeurs qui reçoivent l ’émission ajoutent leur part aux k + j parts
qu’ils ont reçues. Si l ’adjonction de leur part leur permet de calculer le secret,
ils obtiennent la clef. Sinon, ils ne l’ont pas.
Une autre approche est décrite dans [8 8 6 , 885, 1203]. Pour une autre approche encore,
consultez [1009].
Distribution de clef de conférence

Ce protocole permet à un groupe de n utilisateurs de se mettre d’accord sur une clef
secrète à travers un réseau de communication peu sûr. Le groupe partage deux grands
nombres premiers p et q, et un générateur de même taille que q.
1° L ’utilisateur i, où i varie de 1 à n , choisit un nombre aléatoire r, inférieur à q

et diffuse:
z, = gr' mod p.
2 ° Chaque utilisateur vérifie que z j = 1 (mod p) pour tout j entre 1 et n.

3° L ’utilisateur i diffuse :
X; = {z1+1/Z i-i)T' mod p.

22.7 Distribution de clef de conférence et diffusion de secret 553
4° L ’utilisateur i calcule :
K = i ) nr* x a;” -1 x x ••• x Xi- 2 mod p
Tous les indices des calculs du protocole, i,i — l,i — 2 , . . . ,i + 1, sont à prendre modulo
n. A la fin du protocole, tous les utilisateurs honnêtes obtiennent le même K . Personne
d’autre n’apprend quoi que ce soit. Cependant, ce protocole est vulnérable à l’attaque
de l’intercepteur. Un autre protocole, moins beau que celui-ci, est décrit dans [759].
Tatebayashi-Matsuzaki-Newman
Ce protocole de distribution de clef convient aux réseaux [1525]. Alice veut générer une
clef de session avec Bernard grâce à Ivan, le C D C . Tous les participants connaissent la
clef publique n de Ivan. Ivan connaît les deux grands facteurs premiers de n, et peut
donc facilement calculer des racines cubiques modulo n. Une grande partie des détails
est laissée de côté, mais l’idée est là.
1° Alice choisit un nombre aléatoire ta et envoie à Ivan :
r\ mod n.
2 ° Ivan informe Bernard que quelqu’un veut échanger une clef avec lui.
3° Bernard choisit un nombre aléatoire r s et envoie à Ivan:
rB mod n.
4° Ivan utilise sa clef privée pour retrouver ta et r s , et envoie à Alice:
ta ® r B.
5° Alice calcule
(rA <$rB) ® r A = r B.
Elle utilise rB pour communiquer en sécurité avec Bernard.
Ce protocole paraît acceptable, mais il possède un horrible défaut. Christine peut

écouter à l’étape 3 et utiliser cette information pour retrouver rB avec l’aide d’un
utilisateur complice (David), et d’un Ivan peu suspicieux [1476].
1° Christine choisit un nombre aléatoire r c et envoie à Ivan :
r%r% mod n.
2° Ivan informe David que quelqu ’un veut échanger une clef avec lui.
3° David choisit un nombre aléatoire ru et envoie à Ivan:
r\) mod n.
4° Ivan utilise sa clef privée pour retrouver rB et ce qu’il prend pour r c , et envoie
à Christine:
(rBrc m od n) © ru-
5° David envoie ru à Christine.

6° Christine utilise r c et ru pour retrouver r s - Elle utilise r# pour espionner
Alice et Bernard.
Ce n’est pas acceptable.

Chapitre 23
Algorithmes spéciaux pour

protocoles
23.1 Cryptographie à clef publique à clefs

multiples
Ceci est une généralisation du R S A (voir § 19.3 [220, 215]. Le module n est le produit
de deux nombres premiers p et q. Toutefois, au lieu de choisir e et d tels que e x d = 1
(mod (p - 1 ) x (q — 1 )), choisissez t clefs kz telles que :
ki x /c2 x ... x = 1 (mod (p — 1 ) x (q — 1 )).
Comme :
jV ffc,xfc2 x ...x k t
ceci est un schéma à clefs multiples tel que décrit dans le paragraphe 3.5.
Si, par exemple, il y a 5 clefs, un message chiffré avec kz et k^ peut être déchiffré avec
ki, k'2 et k/i i
C = M k3* ks mod n
M = c kixk2 xk4 m o d n
Cela sert pour les signatures multiples. Imaginez la situation où Alice et Bernard
doivent tous les deux signer un document pour le rendre valide. Munissez les de trois
clefs : Ki , K 2 et A 3 . Les deux premières sont destinées à Alice et Bernard, une chacun,
et la troisième est rendue publique.
1° Alice signe A4 et envoie à Bernard :
A4' = M Kl mod n.
2° Bernard peut retrouver A4 à partir de A4' :
A4 — A4'K2XKs mod n.
556 Chapitre 23 Algorithmes spéciaux pour protocoles
3° Il peut aussi ajouter sa signature :
A i " = AA'k 2 mod n.
4° Tout le monde peut vérifier la signature avec la clef publique :
A i = A i " Ks mod n.
Notez qu’une personne de confiance extérieure est nécessaire à la mise en place du

système et à la distribution des clefs. Un autre schéma présentant le même problème
est décrit dans [482]. Un autre encore se trouve dans [697, 831, 701], mais la vérification
y demande un travail proportionnel au nombre de signataires. Des schémas plus récents
[223, 1209], basés sur les schémas de preuve à divulgation nulle vient à bout des défauts
des systèmes précédents.
23.2 Algorithmes de partage de secret

Plus tôt, au paragraphe 3.7, j ’ai décrit l’idée sous-jacente aux schémas de partage de
secret. Les quatre différents algorithmes qui suivent sont tous des cas particuliers d’un
schéma théorique général [883].
Schéma du polynôme d’interpolation de L a g r a n g e

Adi S h a m ir utilise des équations polynomiales sur un corps fini pour construire un
schéma à seuil [1421]. Tout d’abord, choisissez un nombre premier p qui est plus grand
que le nombre de parts possibles et plus grand que le plus grand secret possible. Pour
partager un secret, engendrez un polynôme arbitraire de degré m — 1. Par exemple,
pour créer un schéma à seuil (3,n) (trois parts sont nécessaires pour reconstruire Ai),
engendrez un polynôme quadratique :
F(x) = (ax2 + bx + Ai) mod p,
où p est un nombre premier plus grand que n’importe quel coefficient. Les coefficients
a et b sont choisis aléatoirement ; ils sont tenus secrets et jetés après que les parts aient
été distribuées. A i est le message. Le nombre premier doit être rendu public.
Les parts sont obtenues en évaluant le polynôme en n points différents :
kt = F ( x t).
En d ’autres termes, la première part pourrait être la valeur du polynôme évalué en

x — 1, la deuxième part pourrait être la valeur du polynôme évalué en x = 2, etc.
Comme le polynôme quadratique a trois coefficients inconnus, a, b et Ai, n’importe
quel ensemble de trois parts peut être utilisé pour construire trois équations ; l’algèbre
linéaire peut être utilisée pour retrouver Ai. Deux parts ne suffisent pas. Une part ne
suffit pas. Quatre ou cinq parts sont redondantes.
Par exemple, supposons que A i vaut 11 Pour construire un schéma à seuil (3,5), dans
lequel trois personnes parmi cinq peuvent reconstruire Ai, engendrez une équation
quadratique (7 et 8 ont été choisis aléatoirement) :
F(x) = (7a;2 + 8a; + 11) m od 13.

23.2 Algorithmes de partage de secret 557
Les cinq parts sont :

fcj = F ( l ) = 7 + 8 + l l = 0 (mod 13)
fc2 = F (2) = 2 8 + 1 6 + 11 = 3 (mod 13)
fc3 = F ( 3 ) = 63 + 24 + l l = 7 (mod 13)
k4 = F ( 4 ) = 112 + 3 2 + 11 = 12 (mod 13)
fc5 = F( 5) = 175 + 40 + 11 = 5 (mod 13).
Pour reconstruire A4 à partir de 3 parts, par exemple, ta, ta et k5, il faut résoudre le
jeu d’équations linéaires :
a x 2 2 + f cx2 + M = 3 (mod 13)
a x 3 2 + 6 x 3 + A4 = 7 (mod 13)
a x 5 2+ 6 x 5 + M = 5 (mod 13).
La solution sera a = 7, b = 8 et A4 = II. Ainsi, on a retrouvé A4.
Ce schéma de partage peut être facilement réalisé avec de grands nombres. Si vous vou
lez diviser un message en 30 parts égales de telle manière que 6 d’entre elles quelconques
permettent ensemble de reconstruire le message, donnez à chacune des 30 personnes le
résultat de l’évaluation du polynôme de degré 5 :
F(x) = (ax 6 + bx5 + ex4 + dx3 + ex 2 -f f x + A4) mod p.
Six personnes peuvent calculer les six inconnues (y compris A4) ; cinq personnes ne
peuvent rien apprendre de A4.
L’aspect le plus époustouflant du partage de secret est que si les coefficients sont choisis
aléatoirement, cinq personnes disposant d’une puissance de calcul infinie ne peuvent
rien apprendre du message à part sa longueur (que, de toute façon, ils connaissent tous).
C’est aussi sûr qu’un masque jetable ; une tentative de recherche exhaustive (c’est-à-
dire, essayer toutes les combinaisons possible de six parts) révélerait que tout message
concevable pourrait être le secret. C ’est vrai pour les quatre schémas de partage de
secret présentés ici.
Schéma vectoriel
George B l a k l e y a inventé un schéma qui utilise des points dans l’espace [189]. Le
message est défini comme un point dans un espace à m dimensions. Chaque part est
l’équation d ’un hyperplan de m — 1 dimensions qui inclut ce point. L ’intersection de
n’importe quel ensemble de m de ces hyperplans détermine exactement ce point.
Par exemple, si trois parts sont nécessaires pour reconstruire le message, alors c ’est un
point dans un espace à trois dimensions. Chaque part est un plan différent. Avec une
part, vous savez que le point est quelque part sur le plan. Avec deux parts, vous savez
que le point est quelque part sur la droite d’intersection des deux plans. Avec trois
parts, vous pouvez déterminer le point exactement : c ’est l’intersection des trois plans.
Asmuth—Bloom
Ce schéma utilise des nombres premiers [70]. Pour un schéma à seuil-(m,n), choisissez
un grand nombre premier p plus grand que A4. Ensuite choisissez n nombres inférieurs
kp, dj, d2 , ..., dn tels que:
1. les valeurs des di soient en ordre croissant ; di < dL+i ;

2. chaque di soit premier par rapport à tous les autres d; ;
3. di x d2 x ... X dm > p X dn—m + 2 ^ m +3 ^ ••• ^ ^n*
Pour distribuer les parts, choisissez une valeur aléatoire r et calculez :
A4' = A i + r p .
Les parts sont données par :

ki = A4 1 mod d,.
Tout ensemble de m parts peut être utilisé pour reconstruire A i en utilisant le théorème
du reste chinois, mais m — 1 parts ne le permettent pas. Voyez [70] pour les détails.
Karnin—G reene—Hellman
Le schéma de K a r n in , G r e e n e et H e l l m a n utilise la multiplication matricielle [819].
Choisissez n + 1 vecteurs à m dimensions Vo, Vi, ..., Vn, tels que toute matrice m x rri
formée à partir de ces vecteurs ait un rang m. Le vecteur U est le vecteur ligne de
dimension m.
A4, est le produit matriciel U - Vo- Les parts sont données par les produits matriciels
U ■Vi, où i varie de 1 à n.
Tout ensemble de m parts peut être utilisé pour résoudre le système de m x m équations
linéaires où les inconnues sont les coefficients de U. Connaissant 17, on peut calculer
U ■Vq. Tout ensemble de m — 1 parts ne permet pas de résoudre le système d’équations
linéaires et ne permet donc pas de retrouver le secret.
Schémas à seuil avancés

Les exemples précédents illustrent seulement les schémas à seuil les plus simples : di
viser un secret en n parts de telle manière que m parts puissent être utilisées pour
reconstruire le secret. Ces algorithmes peuvent être utilisés pour construire des sché
mas bien plus compliqués. Les exemples suivants utiliseront l’algorithme de S h a m ir ,
bien que tout autre algorithme décrit ci-dessus puisse convenir.
Pour créer un schéma pour lequel une personne est plus importante que les autres,
donnez plus de parts à cette personne. Supposons qu’il faille avoir 5 parts pour recons
truire le secret. Si une personne a trois parts différentes tandis que toutes les autres
n’en ont qu’une alors cette personne et deux autres peuvent reconstruire le secret. Sans
cette personne particulière, il faut cinq personnes pour reconstruire le secret.
Deux personnes ou plus peuvent recevoir plusieurs parts. Chaque personne différente
peut recevoir un nombre différent de parts. Peu importe la façon dont les parts sont
distribuées, rn d ’entre elles quelconques peuvent être utilisées pour reconstruire le se
cret. Quelqu’un qui a m — 1 parts, que ce soit une personne ou une assemblée, ne peut
pas le reconstruire.
Dans d’autres types de schémas, imaginez un scénario dans lequel il y a deux délégations
hostiles. Vous pouvez partager un secret de telle manière que deux personnes parmi
les sept de la Délégation A et trois personnes parmi les 12 de la Délégation B soient
nécessaires pour reconstruire le secret- Construisez un polynôme de degré 3 qui soit
le produit d’un polynôme linéaire et. d’un polynôme quadratique. Donnez à chaque
membre de la Délégation A une part qui est le résultat d ’une évaluation du polynôme
23.2 Algorithmes de partage de secret 559
linéaire, et donnez à chaque membre de la Délégation B une part qui est le résultat
d’une évaluation du polynôme quadratique.
Deux parts quelconques de la Délégation A peuvent être utilisées pour reconstruire
le polynôme linéaire mais, quel que soit le nombre de parts dont dispose le groupe,
personne ne peut obtenir la moindre information sur le secret. La même chose est vraie
pour la Délégation B : ils peuvent mettre trois parts en commun pour reconstruire le po
lynôme quadratique, mais ils ne peuvent pas obtenir la moindre information nécessaire
pour reconstruire le secret. Ce n’est que si les délégations mettent en commun leurs
polynômes que ceux-ci peuvent être multipliés entre eux pour reconstruire le secret.
En général, tout type de schéma de partage qui peut être imaginé peut être réalisé.
Tout ce que vous avez à faire, c ’est trouver un système d’équations qui correspondent
au schéma particulier choisi. D ’excellents articles concernant les schémas de partage
de secret généralisés sont dans [1468, 1469, 1470].
Partage de secret avec des tricheurs
Cet algorithme modifie le schéma à seuil-(m,n) standard pour détecter les tri
cheurs [1537]. Cela marche avec n’importe quel schéma, mais je vais l’illustrer en
utilisant le schéma de L a g r a n g e .
Choisissez un nombre premier p plus grand que n et plus grand que :
(s — l)(ra — l ) / e + m,
où s est le secret le plus grand possible et e est la probabilité de tricher avec succès.
Vous pouvez rendre e aussi petit que vous le voulez ; cela ne fait que rendre les calculs
plus complexes. Construisez vos parts comme avant, sauf qu’au lieu d ’utiliser 1,2,3,...,n
pour les Xi, vous choisirez des nombres aléatoires entre 1 et p — 1 pour les Xi.
Maintenant si Martin s’introduit subrepticement dans la réunion de reconstruction
du secret avec sa fausse part, celle-ci a une forte probabilité de ne pas être valide.
Un secret impossible est, bien sûr, un secret contrefait. Voyez [1537] pour les détails
mathématiques.
Malheureusement, au moment où Martin est confondu comme tricheur, il apprend
quand même le secret (en faisant l’hypothèse qu’il y a m autres parts valides). Un
autre protocole, décrit dans [1537, 987], évite cela. L’idée de base est d’avoir une suite
de k secrets telle qu’aucun des participants ne sache d’avance quel est le bon secret.
Chaque secret est plus grand que le précédent, sauf pour le vrai secret. Les participants
combinent leurs parts pour engendrer les secrets les uns après les autres, jusqu’à ce
qu’ils créent un secret qui soit inférieur au secret précédent. C ’est le bon.
Ce schéma dévoilera les tricheurs tôt dans le processus, avant que le vrai secret ne soit
révélé. Il y a des complications quand les participants dévoilent leurs parts une par une ;
voyez les articles pour les détails. D ’autres articles sur la détection et les préventions
de la tricherie dans les schémas à seuil sont dans [359, 124, 274],
23.3 Canal subliminal

Ong—Schnorr—Shamir
Ce canal subliminal (voir § 4.2), conçu par Gustavus S im m o n s [1464, 1465, 1467],
utilise le schéma d ’identification O n g - S c h n o r r - S h a m ir (voir § 20.5). Comme dans
le schéma original, l’expéditeur (Alice) choisit un module public n et une clef privée
k telle que n et k soient premiers entre eux. Contrairement au schéma original, k est
partagé entre Alice et Bernard, le destinataire du message subliminal.
La clef publique est calculée de la même façon :
h = —k ~ 2 mod n.
Si Alice veut envoyer un message subliminal A4 au moyen du message inoffensif A4',

elle vérifie d ’abord que A4' et n sont premiers entre eux et que A4 et n sont premiers
entre eux.
Alice calcule :
51 = 1/2 x {AA' f A4 + M ) mod n

5 2 = k /2 x {A4'/A i - A4) mod n.
La paire 5 j et S 2 est à la fois la signature du schéma O n g - S c h n o r r -S h a m ir tradi

tionnel et le porteur du message subliminal.
Gatien, le gardien de prison, peut vérifier l’authenticité du message comme décrit par
le schéma de signature O n g -Sc h n o r r —S h a m ir mais Bernard peut faire mieux. Il
peut vérifier l’authenticité du message (il est toujours possible que Gatien introduise
ses propres messages). Il peut vérifier que:
(Sf — S ^/k2) = A4' (mod n).
Si le message est authentique, le destinataire peut récupérer le message subliminal en

utilisant la formule :
AA = M '/{ S i + S i k - 1) mod n.
C ela m arche, mais rappelez-vou s que le schém a O n g - S c h n o r r —SHAMIR a été cassé.
ElGamal
Le deuxième canal subliminal de S im m o n s [1465], décrit dans [1412, 1477], est basé
sur le schéma de signature E l G a m a l (voir § 19.6).
La génération de clef est la même que pour le schéma de signature E l G a m a l de base.
Choisissez d’abord un nombre premier p et deux nombres aléatoires g et r tels que g
et r soient tous deux inférieurs à p. Ensuite calculez :
K = gr m o d p.
La clef publique est constituée de K , g et p. La clef privée est r. En dehors d’Alice,

Bernard connaît aussi r ; c ’est la clef qui est utilisée pour envoyer et lire le message
subliminal, en plus d ’être la clef utilisée pour signer le message inoffensif.
23.3 Canal subliminal 561
Pour envoyer un message subliminal A4, en utilisant un message inoffensif A4', A4’ , A4
et p doivent être premiers entre eux deux à deux, et AA et p — 1 doivent être premiers
entre eux. Alice calcule :
X = gM m od p
et résout l ’éq u ation suivante par ra p p ort à F (à l ’aide de l ’algoritlune d ’EuCLlDE) :
A4' = (r X + M Y ) mod (p - 1).
Comme dans le schéma E l G a m a l de base, la signature est la paire X et Y .

Gatien peut vérifier la signature E l G a m a l . Il vérifie que :
K x X Y mod p = gM (mod p).
Bernard peut reconstruire le message subliminal. Il vérifie tout d’abord que :
(gr)x X Y mod p = gM (mod p).
Si tel est le cas, il accepte alors le message comme licite (ce n’est pas un message de
Gatien).
Ensuite, pour reconstruire A4, il calcule:
A4 — Y ~ 1 (A4' — r X ) mod (p — 1).
Par exemple, soit p — 11 et g = 2. La, clef privée r choisie vaut 8. Cela signifie que la clef
publique, que Gatien utilise pour vérifier la signature, vaut gr mod p = 28 mod 11 = 3.
Pour envoyer le message subliminal, A4 = 9, en utilisant le message inoffensif A4' = 5,
Alice vérifie que 9 et 11 sont premiers entre eux et que 5 et 11 sont premiers entre eux.
Elle vérifie également que 9 et 11 — 1 sont premiers entre eux. Ils le sont, donc elle
calcule :
X = gM mod p = 29 mod 11 - 6.
Ensuite, elle résout l’équation suivante par rapport à Y :
5 = ( 8 x 6 + 9 x F ) mod 10.
Ce qui donne F = 3, donc la signature est constituée de la paire: X et F : 6 et 3.

Bernard vérifie que :
( gr)x X Y mod p = gM ' (mod p)

(28)663 mod 11 = 25 (mod 11).
Tel est le cas, donc il récupère le message subliminal en calculant :
A4 = Y ~ 1 (A4' — r X ) mod (p — 1) = 3"_1(5 — 8 x 6 ) mod 10

= ( 7 x 7 ) mod 10 — 49 mod 10 = 9.
ESIGN
Un canal subliminal peut être ajouté à ESIGN [1467] (voir § 20.6).
Pour ESIGN, la clef privée est une paire de grands nombres premiers, p et q, et la clef
publique est n = p 2 q. Avec un canal subliminal, la clef privée est constituée de trois
nombres premiers p, q et r, et la clef publique n est telle que :
n — p 2 qr.
La variable r est l’information supplémentaire dont Bernard a besoin pour lire le mes
sage subliminal.
Pour signer un message normal, Alice choisit d ’abord un nombre aléatoire x inférieur
à pqr et calcule :
w, qui est le plus petit entier plus grand que ( H (m ) — x k m od n)/pqr

s — x + (( w /k x k~ *) mod p)pqr .
H (m ) est l’empreinte du message; k est le paramètre de sécurité. La valeur s est la

signature.
Pour vérifier la signature, Bernard calcule sk mod n. Il calcule aussi a, le plus petit
entier plus grand que le nombre de bits de n divisé par 3. Si H(m ) est plus petit ou
égal à sk mod n, et si sk mod n est plus petit que H (m ) + 2“ , alors la signature est
considérée comme valide
Pour envoyer un message subliminal AA en utilisant un message inoffensif A4', Alice
calcule s en utilisant A4 au lieu de H(m ). Cela signifie que le message doit être plus
petit que p 2qr. Elle choisit ensuite une valeur aléatoire u et elle calcule :
x' — A4' + ur.
Ensuite, elle utilise cette valeur x' comme le « nombre aléatoire » x pour signer A4'.
Cette deuxième valeur de s est envoyée comme la signature.
Gatien vérifie que s (le deuxième s) est une signature valide de AA'.
Bernard peut aussi vérifier l’authenticité du message de la même manière. Mais comme
il connaît également r, il peut calculer :
s = x' + ypqr — A4 + ur + ypqr = A4 (mod r).
Cette réalisation d’un canal subliminal est bien meilleure que les deux précédentes.
Dans les réalisation de O n g - S c h n o r r S h a m ir et dans E l G a m a l , Bernard dispose de
la clef privée d’Alice. En dehors du fait que Bernard peut lire les messages subliminaux
d’Alice, il peut aussi se faire passer pour Alice et signer des documents à sa place. Alice
ne peut rien y faire ; sa confiance en Bernard est nécessaire pour mettre en place ce
canal subliminal.
Le schéma ESIGN ne présente pas de ce défaut. La clef privée d’Alice est l’ensemble
des trois nombres premiers p, q et r. La clef secrète de Bernard est seulement constituée
de r. Il connaît n = p2 qr, mais pour récupérer p et q, il doit factoriser ce nombre. Si
les nombres premiers sont assez grands, Bernard a autant de difficulté à se faire passer
pour Alice que Gatien, ou que toute autre personne.
23.3 Canal subliminal 563
DSA
Il y a aussi un canal subliminal dans le D SA (voir § 20.1) [1475, 1478, 1477]. En fait,
il y en a plusieurs. Le canal subliminal le plus simple comprend le choix de k, qui est
censé être un nombre aléatoire de 160 bits. Toutefois, si Alice choisit un k particulier,
alors Bernard, qui connaît également la clef privée d ’Aüce, peut reconstruire k. Alice
peut envoyer à Bernard un message subliminal de 160 bits dans chaque signature
DSA. Toute autre personne peut seulement vérifier la signature. Ce n’est pas si simple.
Puisque k doit être aléatoire, Alice et Bernard doivent partager un masque jetable et
chiffrer le message subliminal avec le masque jetable pour engendrer k.
Il existe des canaux subliminaux dans le D SA qui ne nécessitent pas que Bernard
connaisse la clef privée d’Alice. Ils impliquent également le choix de valeurs particu
lières pour k mais ils ne permettent pas de transmettre 160 bits d ’information. Le
schéma suivant, présenté dans [1475, 1478], permet à Alice et Bernard d’échanger un
bit d’information subliminale par message signé :
1° Alice et Bernard se mettent d’accord sur un nombre premier aléatoire P (dif

férent du paramètre p du schéma de signature). C ’est leur clef secrète pour le
canal subliminal.
2° Alice signe un message inojfensif A i . Si elle veut envoyer à Bernard un bit

subliminal à 1, elle s ’assure que le paramètre r de la signature soit un résidu
quadratique modulo P. Si elle veut lui envoyer un bit subliminal à 0, elle s ’as
sure que le paramètre r ne soit pas un résidu quadratique modulo P. Elle réalise
cela en signant le message avec des valeurs aléatoires de k jusqu’à ce qu’elle
obtienne une signature où r a la bonne propriété. Comme les résidus quadra
tiques et les résidus non quadratiques sont équiprobnbles, cela ne sera pas trop
difficile.
3° Alice envoie le message signé à Bernard.
4° Bernard vérifie la signature pour s ’assurer de l ’authenticité du message.

Ensuite, il vérifie si r est un résidu quadratique ou non modulo P et récupère
ainsi le bit subliminal.
Il existe des moyens d’envoyer plusieurs bits par cette méthode qui implique le fait de
rendre r résidu quadratique ou non d’un ensemble de paramètres. Voyez [1475, 1478]
pour plus de détails.
Ce schéma peut être facilement étendu pour envoyer plusieurs bits subliminaux par
signature. Si Alice et Bernard se mettent d’accord sur deux nombres premiers P et
Q, Alice peut envoyer deux bits en choisissant un k aléatoire tel que r soit un résidu
quadratique ou non modulo P et tel que r soit un résidu quadratique ou non modulo
Q. Une valeur aléatoire de k a 25 % de chances de produire un r de la bonne forme.
Voici comment Martin, un réalisateur peu scrupuleux du DSS, peut arranger la fuite
de 10 bits de la clef privée d ’Alice par document qu’Alice signe :
1° Martin met sa réalisation du DSS dans une puce VLSI résistante à l’investiga
tion en sorte que personne ne puisse en examiner le fonctionnement. Il crée un
canal subliminal de 14 bits dans sa réalisation du DSS. Pour ce faire, il choisit
14 nombres premiers, et la puce choisit la valeur k telle que r soit ou ne soit
pas un résidu quadratique modulo chacun des nombres premiers en fonction du

message subliminal.
2° Martin distribue ses puces à Alice, Bernard, et toute autre personne qui en
veut.
3° Alice signe un message normalement en utilisant sa clef privée de 160 bits y.
4° La puce choisit aléatoirement un bloc de 10 bits de y : les premiers 10 bits, le
second groupe de 10 bits, etc. Comme il y a 16 blocs possibles de 10 bits, un
nombre de 4 bits permet d’identifier de quel bloc il s ’agit. Cet identificateur de
4 bits plus les 10 bits de la clef forment le message subliminal de 14 bits.
5° La puce essaie des valeurs aléatoires de k jusqu’à ce qu’elle en trouve une
avec les bonnes propriétés de résidus quadratiques pour envoyer le message
subliminal. Les chances qu’un k soit correct sont de 1 contre 16384. En faisant
l’hypothèse que la puce peut tester 10000 valeurs k par seconde, cela prendra
moins de 2 secondes pour en trouver une. Ce calcul n’implique pas le message
et peut être effectué hors ligne, avant qu’Alice ne veuille signer un message.
6° La puce signe le message normalement en utilisant la valeur k choisie à
l’étape 5.
7° Alice envoie sa signature numérique à Bernard ou la publie sur le réseau ou
par tout autre moyen.
8° Martin récupère r et, comme il connaît les 14 nombres premiers, il déchiffre le
message subliminal.
Ce qui est effrayant, c ’est que même si Alice sait que cela se produit, elle ne peut pas
le prouver. Tant que les 14 nombres premiers restent secrets, Martin est à l’abri.
Comment boucher le canal subliminal du DSA

L’existence du canal repose sur le fait qu’Alice peut choisir k pour envoyer le message
subliminal. Pour boucher le canal, il ne faut interdire à Alice de choisir k. Il faut aussi
l’interdire à tout autre personne, qui pourrait imiter la signature d ’Alice si elle pouvait
choisir k. La seule solution consiste à amener Alice à générer k conjointement avec une
autre personne, appelons la Bernard, sans qu’Alice puisse contrôler un seul bit de k et
sans que Bernard puisse connaître un seul bit de k. A la fin du protocole, Bernard doit
pouvoir vérifier qu’Alice a bien utilisé le k qu’ils ont généré ensemble.
Voici le protocole [1474, 1476, 1477] :
1° Alice choisit k' et envoie à Bernard :
u = gk mod p
2° Bernard choisit k" et l ’envoie à Alice.

3° A lice calcule k — k'k" mod (p — 1). Elle utilise k pour signer son message M
avec le D SA et envoie à Bernard la signature: r et s.
4° Bernard vérifie que
(( uk mod p) mod q) = r.
Si c ’est le cas, il sait que k a servi à signer AA.
23.f Signatures numériques incontestables 565
Après l’étape 4, Bernard sait que r ne contient aucune information subliminale. S’il
sert de personne de confiance, il peut certifier que la signature d ’Alice ne contient pas
de message subliminal. Les autres doivent croire ce certificat; Bernard ne peut pas
prouver ce fait à une troisième personne avec une transscription du protocole.
Cela donne un résultat surprenant : si Bernard le veut, il peut utiliser ce protocole
pour créer son propre canal subliminal. Bernard peut insérer un message subliminal
dans une des signature d ’Alice en choisissant un k vérifiant certaines caractéristiques.
Quand S im m o n s a découvert cela, il l’a appelé le « canal du coucou ». Les détails du
fonctionnement du canal du coucou, et un protocole à trois passes de génération de k,
qui l’évite, sont décrits dans [1479, 1477].
Autres schémas
Il existe un autre schéma de signature dans lequel on peut cacher un canal sublimi
nal [1464, 1467,1411]. Un protocole pour cacher un canal subliminal dans les protocoles
F ia t - S h a m ir et F ia t - F e ig e - S h a m ir , ainsi que les abus possibles à l’aide de ce canal
sont décrits dans [483]
23.4 Signatures numériques incontestables

Cet algorithme de signature incontestable (voir § 4.3) est dû à David C h a u m [338, 332].
Au départ, un grand nombre premier p et un élément primitif g sont rendus publics
et utilisés par un groupe de signataires. Alice a une clef privée x et une clef publique
gx mod p.
Pour signer un message, Alice calcule z — m x mod p. C ’est tout ce qu’elle doit faire.
La vérification est un petit peu plus compliquée :
1° Bernard choisit deux nombres aléatoires a et b tous deux inférieurs àp et envoie

à Alice :
c = za(gx)h mod p.
2° Alice calcule a:-1 mod (p — 1) et envoie à Bernard:
d — cx mod p.
3° Bernard vérifie que :

d ~ magb (mod p).
Si tel est le cas, il accepte la signature comme valide.
Imaginez qu’Alice et Bernard ayant effectué ce protocole, Bernard est convaincu

qu’Alice a signé le document et il veut en convaincre Christine. Il montre à Christine
une transcription du protocole. David veut convaincre Christine que quelqu’un d ’autre
a signé ce document. Il crée une fausse transcription du protocole. Il engendre le mes
sage de l’étape 1 . Ensuite, il effectue les calculs de l’étape 3 pour engendrer d et la
fausse transmission venant de l’autre personne à l’étape 2. Enfin, il crée le message de
l’étape 2. Pour Christine, les transcriptions de Bernard et de David sont toutes deux
identiques. Elle ne peut pas être convaincue de la validité de la signature, à moins
d’effectuer le protocole par elle-même.
Bien sûr, si elle avait regardé par dessus l’épaule de Bernard pendant l’exécution du
protocole, elle aurait été convaincue. Christine doit voir les étapes exécutées dans le
bon ordre, tout comme Bernard.
Il peut y avoir un problème avec ce protocole de signature, mais je ne connais aucun
détail. Je vous prie de consulter la littérature avant de l’utiliser.
Un autre protocole offre non seulement le moyen pour Alice de convaincre Bernard
de la validité de sa signature, mais il permet aussi à Alice de convaincre Bernard que
sa signature n’est pas valide si tel est le cas, et ce à l’aide d ’un protocole interactif à
divulgation nulle [335].
Tout comme pour le protocole précédent, un grand nombre premier p et un élément
primitif g sont rendus publics et utilisés par un groupe de signataires. Alice dispose
d’une clef privée x et d ’une clef publique gx mod p. Pour signer un message Alice
calcule z = m æ mod p.
Pour vérifier la signature :
1° Bernard choisit deux nombres aléatoires a et b tous deux inférieurs àp et envoie
à Alice:
c - m agb m od p.
2° Alice choisit un nombre aléatoire q inférieur àp, calcule et envoie à Bernard:
si = ( e x gq) mod p , S2 — (c x gq)æ mod p.
3 ° Bernard envoie a et b à Alice afin qu ’elle puisse vérifier qu ’il n’a pas triché à
l’étape 1 .
4° Alice envoie q à Bernard, de telle manière qu’il puisse utiliser m x et recons
truire S\ et S2 - Si:
Si — ( e x gq) m od p
s2 = ((<?æ) 6 + 9 x za) mod p ,
alors la signature est valide.
Alice peut également désavouer sa signature z pour un message m. Voyez [335] pour
les détails.
D’autres protocoles de signatures incontestables sont décrits dans [586, 348]. Lein H a r n
et Shoubao Y a n g ont proposé un schéma de signature incontestable en groupe [701].
Signatures incontestables convertibles

Un algorithme pour une s i g n a t u r e i n c o n t e s t a b l e c o n v e r t i b l e , qui peut être vérifiée,
désavouée et également convertie en signature numérique conventionnelle est donné
par [216]. Il est basé sur l’algorithme de signature numérique E l G a m a l .
Tout comme pour E l G a m a l , choisissez deux nombres premiers p e t q tels que q divise
p — 1. Maintenant, vous devez créer un nombre g inférieur à q. Choisissez un nombre
aléatoire h entre 2 et p — 1 , puis calculez :
g = h{p~ 1)' q mod p.
Si g vaut 1, choisissez un autre nombre aléatoire h. Sinon, gardez le g obtenu.

23.5 Signatures numériques à vérificateur dédié 567
La clef privée est composée de deux nombres aléatoires différents x et z, tous deux
inférieurs à q. La clef publique est constituée de p, q, g, y et u, où :
y = gx mod p,
u = gz mod p.
Pour calculer la signature incontestable convertible du message m (qui est en fait

l’empreinte d’un message), choisissez d’abord un nombre aléatoire t entre 1 et q — 1.
Ensuite, calculez :
T = (fi mod p
et
m ' = T tzm mod q.
Maintenant, calculez la signature E l G a m a l standard de m'. Choisissez un nombre

aléatoire R inférieur à (p — 1) et premier par rapport à p — 1. Ensuite calculez r =
gR mod p et utilisez l’algorithme d ’EuCLlDE étendu pour calculer s tel que :
m ' = (rx + Rs) (mod q).
La signature est constituée de la signature E l G a m a l (r,s) et de T.

Voici comment Alice vérifie la signature de Bernard :
1° Bernard engendre deux nombres aléatoires a et b. Il calcule c = T Tmagb mod p

et envoie le résultat à Alice.
2° Alice engendre un nombre aléatoire k et calcule hi = cgk mod p et h-2 = h\ mod

p puis les envoie tous deux à Bernard.
3° Bernard envoie a et b à Alice.

4° Alice vérifie que c = T Tmagh mod p. Elle envoie k à Bernard.
5° Bernard vérifie que h\ = T Jrnagb 1k mod p et que h2 = yrarsauh+k mod p.
Alice peut convertir toutes ses signatures incontestables en signatures normales, en

publiant z. Maintenant tout le monde peut vérifier sa signature sans son aide.
Les schémas de signature incontestable combinés avec les schémas de partage de secret
permettent de créer des s i g n a t u r e s i n c o n t e s t a b l e s c o n v e r t i b l e s r é p a r t i e s [1245].
Une personne peut signer des messages et ensuite répartir la capacité de vérifier si
la signature est valide. Elle peut, par exemple, rendre nécessaire la coopération de
trois personnes parmi cinq pour convaincre Bernard que la signature est valide. Des
améliorations de cette notion permettent de se passer de la participation d’une autorité
de confiance [701, 1371],
23.5 Signatures numériques à vérificateur

dédié
Voici comment il est possible qu’Alice signe un message et Bernard le vérifie, de sorte
que Christine puisse prouver plus tard à David la validité de 1a, signature d ’Alice (voir
§ 4.4) [337].
Tout d’abord, un grand nombre premier p et un élément primitif g sont rendus publics
et utilisés par un groupe d’utilisateurs. Le produit n de deux nombres premiers est aussi
rendu public. Christine possède une clef privée z et une clef publique h = gx mod p.
Dans le protocole qui suit, Alice peut signer A4 en convaincant Bernard de la validité
de celle-ci, mais sans qu’il puisse lui-même convaincre une troisième personne de ce
fait.
1° Alice choisit un nombre aléatoire x et calcule :
a = gæ mod p
b = hx mod p.
Elle calcule l’empreinte H {Ai) de Ai et celle de a et b juxtaposés, H{a,b). Elle

calcule alors:
j = {H ( Ai) © H (o , 6 ) ) 1 / 3 mod n,
et envoie a, b et j à Bernard.
2° Bernard choisit deux nombres aléatoires s et t inférieurs à p et envoie à Alice :
c = gshf mod p.
3° Alice choisit un nombre aléatoire q inférieur à p et envoie à Bernard :
d = gq mod p
e = (cd)x mod p.
4° Bernard envoie s et t à Alice.

5° Alice vérifie si
gshl = c (mod p),
et envoie q à Bernard.
6° Bernard vérifie si
d ~ g q (mod p)
e /a 9 = asbt (mod p)
H { Ai) © H(a,b) = j 1 / 3 (mod n).
Si les trois équivalences sont vraies, il est convaincu de l’authenticité de la

signature.
Bernard ne pourra pas convaincre David de l’authenticité de la signature d’Alice avec

une transcription de la preuve ci-dessus; mais David peut mener un protocole avec
Christine, le vérificateur dédié d’Alice. Voici comment Christine convaint David de la
validité de la signature constituée de a et b :
1° David choisit deux nombres aléatoires u et v inférieurs à p et envoie à

Christine :
k — guav m od p.
23.6 Calcul avec données chiffrées 569
2° Christine choisit un nombre aléatoire w inférieur à p et envoie à David :
l — gw mod p
y - ( kl)z m od p.
3° David envoie u et v à Christine.

4 ° Christine vérifie si
guav = k (mod p).
Elle envoie ensuite w à David.

5° David vérifie si
gw = 1 (mod p) y /h w = hubv (mod p).
Si les deux équivalences sont vraies, il est convaincu de Vauthenticité de la

signature.
Dans un autre protocole, Christine peut convertir le protocole de signature à vérifica

teur dédié en un protocole de signature numérique conventionnel. Consultez [337] pour
les détails.
23.6 Calcul avec données chiffrées

Le problème du logarithme discret
Il y a un grand nombre premier p et un générateur g. Alice dispose d ’une valeur
particulière pour x et veut connaître e tel que :
ge = x (mod p).
Ceci est normalement un problème difficile et Alice n ’a pas la puissance de calcul né
cessaire pour trouver le résultat. Bernard dispose de la puissance de calcul nécessaire
— disons qu’il travaille pour le gouvernement, par exemple, ou dans une grande or
ganisation informatique. Voici comment Alice peut lui laisser faire les calculs sans lui
révéler x [549, 8 ] :
1° Alice choisit un nombre aléatoire r inférieur à p.
2 ° Elle calcule:
x' = xgr mod p.
3° Elle demande à Bernard de résoudre :
ge = x' (mod p).
4° Bernard calcule e1 et l’envoie à Alice.

5° Alice retrouve e en calculant:
e = (e1 — r) mod (p — 1 ).
Il existe des protocoles similaires pour le problème des résidus quadratiques et pour le
problème des racines primitives [7, 8 ]. (Voyez aussi § 4.8.)
23.7 Pile ou face équitable

Le protocole suivant permet à Alice et Bernard de jouer à pile ou face via un réseau de
communication (voir § 4.9) [201]. C ’est un exemple du lancement d ’une pièce dans un
puits (voir § 4.10). En premier lieu, seul Bernard connaît le résultat du lancer et il le
dit à Alice. Plus tard, Alice peut vérifier que Bernard lui a indiqué une valeur correcte
du résultat du lancer.
Pile ou face à l’aide de racines carrées

Sous-protocole de tirage à pile ou face :
1° Alice choisit deux grands nombres premiers p et q et envoie leur produit n à

Bernard.
2° Bernard choisit un nombre entier positif aléatoire r inférieur ou égal à n/2,

puis calcule:
z = r 2 mod n
et envoie z à Alice.
3° Alice calcule les quatre racines carrées de z modulo n. Elle peut le faire parce
qu’elle connaît la factorisation de n. Appelons les + x , —x , + y et —y. Appelons
x' le plus petit des deux nombres :
x mod n
—x m od n.
De même, appelons y' le plus petit des deux nombres :
y mod n
—y mod n.
Remarquez que r est soit égal à x' soit à y1.
4° Alice parie sur r — x' ou r = y' et envoie son pari à Bernard.
5° Si le pari d’Alice est correct, le résultat du lancer est « face », si son pari est
faux, le résultat du lancer est « pile ». Bernard annonce le résultat du lancer.
Sous-protocole de vérification :
6° Bernard envoie r à Alice.
Alice n’a aucun moyen de connaître r et son pari est réel. À l’étape 4, elle ne donne à
Bernard que 1 bit de son pari (un bit où x' et y' diffèrent) pour éviter qu’il n’ait à la
fois x' et y'. Si Bernard avait les deux nombres, il pourrait changer r après l’étape 4.
23.7 Pile ou face équitable 571
Pile ou face à l’aide de l’exponentiation modulo p

L’exponentiation modulo un nombre premier p est utilisée comme fonction à sens
unique dans le protocole suivant [1317].
Sous-protocole de tirage à pile ou face :
1° Alice choisit un nombre premier p de telle manière que la factorisation de p — 1

soit connue et contienne au moins un grand nombre premier.
2° Bernard choisit deux éléments primitifs h et t dans Z /p . Il les envoie à Alice.

3° Alice vérifie que h et t sont primitifs et choisit un nombre aléatoire x premier
par rapport à p — 1. Elle calcule ensuite l’une des deux valeurs :
y = hx m od p ou y — tx mod p.
Elle envoie y à Bernard.
4° Bernard parie si y est une fonction de h ou de t et envoie son pari à Alice.
5 ° Si le pari de Bernard est correct, le résultat du lancer est « face ». Si le pari

de Bernard est faux, le résultat du lancer est « pile ». Alice annonce le résultat
du lancer.
Sous-protocole de vérification :
6° Alice révèle x à Bernard qui calcule hx mod p et tx mod p à la fois pour vérifier
qu 'Alice a joué honnêtement et pour vérifier le résultat du lancer. Il vérifie aussi
que x et p — 1 sont premier entre eux.
Pour tricher, Alice doit trouver deux entiers x et x' tels que hx = tx' (mod p). Si elle
connaissait de telles valeurs, elle pourrait calculer :
logt h — x 'x ^ 1 mod (p — 1 ) et log^ t = xx 1
Ce sont des problèmes difficiles.

Alice serait capable de faire cela si elle connaissait logt h mais c’est Bernard qui a choisi
h et t h l’étape 2. Alice n’a pas d ’autre recours que d ’essayer de calculer le logarithme
discret. Alice pourrait aussi tenter de tricher en choisissant un x qui ne soit pas premier
par rapport à p — 1 mais Bernard le détecterait à l’étape 6 .
Bernard peut tricher si h et t ne sont pas primitifs dans Z /p mais Alice peut facilement
le vérifier après l’étape 2 , car elle connaît la factorisation en nombres premiers de p —1 .
L’avantage de ce protocole est que si Alice et Bernard veulent jouer plusieurs fois à pile
ou face, ils peuvent utiliser les mêmes valeurs de p, h et t. Alice doit juste engendrer
un nouvel x et le protocole continue à partir de l’étape 3.
Pile ou face à l’aide d’entiers de B lum

Les entiers de B l u m peuvent être utilisés pour un protocole de tirage à pile ou face :
1° Alice engendre un entier de B lu m n, un nombre aléatoire x premier par rapport

à n , x o = x 2 mod n et x i = x 2 mod n. Elle envoie n et x\ à Bernard.
2° Bernard parie sur la parité de xq.

3 ° Alice envoie x et xq à Bernard.
4 ° Bernard vérifie que n est bien un entier de B l u m 1, et il vérifie que xq =

x 2 mod n et que X\ = x\ mod n. Si toutes les vérifications sont correctes et si
son pari est correct, Bernard gagne le jeu.
Il est crucial que n soit un entier de B l u m . Sinon, Alice pourrait trouver un x'q tel
que x'o 2 mod n — xq2 mod n = aq, où x'q est également un résidu quadratique. Si Xq
était pair et x '0 impair (ou vice versa), Alice pourrait tricher librement.
23.8 Accumulateurs à sens unique

Il existe une fonctin d ’accumulateur à sens unique simple (voir § 4.12) [126] :
A(xi,y) = z f - i mod n
où n est le produit de deux nombres premiers.

Les nombres n et æo doivent être choisis à l’avance d’un commun accord.
L’accumulation de y \, ?/2 et jfy est alors donnée par :
((xq 1 mod n )V2 mod n)ya m od n
Ce calcul dépend de l’ordre de j/i, ?y2 et 2/3 .
23.9 Divulgation tout ou rien de secrets

Ce protocole permet à plusieurs participants (deux participants au moins sont néces
saires pour que le protocole marche) d ’acheter des secrets individuels à un seul et même
vendeur (voir § 4.13) [1376, 1181]. Tout d ’abord, voici la définition. Prenez deux chaînes
de bits x et y. L ’i n d e x d e b i t s i d e n t i q u e s (abrégé IBI) de a: et y est composé des
indices i de bits tels que le ie bit de x soit égal au ie bit de y.
Par exemple :
x = 110101001011
y = 101010000110
IBI(a;,t/) = { 1 ,4 ,5 ,1 1 }. (Nous lisons les bits de droite à gauche avec l’indice
le plus à droite valant 0 .)
Voici maintenant le protocole. Alice est le vendeur. Bernard et Christine sont les ache
teurs. Alice dispose de k secrets de n bits : S i, S2, ..., S*. Bernard veut acheter le secret
Sb et Christine veut acheter le secret Sc.
1° Alice engendre un paire « clef privée-clef publique » et donne la clef publique

à Bernard (mais pas à Christine).
Alice engendre une autre paire « clef privée-clef publique » et donne la clef
publique à Christine (mais pas à Bernard).
1. A lice doit donner à Bernard les facteurs d e n ou exécuter un p rotocole à divulgation nulle pou r
le convaincre qu ’ il s’ agit bien d ’un entier de B lu m .
23.9 Divulgation tout ou rien de secrets 573
2° Bernard engendre k nombres aléatoires de n bits, B i, D2, ..., B k et les com

munique à Christine.
Christine engendre k nombres aléatoires de n bits, Ci, C 2 , ■■■, Ck et les com
munique à Bernard.
3° Bernard chiffre Cb (rappelez-vous que Sb est le secret qu’il veut acheter) avec
la clef publique d’Alice. Il calcule ZTBI de Cb et du résultat du chiffrement qu’il
vient juste d ’effectuer. Il envoie cet IBI à Christine.
Christine chiffre B c (rappelez-vous que Sc est le secret qu’elle veut acheter) avec
la clef publique d’Alice. Elle calcule /TB [ de B c et du résultat du chiffrement
qu’elle vient juste d’effectuer. Elle envoie cet IBI à Bernard.
4° Bernard prend chacun des nombres de n bits B lr B 2, ..., Bk et remplace chaque

bit qui n’est pas dans ZTBI qu’il a reçu de Christine par son complément. Il
envoie à Alice cette nouvelle liste de nombres de n bits B \ , B ' 2 , ■■■, B'k-
Christine prend chacun des nombres den bits C i, C2, ..., Ck et remplace chaque
bit qui n’est pas dans ZTBI qu’elle a reçu de Bernard par son complément. Elle
envoie à Alice cette nouvelle liste de nombres de n bits C 'i, C ' 2 , C'k-
5° Alice déchiffre tous les C'i avec sa clef privée associée à la clef publique qu’elle
a donnée à Bernard, ce qui lui donne k nombres de n bits: C " C " 2, ..., C"k-
Elle calcule Si © C "i pour i = 1 à k et envoie les résultats à Bernard.
Alice déchiffre tous les B'i avec sa clef privée associée à la clef publique qu’elle
a donnée à Christine, ce qui lui donne k nombres de n bits: B " 1 , B " 2 ,
B " k■ Elle calcule Si © B "i pour i — 1 à fc et envoie les résultats à Christine.
6° Bernard calcule Sb en combinant par ou exclusif Cb avec le be nombre qu’il a

reçu d’Alice.
Christine calcule Sc en combinant par ou exclusif B c avec le ce nombre qu’elle
a reçu d’Alice.
C’est assez compliqué. Un exemple va clarifier tout ça.

Alice a les 8 secrets suivants de 12 bits : Si = 1990, S2 = 471, S 3 = 3860, S 4 = 1487,
S5 — 2235, S 6 = 3751, S 7 = 2546 et S8 = 4043. Bernard veut acheter S 7 et Christine
veut acheter S2.
1° Alice utilise l’algorithme R SA .

La paire de clefs qu’elle va utiliser avec Bernard est n = 7387, e = 5145 et
d = 777.
La paire de clefs qu’elle va utiliser avec Christine est n = 2747, e = 1421 et
d = 2261. Elle donne à Bernard et à Christine leur clef publique respective.
2° Bernard engendre 8 nombres aléatoires de 12 bits: Bi = 743, B2 = 1988,

£ 3 = 4001, S 4 = 2942, £ 5 = 3421, £ 6 = 2210, £ 7 = 2306 et £ 8 = 222 'et les
communique à Christine.
Christine engendre 8 nombres aléatoires de 12 bits: Ci — 1708, C 2 = 711,
C 3 = 1969, C4 = 3112, C 5 = 4014, C 6 = 2308, C 7 = 2212 et C 8 = 222 et les
communique à Bernard.
Chapitre 23 Algorithmes spéciaux pour protocoles
3° Bernard veut acheter S 7 et donc il chiffre C 7 avec la clef publique qu’Alice lui
a donnée:
22125145 m o d 7387 = 5928.
Maintenant :
2212 = OIOOOIOIOOIOO
5928 = 1011100101000.
Et donc /I B I de ces deux nombres est {0,1,4,5,6}. E l’envoie à Christine.

Christine veut acheter S2 , donc elle chiffre B 2 avec la clef publique qu’Alice
lui a donnée et calcule l IB I de B 2 avec le résultat du chiffrement. Elle envoie
{0,1, 2,6,9,10} à Bernard.
4° Bernard prend B\, B2, ..., Bg et remplace chaque bit dont l’indice n’est pas
dans {0,1,2,6,9,10} par son complément. Par exemple :
B 2 = 111111000100 = 1988
B '2 = 011001111100 = 1660.
E envoie B \ , B '2, ..., B'g à Alice.

Christine prend C i, C2, ..., Cg et remplace chaque bit dont l’indice n’est pas
dans {0,1,4,5,6} par son complément. Par exemple:
C 7 = OIOOOIOIOOIOO = 2212
C '7 = 1011100101000 = 5928.
Elle envoie C \ , C '2, ..., C'g à Alice.
5° Alice déchiffre tous les C \ avec la clef privée associée à Bernard et combine les
résultats par ou exclusif avec les S ,. Par exemple pour i = 7 :
5928777 m o d 7387 = 2212 ; 2546 © 2212 = 342.
Elle envoie le résultat à Bernard.

Alice déchiffre tous les B'i avec la clef privée associée à Christine et combine
les résultats par ou exclusif avec les S ,. Par exemple pour i = 2 :
16602261 m o d 2747 = 1988 ; 471 © 1988 = 1555.
Elle envoie le résultat à Christine.
6° Bernard calcule S7 en combinant par ou exclusif C 7 et le I e nombre qu’il a

reçu d’Alice:
2212 © 342 = 2546.
Christine calcule S 2 en combinant par ou exclusif B 2 et le 2e nombre qu’elle

a reçu d’Alice:
1988 © 1555 = 471.
23.10 Cryptosystèmes équitables et à sûreté intégrée 575
Ce protocole marche pour n’importe quel nombre d ’acheteurs. Si Bernard, Christine et

David veulent acheter des secrets, Alice donne à chaque acheteur deux clefs publiques,
une pour chacun des deux autres. Chaque acheteur reçoit un ensemble de nombres
de la part de chaque autre acheteur. Ensuite, ils terminent le protocole avec Alice
pour chacun de leurs ensembles de nombres et ils combinent par ou exclusif tous les
résultats fournis par Alice pour reconstruire leur secret. Plus de détails sont donnés
dans [1376, 1181].
Malheureusement, un couple de participants malhonnêtes peut tricher. Alice et
Christine, en s’alliant, peuvent facilement deviner le secret que Bernard est en train
d’acheter: si elles connaissent l’IBI de Cb et l’algorithme de chiffrement de Bernard,
elles peuvent trouver le b produisant le bon IBI. De plus, Bernard et Christine, en
travaillant ensemble, peuvent facilement tous les secrets d ’Alice.
Si vous supposez les participants honnêtes, voici un protocole plus facile [393] :
1° Alice chiffre tous les secrets avec R S A et les envoie à Bernard:
Ci — Sf mod n.
2° Bernard choisit son secret Cb, tire un nombre aléatoire, et envoie à Alice :
C — Cbre mod n.
3° Alice envoie à Bernard:
AA' — C'd mod n.
4° Bernard calcule:
Sb = A4V-1 inod n.
Si les participants risquent d’être malhonnêtes, Bernard peut faire une preuve à divul
gation de sa connaissance d ’un nombre r tel que C' — Cbre mod n et garder b secret
jusqu’à ce qu’Alice lui donne AA' à l’étape 3 [249].
23.10 Cryptosystèmes équitables et à sû

reté intégrée
Diffie-Hellman équitable
Les cryptosystèmes équitables permet de réaliser le dépôt de clefs en logiciel (voir
§ 4.14). Cet exemple est dû à Silvio M i c a l i [1091, 1090]. Il est breveté [1092, 1093].
Dans le schéma de base D i f f i e - H e l l m a n , un groupe d ’utilisateurs partage un nombre
premier p et un générateur g. La clef privée d ’Alice est s et sa clef publique est t —
gs mod p.
Voici comment rendre D i f f i e - H e l l m a n équitable (cet exemple utilise 5 dépositaires) :
1° Alice choisit 5 nombres entiers S\, S2 , « 3 , «4 et .se, chacun inférieur à p. La

clef privée d’Alice est donnée par :
s = (si + s2 + s3 + 54 + Sb) m od p
et sa clef publique est:

t = gs mod p.
Alice calcule également:
t, = g s* mod p pour i = 1 à 5.
Les parts publiques d’Alice sont les tt et les parts privées sont les s,.
2° Alice envoie une part privée et la part publique correspondante à chaque dépo
sitaire. Par exemple, elle envoie Si et t\ au dépositaire n° 1. Elle envoie t au
CDC.
3° Chaque dépositaire vérifie que:
U = gSx mod p.
Si tel est le cas, le dépositaire signe tt et envoie le résultat au C D C . Le dépo

sitaire stocke st dans un endroit sûr.
4° Après avoir reçu les 5 parts publiques, le C D C vérifie que :
t = (ti x t2 x t3 x t4 x t5) mod p.
Si tel est le cas, le C D C approuve la clef publique.
À ce point, le C D C sait que chaque dépositaire a une part valide et qu’ils peuvent
reconstruire la clef privée si nécessaire. Toutefois, ni le C D C , ni quatre des cinq dépo
sitaires, travaillant ensemble, ne peuvent reconstruire la clef privée d ’Alice.
L ’article de M icali [1091, 1090] contient également une procédure pour rendre le R S A
équitable et pour combiner un schéma à seuil avec un cryptosystème équitable, tel que
m dépositaires parmi n peuvent reconstruire la clef privée.
Diffie-Hellman à sûreté intégrée

Tout comme dans le protocole précédent, un groupe d ’utilisateurs partage un nombre
premier p et un générateur g. La clef privée d’Alice est s, sa clef publique est t =
gs mod p.
1° Le C D C choisit un nombre aléatoire B entre 0 etp —2, et le met en gage selon

un protocole de mise en gage (voir § 4-9).
2° Alice choisit un nombre aléatoire A entre 0 et p — 2. Elle envoie gA mod p au
CDC.
3° Alice partage A entre les dépositaires en utilisant un schéma de secret réparti
vérifiable (voir § 3.7).
4° Le C D C révèle B à Alice.
5 ° Alice vérifie la mise en gage de l’étape 1 . Elle prend alors pour clef publique :
t = gAgB mod p,
et pour clef privée :

s = (A + B) m od (p — 1).
2S.11 Preuves à divulgation nulle 577
Les dépositaires peuvent reconstruire A. Comme le C D C connaît B , c’est assez pour

reconstruire s. De plus, Alice ne peut se servir d’aucun canal subliminal pour envoyer
des informations non autorisées. Ce protocole, qui est décrit dans [957, 834], est en
cours de brevetage.
23.11 Preuves à divulgation nulle

Preuve à divulgation nulle de logarithmes discrets
Patricia veut prouver à Victor qu’elle connaît un x qui satisfait :
Ax = B (mod p)
où p est un nombre premier et x est premier par rapport à p — 1. Les nombres A, B et

p sont publics, et x est secret. Voici comment Patricia peut prouver qu’elle connaît x
sans le révéler (voir § 5.1) [343, 342] :
1° Patricia engendre t nombres aléatoires r i ,r 2 , ..., rt où tous les r, sont inférieurs

àp — 1 .
2° Patricia calcule hi = Ar’ mod p pour toutes les valeurs de i et envoie ceux-ci
à Victor.
3° Patricia et Victor exécutent un protocole de jeu à pile ou face pour engendrer

t bits : bi , 6 2 ,..., ht-
4° Pour tous les t bits, Patricia exécute l ’une des actions :
a . si bi = 0, Patricia envoie ri à Victor ;
h. si bi = 1, Patricia envoie à Victor Si = (r* —rf) mod (p —1), où j est la

plus petite valeur telle que bj — 1.
5 ° Pour tous les t bits, Victor vérifie l’une des deux relations:
a. si bi — 0, il vérifie que A r' = hi (mod p) ;
b .si bi = 1, il vérifie que A 3* = h^hj1 (mod p).
6° Patricia envoie Z à Victor, où :
Z = (x — rj) mod (p — 1).
7° Victor vérifie que :

A z = BhJ 1 (mod p).
La probabilité que Patricia puisse tricher est de 2 ~l.

Preuve à divulgation nulle de la capacité à casser le RSA

Alice connaît la clef privée de Christine. Peut-être a-t-elle cassé le R S A ; peut-être
a-t-elle pénétré par effraction dans la maison de Christine pour voler la clef. Alice veut
convaincre Bernard qu’elle connaît la clef de Christine. Toutefois, elle ne veut pas dire
à Bernard la valeur de cette clef, ni même déchiffrer un des messages de Christine
pour Bernard. Voici un protocole de preuve à divulgation nulle par lequel Alice peut
convaincre Bernard qu’elle connaît la clef privée de Christine [888].
La clef publique de Christine est e. Sa clef privée est d. Le module R SA est n.
1° Alice et Bernard se mettent d’accord sur une paire aléatoire k et m telle que:
km = e (mod n).
Il doivent choisir les nombres aléatoirement, en utilisant un protocole de jeu à

pile ou face pour engendrer k et ensuite calculer m. Si k et m sont tous deux
plus grands que 3, le protocole continue. Sinon, il faut faire un nouveau choix.
2° Alice et Bernard engendrent un texte chiffré aléatoire C. Une fois de plus ils
doivent utiliser un protocole de jeu à pile ou face.
3° Alice, en utilisant la clef privée de Christine, calcule :
A i — Cd mod n.
Ensuite elle calcule:

X = Adk mod n
et envoie X à Bernard.
4° Bernard vérifie que X rn mod n — C. Si tel est le cas, il croit Alice.
Un protocole similaire peut être utilisé pour démontrer la capacité à casser le problème
du logarithme discret [502].
Preuve à divulgation nulle que n est un entier de B l u m

Il n’existe aucune preuve à divulgation nulle vraiment pratique de n = pq avec p et q
premiers et congrus à 3 modulo 4. Mais si vous tolérez que n soit de la forme pTqs, où
r et s sont impairs, alors les propriétés qui rendent les entiers de B l u m intéressants
en cryptographie tiennent toujours, et il existe une preuve à divulgation que n est de
cette forme.
Supposez qu’Alice connaisse la factorisation d’un tel entier n. Voici comment ellepeut
prouver à Bernard que n est de cette forme [1561].
1° Alice envoie à Bernard un nombre dont le symbole de Jacobi vaut —1 modulo n.

2° Alice et Bernard se mettent d’accord sur des bits aléatoires: b\J>2 , . . . ,bk-
3° Ahœ et Bernard se mettent d’accord sur des nombres aléatoires: Xi,X2 , ■■■,Xk-
4° Pour tout i entre 1 et k, Alice envoie à Bernard la racine carrée modulo n d’un
des quatres nombres suivants: x t, —Xi, uxi, —uxi. Le symbole de Jacobi de la
racine carrée doit valoir bi.
Alice a une chance sur 2fe de réussir à tricher.

23.12 Signatures en aveugle 579
23.12 Signatures en aveugle

La notion de signatures en aveugle (voir § 5.3) a été inventée par David C h a u m [322]
qui a également inventé leur première réalisation [322]. Il utilise l’algorithme R SA .
Bernard a une clef publique e, une clef privée d et un module public n. Alice veut que
Bernard signe un message m en aveugle.
1° Alice choisit une valeur aléatoire k comprise entre 1 et n. Ensuite elle camoufle
m en calculant:
t = mke mod n.
2° Bernard signe t :
td -- (mke)d mod n.
3° Alice retire le facteur de camouflage de td en calculant :
s = td/k mod n.
4° Et le résultat est:
s = m d mod n.
Cela peut être aisément montré grâce à :
td = ( mke)d = m dk {mod n), et donc — = m d x — ~ md (m od n).

k k
C h a u m a inventé une fam ille d ’algorithm es de signatures en aveugle plus com pliqués
dans [326, 325]. Ces signatures sont plus com pliquées à construire, m ais elles sont plus
maléables.
23.13 Transfert inconscient

Dans ce protocole, dû à R a b i n [1298], Alice a 50 % de chances d’envoyer à Bernard
deux nombres premiers p et q. Alice ne saura pas si le transfert a réussi ou non (voir
§ 5 .5 ) 2.
1° Alice envoie à Bernard le produit des deux nombres premiers : n = pq.

2° Bernard choisit un nombre aléatoire x inférieur à n tel que x soit premier par
rapport à n. Il envoie à Alice :
a = x 2 m o d n.
3° Alice qui connaît p et q, calcule les quatre racines de a : x, n — x, y et n — y.

Elle choisit l’une de ces racines aléatoirement et l’envoie à Bernard.
4° Si Bernard reçoit y ou n — y, il peut calculer le plus grand commun diviseur de
x + y et n qui est soit p soit q. Ensuite, bien sûr n /p = q .
Si Bernard reçoit x ou n — x , il ne peut rien calculer.
2. Ce protocole peut servir à envoyer avec 50 % de chances n’importe quel message, si p et q révèlent
une clef privée RSA.
Ce protocole présente éventuellement une faiblesse : il se peut que Bernard puisse cal
culer un nombre a tel qu’une racine carrée de a permette de factoriser n dans tous les
cas.

Le protocole suivant est décrit dans [1375]. Alice connaît un entier i ; Bernard connaît
l’entier j . Alice et Bernard, ensemble, veulent savoir si i < j ou si i > j , mais ni Alice
ni Bernard ne veulent révéler leur entier à l’autre. Ce cas spécial de calcul réparti sûr
(voir § 6.2) est parfois connu sous le nom de p ro b lè m e d u m illionnaire d e Y ao
[1629],
Pour cet exemple, faites l’hypothèse que i et j sont compris dans l’intervalle de 1 à
100. Bernard a une clef publique et une clef privée.
1° Alice choisit un grand nombre aléatoire x et le chiffre avec la clef publique de

Bernard :
c = E b {x ).
2° Alice calcule c — i et envoie le résultat à Bernard.

3° Bernard calcule les 100 nombres suivants:
Vu — D b (c — i + u), pour 1 < u < 100.
D b est l’algorithme de déchiffrement avec la clef privée de Bernard.

Il choisit un grand nombre premier3 p. Il calcule ensuite les 100 nombres sui
vants :
zu = (yu mod p), pour 1 < u < 100.
Il vérifie ensuite que pour tout u / v :
I zu zv | ^ 2
et pour tout u :
0 < zu < p - 1.
Si ce n’est pas vrai, Bernard choisit un autre nombre premier et essaie à nou
veau.
4° Bernard envoie à Alice la suite de nombres dans l’ordre exact suivant:
Zi, Z2 , Zj,Zj+1 + 1, Zj+ 2 + 1, .-.,ZlOO + l ,p
5° Alice vérifie si le i e nombre de la suite est congru à x modulo p. Si tel est le

cas, elle conclut que i < j , sinon elle conclut que i > j .
6° Alice indique sa conclusion à Bernard.
3. La taille de p doit être un petit peu plus petite que celle de x. Bernard ne connaît pas x mais
Alice peut facilement lui indiquer sa taille.
23.14 Calcul réparti sûr 581
Toutes les vérifications que Bernard doit effectuer à l’étape 3 servent à garantir qu’au
cun nombre n’apparaisse deux fois dans la suite engendrée à l’étape 4. Sinon, si za = Zb,
Alice saurait que a < j < b .
Le défaut de ce protocole est qu’Alice apprend le résultat du calcul avant que Bernard
ne l’apprenne. Rien ne l’empêche de compléter le protocole jusqu’à l’étape 5 et d’ensuite
refuser de dire le résultat à Bernard à l’étape 6. Elle peut même mentir à Bernard à
l’étape 6.
Exemple du protocole
Faites l’hypothèse que le R SA est l’algorithme à clef publique utilisé. La clef publique
de Bernard est 7 et sa clef privée est 23 ; n = 55. La valeur secrète i d ’Alice vaut 4 ; la
valeur secrète j de Bernard4 vaut 2.
1° Alice choisit x = 39et c = E B(3 9)= 19.
2° Alice calcule r — i = 19 — 4 = 15.Elle envoie 15 à Bernard.
3° Bernard calcule les 4 nombres suivants :
tn = D b { 15 + 1) = 26
jb = £>s(15 + 2) = 18
y3 = £ » s (15 + 3) = 2
y4 = D B(15 + 4) = 39.
Il choisit un grand p = 31 et calcule :
zi = 26 mod 31 = 26
z2 = 18 mod 31 = 18
Z3 = 2 mod 31 = 2
Z4 = 39 mod 31 — 8.
Il fait toutes les vérifications et confirme que la suite est correcte.

4° Bernard envoie à Alice la suite de nombres suivante dans l’ordre exact:
26,18,2 + 1,8 +- 1,31 = 26,18,3,9,31.
5° Alice vérifie si le 4e nombre de la suite est congru à x modulo p Comme 9 ^ 39

(mod 31), alors i > j .
6° Alice indique le résultat à Bernard.
Ce protocole peut servir à construire des protocoles bien plus compliqués. Un groupe
de gens peut effectuer une vente aux enchères secrète sur un réseau d’ordinateurs. Ils
instaurent un anneau logique entre eux, et déterminent grâce à des comparaisons deux
à deux celui qui offre le plus haut prix. Pour empêcher les gens de changer leur offre
au milieu des enchères, une sorte de protocole de mise en gage peut être utilisée. S’il
s’agit d’enchères au rabais, celui qui a fait la meilleure offre remporte l’objet pour ce
prix. S’il s’agit d ’enchères à l’anglaise, alors il remporte l’objet pour le deuxième prix
le plus élévé5. Des idées similaires s’appliquent aux marchandages, aux négociations
et à l’arbitrage.
4. Faites l’ hypothèse que seules les valeurs 1, 2, 3 et 4 sont possibles pou r i et j .
5. C eci peut être déterminer par une seconde ronde de com paraisons deux à deux.
23.15 Chiffrement probabiliste

La notion de c h if f r e m e n t p r o b a b i lis t e a été inventée par Shafi G o l d w a s s e r et Silvio
MlCALi [626]. Bien que la théorie fasse de ce cryptosystème le plus sûr que l’on ait
inventé, sa première réalisation n’était pas pratique [627]. La plupart des réalisations
récentes ont changé cela.
L’objet du chiffrement probabiliste est d ’éliminer la dernière petite fuite d’information
qui peut se produire grâce à la cryptographie à clef publique. Comme les cryptanalystes
peuvent toujours chiffrer des messages aléatoires avec la clef publique, ils peuvent
obtenir de l’information. En faisant l’hypothèse qu’ils ont le texte chiffré C = E k (.M)
et qu’ils essaient de retrouver le texte en clair A4, ils peuvent choisir un message au
hasard A4', le chiffrer: C' — E k (AA'). Si C = C, alors ils ont deviné le bon texte en
clair. Si l’égalité n’est pas vérifiée, ils n’ont qu’à parier à nouveau.
De plus, il n’y a pas d ’information partielle concernant le message original qui transpire.
Avec la cryptographie à clef publique, les cryptanalystes peuvent parfois apprendre
certaines choses concernant les bits : « le ou exclusif des bits 5, 17 et 39 est 1 », etc.
Avec le chiffrement probabiliste, même ce type d ’information demeure caché.
Cela n’apporte pas beaucoup d ’information, mais il y a des problèmes potentiels à per
mettre aux cryptanalystes de chiffrer des messages aléatoires avec votre clef publique.
Quelques informations peuvent fuir vers les cryptanalystes chaque fois qu’ils chiffrent
un message. Personne ne sait vraiment combien.
Le chiffrement probabiliste essaie d ’éliminer cette fuite d’information. Le but est qu’au
cun calcul sur le texte chiffré ou qu’aucun autre texte en clair d’essai, ne donne au
cryptanalyste la moindre information concernant le texte en clair correspondant.
Dans le cadre du chiffrement probabiliste, l’algorithme de chiffrement est probabiliste
plutôt que déterministe. En d’autres termes, il existe un grand nombre de textes chiffrés
qui correspondent à un texte en clair donné, et ce texte chiffré particulier utilisé dans
n’importe quel chiffrement est choisi aléatoirement. Tous ces textes chiffrés donnent au
déchiffrement le même texte en clair.
Ci = E k (A 4 ),C 2 = E k(A 4),C s = E j i ( A 4 ) , ..., C t - Ek{A 4)
A4 = D k (Ci ) , M = D k {C2), A4 = D K (C3), ...,M = D K (Ct)
Avec le chiffrement probabiliste, les cryptanalystes ne peuvent plus chiffrer des textes
en clair aléatoires pour trouver le bon. Pour illustrer, faites l’hypothèse que les crypta
nalystes ont le texte chiffré Ct = E k (AA). Même s’ils devinent A4 correctement, quand
ils calculent E k (A4), le résultat sera un C complètement différent: C3. Ils ne peuvent
pas comparer Ct et Cj donc ils ne peuvent pas savoir s’ils ont deviné correctement le
texte en clair.
C’est quelque chose d ’étonnamment séduisant. Même si les cryptanalystes ont à la fois
la clef publique de chiffrement, le texte en clair et le texte chiffré, ils ne peuvent pas
prouver que le texte chiffré est bien le chiffrement du texte en clair sans disposer de
la clef privée de déchiffrement. Même s’ils essaient une recherche exhaustive, ils ne
peuvent que prouver que tout texte en clair concevable est un texte en clair possible.
En utilisant ce type de schéma, le texte chiffré sera toujours plus long que le texte en
clair. Vous ne pouvez pas l’éviter ; c ’est le résultat du fait que plusieurs textes chiffrés
correspondent à un seul et même texte en clair. Le premier schéma de chiffrement
23.15 Chiffrement probabiliste 583
probabiliste [627] donnait un texte chiffré tellement plus long que le texte en clair qu’il
n’était pas utilisable en pratique.
Toutefois, il existe une réalisation efficace du chiffrement probabiliste due à Manuel
B l u m et Shafî G o l d w a s s e r , utilisant le générateur de bits aléatoires B l u m B l u m
S h u b (B B S) décrit dans le paragraphe 17.9 [205].
Le générateur BBS est basé sur la théorie des résidus quadratiques. En termes simples,
il y a deux nombres premiers p et q qui sont congrus à 3 modulo 4. C ’est la clef privée.
Leur produit p x q = n constitue la clef publique6.
Pour chiffrer un message A i, choisissez d’abord un x aléatoire, premier par rapport à
n. Ensuite calculez :
xo = x 2 mod n.
Utilisez xo comme germe pour le générateur pseudo-aléatoire de bits BBS et combinez

Ai par ou exclusif 1 bit à la fois avec la sortie du générateur. Le générateur produit
des bits bi (le bit de poids faible de X » , où X j — X i _ i mod n ) , et on a :
M = A i i ,M 2 ,A i 3 ,—, M t
C = A ii © b i,A i 2 © b2 ,A iz © 83, ...,A it ffi bt
où t est la longueur du texte en clair.
Joignez la dernière valeur calculée x< à la fin du message et vous avez fini.
Le seul moyen de déchiffrer le message est de retrouver x 0 et ensuite de mettre en
place le même générateur BBS pour le combiner par ou exclusif avec le texte chiffré.
Comme le générateur BBS est sûr à gauche, la valeur de x t n’est d ’aucune utilité pour
le cryptanalyste. Seul quelqu’un qui connaît p et q peut déchiffrer le message.
L’algorithme en C pour retrouver xo à partir de x t est donné par :
/* modexp (x , y , z ) é lè v e x à la puissance y modulo z . */
in t xO ( i n t p , in t q , in t n , in t t , in t x t)
f
in t a, b , u, v , w, z ;
/ * on s a it d é jà que p g cd (p , q) == 1 * /
(v o id )e u clid e _ e te n d u (p , q , &a, &b) ;
u = modexp ( ( p + l ) /4 , t , p - 1 ) ;
v = modexp ( ( q + l ) / 4 , t , q - 1 ) ;
w = modexp ( x t % p , u , p ) ;
z = modexp ( xt % q , v , q ) ;
retu rn (b*q*w + a*p*z) % n;
>
Une fois que vous avez Xo, le déchiffrement est facile. Mettez en place un générateur
BBS et combinez par ou exclusif sa sortie avec le texte chiffré.
Vous pouvez rendre ce schéma encore plus rapide en utilisant tous les bits sûrs de
x,, pas seulement le bit de poids faible. En utilisant cette amélioration, le chiffrement
probabiliste B l u m - G o l d w a s s e r est plus rapide que le R S A et il empêche la fuite de
6. Faites attention à vos p et ç, car la sécurité de ce schém a dépend de la difficulté de factoriser n .

toute information partielle concernant le texte en clair. Vous pouvez également prouver
que la difficulté de casser ce schéma est la même que la difficulté de factoriser n.
Cependant, ce schéma n ’est pas sûr du tout contre une attaque à texte chiffré choisi.
A partir du bit le moins significatif des bons résidus quadratiques, il est possible de
calculer la racine carrée de n’importe quel résidu quadratique. Si vous le pouvez, alors
vous pouvez factoriser. Pour les détails consultez [1572, 1573, 36, 37].
23.16 Cryptographie quantique

La cryptographie quantique prend sa source à l’incertitude naturelle du monde quan
tique. Grâce à elle, vous pouvez créer des canaux de communication qu’il est impossible
d ’espionner sans perturber la transmission. Les lois de la physique garantissent la sé
curité de ce canal — même si les espions peuvent faire ce qu’ils veulent, même s’ils
disposent d ’une puissance de calcul illimitée, même si P = N P . Charles B e n n e t t
et Gilles B r a s s a r d ont poussé cette idée aussi loin qu’ils ont pu, en décrivant une
distribution de clefs quantique, le jeu à pile ou face quantique, la mise en gage de bits
quantiques. Leurs travaux sont décrits dans [138, 139, 133, 135, 134, 143, 136, 398,
144, 396, 247, 519, 142, 140, 248, 397, 400]. Le meilleur aperçu de la cryptographie
quantique est donné par [141] ; [1653] est un bon survol vulgarisé. Une bibliographie
complète de cryptographie quantique est donnée dans [241].
Cela aurait pu rester à la frontière doucement délirante de la cryptographie, mais
B e n n e t t et B r a s s a r d l’ont sérieusement développé et ils ont construit un prototype
qui fonctionne [137, 131, 132], Maintenant, nous avons la cryptographie quantique
expérimentale.
Asseyez-vous, prenez quelque chose à boire et détendez-vous. Je vais vous expliquer de
quoi il s’agit.
D ’après la mécanique quantique, les particules ne sont pas localisées. Elles sont en
plusieurs endroits à la fois avec des probabilités d’être en ces différents endroits si
quelqu’un les cherche. Toutefois, ce n ’est pas avant que le scientifique arrive et qu’il
mesure la particule que celle-ci « s’effondre » en un seul endroit. Mais vous ne pouvez
pas mesurer tous les aspects d’une particule en même temps : la position et la vitesse,
par exemple. Si vous mesurez l’une de ces deux quantités, l’acte même de la mesure
détruit toute possibilité de mesurer l’autre quantité. Il y une incertitude fondamentale
dans le monde quantique, et il n’y a pas moyen de l’éviter.
Cette incertitude peut être utilisée pour engendrer une clef secrète Les photons vibrent
pendant leur déplacement. Cette vibration a une certaine direction : de haut en bas,
de gauche à droite ou, plus probablement, suivant un certain angle. La lumière solaire
normale n ’est pas polarisée : les photons vibrent dans toutes les directions possibles.
Quand un grand groupe de photons vibrent tous dans la même direction, ils sont p o
larisés. Les filtres à polarisation ne laissent passer que les photons qui sont polarisés
dans une certaine direction ; ils arrêtent tout le reste. Par exemple, un filtre à polarisa
tion horizontale ne laissera passer que les photons polarisés horizontalement. Tournez
le filtre de 90° et seuls les photons polarisés verticalement passeront.
Faisons l’hypothèse que vous avez une impulsion de photons polarisés horizontalement.
S’ils essaient de traverser un filtre à polarisation horizontale, ils passent tous. Tournez
lentement ce filtre vers la position à 90° ; le nombre de photons qui passent devient de
plus en plus petit, jusqu’à ce qu’il n’y en ait plus un seul qui passe. C ’est contraire à
23.16 Cryptographie quantique 585
l’intuition. Vous vous attendriez à ce que tourner le filtre ne serait-ce qu’un petit peu
bloque tous les photons, puisqu’ils sont polarisés horizontalement. Ce raisonnement
serait sensé dans notre monde, mais il ne l’est pas dans celui de la mécanique quantique.
Chaque particule a une probabilité de changer brusquement sa polarisation pour être
en accord avec l’orientation du filtre. Si l’angle est un petit peu diflérent, il y a une
bonne probabilité. Si l’angle est de 90°, la probabilité est 0. Si l’angle est de 45°, la
probabilité est de 50 %.
La polarisation peut être mesurée dans n’importe quelle base : deux axes à angle droit.
Par exemple, la base rectiligne est composée des axes horizontal et vertical, la base
diagonale des deux diagonales. Si une impulsion de photon est polarisée et si vous la
mesurez dans la même base, vous apprenez quelle est la polarisation. Si vous la mesurez
dans une mauvaise base, vous obtenez un résultat aléatoire. Nous allons utiliser cette
propriété pour engendrer la clef secrète :
1° Alice envoie à Bernard un train d’impulsions de photons polarisés. Chaque im

pulsion est polarisée aléatoirement dans une des quatre directions : horizontale
( ~ ) , verticale ( I ), oblique à gauche ( ^ ) , oblique à droite ( ^ )■
Par exemple, Alice envoie à Bernard:
J J / ------- \ " t ~ /
2° Bernard a un détecteur de polarisation. Il peut positionner ce détecteur pour

mesurer des polarisations verticales et horizontales & ) ou peut le positionner
pour mesurer des polarisations obliques ( X / / ne peut, pas faire les deux;
la mécanique quantique ne le laisserait pas faire. Mesurer une direction de
polarisation détruit toute possibilité de mesurer l’autre. Il positionne donc son
détecteur aléatoirement, par exemple :
x-l*'fxxx + x-f-f
À partir de là, quand Bernard positionne son détecteur correctement, il enre
gistre la bonne réponse. S ’il positionne son détecteur pour mesurer une pola
risation verticale ou horizontale et que l’impulsion est polarisée soit horizon
talement soit verticalement, il apprendra de quelle façon Alice a polarisé cette
impulsion. S ’il positionne mal son détecteur, il obtiendra un résultat aléatoire.
Il ne pourra pas distinguer les cas où il a le bon résultat de ceux pour lesquels il
obtient un résultat aléatoire. Dans cet exemple, il pourrait obtenir le résultat :
y 1— \ \ — 1
3° Bernard indique à Alice, par un canal de communication non sûr, quels posi
tionnements il a utilisés.
4° Alice indique à Bernard quels sont les positionnements corrects. Dans notre
exemple, le détecteur était correctement positionné pour les impulsions 2, 6, 7
et 9.
5° Alice et Bernard gardent uniquement les valeurs de polarisations correctement

mesurées. Dans notre exemple, ils gardent:
* 1& & & / — & ~ &

En utilisant un code convenu au préalable, Alice et Bernard, traduisent chacun
de leur côté ces polarisations en bits. Par exemple, « horizontal » et « oblique
à droite » pourraient représenter 1, et « vertical » et « oblique à gauche »
pourraient représenter D. Dans le contexte de notre exemple, ils ont tous deux:
0 0 11.
Ainsi, Alice et Bernard ont engendré 4 bits. Ils peuvent en engendrer autant qu’ils
veulent en utilisant ce système. En moyenne, Bernard devinera le bon positionnement
dans 50 % des cas et Alice devra donc envoyer 2 x n photons pour engendrer n bits.
Ils peuvent utiliser ces bits comme clef secrète pour un algorithme cryptographique
conventionnel, ou bien ils peuvent se garantir une confidentialité absolue en engendrant
suffisamment de bits pour un masque jetable.
S’ils utilisent ce système, Estelle ne peut pas les espionner. Si elle essaie de détecter les
impulsions quand elles passent, Bernard le détectera. Son seul espoir est de capturer
et mesurer les impulsions et ensuite d ’essayer d’envoyer des impulsions identiques à
Bernard. Mais tout comme Bernard, elle doit deviner quel type de polarisation mesurer ;
et tout comme Bernard, elle se trompera en moyenne une fois sur deux. Elle ne peut
pas éviter d ’envoyer des impulsions erronées à Bernard.
Si Estelle fait cela, Alice et Bernard auront des chaînes de bits différentes. C’est pour
quoi ils terminent le protocole de la manière suivante :
6° Alice et Bernard comparent quelques bits de leurs chaînes. S ’il y a des dis
cordances, ils savent qu’une oreille indiscrète pollue la ligne. S ’il n’y a pas de
discordances, ils jettent les bits utilisés pour la comparaison et utilisent ceux
qui restent.
Il existe des améliorations de ce protocole qui permettent à Alice et Bernard d’utiliser

leurs bits même si Estelle écoute [143,144,199]. Ils pourraient ne comparer que la parité
de certains sous-ensembles de bits. S’il n’y a aucune discordance, ils n’ont besoin de jeter
qu’un bit par sous-ensemble. Cela permet de détecter les écoutes avec une prababilité
de 50 % seulement, mais s’ils le font avec n sous-ensemble, Estelle n’a qu’une chance
sur 2” d’écouter la ligne sans se faire détecter.
Il n’y a rien qui puisse ressembler à l’écoute passive dans le monde quantique. Si Estelle
essaye de récupérer tous les bits, elle perturbera forcément les communications.
B e n n e t t et B r a s s a r d ont un prototype qui fonctionne. La dernière fois que j ’en ai
entendu parlé, des gens de B r i t i s h T e l e c o m transmettaient des bits sur un lien en
fibre optique de 10 kilomètres de long [280, 1255, 1541]. On croit rêver!
Quatrième partie
Le monde réel
Chapitre 24
Exemples de réalisation
Concevoir des protocoles et des algorithmes est une chose, mais les réaliser dans des
systèmes opérationnels en est une autre. En théorie, la théorie et la pratique sont
identiques ; en pratique, elles sont différentes. Souvent des idées intéressantes sur papier
ne marchent pas dans la pratique. Les exigences sont peut-être trop restrictives ; le
protocole est peut-être trop lent. Le chapitre 10 traite de quelques débouchés relatifs
à l’utilisation de la cryptographie ; ce chapitre donne des exemples pratiques de ce qui
se fait.
24.1 Protocole IBM de gestion de clefs se

crètes
A la fin des années 70, IBM a conçu un système complet de gestion de clefs pour la
sécurité des communications et des fichiers dans un réseau informatique, qui n’utilise
que la cryptographie à clef secrète [517, 1032]. Ce protocole est moins important au
niveau de son fonctionnement qu’au niveau de sa philosophie générale : En automatisant
la génération, la distribution, l’installation, le stockage, le changement et la destruction
des clefs, le protocole a beaucoup progressé pour assurer la sécurité des algorithmes
cryptographiques sous-jacents.
Ce protocole procure trois choses: communications sûres entre un serveur et divers
terminaux, stockage sûr de fichiers sur le serveur et communications sûres entre les
serveurs. Ce protocole n ’offre pas vraiment la possibilité de communications directes
de terminal à terminal bien qu’il puisse être modifié dans ce but.
Chaque serveur dans le réseau est raccordé à un dispositif cryptographique qui réalise
tous les chiffrements et les déchiffrements. Chaque serveur a une clef maîtresse KMo
et deux variantes K M i et K M 2 , toutes deux sont des variantes simples de KMo- Ces
clefs sont utilisées pour chiffrer d ’autres clefs et pour engendrer de nouvelles clefs.
Chaque terminal a une clef terminal maîtresse K M T qui est utilisée pour échanger
des clefs avec d ’autres terminaux.
Le serveur stocke K M T chiffré avec K M i. Toutes les autres clefs, dont celles utilisées
pour chiffrer les fichiers de clefs (appelés K N F ), sont stockées chiffrées avec K M 2. La
clef maîtresse K M 0 est stockée dans un module de sécurité sans fuite. Actuellement, ce
590 Chapitre 24 Exemples de réalisation
pourrait être une clef R O M ou une carte magnétique, ou bien une entrée dactylogra
phiée par l’utilisateur (probablement sous forme d’un texte qui serait ensuite « broyé »
pour obtenir une clef). K M j et K M 2 ne sont stockées nulle part dans le système,
mais elles sont calculées à partir de KM o chaque fois qu’elles sont nécessaires. Les
clefs de session, pour les communications entre serveurs, sont engendrées par un pro
cessus pseudo-aléatoire par le serveur. Les clefs utilisées pour chiffrer les fichiers pour
archivage (K N F ) sont engendrées de la même manière.
Le cœur du protocole est un module résistant à l’investigation appelé mécanisme
cryptographique. Du côté du serveur comme du côté du terminal, tous les chiffre
ments et les déchiffrements sont réalisés par ce mécanisme cryptographique. Les clefs
les plus importantes, celles qui sont utilisées pour engendrer les clefs de chiffrement,
sont stockées dans ce module. Ces clefs ne peuvent jamais être lues une fois qu’elles sont
stockées. Et elles sont liées à une utilisation : une clef affectée à une tâche ne peut pas
être accidentellement utilisée pour autre chose. Ce concept de vecteurs de contrôle
de clefs est probablement la contribution la plus significative de ce système. Donald
D a v i e s et William P r i c e décrivent en détail ce protocole de gestion de clefs [435],
Une variante
Une variante de ce schéma avec clefs maîtresses et clefs de session est décrite dans [1485].
Il est construit autour des nœuds du réseau avec des mécanismes de dépôt de clefs qui
peuvent desservir des terminaux. Il est conçu pour :
protéger les communications entre n’importe quelle paire d’utilisateurs à des ter
minaux ;
- protéger les communications à l’aide de courrier électronique chiffré ;
- protéger des fichiers personnels ;
- permettre de réaliser des signatures numériques.
Pour les communications et les transferts de fichiers entre utilisateurs, le schéma utilise
des clefs engendrées par le mécanisme de dépôt et envoyées aux utilisateurs chiffrées
avec une clef maîtresse. L’identité des utilisateurs est incorporée à la clef pour qu’il
soit possible de prouver qu’une clef de session a été utilisée par une paire particulière
d’utilisateurs. Ce mécanisme de dépôt de clefs est central à tout le système. Bien
que ce système n’utilise pas la cryptographie à clef publique, il offre des possibilités de
signature numérique : une clef ne peut être originaire que d’une seule source et elle ne
peut être lue que par un seul destinataire donné.
24.2 M ITRENET
L’une des premières réalisations de la cryptographie à clef publique était le système ex
périmental M E M O (pour « M ITRE Encrypted Mail Office »). M IT R E est un contrac
tant du Département de la Défense américaine — un groupe de réflexion gouverne
mental et un ensemble de personnes intelligentes. M E M O était un système de courrier
24-3 R N IS 591
électronique sûr destiné aux utilisateurs du réseau M IT R E N E T , utilisant la cryp

tographie à clef publique pour l’échange des clefs et le DES pour le chiffrement des
fichiers.
Dans le système M E M O , toutes les clefs publiques sont stockées dans un « centre
de distribution de clefs publiques », qui forme un nœud à part du réseau. Elles sont
stockées dans une E P R O M , pour éviter que quiconque ne les modifie. Les clefs privées
sont engendrées par les utilisateurs ou par le système.
Pour qu’un utilisateur puisse envoyer des messages en toute sécurité, le système établit
en premier lieu un lien de communication sûr avec le « centre de distribution de clefs
publiques ». L’utilisateur demande un fichier avec toutes les clefs publiques auprès
du « centre ». Si l’utilisateur réussit un test d ’identification en utilisant sa clef privée
individuelle, le « centre » envoie cette liste à sa station de travail. Cette liste est chiffrée
à l’aide du DES pour garantir l’intégrité du fichier.
Le processus utilise le DES pour chiffrer les messages. Le système engendre une clef
DES aléatoire pour le chiffrement des fichiers ; l’utilisateur chiffre le fichier avec cette
clef DES et il chiffre la clef DES avec la clef publique du destinataire. Le fichier chiffré
par le DES et la clef chiffrée par la clef publique sont tous deux envoyés au destinataire.
M EM O tient compte du problème de la perte des clefs. Il tient également compte de
la vérification de l’intégrité des messages en utilisant des sommes de contrôles. Il n’y a
pas de mécanisme d’authentification inclus dans le système.
On a montré que la réalisation particulière de cryptographie à clef publique utilisée
dans ce système — l’échange de clef D i f f i e - H e l l m a n basé sur Z j 2127 — n’était
pas sûre avant même que le système ne soit réalisé (voir § 11.6), bien qu’il soit facile
de modifier le système pour utiliser des nombres plus grands. M E M O était destiné
principalement à des fins expérimentales et n ’a jamais été rendu opérationnel sur le
vrai système M IT R E N E T .
24.3 RNIS
R e s e a r c h a développé un prototype de téléphone terminal RNIS
B e ll-N o r th e r n
sûr (pour « Réseau numérique à intégration de services » *) [497, 1201, 491, 498]2. La
version téléphone n’a pas dépassé le stade de prototype. Le produit final était le Paquet
de sécurisation des données (« Packet Data Security Overlay »). Le terminal utilise
l’échange de clefs D i f f i e H e l l m a n , les signatures numériques R SA et le chiffrement
des données par le DES ; il peut recevoir et émettre la voix et les données à 64 kilo-bits
par seconde.
Clefs
Une paire « clef publique-clef privée » à long terme est incorporée dans le téléphone.
La clef privée est stockée dans une zone du téléphone résistante à l’investigation. La
clef publique est utilisée comme identification du téléphone. Ces clefs font partie du
téléphone et ne peuvent être altérées en aucune façon.
De plus, deux autres clefs publiques sont stockées dans le téléphone. L’une de ces clefs
est la clef publique du propriétaire, qui est utilisée pour authentifier les commandes
1. N ote du traducteu r: en anglais on parlera d ’ ISDN p ou r « In teg ra ted S e r v ic e s D ig ita l N etw o rk ».
2. N ote d u traducteur : il est com m ercialisé en France sous le n om de NUMERIS.
faites par le propriétaire et peut être changée par une commande signée par le proprié
taire. De cette façon, un propriétaire peut céder son téléphone à quelqu’un d’autre.
La clef publique du réseau est aussi stockée dans le téléphone. Cette clef est utilisée
pour authentifier les commandes envoyées par le dispositif de gestion de clefs du réseau
et pour authentifier les appels des utilisateurs sur le réseau. Cette clef peut également
être changée par une commande signée par le propriétaire. Cela permet au propriétaire
de faire passer son téléphone d’un réseau à un autre.
Ces clefs sont considérées comme des clefs à long terme : elles ne sont changées que
rarement, ou même jamais. Une paire « clef privée-clef publique » à court terme est
aussi stockée dans le téléphone. Cette paire est encapsulée dans un certificat signé par le
dispositif de gestion des clefs. Quand deux téléphones établissent une communication,
ils échangent leurs certificats. La clef publique du réseau authentifie ces certificats.
Cette procédure d’échange et vérification de certificats ne permet que l’établissement
d’une communication sûre de poste à poste. Pour établir une communication sûre de
personne à personne, le protocole a une étape supplémentaire. La clef privée du proprié
taire est stockée dans une « clef matérielle d ’amorce » qui est insérée par le propriétaire
dans le téléphone. Cette clef d’amorce contient la clef privée du propriétaire, chiffrée à
l’aide d ’un mot de passe connu de lui seul (et non par le téléphone, ni par le dispositif
de gestion des clefs du réseau, ni quiconque autre). Elle contient également un certi
ficat signé par le dispositif de gestion des clefs du réseau ; ce certificat contient la clef
publique du propriétaire et certaines informations le concernant (nom, société, profes
sion, niveau d’accès à l’information confidentielle, garniture favorite de pizzas, tendance
sexuelle, etc.). Ce certificat est également chiffré. Pour déchiffrer ces informations et
les entrer dans le téléphone, le propriétaire entre son mot de passe secret à l’aide du
clavier du téléphone. Après que le téléphone a utilisé les informations pour établir la
communication, il les efface une fois que le propriétaire a retiré sa clef d ’amorce.
Le téléphone stocke également un ensemble de certificats du dispositif de gestion des
clefs du réseau. Ces certificats autorisent des utilisateurs particuliers à utiliser certains
des particuliers.
Appel
Un appel d’Alice vers Bernard se déroule comme suit :
1° Alice insère sa clef d’amorce dans le téléphone et elle entre son mot. de passe.
2° Le téléphone interroge la clef d ’amorce pour déterminer l’identité d’Alice et lui
donne la tonalité.
3° Le téléphone vérifie son ensemble de certificats pour vérifier que cet utilisateur
particulier est autorisé à utiliser ce téléphone particulier.
4° Alice forme le numéro; le téléphone établit l’appel.
5° Les deux téléphones utilisent un protocole d ’échange de clefs par cryptographie
à clef publique pour engendrer une clef de session unique et aléatoire. Toutes
les étapes suivantes du protocole seront chiffrées à l’aide de cette clef.
6° Le téléphone d ’Alice transmet son certificat et l’authentification de l ’utilisateur.
7° Le téléphone de Bernard vérifie l ’authenticité des signatures du certificat et de
l’authentification de l ’utilisateur en utilisant la clef publique du réseau.
244 S T U -III 593
8° Le téléphone de Bernard amorce une suite de « défis -réponses ». Il demande des

réponses signées en temps réel à des défis dépendant du temps3. Une réponse
doit être signée avec la clef privée du téléphone d’Alice et l’autre doit être signée
avec la clef privée d’Alice.
9° Le téléphone de Bernard sonne, à moins qu’il ne soit déjà en ligne.
10° S ’il est à la maison, Bernard insère sa clef d’amorce dans le téléphone. Son
téléphone interroge la clef d’amorce et vérifie le certificat de Bernard comme
aux étapes 2 et S.
11° Le téléphone de Bernard transmet son certificat et l’authentification de l ’utili
sateur.
12° Le téléphone vérifie l’authenticité des signatures de Bernard comme à l’étape 7
et débute une suite de « défis -réponses » comme à l’étape 8.
13° Les deux téléphones affichent l’identité de l’autre utilisateur et de l’autre télé
phone sur leur écran.
14° La conversation confidentielle commence.
15° Quand l’un des participants raccroche, la clef de session est effacée, ainsi que
les certificats que le téléphone de Bernard a reçus du téléphone d’Alice et les
certificats du téléphone d’Alice reçus du téléphone de Bernard.
Une nouvelle clef DES est utilisée pour chaque appel. Elle n’existe que dans chacun des
deux téléphones pour la durée de l’appel et est détruite immédiatement après la fin de
la conversation. Si un adversaire capture un ou les deux téléphones impliqués dans une
communication, il ne sera pas capable de déchiffrer la moindre communication passée
entre ces deux téléphones.
24.4 ST U -III
Le STU (pour « Secure Téléphoné Unit ») est un téléphone sûr conçu par la NSA. Ce
terminal a à peu près l’allure et la taille d ’un téléphone normal et peut servir comme
tel. Les téléphones sont aussi inviolables, assez pour ne pas être classés s’ils n’ont pas
de clef. Ils ont aussi un port de données et peuvent protéger le trafic entre modems
ainsi que les communications vocales [1140].
Whitfield D i f f i e parle du STU - III dans [492] :
« Pour appeler avec le S T U -III, il suffit d’appeler normalement un autre

poste S T U -III, puis d’insérer la clef contenant une variable cryptogra
phique et d ’appuyer sur le bouton « sécurité ». Après une attente d ’environ
15 secondes pour réglage cryptographique, chaque téléphone affiche des in
formations concernant l’identité et l’autorisation de l’autre partie, puis la
conversation peut commencer.
« Fait sans précédent, Walter D e e l e y , directeur de la sécurité des commu
nications à la N SA, a annoncé le S T U -III ou le système future de sûreté
vocale lors d ’un entretien avec The New York Times [286]. L’objectif initial
3. C e qui évite q u ’un adversaire puisseYitiliser des réponses fournies lors d ’ un échange précédent.
Chapitre 24 Exemples de réalisation
de ce nouveau système était de protéger les communications vocales et les

transmissions de données à basse vitesse pour le Département américain
de la Défense et ses fournisseurs. L’article ne révélait rien à propos de son
fonctionnement, mais par la suite, des fuites ont levé le voile. Le nouveau
système allait utiliser la cryptographie à clef publique.
La nouvelle approche de la gestion de clefs avait été remarquée plus tôt
dans [72] et un article parlait de téléphones « reprogrammés une fois par
an par une liaison téléphonique sûre », une tournure de phrase qui sug
gère l’utilisation d ’un protocole de passage de certificat, similaire à celui
décrit dans le paragraphe 24.3, qui minimise le besoin de communications
entre les téléphones et le centre de gestion de clefs. De récents rapports ne
se sont pas fait attendre, parlant d’un système de gestion de clefs appelé
F IR E F L Y qui [1353] « est issu de la technologie de clef publique et est
utilisé pour établir une paire de clefs de chiffrement de trafic ». Cette des
cription et ce témoignage soumis au Congrès américain par Lee N e u w i r t i i
de C y l i n k [1164] suggèrent une combinaison d’échange de clefs et de certi
ficats similaire à celle utilisée par le téléphone sûr ISDN, et il est plausible
que F IR E F L Y soit aussi basé sur le calcul de puissances modulo n. »
Les S T U -III sont fabriqués par A T & T et GE. Entre 300000 et 400000 unités ont
été mises en ligne en 1994. Une nouvelle version, l’équipement terminal sûr (ST E pour
« Secure Terminal Equipment »), fonctionnera sur les lignes ISDN.
24.5 Kerberos
K e r b e r o s est un protocole d ’authentification à tierce personne de confiance conçu
pour les réseaux T C P /I P . Un service K e r b e r o s , résidant dans le réseau, agit comme
un arbitre de confiance. K e r b e r o s offre l’authentification sûre en réseau en permettant
à une personne d’accéder à différentes machines dans le réseau. K e r b e r o s est basé
sur la cryptographie à clef secrète (le DES dans le cas de la réalisation concrète de
K e r b e r o s , mais tout autre algorithme pourrait être utilisé) ; K e r b e r o s partage une
clef secrète différente avec chaque entité du réseau et la connaissance de cette clef
secrète tient lieu de preuve d’identité.
K e r b e r o s a initialement été développé au M IT dans le cadre du projet A t h e n a .
Le modèle de K e r b e r o s est basé sur le protocole à tierce personne de confiance
de N e e d h a m et S c h r o e d e r (voir § 3.3) [1159J. La version originale de K e r b e r o s ,
V e r s i o n 4, a été spécifiée dans [1100, 1503]4. La V e r s i o n 5, construite par modi
fication à partir de la V e r s i o n 4, a été spécifiée dans [877, 1417, 878], La meilleure
vue d’ensemble de K e r b e r o s est [1163]. D ’autres articles d’études sont [1389, 1500]
et deux bons articles décrivant l’utilisation concrète de K e r b e r o s sont [781, 782].
Le modèle de Kerberos
Le protocole de base de K e r b e r o s est esquissé dans le paragraphe 3.3. Dans le modèle
de K e r b e r o s il y a des entités — des clients et des serveurs — résidant dans le réseau.
4. Les versions 1 à 3 étaient des versions de développem ent interne.

2 f.5 K erb eros 595
Les clients peuvent être des utilisateurs, mais peuvent également être des programmes
indépendants qui doivent faire certaines choses : télé-charger des fichiers, envoyer des
messages, accéder à des bases de données, accéder à des imprimantes, obtenir des
privilèges administratifs, etc.
K er ber o s tient une base de données des clients et de leurs clefs secrètes. Pour un
utilisateur humain, la clef secrète est un mot de passe chiffré. Les services du réseau
nécessitant une authentification, ainsi que les clients qui désirent utiliser ces services,
enregistrent leur clef secrète auprès de K e r b e r o s .
Comme K er ber o s connaît la clef secrète de tout le monde, il peut créer des messages
pour convaincre une entité de l’identité d’une autre entité. K er ber o s crée également
des clefs d e session qui sont données au client et au serveur (ou aux deux clients)
et à personne d ’autre. Une clef de session est utilisée pour chiffrer les messages entre
deux participants, ensuite elle est détruite.
K er ber o s utilise DES pour le chiffrement. La V ersio n 4 fournit un mode non-
standard pour l’authentification. Ce mode est faible : il ne détecte pas certains change
ments apportés au texte chiffré (voir § 9.10). La VERSION 5 de utilise le mode C B C .
Fonctionnement de Kerberos
Cette section décrit KERBEROS V e r sio n 5. Je soulignerai plus loin les différences entre
la V ersion 4 et la V ersio n 5. Le protocole K er b e r o s est simple (voir la figure 24.1).
Un client demande à K er b e r o s un ticket pour le serv ice d e d éliv ra n ce d e tickets
(ticket S D T ) 5. Ce ticket, appelé « ticket d’obtention de ticket » (T O T ) 6, est envoyé
au client, chiffré avec la clef secrète du client. Pour utiliser un serveur particulier, le
client demande un ticket pour ce serveur au SD T. En faisant l’hypothèse que tout
est en ordre, le S D T envoie au client le ticket demandé. Le client présente alors ce
ticket avec un authentifiant au serveur du service désiré. Si rien ne cloche avec les
accréditations du client, le serveur laisse le client accéder au service.
1. Requête pour un T O T
2. T O T
( Kerberos] ( SDT ' 3. Requête pour un ticket de service
4. Ticket de service
5. Requête pour le service
1 \ V ----- / a
5 — Serveur ]
f Client ]- h
F ig . 24.1 - Etapes d’authentification K e rb e ro s
5. N ote du traducteur : en anglais, un tel service est appelé « T ic k e t-G r a n tin g S er v ic e » (T G S ).

6. N ote du traducteur : en anglais, un tel ticket est appelé « T G T » pou r « T ic k e t-G r a n tin g T ic k e t ».
Accréditations
K e r b e r o s utilise deux types d ’accréditations : les t ic k e t s et les a u t h e n t if ia n t s 7. Un
ticket est utilisé pour passer au serveur, de manière sûre, l’identité du client à qui le
ticket a été émis. Il contient également des informations que le serveur peut utiliser
pour s’assurer que le client qui utilise le ticket est bien celui à qui le ticket a été délivré.
Un authentifiant est une accréditation supplémentaire présentée avec le ticket.
T ab . 24.1 - Tableau des abréviations utilisées par K erbero s
c — client
s = serveur
a = adresse réseau du client
v = temps de début et de fin de validité d’un ticket
t = datation
Kx = clef secrète de x
K x,y = clef de session pour x et y
{m }K x = m chiffré avec la clef secrète de x
T x ,y = ticket de x pour utiliser y
A x ,y = authentifiant de x pour y
Un ticket K erberos ressemble à ceci :
Tc.s ~ 5, { c , g , v , K CjS)./y s -
Un ticket est valable pour un seul serveur et un seul client. Il contient le nom du client
et son adresse réseau, le nom du serveur, une datation et une clef de session. Cette
information est chiffrée avec la clef secrète du serveur. Une fois que le client obtient ce
ticket, il peut l’utiliser plusieurs fois pour accéder au serveur, jusqu’à ce que le ticket
expire. Le client ne peut pas déchiffrer le ticket (il ne connaît pas la clef secrète du
serveur), mais il peut le présenter au serveur sous sa forme chiffrée. Personne ne peut
espionner le réseau pour lire ou modifier les tickets qui passent.
Un authentifiant K e r b e r o s ressemble à ceci :
A Cfs — ( c tj clef)K c,s ■
Le client l’engendre chaque fois qu’il veut utiliser un service du serveur. L’authentifiant
contient le nom du client, une datation et une clef de session supplémentaire optionnelle,
tous chiffrés avec la clef de session partagés par le client et le serveur. Contrairement à
un ticket, il ne peut être utilisé qu’une fois. Toutefois, comme un client peut engendrer
les authentifiants suivant ses besoins (il connaît la clef secrète partagée), ce n’est pas
un problème.
L’authentifiant sert à deux choses. Primo, il contient du texte en clair chiffré avec la
clef de session. Cela prouve qu’il connaît également la clef. Mais, ce qui est tout aussi
important, le texte en clair scellé contient une datation. Un espion qui enregistre le
ticket et l’authentifiant ne peut pas les rejouer deux jours après.
7. Le reste ce cette section utilise les notations utilisées dans les docum ents K erberos — voir le
tableau 24.1.
24.5 K erberos 597
Messages de Kerberos Version 5

Le K erberos V ersion 5 a cinq messages:
1. Client vers K e r b e r o s : c,sdt.

2. K erberos vers le client : { K CiSdt} K c,{TCiSdt} K sdt.
3. Client vers le S D T : { A c,a} K c<sdt, {Tc,sdt}Ksdt,s-

4. SD T vers le client : { K CtS} K CiSdt, {T C,S} K S.
5. Client vers le serveur: { A c>B}ÜfCiS, {Tc s} K s
Ces messages vont maintenant être développé en détails.
Obtention du premier ticket

Le client dispose d’une information qui prouve son identité : son mot de passe. Il est
clair que nous ne voulons pas que le client envoie son mot de passe sur le réseau. Le
protocole K erberos minimise les chances que ce mot de passe soit compromis, tout
en empêchant un utilisateur de s’identifier correctement s’il ne connaît pas son mot de
passe.
Le client envoie un message contenant le nom de l’utilisateur et le nom de son ser
veur SD T au serveur d ’authentification K erberos 8. En réalité, l’utilisateur entre
probablement juste son nom dans le système, et le programme de connexion envoie la
requête.
Le serveur d ’authentification K erberos cherche le client dans sa base de données. Si
le client est dans la base de données, K erberos engendre une clef de session qui doit
être utilisée entre le client et le SD T. C ’est ce qui est appelé un t ic k e t d ’ o b t e n t io n
d e t ic k e t (T O T ). K erberos chiffre la clef de session avec 1a. clef secrète du client.
Ensuite il crée un T O T pour le client, afin que celui-ci puisse s’authentifier au S D T et
chiffre ce dernier ticket à l’aide de la clef secrète du SD T. Le serveur d’authentification
envoie les deux messages chiffrés au client.
Le client déchiffre alors le premier message et récupère la clef de session. La clef secrète
étant une empreinte obtenue par hachage à sens unique de son mot de passe, un utilisa
teur légitime n’aura donc aucun problème à effectuer ce déchiffrement. Si l’utilisateur
était un imposteur, il ne connaîtrait pas le bon mot de passe et il ne pourrait donc pas
déchiffrer la réponse du serveur d’authentification K erberos . L’accès serait refusé et
le client ne pourrait pas obtenir le ticket ou la clef de session.
Le client garde le T O T et la clef de session et il efface le mot de passe et l’empreinte
obtenue par hachage à sens unique. Ces informations sont effacées pour minimiser les
confusions possibles. Si un adversaire arrivait à avoir une copie de la mémoire centrale
du client, il ne trouverait que le T O T et la clef de session. Ce sont des morceaux
d’information qui ont de la valeur mais seulement durant la durée de vie du T O T .
Après expiration du T O T , ils n’auront plus d ’utilité.
Le client peut alors prouver son identité au S D T pendant la durée de vie du T O T .
8. Il peu t y avoir de nom breux serveurs S D T .

Obtention de tickets pour un service

Un client doit obtenir un nouveau ticket pour chaque service qu’il désire utiliser. Le
S D T délivre des tickets pour un seul serveur à la fois.
Quand un client a besoin d’un nouveau ticket, il envoie sa requête au S D T 9.
Quand le S D T reçoit la requête, il déchiffre le T O T avec sa clef secrète. Ensuite il
utilise la clef de session incluse dans le T O T pour déchiffrer l’authentifiant. Enfin, il
compare les informations de l’authentifiant avec les informations dans le ticket, l’adresse
réseau du client avec l’adresse d ’où la requête a été envoyée et la datation avec le temps
courant. Si tout concorde, il autorise l’exécution de la requête.
La vérification des datations est basée sur l’hypothèse que toutes les machines ont
synchronisé leurs horloges, du moins à quelques minutes près. Si la datation de la
requête est trop lointaine dans le futur ou dans le passé, le S D T considère cette requête
comme une ancienne requête rejouée. Le S D T doit également garder la trace de tous
les authentifiants actifs, car des requêtes passées peuvent avoir des des datations encore
valides. Une requête reçue avec le même ticket et la même datation qu’une autre requête
déjà reçue peut être ignorée
Le S D T répond à une requête valide en envoyant un ticket valide au client que ce
dernier pourra présenter au serveur. Le S D T crée aussi une nouvelle clef de session
pour le client et le serveur, chiffrée avec la clef de session partagée par le client et le
SD T. Ces deux messages sont alors renvoyés au client. Celui-ci déchiffre le message et
extrait la clef de session.
Demande d’un service

Maintenant, le client est prêt à s’authentifier auprès du serveur. Il crée un message
très similaire à celui qu’il a envoyé au S D T (ce qui est logique puisque le SD T est un
service).
Le client crée un authentifiant qui contient son nom et son adresse sur le réseau ainsi
qu’une datation, le tout chiffré avec la clef de session entre le client et le serveur
engendrée par le SD T . La requête contient le ticket reçu de K e r b e r o s (déjà chiffré
avec la clef secrète du serveur) et l’authentifiant chiffré.
Le serveur déchiffre et vérifie le ticket et l’authentifiant, comme décrit ci-dessus, et
vérifie également l’adresse du client et la datation. Si tout concorde, le serveur sait,
d’après K E R B E R O S , que le client est bien celui qu’il prétend être.
Pour des applications qui nécessitent l’authentification mutuelle, le serveur envoie au
client un message en retour qui contient la datation, chiffré avec la clef de session. Ceci
prouve que le serveur connaissait la clef secrète du client et qu’il a pu déchiffrer le
ticket et donc l’authentifiant.
Le client et le serveur chiffrent les futurs messages avec la clef partagée, s’ils le désirent.
Comme eux seuls partagent cette clef, ils peuvent tous deux faire l’hypothèse qu’un
message récemment reçu et chiffré avec cette clef a bien pour origine l’autre participant.
Kerberos Version 4
La section précédente a décrit K e r b e r o s V e r s i o n 5. K e r b e r o s V e r s i o n 4 dif
fère légèrement quant au contenu des messages et à la construction des tickets et des
9. Dans la réalité, le program m e peut faire cela autom atiquem ent et ce sera invisible à l’ utilisateur.
24-5 K erberos 599
authentifiants.
Dans K erberos V ersion 4, les cinq messages ressemblent à ceci :
1. Client vers K e r b e r o s : c , s d t .
2. K erberos vers le client: { K c<sdt, {Tc>sdt] K sdt} K c.
3. Client vers le S D T : {A c,s} K c,sdt, {TCtSdt} K sdt, s.

4. S D T vers le client: { K CjS,{T c s } K s} K C7sdt.
5. Client vers le serveur: { A C^ } K CS, {TCjS} i f 8
T vs — { s , r ,(7, ( 1. / , 1/ \s
A . Cls ~ {c,u,t}/éC)S.
Les messages 1, 3 et 5 sont identiques. Le double chiffrement des tickets pour les
messages 2 et 4 a été retiré dans la VERSION 5. Les tickets de la VERSION 5 offrent la
possibilité d’avoir des adresses multiples et ils remplacent le champs « life », 1, par un
temps de début et de fin de validité du ticket. L’authentifiant de la V ersion 5 offre la
possibilité d ’inclure une clef additionnelle.
Sécurité de Kerberos
Steve B ellovin et Michael M erritt décrivent diverses vulnérabilités potentielles de
K erberos au niveau de la sécurité [115]. Bien que cet article ait été écrit pour les
protocoles de laVERSlON 4, nombre de leurs commentaires s’appliquent également à la
V ersion 5.
Il serait possible d’engranger des anciens authentifiants et de les rejouer. Bien que les
datations soient supposées éviter cela, les messages peuvent être rejoués pendant la
durée de vie du ticket. Les serveurs sont supposés stocker les tickets valides pour éviter
que des messages soient rejoués, mais ce n’est pas toujours possible. De plus, la durée
de vie du ticket peut être longue ; huit heures est la moyenne.
Les authentifiants dépendent du fait que toutes les horloges du réseau sont plus ou
moins synchronisées. Si l’on peut tromper un ordinateur quant à l’heure réelle, alors
un ancien authentifiant peut être rejoué sans problème. La plupart des protocoles de
maintien du temps en réseau ne sont pas sûrs, ce qui peut donc être un défaut sérieux.
K erberos est aussi vulnérable aux attaques de paris de mots de passe. Un intrus
peut collectionner les tickets et ensuite essayer de les déchiffrer. Rappelez-vous que
l’utilisateur moyen ne choisit généralement pas des bons mots de passe. Si Martin
collecte suffisamment de tickets, ses chances de retrouver le mot de passe sont bonnes.
L ’attaque, la plus sérieuse peut-être, implique un logiciel malicieux. Le protocole K erb
eros repose sur le fait que le logiciel K erberos est digne de confiance. Rien n’empêche
Martin de remplacer subrepticement tous les logiciels K erberos clients par une ver
sion qui non seulement réalise les protocoles K erberos mais également enregistre les
mots de passe. C ’est un défaut commun à tous les logiciels cryptographiques qui sont
exécutés sur un ordinateur peu sûr, mais l’utilisation répandue de K erberos dans
ces environnements en fait une cible particulièrement attrayante. Des améliorations de
K erberos sont à l’étude, comprenant une réalisation de cryptographie à clef publique
et une interface à carte à puce pour la gestion de clef.
Licences
K e r b e r o s n’est pas dans le domaine public, mais le code du M IT est disponible
gratuitement . Dans les faits, utiliser ce code dans un environnement U N IX opérationnel
est une toute autre histoire. De nombreux magasins vendent des versions de K e r b e r o s ,
mais vous pouvez obtenir une bonne version gratuite auprès de Cygnus Support, 814
University Ave., Palo Alto, CA, 94301 ; (415) 322-3811 ; fax: (415) 322-3270.
24.6 KryptoKnight
K r y p t o K n i g h t (subtil, n o n ? )10 est un système d ’authentification et de distribution
de clef conçu par IBM . C ’est un protocole à clef secrète qui utilise soit le DES en
mode C B C (voir § 9.3), soit une version modifiée de M D5 (voir § 18.5).
K r y p t o K n i g h t offre quatre services de sécurité :
- l ’a uthentification de l ’utilisateur (appelée « Single Sign-On ») ;
- l ’a uthentification à deux particip ants ;
la distrib u tion de clefs ;
- l’authentification de l’origine et du contenu des données.
Du point de vue de l’utilisateur, K rypto K n ig h t est similaire à K erberos. Il y a

quand même quelques différences :
- K rypto K n ig h t utilise une fonction de hachage po ur l ’identification et le chif

frement des tickets ;
K rypto K n ig h t ne repose pas sur des horloges synchronisées ; il utilise des mots
créés p o u r à l ’occasion p o u r les challenges (voir § 3.3) ;
- Si Alice veut communiquer avec Bernard, K r y p t o K n i g h t donne la possibi

lité à Alice d’envoyer un message à Bernard, et à Bernard d’initier le protocole
d ’échange de clefs.
K r y p t o K n i g h t a des tickets et des authentifiants, tout comme K e r b e r o s . Il a des

SD T , mais il les appelle des serveurs d’authentification. Les concepteurs de K r y p t o
K n i g h t ont fait des efforts considérables pour réduire le nombre de messages, leurs
longueurs ainsi que le volume de chiffrement. Pour plus d ’informations concernant
K r y p t o K n i g h t , lisez [1116, 180, 182, 181].
24.7 SESAME
SESAM E (pour « Secure European System for Applications in a Multivendor Environ
ment ») est un projet de sécurité de la communauté européenne, financé à 50 pourcent
par R A C E (voir paragraphe 25.7), dont l’objectif principal est la production de tech
nologie pour l’authentification des utilisateurs avec distribution du contrôle d’accès.
10. N ote du traducteur : en anglais, K ryptoK n ight se prononce com m e K ryptonite.
2f.8 Architecture cryptographique commune d T B M 601
C’est un peu une version européenne de K e r b e r o s . C’est un projet en deux parties :

la première est un prototype de base de l’architecture, et la deuxième est un ensemble
de projets commerciaux. Les trois entreprises les plus influents dans le développement
sont ICL au Royaume-Uni, S i e m e n s en Allemagne et B u l l en France.
SESAM E est mi système d ’authentification et d ’échange de clefs [365, 1258, 798,
1051]. Il utilise le protocole de Needham-Schroeder, avec cryptographie à clef publique
pour communiquer entre différents domaines sensibles. Le système présente de sérieux
défauts à plusieurs niveaux. Au lieu d ’utiliser un vrai algorithme de chiffrement, ils
combinent par ou exclusif avec une clef de 64 bits. Pire encore, ils combinent par ou
exclusif en mode C B C , ce qui ne chiffre que la moitié du texte en clair. Pour leur
défense, ils voulaient utiliser le DES mais le gouvernement français a contesté ; ils
ont validé le code avec DES mais l’ont ensuite retiré en espérant que les personnes le
rajouteraient- Tout cela ne m ’impressionne guère.
L’authentification dans SE SA M E est une fonction sur le premier bloc d ’im message,
pas sur le message entier. Ceci a pour effet d’authentifier « Monsieur », et non pas
le corps d ’une lettre. La génération de clefs consiste en deux appels vers la fonction
rand d’U N IX, qui n’est pas très aléatoire. SE SAM E utilise crc32 et MD5 en tant que
fonctions de hachage à sens unique. Bien sûr, SE SA M E est vulnérable
24.8 Architecture cryptographique com

mune d’IBM
L’architecture cryptographique commune (C C A pour « Common Cryptographie Archi
tecture ») a été conçue et développée par IBM afin de fournir des primitives cryptogra
phiques pour la confidentialité, l’intégrité, la gestion des clefs et des codes personnels
(PIN pour « Personal Identification Number ») [753, 784, 1035, 1036, 951, 754]. Les
clefs sont gérées par les vecteurs de contrôle VC (voir § 8.5). Chaque clef a un VC com
biné par ou exclusif et n’est jamais séparée du vecteur sauf à l’intérieur d ’un matériel
sûr. Le VC est une structure de données fournissant une compréhension intuitive des
privilèges associés à une clef particulière.
Les bits individuels du VC ont des significations spécifiques pour utiliser et manier
chaque clef gérée par la C C A . Le VC est transporté avec la clef chiffrée dans des
structures de données appelées bons de clefs. Les bons de clef interne sont utilisés pour
exporter et importer des clefs chiffrées entre systèmes. Les clefs dans les bons de clef
externe sont chiffrées par les clefs de chiffrement de clefs (K E K pour « Key-encrypting
keys »). Ces K E K sont gérées dans les bons de clef interne. Les clefs sont séparées
selon leurs usages autorisés.
La longueur de clef est aussi précisée et respectée en utilisant les bits du VC. Les
clefs de longueur simple ont 56 bits et sont utilisées pour des fonctions telles que
la confidentialité et l’authentification de messages. Les clefs de longueur double ont
112 bits et sont utilisées pour la gestion des clefs, les fonctions PIN et autres tâches
spéciales. Les clefs peuvent être soit « doubles uniquement », dans ce cas les deux
moitiés gauche et droite de la clef doivent être différentes, soit « doubles », et les
moitiés peuvent être égales par chance, soit « simples reproduites », alors les moitiés
gauches et droites sont égales, soit « simples » et contiennent 56 bits. Les fonctions
de la C C A spécifient le matériel à utiliser avec certains types de clefs pour quelques
opérations.
Le VC est vérifié dans un processeur sûr: il doit être en conformité avec les lois au
torisées par la C C A pour chaque fonction C C A . Si le VC passe le test, une variante
de la K E K ou M K est obtenue par la combinaison par ou exclusif de la K E K ou M K
avec le VC, et la clef du texte en clair est disponible pour une utilisation interne avec
la fonction C C A . Quand les nouvelles clefs sont générées, le VC précise les utilisations
possibles de la clef générée. Ces combinaisons de types de clefs qui pourraient être
utilisées pour attaquer le système ne sont pas générées ou importées dans un système
compatible C C A .
La C C A utilise une combinaison de cryptographie à clef publique et à clef secrète
pour la distribution des clefs. Le K D C partage une clef maîtresse secrète avec chaque
utilisateur et chiffre les clefs de séance avec cette clef maîtresse. Les clefs maîtresses
sont distribuées en utilisant la cryptographie à clef publique.
Les concepteurs du système ont choisi une approche hybride pour deux raisons. La
première est la performance. La cryptographie à clef publique est informatiquement
intense ; si les clefs de séance sont distribuées en utilisant la cryptographie à clef pu
blique, une erreur système peut intervenir. La seconde est la compatibilité récurrente ;
ce système peut être recouvert par des schémas à clef secrète avec une interruption
minimum.
Les systèmes C C A sont conçus pour être interopérables. Pour les systèmes non compa
tibles C C A , une fonction de traduction de vecteur de contrôle (C V X L T pour « Control
Vector Translate ») permet de passer les clefs entre les deux systèmes. L’initialisation
de la fonction C V X L T exige un double contrôle. Les deux parties doivent régler les
tables de traduction de façon indépendante. Un tel double contrôle garantit un haut
niveau d’assurance concernant l’intégrité et le pédigré de toute clef introduite dans le
système.
Une clef de type D A T A est fournie pour la compatibilité avec d’autres systèmes. Une
clef D A TA est stockée avec un VC qui l’identifie comme étant bien une clef DATA.
Les clefs D A TA sont d ’une utilisation très large et doivent donc être considérées avec
suspicion et utilisées avec prudence. Les clefs D ATA ne devraient pas être utilisées
dans les fonctions de gestion de clefs.
Le C D M F (pour « Commercial Data Maskmg Facility ») fournit une version exportable
de C C A . Elle a une caractéristique spéciale qui réduit les clefs DES à 40 bits pour
l’export (voir § 15.5) [785].
24.9 Environnement d’authentification ISO

La cryptographie à clef publique a été recommandé pour l’environnement d’authenti
fication ISO, connu aussi sous l’appellation « protocoles X .509 » [309]. Cet environ
nement offre l’authentification à travers plusieurs réseaux. Bien qu’aucun algorithme
particulier ne soit spécifié ni pour la sécurité ni pour l’authentification, la spécification
recommande le R SA .. Il y a toutefois des aménagements pour permettre l’utilisation
de multiples algorithmes et fonctions de hachage. Le protocole X .509 a été introduit
pour la première fois en 1988. Après utilisation par le public, il a été révisé en 1993
pour corriger des problèmes de sécurité [1106, 752],
2Jt.9 Environnement d’authentification IS O 603
Certificats
La partie la plus importante du protocole X .509 est sa structure pour les certificats à
clefs publiques. Chaque utilisateur a un nom distinct. Une a u to rité de certifica tion
(C A pour « Certification Authority ») fiable assigne un nom unique à chaque utilisateur
et émet un certificat signé contenant le nom et la clef publique de l’utilisateur. La
figure 24.2 montre un certificat X .509 [309],
Version
Numéro de série
Identificateur de l’algorithme :
—Algorithme
—Paramètres
Délivreur
Période de validité :
—Pas avant ...
—Pas après ...
Sujet
Clef publique du sujet :
—Algorithme
—Paramètres
— Clef publique
Signature
F i g . 24.2 - Un certificat X.509
Le champ de la version identifie le format du certificat. Le numéro de série est unique

dans la C A . Le champ suivant identifie l’algorithme utilisé pour signer le certificat,
ainsi que tous les paramètres nécessaires. L’autorité qui délivre est la C A . La période
de validité est une paire de dates entre lesquelles le certificat est valide. Le sujet est
le nom de l’utilisateur. L’information de clef publique du sujet comprend le nom de
l’algorithme, tous les paramètres nécessaires et la clef publique. Le dernier champ est
la signature de l’entre la C A .
Si Alice veut communiquer avec Bernard, elle doit d’abord trouver son certificat dans
une base de données. Puis elle vérifie son authenticité. S’ils utilisent tous deux la
même C A , c’est facile. Alice vérifie simplement la signature de la C A sur le certificat
de Bernard.
S’ils utilisent des C A différentes, c ’est plus compliqué. Imaginez une structure arbo
rescente, avec des C A différentes qui certifient d’ autres C A et d ’autres utilisateurs.
Au sommet, il y a une C A maîtresse. Chaque C A a un certificat signé par la C A
supérieure, ainsi que par la C A inférieure. Alice utilise ces certificats pour vérifier le
certificat de Bernard.
La figure 24.3 illustre cela. Le certificat d’Alice est certifié par l’C A ^ ; celui de Bernard
par l’C A ii. Alice connait la clef publique de I’C A a- L’C A c a un certificat signé par
I’C A a , aussi Alice peut le vérifier. L’CA o a un certificat signé par l’C A c . L’C A /j a un
certificat signé par l’ C A p- Le certificat de Bernard est signé par l’C A g . En remontant
l’arborescence jusqu’à un point de commun, dans ce cas I’C A d , puis en la redescendant
jusqu’à Bernard, Alice peut vérifier le certificat de Bernard.
F ig . 24.3 - Exemple de hiérarchie de certification
Les certificats peuvent être stockés dans des bases de données sur le réseau. Les uti
lisateurs peuvent se les envoyer. Quand un certificat expire, il doit être retiré de tous
les répertoires publics. Toutefois, la C A émettrice doit garder une copie du certificat.
Elle sera nécessaire pour résoudre tout conflit ultérieur qui pourrait se produire.
Les certificats peuvent aussi être révoqués, soit parce que la clef de l’utilisateur a été
compromise, la clef de la C A a été compromise, soit parce que la C A ne veut plus
certifier l’utilisateur. Chaque C A doit garder une liste des certificats révoqués mais
non expirés. Quand Alice reçoit un nouveau certificat, elle devrait vérifier qu’il n’a pas
été révoqué. Elle peut consulter une base de données sur le réseau de clefs révoquées,
mais plus probablement, elle consultera plutôt une liste en mémoire cache locale de
clefs révoquées. Il y a sûrement des abus à ce système ; la révocation de clef en est la
partie la plus faible.
Les protocoles d’authentification

Alice veut communiquer avec Bernard. D ’abord, elle consulte une base de données et
elle obtient ce que l’on appelle un « chemin de certification » d ’Alice à Bernard ainsi
que la clef publique de Bernard. A partir de là, Alice peut démarrer un protocole
d ’authentification uni-, bi- ou tri-directionnel.
Le protocole unidirectionnel est une communication simple entre Alice et Bernard. Il
établit l’identité d ’Alice et de Bernard ainsi que l’intégrité de toutes les informations
qui transitent entre Alice et Bernard. Il empêche également les attaques par blocs
rejoués pendant la communication.
Le protocole bidirectionnel ajoute une réponse de Bernard. Il établit que Bernard, et
non un imposteur, a envoyé la réponse. Il garantit également la confidentialité des deux
communications et il empêche les attaques par blocs rejoués.
24-9 Environnement d’authentification IS O 605
Les protocoles uni- et bi-directionnels utilisent tous deux des datations. Un protocole
tridirectionnel ajoute un message supplémentaire entre Alice et Bernard, qui permet
de se passer de datations (et donc d’heure authentifiée).
Le protocole unidirectionnel est donné par :
1° Alice engendre un nombre aléatoire R a -

2° Alice construit un message, A4 = (TA,RA,Is,d ) où Ta est la datation d’Alice,
I b est l’identité de Bernard et d est une donnée arbitraire. Les données peuvent,
par sécurité, être chiffrées avec la clef publique de Bernard E b -
3° Alice envoie (C a ,D a (A4)) à Bernard (C a est le certificat d’Alice; D a est le
point commun dans l’arborescence).
4° Bernard vérifie C a et obtient E a - Il vérifie que ces clefs n’ont pas expiré. (E a
est la clef publique d’Alice.)
5° Bernard utilise Ea pour chiffrer D a (A4). Il vérifie la signature d’Alice et l’in
tégrité des données signées.
6° Bernard vérifie l ’exactitude de I b dans A4.
7 ° Bernard vérifie Ta dans A4 et ainsi s ’assure que le message est d’actualité.
8° Optionnellement, Bernard peut chercher la partie R a de A4 dans une base de
données d’anciens nombres aléatoires pour vérifier que ce message n’est pas un
ancien message rejoué.
Le protocole bidirectionnel est constitué du protocole unidirectionnel, puis d ’un pro

tocole unidirectionnel similaire de Bernard vers Alice. Après l’exécution des étapes 1
à 8 du protocole unidirectionnel, le protocole bidirectionnel continue ainsi :
9° Bernard engendre un autre nombre aléatoire R b -

10° Bernard construit un message AA' = (Tb ,Rb ,I a ,R a ,(I), où T b est la datation
de Bernard, I a est l’identité d’Alice et d est une donnée arbitraire. Par sécurité,
les données peuvent être chiffrées avec la clef publique d’Alice E a - R a est le
nombre aléatoire engendré par Alice à l’étape 1.
11° Bernard envoie D b (AA') à Alice.
12° Alice utilise E b pour déchiffrer D b {AA'). Elle vérifie la signature de Bernard
et l’intégrité des informations signées.
13° Alice vérifie l’exactitude de 1a extraite de AA'.
14° Alice vérifie la datation Tb de A4' et s ’assure que le message est d’actualité.
15° Optionnellement, Alice peut vérifier R b de A4' pour s ’assurer que ce n’est pas
un vieux message rejoué.
Le protocole tridirectionnel fait la même chose que le protocole bidirectionnel, mais

sans les datations. Les étapes 1 à 15 sont identiques à celles du protocole bidirectionnel
avec Ta = Tb — 0.
16° Alice compare le R a qu’elle a reçu au R a qu’elle a envoyé à Bernard à l’étape

3.
17° Alice envoie D a ( R b ) à Bernard.
18° Bernard utilise E a pour déchiffrer D a (R b )- Cela permet de contrôler la signa

ture d’Alice et l’intégrité des données signées.
19° Bernard compare le R b reçu au R b qu’il a envoyé à Alice à l’étape 10.
24.10 « Privacy-Enhanced Mail » (PEM)

P E M est le standard I n t e r n e t de « Privacy-Enhanced Mail » adopté par l’« Internet
Architecture Board » (IA B ) pour offrir du courrier électronique sûr à travers le réseau
I n t e r n e t . Il a initialement été conçu par le groupe « Privacy and Security Research
Group » (P S R G ) de l’« Internet Resources Task Force » (IR T F ) et a ensuite été passé
au groupe « PEM Research Group » de l’ « Internet Engineering Task Force » (IE TF).
Les protocoles PE M offrent le chiffrement, l’authentification, l’intégrité des messages
et la gestion des clefs.
Les protocoles P E M complets ont été initialement décrits dans une série de R F C (pour
« Requests For Comments ») dans [988] et ensuite révisés dans [989]. Une troisième
révision des protocoles [990, 825, 991] est résumée dans [184, 185]. Les protocoles ont
été modifiés et améliorés, et les protocoles résultants sont détaillés dans une autre série
de R F C [992, 827, 83, 812]. Un autre article de Matthew B lS H O P [186] détaille ces
changements. Des rapports de tentatives d ’applications du P E M sont dans [601, 1509,
1526, 81, 355, 1368, 1369]. Voir aussi [1398].
P E M est un standard global. Les procédures et les protocoles P E M sont conçus pour
être compatibles avec une large gamme d ’approches de gestion de clefs, y compris les
deux schémas à clef secrète et à clef publique pour chiffrer des clefs de chiffrement
de données. La cryptographie à clef secrète est utilisée pour le chiffrement du texte
des messages. Des algorithmes de hachage cryptographique sont utilisés pour garantir
l’intégrité des messages. D ’autres documents supportent les mécanismes de gestion de
clefs utilisant des certificats à clef publique ; les algorithmes, les modes et les identifi
cateurs associés ; et les détails concernant les formats papier et électronique ainsi que
les procédures d ’infrastructure de la gestion des clefs nécessaires pour supporter ces
services.
PE M n’est prévu que pour certains algorithmes, mais accepte différentes suites d ’al
gorithmes que nous préciserons plus tard. Les messages sont chiffrés avec le DES en
mode C B C . L’authentification est fournie par ce que l’on appelle « Contrôle d ’intégrité
de Messages » (C IM ) et utilise soit M D2 soit M D5 La gestion de clefs à l’aide de
clefs secrètes peut utiliser soit le DES en mode E C B soit le DES triple, avec deux
clefs (appelé le mode E D E ). P E M supporte aussi les certificats à clef publique pour
la gestion des clefs en utilisant l’algorithme R SA (avec une clef d’au plus 1024 bits)
et la structure standard de certificat X.509.
La cryptographie de bout en bout offre trois « services à confidentialité renforcée » :
la confidentialité, l’authentification, l’intégrité des messages. Il n’y a pas de requis
spéciaux imposés au système de courrier électronique. P E M peut être incorporé sélec
tivement, par site ou par utilisateur, sans affecter le reste du réseau.
2^.10 « Privacy-Enhanced Mail » ( P E M ) 607
Documents PEM
Les spécifications du PE M proviennent de quatre documents :
RFC 1421, P a r t I, M e s s a g e E n c r y p tio n and A u th e n tic a tio n

PROCEDURES. C e d ocu m en t définit le chiffrem ent des messages et les procédures
d ’authentification nécessaires p o u r offrir sur P I n t e r n e t des services de courrier
électroniqu e à confidentialité renforcée.
- R F C 1422, P a r t II, C e r t i f i c a t e - B a s e d K e y M a n a g e m e n t . Ce document

définit l’architecture et l’infrastructure de la gestion de clefs basées sur des tech
niques de certification à clef publique afin d’offrir des informations sur les clefs
aux expéditeurs et aux destinataires de messages.
- R F C 1423, P a r t I I I , A l g o r i t h m s , M o d e s , I d e n t i f i e r s . Ce document four

nit les définitions, les formats, les références et les citations pour les algorithmes
cryptographiques, les modes d ’utilisation, ainsi que les identificateurs et para
mètres associés.
- R F C 1424, P a r t IV , K e y C e r t i f i c a t i o n a n d R e l a t e d S e r v i c e s . Ce docu
ment décrit trois types de services pour le support de P E M : la certification de
clef, le stockage de la liste des certificats révoqués (C R L ) et l’accès à cette liste.
Les certificats
PEM est compatible avec l’environnement d’authentification décrit dans [309] ; voir
aussi [828].PE M est une sur-couche de X .509 ; il établit les procédures et les conven
tions pour une infrastructure de gestion de clefs à utiliser avec P E M et, dans le futur,
avec d ’autres protocoles (à la fois des suites T C P /I P et ISO).
L’infrastructure de gestion de clefs instaure une seule source pour toutes les certifi
cations sur P I n t e r n e t . L’« Internet Policy Registration Authority » (IP R A ) édicté
tous les règlements qui s’appliquent aux certifications dans la hiérarchie. A partir de
la racine IP R A on trouve les « Policy Certification Authorities » (P C A ), dont cha
cune instaure et publie ses règlements pour l’enregistrement des utilisateurs ou des
organisations. Chaque P C A est certifiée par l’IP R A . En dessous des P C A , les C A
certifient les utilisateurs et les entités subordonnées aux organisations (tels que les dé
partements, bureaux, filiales). Initialement, la majorité des utilisateurs sont supposés
être enregistrés au sein d’une organisation.
Certaines P C A sont censées offrir la certification pour les utilisateurs qui ne font pas
partie d’une organisation. Pour les utilisateurs qui veulent préserver leur anonymat tout
en ayant accès aux avantages du courrier à confidentialité renforcée de PE M , une ou
plusieurs P C A sont prévues pour établir les règlements qui permettent l’enregistrement
d’utilisateurs ne voulant pas divulguer leur identité.
Messages PEM
Le cœur d’un message P E M est son format. La figure 24.4 montre un message chiffré en
utilisant la gestion de clefs à clef secrète ; la figure 24.5 montre un message authentifié
BEGIN PRIVACY-ENHANCED MESSAGE-----

Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: D E S - C B C ,F8143EDE5960C597
Originator-ID-Symmetric: linn@zendia.enet.dec.c o m ,,
Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3
K e y - I n f o : D E S - E C B ,R S A - M D 2 ,9FD3AAD2F2691B9A,B70665BB9BF7CBCDA60195DB94F727D3
Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4
K e y - I n f o : D E S - E C B ,RS A - M D 2 ,161A3F75DC82EF26,E2EF532C65CBCFF79F83A2658132DB47
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoHlnvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlKlZ6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
END PRIVACY-ENHANCED MESSAGE-----
F ig . 24.4 - Exemple de message encapsulé (à clef secrète)
et chiffré utilisant la gestion de clefs à clef publique et la figure 24.6 montre un message
authentifié mais non chiffré qui utilise la gestion de clefs à clef publique.
Le premier champ est « Proc-Type » qui identifie le type de traitement effectué sur le
message. Il y a trois types possibles de messages. L’identificateur « ENCRYPTED » signifie
que le message est chiffré et signé. Les identificateurs « MIC-ONLY » et « MIC-CLEAR »
indiquerait que le message est signé mais non chiffré. Les messages « MIC-CLEAR »
ne sont pas encodés et ils peuvent être lus par des logiciels non-PEM . Les messages
« MIC-ONLY » ont besoin d ’un logiciel P E M pour être transformés afin d’être lisibles par
un être humain. Un message PE M est toujours signé ; il est optionnellement chiffré.
Le champ suivant, « Content-Domain » spécifie le type de message. Il n’a rien à voir
avec la sécurité. Le champ « DEK-Info » donne ses informations sur la « Data Exchange
Key » (D E K , clef d’échange de données), l’algorithme utilisé pour chiffrer le texte et
n’importe quels paramètres associés à cet algorithme de chiffrement. Seul le DES,
ou « DES-CBC » est spécifié. Le second sous-champ spécifie l’IV. D ’autres algorithmes
pourraient à l’avenir être spécifiés pour PE M ; leur utilisation sera indiquée dans le
champ « DEK-Info » et dans d ’autres champs qui identifient les algorithmes.
Pour les messages avec gestion de clefs à clef secrète (voir figure 24.4), « O rig in a tor-
-ID-Symmetric » est le champ suivant, avec trois sous-champs. Le premier sous-champ
identifie l’expéditeur par une adresse de courrier électronique unique. Le deuxième sous-
champ est optionnel et identifie l’autorité qui a émis la clef d ’échange (l’IK décrite ci-
après). Le troisième sous-champ est un sous-champ optionnel « V e rsion /E x p ira tion ».
En continuant avec le cas de la gestion de clefs à clef secrète, à chaque destinataire sont
associés les deux champs: « R ecipient-ID -Sym m etric » et « K ey-Inf o » . Le champ
« R ecipient-ID -Sym m etric » a trois sous-champs; ils identifient le destinataire de la
même manière que le champ « O riginator-ID -Sym m etric » identifie l’expéditeur.
Le champ « K ey-Inf o » spécifie les paramètres de la gestion de clefs. Ce champ a quatre
sous-champs. Le premier sous-champ donne l’algorithme utilisé pour chiffrer la DEK.
Comme la gestion de clefs pour ce message est à clef secrète, l’expéditeur et le desti-
24-10 « Privacy-Enhanced Mail » ( P E M ) 609
BEGIN PRIVACY-ENHANCED MESSAGE-----

Proc-Type: 4,ENCRYPTED
DEK-Inf o : D E S - C B C ,BFF968AA74691A C 1
Driginator-Certificate:
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGAlUEBhMCVVMxIDAeBgNV
BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQx0DM4MTdaFw05MzA5MDMx0DM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWNlcml0eSwgSW5jLjEU
MBIGAlUEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZH17i+
yJcqDtjJCowzTdBJrdAiLAnSC+Cnnj0JELyuQiBgkGrgIh3j8/xOfM+YrsyFlu3F
LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAAlkACKr0PqphJYwlj+YPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
5XUXGx7qusDgHQGs7Jk9W8CWlfuSWUgN4w==
Key-Info: RSA,
I3rRIGXUGWAF8js5wCzRTkdh034PTHdRZY9Tuvm03M+NM7fx6qc5udixps2Lng0+
wGrtiUm/ovtKdinz6ZQ/aQ==
Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGAlUEBhMCVVMxIDAeBgNV
BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQOEwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc10TU5Wj BRMQsw
CQYDVQQGEwJVUzEgMB4GAlUEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMA0GAlUECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnp61QCxYykN10DwutF/jMJ3kL+3PjYyH0wk+/9rLg6X65B/LD4bJHt05XW
cqAz/7R7XhjYCmOPcqbdzoACZtHETrKrcJiDYoP+DkZ8klgCk7hQHpbIwIDAQAB
MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMG0x
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nB07CMxpUVRBcXUpE+x
EREZd9++32ofGBIXaiaIn0gVUn00zSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
MIC-Info: RSA-MD5.RSA,
UdFJR8u/TIGhfH65ieewe210W4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv
Aj RFbHoNPzBuxwmOAFeAOHJszL4yBvhG
Recipient-ID-Asymmetric:
MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWNlcml0eSwgSW5j
LjEPMAOGA HJECxMGQmV0YSAxMQ8wDQYDVQQLEwZ0TlRBUlk=,
66
K ey-Info: R S A ,
D6BS1ww9CTyHPt S3bMLD+L0hej dvX6QvlHK2ds2sQPEaXhX8EhvVphHYTjwekdWv
7xOZ3Jx2vTAhOYHMcqqCjA==
qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d
jIqCJAxvld2xgqQimUzoSla4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA==
FlG. 24.5 - Exemple de message encapsulé chiffré (à clef publique)
nataire doivent partager une clef commune. C ’est ce que l’on appelle l’« Interchange
Key » (IK ) qui est utilisée pour chiffrer la D E K . La D E K peut soit être chiffrée avec le
DES en mode E CB (dénoté « DES-ECB ») ou avec le DES- triple (dénoté « DES-EDE »).
Le deuxième sous-champ spécifie l’algorithme pour le CIM (M IC). Cela peut être soit
MD2 (dénoté « RSA-MD2 ») soit M D 5 (dénoté « RSA-MD5 »). Le troisième sous-champ,
BEGIN PRIVACY-ENHANCED MESSAGE--------

Proc-Type: 4,MIC-ONLY
Originator-Certificate:
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGAlUEBhMCVVMxIDAeBgNV
BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQx0DM4MTdaFw05MzA5MDMx0DM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWNlcml0eSwgSW5jLjEU
MBIGAlUEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZH17i+
yJcqDtjJCowzTdBJrdAiLAnSC+Cnnj0JELyuQiBgkGrgIh3j8/x0fM+YrsyFlu3F
LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAAlkACKr0PqphJYwlj+YPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
5XUXGx7qusDgHQGs7 Jk9W8 CW 1f u SWUgN4w==
Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGAlUEBhMCVVMxIDAeBgNV
BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQ0EwHhcN0TEw0TAxMDgwMDAwWhcN0TIw0TAxMDcl0TU5WjBRMQsw
CQYDVQQGEwJVUzEgMB4GAlUEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMA0GAlUECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnp61QCxYykN10DwutF/jMJ3kL+3PjYyH0wk+/9rLg6X65B/LD4bJHt05XW
cqAz/7R7XhjYCmOPcqbdzoACZtHETrKrcJiDYoP+DkZ8klgCk7hQHpbIwIDAQAB
MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMG0x
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nB07CMxpUWRBcXUpE+x
EREZd9++32ofGBIXaialn0gVUn00zSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
MIC-Info: R S A - M D 5 ,R S A ,
jV20fH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZA0VRZ5q5+Ej15bQvqNeqOUNQj r6
EtE7K2QDeVMCyXsdJlA8fA==
LSBBIGllc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3dpbmcgaXMg
YSBibGFuayBsaW510g0KDQpUaGlzIGlzIHRoZSBlbmQuDQo=
F i g . 24.6 - Exemple de message M IC -ONLY encapsulé (à clef publique)
la D EK , et le quatrième sous-champ, le CIM , sont tous deux chiffrés avec l’IK.

Les figures 24.5 et 24.6 montrent des messages avec une gestion de clefs à clef pu
blique (appelée « asymétrique » en nomenclature P E M ). Les en-têtes sont différents.
Dans les messages « ENCRYPTED », après le champ « DEK-Info », vient le champ
« Originator-Certif icate ». Le certificat est conforme au standard X .509 (voir
§ 24.9). Le champ suivant est « Key-Info » qui comporte deux sous-champs. Le pre
mier spécifie l’algorithme à clef publique utilisé pour chiffrer la D E K ; actuellement
seul le R SA est offert. Le second sous-champ est la D EK chiffrée avec la clef publique
de l’expéditeur. C’est un champ optionnel, destiné à permettre à l’expéditeur de dé
chiffrer son propre message dans le cas où celui-ci serait renvoyé à l’expéditeur par le
système de courrier. Le champ suivant « Issuer-Certif icate » est le certificat de
celui qui a signé le « Originator-Certif icate ».
En continuant avec le cas de la gestion de clefs à clef publique, le champ suivant
est « MIC-Info » Le premier sous-champ donne l’algorithme utilisé pour calculer le
CIM . Le deuxième sous-champ désigne l’algorithme avec lequel le CIM a été signé. Le
24-10 « Privacy-Enhanced Mail » / P E M ) 611
troisième sous-champ contient le C IM signé avec la clef privée de l’expéditeur.

Toujours avec la gestion de clefs à clef publique, les champs suivants décrivent les
destinataires. « Recipient-ID-Asymmetric » et « Key-Info » sont deux champs pré
sents pour chaque destinataire. Le champ « Recipient-ID-Asymmetric » a deux sous-
champs. Le premier identifie l’autorité qui a émis la clef publique du destinataire ; le
second est un sous-champ optionnel « Version/Expiration » Le champ « Key-Info »
spécifie les paramètres de la gestion de clefs: le premier sous-champ identifie l’algo
rithme utilisé pour chiffrer le message et le second sous-champ est la DEK chiffrée
avec la clef publique du destinataire.
Sécurité de PEM
Les clefs R S A dans PE M peuvent avoir de 508 à 1024 bits. Cela devrait être assez long
pour les besoins de sécurité de n ’importe qui. Une attaque plus probable serait contre
le protocole de gestion des clefs. Martin peut voler votre clef privée ne l’écrivez
jamais nul part ou bien il peut essayer de vous duper en vous faisant accepter une
fausse clef publique. Les règles de certification des clefs de PE M rendent improbable
une telle attaque pour autant que les utilisateurs suivent scrupuleusement les bonnes
procédures, mais les gens ont une tendance naturelle à être négligents.
Une attaque plus insidieuse consisterait pour Martin à modifier la réalisation de P E M
qui tourne sur votre système. La réalisation modifiée pourrait subrepticement envoyer
à Martin tout votre courrier chiffré avec sa clef publique. Il pourrait même s’envoyer
une copie de votre clef privée. Si la réalisation modifiée fonctionne correctement, vous
ne serez pas au courant de ce qui se passe.
U n’y a pas de vrai moyen de se prémunir contre ce genre d’attaque. Vous pouvez utiliser
une fonction de hachage à sens unique pour associer une empreinte à l’exécutable de
PEM . Ainsi, chaque fois que vous l’exécutez vous pouvez vérifier l’empreinte pour
détecter une modification éventuelle. Mais Martin peut modifier le code de calcul de
l’empreinte en même temps qu’il modifie le code de PE M . Vous pourriez calculer
l’empreinte de l’empreinte, mais Martin peut modifier cela aussi. En fait, si Martin a
accès à votre machine, il peut subvertir la sécurité de PEM .
La morale de cette histoire est que vous ne pouvez jamais vraiment faire confiance
à un morceau de logiciel si vous ne pouvez pas avoir confiance dans la machine qui
l’exécutera. Pour la plupart des gens, ce type de paranoïa est injustifié. Pour d ’autres,
c’est très concret.
T IS/P E M
T r u s t e d I n f o r m a t i o n S y s t e m s , partiellement subventionnée par l’agence « Advan
ced Research Projects Agency » du Gouvernement américain, a conçu et réalisé une

référence de PE M (T IS /P E M ). Développée pour des plates-formes U NIX, elle a éga
lement été portée sous V M S, M S- D O S et MS W i n d o w s .
Bien que la spécification P E M n’indique qu’une seule hiérarchie de certification pour
l’iN T E R N E T , T IS /P E M autorise l’existence de plusieurs hiérarchies de certification.
Les sites peuvent spécifier un ensemble de certificats qui doivent être considérés comme
valides, y compris les certificats émis par eux-mêmes. Un site n’est pas obligé de se
joindre à la hiérarchie In t e r n e t pour utiliser T IS /P E M .
T IS /P E M est actuellem ent disp on ib le p o u r tou tes les organisations et tou s les citoyens
am éricains et canadiens qui en fon t la dem ande. T IS /P E M est distribué sous form e de
co d e source. Les personnes intéressées doivent co n ta cte r : P r iv a c y -E n h a n c e d M a il,
T r u s te d I n fo r m a t io n S y s te m s , I n c . , 3060 W a sh in g ton Road (R t e . 9 7 ) ,
G len w ood , MD 2 1 7 3 8 , USA; +1 (3 0 1 ) 8 5 4 - 6 8 8 9 ; F a x: +1 (3 0 1 ) 8 5 4 - 5 3 6 3 ;
I n t e r n e t : p e m -in fo @ t is .c o m .
RIPEM
R IP E M est un programme écrit par Mark R i o r d a n qui réalise les protocoles PEM.
Bien que ce programme ne soit pas techniquement pas dans le domaine public, il est
disponible publiquement et peut être utilisé sans paiement de royalties pour les appli
cations à usage individuel non commerciales. Une licence d’exploitation accompagne
la documentation.
Le code ne peut pas être exporté hors des Etats-Unis et du Canada. Naturellement, les
lois du Gouvernement américain ne s’appliquent pas hors des Etats-Unis et les gens ont
ignoré les règles d ’exportation. Le code de R IP E M est disponible à travers le monde
entier sur des tableaux d ’affichage. Le R IP E M /S IG , qui ne fait que des signatures
digitales, est exportable.
A la parution de ce livre, R IPE M n’est pas une réalisation complète des protocoles
PE M ; il ne réalise pas les certificats pour les clefs d ’authentification.
Avant d’écrire R IP E M , R i o r d a n a écrit un programme similaire appelé R PE M . Ce
dernier devait être un programme du domaine public de courrier électronique chiffré.
Pour éviter les problèmes de brevet, R i o r d a n avait utilisé l’algorithme de R a b i n (voir
§ 19.5). Mais P u b l i c K e y P a r t n e r s prétendit que leurs brevets sont assez larges
pour couvrir toute la cryptographie à clef publique et a menacé d’attaquer en justice ;
R i o r d a n a arrêté de distribuer R PE M .
R P E M n ’est plus vraim ent utilisé. Il n ’est pas com patible avec R IPE M . Com m e
R IP E M peut être utilisé avec la bénédiction de P u b l i c K e y P a r t n e r s , il n ’y a
pas de raison de lui préférer R PE M .
24.11 « Message Security Protocol » (MSP)

Le « Message Security Protocol » (abrégé M SP) est l’équivalent militaire de PEM . Il a
été développé par la NSA à la fin des années 80 dans le cadre du programme « Secure
Data Network System » (abrégé SDNS). C ’est un protocole compatible X .400 au
niveau des applications pour protéger le courrier électronique. Le M SP sera utilisé
pour signer et chiffrer les messages au sein du réseau « Defense Message System »
(D M S) du Département de la Défense américaine.
Le protocole « Preliminary Message Security Protocol » (P M S P ), destiné à être utilisé
pour des messages non classés mais sensibles, est une version adaptée pour fonctionner
avec X .400 et T C P /I P . Ce protocole est également appelé « Mosaic ».
Tout comme pour P E M , les applications logicielles M SP et PM SP sont flexibles et
conçues pour adapter une variété d ’algorithmes à des fonctions de sécurité, y compris
la signature, le hachage et le chiffrement. P M SP fonctionnera avec la puce C a p s t o n e
(voir § 24.17).
24-i 2 « Pretty Good Privacy » (PGP) 613
24.12 « Pretty Good Privacy » (PGP)

P r e t t y G o o d P r i v a c y (P G P ) est un programme gratuit de protection du courrier
électronique conçu à l’origine par Philip ZlMMERMANN [1654|J1. P G P utilise IDEA
pour le chiffrement, R SA (avec des clefs allant jusqu’à 2047 bits) pour la gestion des
clefs et les signatures digitales, et M D5 comme fonction de hachage à sens unique.
Les clefs publiques aléatoires P G P utilisent un test de primalité probabiliste et ob
tiennent leurs germes initiaux en mesurant les intervalles entre les touches frappées
au clavier par l’utilisateur. P G P engendre des clefs ID E A aléatoires en utilisant la
méthode présentée dans l’annexe C du document ANSI X 9.17 (voir § 8.1) [57], avec
ID E A comme algorithme à clef secrète au lieu du DES. P G P chiffre également la clef
privée de l’utilisateur en utilisant l’empreinte d’une phrase clef au lieu d’un mot de
passe.
Les messages chiffrés par P G P ont une structure de sécurité en couches. La seule chose
qu’un cryptanalyste puisse apprendre d ’un message chiffré est l’identité de l’expéditeur,
pour autant qu’il connaisse l’identificateur de la clef du destinataire. Ce n’est qu’après
que le destinataire a déchiffré le message qu’il peut apprendre qui l’a signé, s’il est signé.
Comparez cette approche à P E M qui laisse quand même un bon nombre d’informations
dans l’en-tête sous forme non chiffrée concernant l’expéditeur, les destinataires et le
message lui-même.
L’aspect le plus intéressant de P G P est son approche à la gestion de clefs distribuée
(voir § 8.12). Il n’y a pas d ’autorité de certification ; P G P a instauré à la place un
climat de confiance. Chaque utilisateur engendre et distribue sa propre clef publique.
Les utilisateurs signent mutuellement leur clefs publiques, créant ainsi une communauté
d’utilisateurs de P G P interconnectés.
Par exemple, Alice peut donner physiquement sa clef publique à Bernard. Il connaît
Alice et donc signe sa clef publique. Puis il lui redonne la clef signée et en garde une
copie. Quand Alice veut communiquer avec Christine, elle lui envoie une copie de la
clef que Bernard a signée. Christine, qui a déjà la clef publique de Bernard (elle l’a
eue à un autre moment) et qui fait confiance à Bernard pour certifier les clefs d’autres
personnes, vérifie sa signature sur la clef d’Alice et l’accepte. Bernard a présenté Alice
à Christine.
P G P n ’a pas mis en place de politique en ce qui concerne la confiance ; les utilisateurs
sont libres de décider à qui ils font confiance et à qui ils ne font pas confiance. P G P
fournit les mécanismes pour associer la confiance aux clefs publiques et pour utiliser
cette confiance. Chaque utilisateur a toute une collection de clefs publiques signées qu’il
garde dans un fichier appelé a n n e a u d e c le fs p u b liq u e s . Chaque clef de ce réseau a
un champ de validité de clef qui indique le niveau auquel l’utilisateur particulier fait
confiance en la validité de la clef. Plus le niveau de confiance est élevé, plus l’utilisateur
pense que la clef est valide. Un champ de confiance de signature indique le niveau de
confiance accordé au signataire pour certifier les clefs publiques d ’autres utilisateurs.
Enfin, un champ de confiance du propriétaire indique le niveau auquel l’utilisateur
particulier fait confiance au propriétaire de la clef pour signer d’autres clefs publiques ;
ce champ est géré manuellement par l’utilisateur.
11. P G P n ’est pas dans le dom aine public. Il porte un copyright de Philip ZlMMERMANN et il est
disponible librem ent suivant les termes de la « “ C o p y le ft ” G e n e r a l P u b lic L ic e n s e » de la FREE
S o f t w a r e F o u n d a tio n .
Chapitre 24 Exemples de réalisation
La figure 24 7 montre ce à quoi un tel modèle pourrait ressembler pour un utilisateur

particulier, Alice. La clef d ’Alice est au sommet, la valeur de confiance du propriétaire
est maximum. Alice a signé les clefs de Bernard, Christine, David, Etienne et Francis.
Elle fait confiance à Bernard et à Christine, et partiellement confiance à David et à
Etienne, pour signer les clefs publiques d ’autres personnes. De même, elle fait confiance
à Gabrielle, même si elle n’a pas elle-même signé sa clef.
F ig . 2 4 .7 - Modèle de confiance de PGP
Deux signatures dignes de confiance peuvent être suffisantes pour certifier une clef.
Alice pense que la clef de Karine est valide car David et Etienne l’ont signée. Ce n’est
pas automatique avec P G P ; Alice peut régler son propre niveau de paranoïa.
Ce n’est pas parce qu’Alice croit qu’une clef est valide qu’elle doit lui faire confiance
pour signer les clefs d’autres personnes. Elle ne fait pas confiance à Francis pour signer
les clefs publiques d ’autres personnes, même si elle a elle-même signé sa clef. Elle ne
fait pas confiance en la signature de Jean sur la clef de Martin, ni en celle de Karine
24-13 Cartes à puce 615
sur la clef de Nathalie.

La clef d ’Olivier ne marche nulle part sur le réseau; peut-être qu’Alice l’a eue sur un
serveur de clefs. P G P pense que la clef n’est pas valide ; Alice doit soit déclarer la clef
valide, soit décider de faire confiance à l’un des signataires de la clef.
Bien entendu, rien n’empêche Alice d’utiliser la clef en laquelle elle n’a pas confiance. Le
travail de P G P est de l’alerter que la clef n’est pas digne de confiance, pas d’empêcher
les communications.
Le lien le plus vulnérable de tout ce système est la révocation de clefs : il est impossible
de garantir que personne n’utilisera une clef compromise. Si la clef privée d’Alice est
volée, elle peut envoyer ce qu’on appelle un C E R T I F I C A T D E R É V O C A T I O N D E C L E F ,
mais comme la distribution des clefs est ad hoc et suit largement le bouche à oreille, il
n’y a pas de garantie que ce certificat atteindra quiconque a sa clef publique sur son
réseau. De plus, comme Alice doit signer le certificat de révocation avec sa clef privée,
si elle 1’ a perdue, elle ne peut pas la révoquer.
La dernière version de P G P est 2.6.2. Une nouvelle version, P G P 3.0 est prévue pour
la fin 1995. Les changements dans la version 3.0 inclut des options pour les algorithmes
DES, SH A et de clefs publiques, une séparation du chiffrement et de la signature des
paires « clef publique / clef privée », une amélioration des procédures de révocation
des clefs, de meilleures fonctions de gestion de réseau de clefs, un A P I pour intégrer
P G P dans d ’autres programmes et un code de base complètement réécrit.
P G P est disponible sous M S -D O S , U NIX, M a c i n t o s h , A m i g a et A t a r i . Il est
gratuit pour un usage personnel, à usage non commercial, et est disponible sur de
nombreux sites ftp d’Internet. Pour charger P G P du M IT , accédez à getpgp sur
net-dist.mit.edu, répondez aux questions puis transférez et changez le nom dans la
séance telnet. Il est aussi disponible sur ftp.ox.ac.uk, ftp.dsi.unimi.it, ftp.demon.co.uk,
CO M PU SERVE, A O L , etc. Pour les utilisateurs commerciaux américains, P G P peut être
acheté - avec licence - pour à peu près 100 dollars auprès de l’entreprise ViaCrypt, 9033
N 24th Ave., Phoenix, AZ, 85021 ; +1 (602) 944 0773 ; viacrypt@acm.org. Plusieurs
shareware sont disponibles pour aider à l’intégration de P G P sous M S -D O S , WIN
DOWS, M a c i n t o s h et UNIX.
Il existe plusieurs livres sur P G P [604, 1398, 1502]. Le code source a même été publié
dans un livre [1655] dans le seul but de frustrer le Département d ’Etat américain qui
soutient encore que le code source est exportable sur papier mais pas électroniquement.
En supposant que vous faites confiance à ID E A , P G P est sans aucun doute le système
de chiffrement le plus proche de la classe militaire.
24.13 Cartes à puce

Une carte à puce est une carte en plastique de la taille d’une carte de crédit avec une
puce électronique. C ’est une vieille idée (les premiers brevets ont été déposés il y a
20 ans), mais des limitations pratiques ne les ont rendues faisables qu’il y a environ
cinq ans. Depuis, elles ont littéralement explosé, surtout en Europe. Beaucoup de pays
utilisent des cartes à puce dans les cabines téléphoniques. Il y a aussi des cartes de crédit
à puce, ainsi que des cartes à puce pour d ’autres usages. Les compagnies américaines
de cartes de crédit étudient cette technologie, et d’ici quelques années, les américains
auront des cartes à puce dans leurs portefeuilles.
Une carte à puce contient un petit ordinateur (habituellement un microprocesseur

à 8 bits), de la R A M (à peu près un quart de kilo-octet), de la R O M (environ 6
à 8 kilo-octets) et soit de l’E P R O M ou de l’E E P R O M (quelques kilo-octets). Les
générations futures de cartes à puce auront sans aucun doute plus de capacité, mais
des limitations physiques rendent son expansion difficile. La carte a ses propres système
d’exploitation, programmes et données. (Ce qu’elle n’a pas est la puissance ; ce qu’elle
obtient néanmoins lorsqu’on la branche à un lecteur.) De plus, elle est sûre. Dans un
monde où vous ne pouvez pas faire confiance à l’ordinateur, au téléphone ou à quoi
que ce soit de quelqu’un d’autre, vous pouvez toujours avoir confiance en une carte que
vous gardez avec vous dans votre portefeuille.
Les cartes à puce peuvent avoir différents protocoles et algorithmes cryptographiques
préprogrammés. Elles peuvent être configurées en porte-monnaie électronique et rece
voir ou dépenser de l’argent électronique. Elles peuvent opérer avec des protocoles d ’au
thentification à divulgation nulle ; elles peuvent avoir leurs propres clefs de chiffrement.
Elles pourraient signer des documents, déverrouiller des applications sur ordinateur.
Quelques cartes à puce sont censées être inviolables ; cela protège souvent l’institution
qui a fournit les cartes. Une banque ne voudrait sûrement pas que vous puissiez pirater
ses cartes à puce afin de détourner de l’argent.
Les cartes à puce sont très intéressantes et beaucoup d’information à leur sujet sont
disponibles. Un bon article sur la cryptographie dans les cartes à puce est [673].
« CARTES » est une conférence qui se tient à Paris chaque mois d’octobre et
« CardTech » se tient à Washington, D.C. en avril. Les tenues de deux autres confé
rences sur les cartes à puce sont [35, 3]. Il y a des centaines de brevets sur les cartes à
puce, la plupart déposés par des entreprises européennes. Un article intéressant sur les
applications futures possibles (vérification d ’intégrité, pistes d’audit, protection contre
la copie, argent électronique, adressages sûrs) est [1630].
24.14 « Public-Key Cryptography Stan

dards » (PKCS)
Les PK C S, standards de la cryptographie à clef publique, sont les fruits d ’une tentative
de R S A D a t a S e c u r i t y , I n c . pour fournir une interface standard industrielle pour
la cryptographie à clef publique. D ’habitude, ce type de démarche est effectué par
ANSI, mais, en considérant la situation politique en ce qui concerne la cryptographie,
les gens de R SA D S I ont préféré le faire eux-même. En travaillant en collaboration
avec de nombreuses entreprises, ils ont développé une série de standards. Certains sont
compatibles avec d’autres, mais pas tous.
Ce ne sont pas des standards dans le sens propre du terme ; aucun office de standar
disation ne s’est réuni pour voter PK C S. C'est apparemment R SA D SI qui « détient
le seul pouvoir de décision sur ses standards, et ils publierons des révisions en temps
voulu » [811].
Néanmoins, il y a là beaucoup de choses intéressantes. Si vous ne savez pas quelle
syntaxe ou quelle structure de données utiliser pour programmer de la cryptographie à
clef publique, ces standards sont sans aucun doute aussi bon que n’importe quel autre.
Qui plus est, comme ce ne sont pas de vrais standards, vous pouvez les modifier à
volonté afin qu’ils répondent à vos besoins.
24-14 * Public-Key Cryptography Stan-
« dards » ('PKCS ) 617
Les lignes suivantes décrivent brièvement chaque P K C S (PK C S # 2 et PK C S # 4 ont

été inclus dans P K C S # 1 ) .
PKCS # 1 [919] décrit une méthode pour le chiffrement et le déchiffrement R SA ,
principalement pour construire les signatures et les enveloppes électroniques décrites
dans PK C S # 7 . Pour les signatures électroniques, le message est haché puis chiffré
avec la clef privée du signataire. Le message et le hachage sont représentés ensemble
comme on l’explique dans P K C S # 7 . Pour les enveloppes électroniques (messages
chiffrés), le message est d’abord chiffré avec un algorithme à clef secrète, et la clef du
message est chiffrée avec la clef publique du destinataire. Les message et clef chiffrés sont
représentés ensemble conformément à la syntaxe de P K C S # 7 . Ces deux méthodes sont
compatibles avec les standards PE M . P K C S # 1 décrit aussi une syntaxe, identique
à celle de X .509 et de PE M , pour les clefs publiques et privées RSA et pour les trois
algorithmes de signature (M D 2 et R SA , M D4 et R SA , M D5 et R S A ) signant les
certificats.
PK C S # 3 [921] décrit une méthode pour appliquer l’échange de clefs de « Diffie-
Hellman ».
PKCS # 5 [922] décrit une méthode pour chiffrer des messages avec une clef secrète
dérivée d’un mot de passe. Elle utilise soit M D2 soit M D 5 pour dériver la clef du
mot de passe, et chiffre avec le DES en mode C B C . Cette méthode est essentiellement
vouée à chiffrer les clefs privées quand on les transfère d ’un système informatique vers
un autre, mais peut être utilisée pour chiffrer des messages.
PK C S # 6 [923] décrit une syntaxe standard pour les certificats à clef publique. La
syntaxe est une sur-couche d’un certificat X.509, ainsi ce type de certificat peut être
extrait si nécessaire. Bien plus que l’ensemble X .509, des qualités supplémentaires
étendent le processus de certification au-delà de la seule clef publique. Celles-ci incluent
d’autres informations, telle que l’adresse électronique.
PK C S # 7 [924] est une syntaxe générale pour des données qui peuvent être chiffrées
ou signées, telles que des enveloppes ou des signatures électroniques. La syntaxe est
récursive, ainsi les enveloppes peuvent être empilées, ou quelqu’un peut signer des don
nées déjà chiffrées. La syntaxe a aussi d’autres qualités, telle que la datation, pour être
authentifiée avec le contenu du message. P K C S # 7 est compatible avec PE M et les
messages signés et chiffrés peuvent être convertis en messages P E M sans aucune opéra
tion cryptographique, et vice-versa. PK C S # 7 supporte de nombreuses architectures
(PE M en est une) pour la gestion de clefs de certificats.
PK CS # 8 [925] décrit une syntaxe pour l’information à clef privée (incluant une clef
privée et un ensemble de qualités) et une syntaxe pour les clefs privées chiffrées. PK CS
# 5 peut être utilisé pour chiffrer l’information à clef privée.
PK C S # 9 [92G] définit les types de qualités sélectionnées pour les certificats étendus
de PK C S # 6 , les messages signés électroniquement de PK C S # 7 et l’information à
clef privée de P K C S # 8 .
PK C S # 1 0 [920] décrit une syntaxe standard pour les demandes de certification.
Une certification comprend un nom, une clef publique et (en option) un ensemble de
qualités, collectivement signés par la personne à la demande de la certification. Les
demandes de certification sont envoyées à une autorité de certification qui transforme
la demande soit en un certificat à clef publique X.509, soit en un certificat P K C S # 6 .
PK C S # 1 1 [927], le bon cryptographique au standard A P I, spécifie une interface-
programme appelée « Cryptoki » pour les matériels cryptographiques portables de
tout genre. « Cryptoki » présente un modèle commun de logique, permettant aux

applications de réaliser des opérations cryptographiques sur du matériel portable sans
connaître les détails de la technologie servant de base. Le standard définit aussi le profil
des applications : ensembles d ’algorithmes qu’un matériel peut accepter.
P K C S # 1 2 [928] décrit une syntaxe pour stocker dans un logiciel les clefs publiques
d’un utilisateur, les clefs privées protégées, les certificats et d’autres informations cryp
tographiques. Le but est de standardiser un dossier à clef secrète parmi toute une variété
d’applications.
Ces standards sont détaillés mais pas exhaustifs. Beaucoup de sujets sont hors
de leurs champs d ’action : le problème de la nomination, des considérations non-
cryptographiques concernant la certification, les longueurs de clefs et les conditions
de différents paramètres. Ce que le P K C S fournit sont un format pour transférer des
données basées sur la cryptographie à clef publique et une infrastructure pour supporter
ce transfert.
24.15 Système de paiement électronique

universel
Le système de paiement électronique universel (UEPS pour « Universal Electronic
Payment System ») est une carte à puce bancaire, à l’origine développée pour les
parties rurales de l’Afrique du Sud, mais finalement adoptée par toutes les banques
majeures du pays. Au début 1995, environ 2 millions de cartes ont été distribuées dans
ce pays. Elle a aussi été adoptée en Namibie et est distribuée par au moins une banque
en Russie.
Le système procure une carte à débit sûre, bien adaptée dans des régions où le sys
tème téléphonique déficient ne permet pas la vérification en ligne. Les clients et les
commerçants ont des cartes ; les clients utilisent leurs cartes pour transférer de l’argent
vers les commerçants. Ces derniers mettent alors leurs cartes dans un téléphone et
déposent l’argent sur leurs comptes bancaires ; les clients peuvent mettre leurs cartes
dans un téléphone et transférer de l’argent sur leur carte. Le but n’est pas de garder
l’anonymat, mais d’empêcher la fraude.
Voici le protocole de communication entre la cliente Alice et le marchand Bernard. (En
fait, Alice et Bernard branchent juste leur carte dans une machine et attendent que la
transaction se fasse.) Quand Alice a reçu sa carte pour la première fois, on lui a donné
une paire de clefs K\ et K 2 ; la banque les calcule à partir de son nom et de quelques
fonctions secrètes. Seules les cartes des commerçants ont les secrets nécessaires pour
opérer avec les clefs des clients.
1° Alice envoie à Bernard son nom à elle, A, son nom à lui, B , et un nombre
aléatoire, Ra, chiffré en utilisant le DES : d ’abord avec K 2 puis avec K\. Elle
lui envoie aussi son nom en clair.
A , E k 1 ( E k 2 ( A , B , Ra ))•
2° Bernard calcule K i et K 2 à partir du nom d ’Alice. Il déchiffre le message,

confirme que A et B sont corrects, puis chiffre le second message en clair
d’Alice avec K 2.
24-15 Système de paiement électronique universel 619
E k 2(A, B, Ra ).
Bernard n’envoie pas ce message à Alice; 56 bits du texte chiffré deviennent

K 3. Bernard envoie à Alice son nom à lui, son nom à elle et un autre nombre
aléatoire, R b , chiffré en utilisant le DES : d’abord avec K 3 puis avec K\.
E k i (E k 3(B ,A,Rb ))-
3° Alice calcule K 3 de la même manière que Bernard. Elle déchiffre le message de

Bernard, confirme que B et A sont corrects, puis chiffre le message en clair de
Bernard avec K 3.
E k 3(B, A, Rb )-
Alice n’envoie pas ce message à Bernard; 56 bits du texte chiffré deviennent

K, i- Alice envoie à Bernard son nom à elle, son nom à lui et un contrôle digital,
C . Ce contrôle contient les noms de l’envoyeur et du destinataire, une date,
un contrôle de nombre, un montant et deux C A M , tous chiffrés avec le DES :
d’abord avec K 4 puis avec K\. Un des C A M peut être vérifié par la banque
d’Alice, et l’autre peut seulement être vérifié par le centre d’autorisation. Alice
débite son compte du montant correcte.
E Kl (E k 4(A,B,C)).
4 ° Bernard calcule K 4 de la même manière que Alice. Si tous les noms et le

contrôle correspondent, il l’accepte pour le paiement.
Un aspect très intéressant de ce protocole est que la clef de chiffrement pour chaque
message dépend du message précédent. Chaque message double en tant qu’authentifiant
de tous les précédents messages. Ceci implique qu’on ne peut pas rejouer un ancien
message ; le destinataire ne pourrait jamais le déchiffrer. Je suis enthousiasmé par cette
idée et espère qu’elle sera plus largement utilisée une fois qu’elle sera plus connue.
Un autre aspect très intéressant de ce protocole est qu’il oblige les applications à être
correctes. Si le concepteur de l’application n ’introduit pas correctement le protocole, il
ne marchera pas.
Les deux cartes gardent en mémoire le relevé de toutes les transactions. Quand les
cartes sont mises en ligne pour communiquer avec la banque (quand le commerçant
dépose son argent et que le client en retire), la banque charge ce relevé dans un but de
contrôle.
La puce résistante à l’investigation empêche les participants d’altérer les données;
Alice ne peut pas changer la valeur de sa carte. Des recherches intensives fournissent
les données pour identifier et tracer les transactions frauduleuses. U y a des secrets
universels dans les cartes (les clefs C A M dans les cartes-clients, les fonctions pour
convertir les noms des clients en K± et K 2 dans les cartes-commerçants) mais ils sont
supposés être difficile à découvrir.
Ce schéma n’est pas supposé être parfait, simplement plus sûr que les traditionnels
contrôles sur papier ou cartes de débit. La menace de la fraude ne vient pas de puis
sances militaires rivales, mais de clients et commerçants opportunistes. UEPS protège
contre ce type d ’abus.
L ’échange de messages est un excellent exemple de protocole robuste : chaque message
nomme les deux parties, inclut des informations uniques pour confirmer l’actualité et
dépend explicitement de tous les messages précédents.
24.16 Clipper
La puce C l i p p e r (aussi appelée M Y K -7 8 T ) a été conçue par la NSA, est du type VLSI
résistante à l’investigation et est dédié au chiffrement des conversations vocales ; c’est
une des deux puces qui applique le standard de chiffrement par clefs sous dépôt (EES
pour « Escrowed Encryption Standard ») du gouvernement américain [1173], VLSI
Technologies, Inc. fabrique la puce, et Mykotronx, Inc. la programme. Pour commencer,
la puce C l i p p e r sera intégrée dans le modèle 3600 du dispositif de sécurité du téléphone
d ’A T & T (voir § 24.18). La puce utilise l’algorithme de chiffrement S K IP J A C K (voir
§ 13.12), conçu par la NSA et classé algorithme secret de chiffrement de clefs, en mode
O F B seulement.
L’aspect le plus controversé de la puce C l i p p e r , et de tout l’EES, est le protocole de
dépôt de clef (voir § 4.14). Chaque puce a une clef spéciale, qui n’est pas nécessaire pour
les messages. Cette clef est utilisée pour chiffrer une copie de la clef utilisée par chaque
utilisateur pour chiffrer ses messages. Lors du processus de syncronisation, la puce
C l i p p e r émettrice génère et envoie un champ d’accès de respect de la loi (L E A F pour
« Law Enforcement Access Field ») à la puce C l i p p e r réceptrice. Le L E A F contient
une copie de la clef de séance courante, chiffrée avec une clef spéciale (appelée clef
d ’unité). Ceci permet au personnel du gouvernement12 de découvrir la clef de séance
et ainsi d’écouter le contenu de la conversation.
D ’après le directeur du N IST [802] :
« Un système de « dépôt de clefs » est prévu de manière à ce que la « puce

C l i p p e r » soit utilisée pour protéger la vie privée des citoyens américains
respectueux des lois. Chaque dispositif contenant la puce aura deux « clefs »
uniques, des nombres qui seront nécessaires aux agences autorisées du gou
vernement pour déchiffrer les messages chiffrés avec le dispositif. Quand le
dispositif sera fabriqué, les deux clefs seront déposées séparément dans deux
bases de données de dépôt de clefs mises en place par l’attorney général.
L’accès à ces clefs sera limité aux officiels du gouvernement qui disposent
d’une autorisation légale pour placer une écoute. »
Le gouvernement veut aussi encourager la vente de téléphones équipés de cette puce à

l’étranger ; personne ne sait ce qui pourrait arriver à ces bases de données de dépôt de
clefs.
En laissant de côté la politique, la structure interne du LE A F vaut la peine que nous
nous y attardions [802, 1174, 1596, 465, 114, 468]. Le LE A F est une chaîne de 128 bits
qui contient assez d’informations pour permettre aux services de sécurité de trouver
12. N o te d u tra d u cte u r : il s ’a g it ici d u G o u v e rn e m e n t a m érica in , d u m oin s ju s q u ’ à p résent.
24-16 C l ip p e r 621
la clef de session, K s , en supposant que les deux agences d e d é p ô t de clefs en

charge des bases de données coopèrent. Le L E A F contient un identifiant d’unité de
32 bits, U, unique pour la puce C l i p p e r . Il contient aussi la clef de séance courante
de 80 bits chiffrée avec la clef d’unité unique de la puce, Kjj, et une somme de contrôle
de 16 bits, C , appelée identifiant de dépôt. Cette somme de contrôle est une fonction
de la clef de séance, de l’IV et probablement d’autres informations. Ces trois champs
sont chiffrés avec une famille fixe de clefs, K f , partagée par toutes les puces C l i p p e r
interopérables. La famille de clefs, les modes de chiffrement utilisés, les détails de la
somme des contrôles et la structure exacte du L E A F sont tous secrets. Cela ressemble
probablement à:
E k , ( E K u ( K s ,U,C))
K f est programmé dans la puce C l i p p e r au niveau de l’usine. Cette clef est alors divi
sée en deux (voir § 3.5) et est stockée dans deux bases de données de dépôt différentes,
gardées par deux agences de dépôt différentes.
Si Estelle veut obtenir K s à partir du L E A F , elle doit d’abord déchiffrer le LEAF
avec Kp et retrouver U. Puis elle doit présenter un ordre judiciaire à chaque agence
de dépôt, qui chacune lui donnera une moitié de K f pour le U donné. Estelle combine
par ou exclusif les deux moitiés pour obtenir K f , puis elle utilise K f pour obtenir
K s , et K s pour espionner la conversation.
La somme de contrôle est conçue de façon à ce que personne ne puisse contourner ce
schéma ; la puce C l i p p e r réceptrice ne déchiffrera pas si cette somme de contrôle ne
correspond pas. Néanmoins, il n’y a que 216 valeurs possibles de sommes de contrôle, et
un faux LE A F avec une somme de contrôle correcte mais avec une mauvaise clef peut
être trouvé en à peu près 42 minutes [195]. Ce qui n’est pas d’une très grande efficacité
pour les conversations vocales en mode C l i p p e r . D u fait que le protocole d’échange
de clefs n’est pas partie intégrante de la puce C l i p p e r , une attaque exaustive de 42
minutes doit être menée après l’échange de clefs ; elle ne peut pas être menée avant
l’appel téléphonique. Cette attaque peut fonctionner lors de transmissions de facsimilés
ou avec la carte Fortezza (voir § 24.17).
En principe, la puce C l i p p e r est résistante à l’investigation « contre des adversaires
très sophistiqués et très bien financés » [1174], mais des rumeurs disent que les « Sandia
National Laboratories » ont réussi. Même si ces rumeurs sont fausses, je suis persuadé
que le plus grand constructeur de puces dans le monde peut violer la puce C l i p p e r ;
c’est juste une question de temps avant que quelqu’un avec la bonne combinaison de
ressources et d’éthiques n’y arrive.
D’énormes problèmes de respect de la vie privée sont associés à ce schéma. Il y a de
nombreux groupes défenseurs de la liberté civile qui luttent activement contre tout
mécanisme de dépôt de clef qui donnerait le droit au gouvernement d’espionner les
citoyens. Mais le problème est que cette idée n’est jamais passée par le Congrès; le
NIST a publié le standard de chiffrement par clefs sous dépôt en tant que FIPS [1173],
court,-cicuitant ainsi cet irritant processus législatif. A l’heure actuelle, il semble que
l’EES meurt d’une mort lente et douce, mais les standards ont leur manière de vous
surprendre.
Le tableau 24.2 donne la liste des différentes agences participant à ce programme.
Quelqu’un veut-il porter un jugement critique sur le fait que les deux agents de dépôts
soient dans la branche exécutive, ou sur le fait qu’ils ne connaissent rien à propos des
demandes d ’écoutes et ne font que les approuver aveuglément, ou sur le fait que le
gouvernement impose un algorithme secret comme un standard commercial?
Tab. 24.2 - A g e n c e s p a r t ic ip a n t à l ’ EES
Ministère de la Justice — Sponsor du système et agent de famille de clefs

NIST — Directeur de programme et agent de dépôt
FBI — Utilisateur du déchiffrement et agent de famille de clefs
Ministère des finances — Agent de dépôt
NSA — Développeur de programme
De toutes façons, l’appication de C l i p p e r soulève déjà assez de problèmes pour s’in

terroger de sa valeur en com' de justice. Souvenez-vous, C l i p p e r ne fonctionne qu’en
mode O FB. Malgré tout ce qu’on a pu vous dire de contraire, cela ne garantit pas
l’intégrité et l’authentification. Imaginez qu’Alice soit en procès et qu’un appel télé
phonique chiffré en mode C l i p p e r soit une pièce à conviction. Alice affirme qu’elle
n’a jamais fait cet appel ; la voix n’est pas la sienne. L’algorithme de compression du
téléphone est si mauvais qu’il est dur de pouvoir reconnaître la voix d’Alice, mais l’ac
cusation soutient que comme seule la clef sous dépôt d ’Alice peut déchiffrer l’appel,
alors il a dû être passé à partir de son téléphone.
Alice affirme que l’appel a été faussé de la manière suivante [993, 1351] : ayant les
textes chiffré et en clair, il est possible de les combiner par ou exclusif pour obtenir
le flux de codons. Celui-ci peut alors être combiné par ou exclusif avec un texte en
clair entièrement différent pour former un texte chiffré faussé, qui peut ensuite être
convertit en texte en clair faussé quand il passe par le déchiffrement C l i p p e r . Vrai ou
faux, cet argument pourrait facilement instaurer le doute dans l’esprit des jurés afin
de ne pas retenir l’appel téléphonique comme preuve.
Une autre attaque, appelée attaque « squeeze », permet à Alice de piéger Bernard. Voici
comment [577] : Alice appelle Bernard en utilisant C l i p p e r . Elle sauvegarde une copie
du L E A F de Bernard ainsi que de la clef de séance. Puis elle appelle Christine (qu’elle
sait mise sur écoute). Pendant le réglage des clefs, Alice force la clef de séance à être
identique à celle qu’elle a utilisée avec Bernard ; cela exige de pirater le téléphone, mais
ce n’est pas dur. Enfin, au lieu de lui envoyer son L E A F , elle envoie celui de Bernard.
Le LE A F est valide, donc le téléphone de Christine ne remarquera rien. Maintenant,
elle peut dire ce qu’elle veut à Christine; quand la police déchiffrera le LE A F, elle
trouvera que c’est celui de Bernard. Même si Bernard n’a pas été piégé par Alice, le
simple fait qu’il puisse dire cela en cour de justice contrecarre le but du schéma.
Les autorités représentant la loi aux Etats-Unis ne devraient pas pouvoir rassembler des
informations dans des enquêtes criminelles qui sont inutiles lors d’un jugement. Même
si le dépôt de clefs était une bonne idée, le L E A F en est une mauvaise application.
24.17 Capstone
C a p s t o n e (aussi appelée M Y K -80) est l’autre puce cryptographique VLSI développée
par la NSA qui applique le standard de chiffrement par clefs sous dépôt du gouverne
ment américain [1173]. C a p s t o n e inclut les fonctions suivantes [1170, 468] :
- L’algorithme S K IP J A C K dans les quatre modes basiques: E C B , C B C , C FB et

24-18 Modèle 3600 du dispositif de sécurité du téléphone d’A T & T 623
OFB;
- Un algorithme d ’échange de clefs à clef publique K E A , probablement D i f f i e -

H ellm an ;
- L’algorithme de signature numérique D S A ;
- L ’algorithme de hachage sûr SHA ;
- Un algorithme d’exponentiation polyvalent ;
- Un générateur de nombres aléatoires polyvalent utilisant une vraie source de bruit

blanc.
C a p s t o n e fournit la fonctionnalité cryptographique nécessaire pour un commerce élec

tronique sûr et pour d’autres applications informatiques. La première application de
C a p s t o n e est dans la carte P C M C IA appelée « Fortezza ». (Autrefois, elle s’appelait
« Tessera » jusqu’à ce qu’une compagnie appelée Tessera, Inc. se plaigne.)
La NSA a pensé rallonger la somme des contrôles du L E A F de C a p s t o n e dans les
versions de commercialisation des cartes « Fortezza », afin de contrecarrer les attaques
exaustives contre le L E A F dont nous avons déjà discuté. A la place, ils ont ajouté
une fonction qui annule la carte après 10 mauvais LE A F. Cela ne fait qu’augmenter
le temps nécessaire pour trouver un L E A F valide de 10 pourcents, à 46 minutes. Cela
ne m’impressionne pas.
24.18 Modèle 3600 du dispositif de sécurité

du téléphone d’AT& T
Le dispositif de sécurité du téléphone d ’A T & T (T S D pour « Téléphoné Security Devi
ce ») est un téléphone C l i p p e r . En réalité, il existe quatre modèles de T S D . Un premier
inclut la puce C l i p p e r , un second renferme un algorithme de chiffrement exportable
breveté A T & T , un troisième renferme un algorithme breveté pour un usage domes
tique plus un algorithme exportable, et un quatrième inclut les algorithmes C l i p p e r ,
domestique et exportable.
Les T SD utilisent une clef de séance différente à chaque appel téléphonique. Une paire
de T S D génère une clef de session en utilisant l’echange de clefs D i f f i e - H e l l m a n ,
indépendant de la puce C l i p p e r . Comme D i f f i e - H e l l m a n n’intègre pas d’authenti
fication, le T SD a deux méthodes pour déjouer une attaque de l’intercepteur.
La première est un écran. Le TSD hache la clef de session et affiche cette empreinte
sur un petit écran avec un nombre hexadécimal à quatre chiffres. Les personnes qui
conversent devraient confirmer que leurs écrans affichent la même chose. La qualité
d’écoute est assez bonne pour pouvoir reconnaître la voix de son correspondant.
Estelle a toujours une attaque possible. Imaginez-la au beau milieu de la converstation
entre Alice et Bernard. Elle utilise un T S D en ligne avec Alice et un T SD modifié en
ligne avec Bernard ; entre les deux, elle relie les appels téléphoniques. Alice essaie d’être
prudente. Elle génère une clef comme d’habitude, excepté qu’Estelle se fait passer pour
Bernard. Estelle obtient la clef, et en utilisant le T S D modifié, elle force la clef qu’elle
génère avec Bernard à avoir la même valeur de hachage. Cette attaque ne semble peut-
être pas être probable, mais le T S D utilise une variante du protocole à cliquets pour
la déjouer.
Le T S D génère des nombres aléatoires en utilisant une source de bruits et un ampli
ficateur à rétroaction numérique. Ceci créé un flot de bits, qui est ensuite transformé
en bruit blanc par filtrage au moyen d’un processeur de signaux numériques.
Malgré tout cela, le manuel du TSD ne parle absolument pas de sécurité. En fait, il
dit [75] :
« A T & T ne garantit pas que le T SD résistera à une attaque cryptanaly-

tique d ’une transmission chiffrée menée par une agence gouvernementale,
ses agents, ou une tierce personne. De plus, A T & T ne garantit pas que le
T SD résistera à une attaque utilisant des méthodes qui court-circuitent le
chiffrement. »
Chapitre 25
Politique
25.1 « National Security Agency » (NSA)

La NSA(les jeux de mots « No Such Agency » ou « Never Say Anything » 1 ne sont plus
souvent utilisés) est l’organisme officiel de sécurité du gouvernement américain. Le pré
sident Harry T r u m a n l’a créée en 1952 sous le Département de la Défense et, pendant
de nombreuses années, son existence même a été gardée secrète. La NSA renseigne sur
les signaux, son mandat est d'écouter et de décoder toutes les communications entrant
aux Etats-Unis et en sortant, qui pourraient présenter un intérêt pour la sécurité du
pays.
Les paragraphes suivants sont extraits de la charte originelle de la NSA, signée par le
Président T r u m a n en 1952 puis classée pendant de nombreuses années [1543] :
« La mission C O M IN T de l’Agence nationale de sécurité (N SA) est de pro

curer une organisation efficace et unifiée ainsi qu’un contrôle des activités
de renseignement des communications des Etats-Unis dirigées contre des
gouvernements étrangers, afin de prévoir une politique et des procédures
opérationnelles adaptées. Tel qu’utilisé dans cette directive, le ternie « ren
seignement des communications » ou « C O M IN T » (pour « Communication
Intelligence ») comprend toutes les procédures et méthodes utilisées pour
l’interception de communications autres que la presse étrangère et les émis
sions de propagande, ainsi que l’obtention d ’informations de telles com
munications par une autre personne que son destinataire, mais proscrit la
censure de même que la production et la dissémination de renseignements.
« La nature spéciale des agents du C O M IN T implique qu’ils soient, en
tout point, considérés hors du cadre des autres activités générales de ren
seignement. Les ordres, directives, politiques ou recommandations d’une
quelconque authorité de la Branche Exécutive concernant le rassemble
ment, la protection, la sécurité, le maniement, la dissémination ou l’uti
lisation de renseignements, et/ou de matériels classés, ne doivent pas être
applicables aux agents du C O M IN T , à moins que ce ne soit spécifique
ment, mentionné et ordonné par une authorité départementale compétente
1. Note du traducteur : « Surtout pas une telle agence » et « N’avouez jamais rien ».
626 Chapitre 25 Politique
représentée au Bureau. Les autres directives du National Security Council

Intelligence au Directeur de la Central Intelligence et les directives qui en
découlent doivent être considérées comme non-applicables aux activités du
C O M IN T , à moins que le National Security Council ait rendu sa directive
spécifiquement applicable au C O M IN T . »
La NSA mène de la recherche en cryptologie, à la fois pour concevoir des algorithmes

sûrs afin de protéger les communications américaines et pour concevoir des techniques
de cryptanalyse permettant d ’écouter les communications des autres. La NSA est
connue pour être le plus gros employeur de mathématiciens au monde ; elle est égale
ment le plus gros acheteur de matériel informatique au monde. La N SA possède une
expertise cryptographique qui est probablement en avance de nombreuses années sur
ce qui se fait de mieux dans le domaine public (en algorithmes, mais probablement
pas en protocoles), et elle peut certainement casser de nombreux systèmes utilisés en
pratique. Mais, pour des raisons de sûreté nationale, presque toutes les informations
concernant la NSA, même son budget, sont classées secrètes. (Son budget pourrait
s’élever à 13 milliards de dollars par an, incluant la participation militaire dans les
projets et le personnel de la N SA, et pourrait employer 16000 personnes.)
La NSA utilise sa puissance pour restreindre la disponibilité de la cryptographie au
sein du public évitant ainsi que d ’autres nations puissent employer des méthodes de
chiffrement que la NSA ne peut pas casser. James MASSEY décrit cette lutte entre la
recherche académique et la recherche militaire en cryptographie [1013] :
« Si l’on considère que la cryptographie est la prérogative du gouverne

ment, on accepte que la plupart de la recherche en ce domaine se déroule
derrière des portes closes. Sans aucun doute, le nombre de travailleurs enga
gés aujourd’hui dans ce type de recherche cryptologique dépasse largement
le nombre de ceux engagés dans la recherche cryptologique ouverte. Ce
n’est que depuis 10 ans, en fait, que la recherche cryptologique ouverte se
répand. Il y a eu, et il continuera d’y avoir, des conflits entre ces deux com
munautés de recherche. La recherche ouverte est une quête commune de
la connaissance qui dépend de façon vitale du libre-échange des idées par
le biais des présentations lors des conférences ou des publications dans les
journaux scientifiques. Mais est-ce qu’une agence gouvernementale, char
gée de casser les algorithmes de chiffrement des autres nations, peut en
courager la publication d ’un algorithme de chiffrement qu’elle ne peut pas
casser? Est-ce qu’un chercheur peut en gardant bonne conscience, publier
un tel algorithme qui pourrait miner l’efficacité des casseurs d’algorithmes
de chiffrement de son propre gouvernement? On pourrait argumenter que
la publication d’un code dont il est prouvé qu’il est sûr forcerait tous les
gouvernements à se comporter en gentlemen, mais il faut être conscient du
fait que la recherche ouverte en cryptologie est lourde de considérations
politiques et éthiques d ’une importance nettement plus grande que dans la
plupart des autres domaines scientifiques. Le miracle n’est pas qu’il y ait
eu conflits entre les agences gouvernementales et les chercheurs publics en
cryptologie mais plutôt que ces conflits (du moins ceux dont on a connais
sance) aient été si peu nombreux et si modérés. »
Jam es B A M FO R D a écrit un livre fascinant sur la NSA: « The Puzzle Palace » [86]
25.2 « National Computer Security Center » ( N C S C ) 627
récemment mis à jour par B a m f ORD et Wayne M adsen [87]
« Commercial COM SEC Endorsement Program » (CCEP)

Le C C E P qui est un programme d’approbation commerciale, de nom de code Overtake,
est une initiative de la NSA prise en 1984 afin de faciliter le développement d’ordina
teurs et de produits de communications munis d’une cryptographie intégrée [92, 1165],
Les militaires s’étaient toujours offerts ce genre de choses et cela était très cher. La
NSA pensait que si des constructeurs pouvaient vendre des équipements à la fois aux
militaires et aux utilisateurs civils, même outre Atlantique, les prix baisseraient et
tout le monde en bénificierait. Ils n’habiliteraient plus d’équipement selon le Standard
Fédéral 1027 et le C C E P pourrait fournir des équipement cryptographiques approuvés
par le gouvernement [711].
La NSA a développé une série de modules cryptographiques pour diverses utilisations.
Des Algorithmes différents étaient utilisés dans les modules pour différentes applica
tions, et les constructeurs étaient capable de retirer un module et de le remplacer par
un autre en fonction du client destinataire. Il y avait des modules à usage militaire
(Type I), des modules à usage gouvernemental « non-classé mais sensible » (Type II),
des modules destinés aux sociétés (Type III) et des modules destinés à l’export. Le
tableau 25.1 résume les différents modules, applications et noms.
Tab. 25.1 - M odules CCEP
Application Type I Type II

Voix/données à faible vitesse Winster Edgeshot
Ordinateur Tepache Bulletproof
Données à grande vitesse Foresee Brushstroke
Prochaine Génération Countersign I Countersign II
Ce programme est toujours en vigueur, mais n’est jamais devenu populaire en dehors
du gouvernement. Tous les modules étaient inviolables, tous les algorithmes étaient
classés secrets et il fallait vous procurer vos clefs auprès de la NSA. Les sociétés n ’ont
jamais aimé l’idée d’utiliser des algorithmes classés secrets dictés par le gouvernement.
On pourrait penser que la NSA aurait appris cette leçon et ne se serait pas lancée dans
les Clipper, Skipjack et autres puces de chiffrement par clefs sous dépôt.
25.2 « National Computer Security

Center » (NCSC)
Le « National Computer Security Center » est la branche de la NSA responsable des
programmes informatiques sûrs du Gouvernement américain. Actuellement, le centre
évalue les produits commerciaux de sécurité (à la fois logiciels et matériels), parraine et
publie la recherche, développe des directives techniques et offre des conseils, du support
et de la formation en général.
Le NCSC édite le fameux « O r a n g e B o o k » [471], Son titre exact est « Department
of Defense Trusted Computer System Evaluation Criteria » mais c ’est long à dire, et
le livre a une couverture orange. L ’O range B ook tente de définir les exigences en
matière de sécurité, donne au x fabricants d ’o rdinateurs un m oyen o b je ctif de mesurer
le niveau de sécurité de leurs systèmes et les aide à personnaliser leurs produits de
sécurité. Il se concentre sur la sécurité inform atique et ne dit vraim ent pas grand chose
à propos de cryptographie.
L ’O r a n g e B o o k définit quatre grandes divisions de niveau de protection de sécurité.
Il définit également des classes de protection au sein de certaines de ces divisions. Elles
sont résumées dans le tableau 25.2.
T ab . 25.2 - O r a n g e B o o k C la ssific a tio n s
D : Sécurité minimale
C : Protection discrète
C l : Protection par sécurité discrète
C2 : Protection par contrôle d ’accès
B : Protection obligatoire
B I : Protection par sécurité étiquetée
B2 : Protection structurée
B3 : Domaines de sécurité
A : Protection vérifiée
A l : Conception vérifiée
Quand les fabricants disent des choses comme « nous offrons la sécurité C2 », c’est
de cela qu’ils parlent. Pour plus d’informations à ce propos, lisez [1367]. Le modèle de
sécurité informatique utilisé dans ces critères s’appelle le modèle B e l l - L a P a d u l a [108,
107, 109, 110].
Le N CSC a publié toute une série de livres sur la sécurité informatique, parfois appelés
les livres arc-en-ciel (« Rainbow Books », les couvertures ont chacune une couleur diffé
rente). Par exemple, « Trusted Network Interprétation of the Trusted Computer System
Evaluation Criteria » [1148], parfois appelé R e d B o o k , donne une interprétation de
I’ O r a n g e B o o k pour les réseaux et les équipements de réseau. Le « Trusted Database
Management System Interprétation of the Trusted Computer System Evaluation Crite
ria » [1150] — je ne peux même pas commencer à décrire la couleur de sa couverture
— fait la même chose pour les bases de données. Il y a ainsi plus de trente de ces livres
à l’heure actuelle, certains avec une couverture de couleur hideuse.
Pour commander un jeu complet des R a i n b o w B o o k s , écrivez au Director,
National Security Agency, INFOSEC Awareness, Attention: C81, 9800
Savage Road, Fort
George G. Meade, MD 20755-6000, USA, Tél: +1 (301) 766-8729.
Ne leur dites pas que c ’est moi qui vous envoie.
25.3 « National Institute of Standards and

Technology » (NIST)
Le NIST est l’Institut national des standards et de la technologie, une division du
Département du Commerce. Avant 19 88 , il était dénommé « Bureau national de nor
25.3 National Institute of Standards and Technology » ('NIST ) 629
malisation » (« National Bureau of Standards » (N B S)). Par le biais de son laboratoire

« Computer Systems Laboratory » (C SL), le N IST fait la promotion de standards
ouverts et de l’interfonctionnement qui, ils l’espèrent, va favoriser le développement
économique de l’industrie informatique américaine.Â cette fin, le N IST publie des
standards et des directives qu’il espère voir adoptés par tous les systèmes informa
tiques aux Etats-Unis. Les standards officiels sont publiés sous forme de publications
dénommées FIPS (« Fédéral Information Processing Standards »).
Si vous voulez des copies des FIPS (ou de toute autre publication du N IST), contactez
le National Technical Information Service (NTIS), U.S. Department o f Commerce, 5285
Port Royal Road, Springfield, VA 22161, USA, Tél: +1 (703) 487-4650; ou visitez le
site gopher. //csrc.ncsl.nist.gov.
Quand le Congrès américain a fait passer le « Computer Security Act » en 1987, le
NIST fut mandaté pour définir des standards garantissant la sécurité des informations
sensibles mais non classées pour les systèmes informatiques gouvernementaux2. Cet
acte autorise le N IST à travailler avec d ’autres agences gouvernementales et l’industrie
privée pour évaluer les propositions de normalisation technologique.
Le N IST publie des standards pour les fonctions cryptographiques. Les agences gou
vernementales américaines doivent les utiliser pour les informations sensibles mais non
classées. Souvent, le secteur privé adopte également ces standards. Le N IST a publié
le DES, le DSS, le SHS et le EES.
Tous ces algorithmes ont été développés avec l’aide de la NSA, allant de l’analyse du
DES jusqu’au design du DSS et du SHS en passant par l’algorithme Skipjack du EES.
Certaines personnes ont critiqué le N IST pour avoir donné trop de contrôle à la NSA
sur ces standards, car les intérêts de la NSA ne sont pas forcément les mêmes que
ceux du NIST. On ignore à quel point la NSA a influencé la conception et le déve
loppement de ces algorithmes. Etant donné les ressources limitées du N IST aussi bien
en personnel qu’en budget ou en matériel, l’intervention de la NSA est probablement
considérable. La NSA a des ressources significatives à mettre à contribution, y compris
des équipements informatiques qui n’ont pas leur pareil.
Le « protocole d’accord » (« Mémorandum of understanding » (M O U )) officiel entre
les deux agences est le suivant :
PROTOCOLE D ’ACCORD ENTRE LE DIRECTEUR DE L’INSTITUT

NATIONAL DES STANDARDS ET DE LA TECHNOLOGIE ET LE
DIRECTEUR DE L’AGENCE NATIONALE DE SÉCURITÉ QUANT À
L’APPLICATION DU DROIT PUBLIC 100-235 Reconnaissant que: « A.
En vertu de la section 2 du « Computer Security Act » de 1987 (Droit

Public 100-235), (l’acte), l’Institut national des standards et de la techno
logie (NIST) est responsable devant le gouvernement fédéral pour :
« 1. Développer des standards et des recommandations techniques, de
gestion, physiques, et administratifs pour la sécurité et la confidentialité
à faible coût des informations sensibles dans les systèmes informatiques
fédéraux tels que définis par l’Acte ; et :
« 2. S’inspirer à ce propos des recommandations techniques en matière
de sécurité informatique de l’Agence nationale de sécurité (NSA) quand
2. Les inform ations classées et les données qui sont définies par le « W a r n e r A m e n d a ie n t » sont
sous la ju rid iction de la N SA .
cela est approprié,

« B. En vertu de la section 3 de l’Acte, le NIST doit coordonner ses ac
tivités en étroite collaboration avec les autres agences et services, y compris
la NSA, pour garantir :
« 1. l’utilisation maximale de tous les programmes, des études et des
rapports existants et planifiés ayant trait à la sécurité et à la confidentialité
des systèmes informatiques, de façon à éviter des doubles emplois coûteux
et inutiles; et,
« 2. autant que possible, la cohérence et la compatibilité des standards
développés par le NIST dans le cadre de l’ Acte soient avec les standards
et les procédures développés pour la protection des informations secrètes
(classées) dans les systèmes informatiques fédéraux,
« C. en vertu de l’Acte, le Secrétaire d ’Etat au Commerce a la res
ponsabilité, qu’il délègue au directeur du NIST, de désigner les membres
du Conseil de la sécurité et de la confidentialité informatique (« Computer
System Security and Privacy Advisory Board »), dont l’un, au moins, doit
appartenir à la NSA
« En conséquence, pour servir les objectifs de ce protocole d’accord, le
directeur du NIST et le directeur de la NSA conviennent par la présente de
ce qui suit :
« I. Le NIST s’engage à :
« 1. Désigner au moins un représentant choisi par le directeur de la NSA
dans le Conseil de la sécurité et de la confidentialité informatique.
« 2. S’inspirer des recommandations en matière de sécurité des systèmes
informatiques développées par la NSA, pour autant que le NIST considère
que de telles recommandations sont compatibles avec les exigences de pro
tection d ’informations sensibles dans les systèmes informatiques fédéraux.
« 3. Reconnaître la cote résultant de l’évaluation des systèmes sûrs dans
le cadre du « programme des critères d’évaluation de la sécurité des systèmes
informatiques sûrs » sans requérir une nouvelle évaluation.
« 4. Développer des standards de télécommunications sûres pour la pro
tection des données informatiques sensibles non classées, en s’inspirant,
dans la mesure du possible, de l’expérience et des produits de la NSA et ce,
de manière efficace en temps et en argent.
« 5. Eviter les doubles emplois là où cela est possible en concluant des
accords de soutien mutuel avec la NSA.
« 6. Requérir l’aide de la NSA pour toute matière liée aux algorithmes
et aux techniques cryptographiques, notamment la recherche, le développe
ment, l’évaluation ou l’acceptation.
« II. La NSA s’engage à:
« 1. Fournir au NIST les recommandations techniques en technologies
sûres, en sécurité des télécommunications et en identification individuelle
qui peuvent être utilisées, de manière effective quant au coût, pour protéger
des données informatiques sensibles.
« 2. Mener ou prendre l’initiative de programmes de recherche et dé
veloppement en tecnnologies liées à la sécurité, en sécurité des télécommu
nications, en techniques cryptographiques et en méthodes d ’identification
25.3 « National Institute of Standards and Technology » ( N I S T j 631
individuelle.
« 3. D ’être à l’écoute des demandes du NIST en matière d ’aide pour
toutes les matières liées aux algorithmes et aux techniques cryptogra
phiques, notamment la recherche, le développement, l’évaluation ou l’ac
ceptation.
« 4. Appliquer les standards et participer à l’acceptation des produits
pour les applications informatiques de sécurité couvertes par la section 23.15
(10 USC) (l’amendement Warner).
« 5. A la requête des agences fédérales, de leur contractants et des autres
entités subventionnées par le gouvernement, d’assurer l’évaluation du risque
d’attaque par des agents hostiles des systèmes informatiques fédéraux, et
de fournir aide technique et recommandations quant aux produits acceptés
pour les applications des systèmes de sécurité visant à lutter contre ces
attaques.
« III. Le NIST et la NSA s’engagent à:
« 1. Examiner conjointement les projets pour la sécurité et la confiden
tialité des systèmes informatiques soumis au NIST et à la NSA en accord
avec la section 6(b) de l’Acte.
« 2. Echanger les standards techniques et les recommandations néces
saires pour réaliser les objectifs de l’Acte.
« 3. Collaborer pour atteindre les objectifs de ce protocole avec la plus
grande efficacité possible, en évitant les doubles emplois inutiles.
« 4. Entretenir un dialogue ouvert pour garantir que chaque organi
sation reste au courant des technologies et des thèmes naissants affectant
l’automatisation de la sécurité de l’information dans les systèmes informa
tiques.
« 5. Créer un groupe de travail technique qui examinera et analysera les
sujets d’intérêt mutuel relevant de la protection des informations sensibles
ou non classées. Le groupe devrait être composé de six employés fédéraux,
trois choisis par le NIST et trois choisis par la NSA et il serait augmenté
si nécessaire par des représentants des autres agences. Les sujets pourront
être proposés au groupe par le sous-directeur à la sécurité de l’information
de la NSA, ou pourront être soulevés et traités par le groupe lui-même avec
l’approbation du sous-directeur à la sécurité de l’information de la NSA
et du sous-directeur du NIST. Pendant la période d ’évaluation d’un sujet
soumis au groupe soit par le sous-directeur à la sécurité de l’information de
la NSA soit par le sous-directeur du NIST, le groupe fournira des rapports
sur l’état d ’avancement et des plans pour les éventuelles analyses futures.
« 6. Echanger des plans de travail sur une base annuelle pour tous les
projets de recherche et de développement relevants de la protection des sys
tèmes qui traitent des informations sensibles ou non classées, y compris les
technologies sûres, pour la préservation de l’intégrité et de la disponibilité
des données, la sécurité des télécommunications et les méthodes d’identifi
cation individuelles. Les mises à jour des projets seront échangées tous les
trimestres et les évaluations des projets seront fournies à l’autre partie sur
demande.
« 7. Garantir l’analyse par le groupe de travail technique, avant toute
divulgation publique, de toutes les matières concernant les techniques de

sécurité des systèmes développés pour la protection d ’informations sensibles
dans les systèmes informatiques fédéraux, afin de garantir qu’ils sont com
patibles avec la sécurité nationale des Etats-Unis. Si le NIST et la NSA ne
sont pas en mesure de conclure sur un tel sujet dans les 60 jours, l’une des
agences peut décider de soumettre le cas au Secrétaire d ’Etat à la Défense
ou au Secrétaire d ’Etat au Commerce. Il est convenu qu’un tel cas pourra
être soumis pour décision au président [des Etats-Unis] par le biais de la
NSC. Aucune action ne devra être entreprise sur un tel cas tant que la
décision n’est pas prise.
« 8. Spécifier des accords d ’organisation additionnels dans des annexes
au présent protocole tels que convenus par la NSA et le NIST.
« IV. Chaque partie peut mettre fin au présent protocole d ’accord
moyennant un préavis écrit de six mois. Le présent protocole d ’accord entre
en application à dater de l’approbation par les deux signataires. » /s i g n é /
RAYMOND G. KAM M ER
Directeur intérimaire, National Institute o f Standards and Technology, 24
Mars 1989
W . O. STUDEMAN
Vice-amiral, U.S. Navy ; Directeur, National Security Agency, 23 Mars 1989
25.4 RSA Data Security, Inc.

R SA D a t a S e c u r i t y , I n c . (R S A D S I)a été fondée en 1982 pour développer, octroyer
des licences et commercialiser le brevet R SA . Elle offre quelques produits commerciaux,
dont un logiciel mono-station de sécurité pour courrier électronique et diverses biblio
thèques cryptographiques (disponibles soit sous forme de code source soit sous forme
binaire). R SA D SI commercialise également les algorithmes à clef secrète RC2 et RC4
(voir § 13.8). R SA L a b o r a t o r i e s , un laboratoire de recherche associé à RSADSI,
effectue des recherches sur la cryptographie fondamentale et fournit des services de
consultation en cryptographie.
Toute personne intéressée par ces brevets ou ces produits doit contacter le Director
of Sales, RSA Data Security, Inc., 100 Marine Parkway, Redwood City, CA
94065, USA, Tél: +1 (415) 595-8782, Fax: +1 (415) 595-1873.
25.5 « Public Key Partners » (PKP)

Les (PKP) sont « les partenaires de la clef publique ». Les cinq brevets du tableau 25.3
sont détenus par (PKP) de Sunnyvale, Californie, qui est un partenariat entre R SA D SI
et C a r o - K a h n , I n c . - compagnie parente de C y l i n k . (R SA D SI détient 65 pourcent
des profits et C a r o - K a h n 35 pourcent.) P K P affirme que ces brevets, et plus parti
culièrement le 4218 582, s’appliquent à toutes les applications de cryptographie à clef
publique.
Dans [576], P K P écrit :
« Ces brevets [4 200 770, 4 218 582, 4 405 829 et 4 424 414] couvrent toutes
25.5 « Public Key Partners » ( 'P K P ) 633
Ta b . 25.3 - Les brevets de P u b l i c K ey Partners
Numéro de brevet Date Inventeurs Couverture du brevet

4200 770 29/3/80 H ellm an , D iffie, Echange de clef
M er kle D iffie - H ellm an
4 218 582 19/8/80 H ellm an , M er kle Empilements

M erkle -H ellm an
4405 829 20/9/83 R iv e s t , Sh a m ir , R SA

A d lem an
4424414 3 /3 /8 4 H ellm an , P o h lig P o h lig - H e l l m a n
4995082 19/2/91 Sch n o r r Signatures

de S c h n o r r
les méthodes connues dans la pratique de l’art de la clef publique, y compris

les variantes connues collectivement sous le nom E l G a m a l .
« Du fait de la large acceptation des signatures numériques R SA à
travers la communauté internationale, P u b l i c K e y P a r t n e r s appuie for
tement son incorporation dans un standard de signature numérique. Nous
affirmons à toutes les parties intéressées que P u b l i c K e y P a r t n e r s res
pectera tous les règlements d’ ANSI et d ’IEEE en ce qui concerne la dispo
nibilité des licences pour pratiquer cet art. Spécifiquement, en soutien au
standard de signature numérique R SA qui pourrait être adopté, P u b l i c
K e y P a r t n e r s donne par la présente sa garantie que des licences pour pra
tiquer l’art des signatures R SA seront octroyées en des termes raisonnables
et à des conditions fondées sur des bases non discriminatoires. »
La véracité de ceci dépend de votre interlocuteur. Les licences P K P ont principalement

été secrètes, il n’y a donc pas de moyens de vérifier si elles sont standard. Bien qu’ils
prétendent n’avoir jamais refusé de licence à qui que ce soit, au moins deux compagnies
disent s’être vues refuser une telle licence. P K P protège ses brevets de près, attaquant
quiconque essaie de se servir de la cryptographie à clef publique sans licence. En partie,
cela est dü aux lois américaines sur les brevets. Si vous détenez un brevet et que vous
ne pourchassez pas les infractions, vous pouvez perdre votre brevet. Il y a eu beaucoup
de discussions quant à savoir si ces brevets sont légaux mais jusqu’à présent c ’en est
resté au stade des discussions. Toutes les tentatives de mise en doute des brevets P K P
ont été retirées avant que le jugement n’ait, lieu.
Je ne vais pas vous donner de conseils légaux en matière de brevets dans cet ouvrage.
Peut-être que le brevet R S A ne tiendrait pas devant une cour de justice. Peut-être que
les brevets ne s’appliquent pas à toute la cryptographie à clef publique. (Honnêtement,
je ne vois pas comment il peuvent couvrir E l G a m a l o u les systèmes cryptographiques à
courbe elliptique.) Peut-être que quelqu’un va finalement gagner un procès contre PK P
ou R SA D SI. Mais gardez en mémoire que des compagnies qui ont de grands dépar
tements juridiques telles que IB M , M i c r o s o f t , L o t u s , A p p l e , N o v e l l , D i g i t a l ,
N a t i o n a l S e m i c o n d u c t o r , A T & T et S u n ont toutes demandé une licence pour
l’utilisation de R SA dans leurs produits, plutôt que d ’intenter un procès en justice. Et
des sociétés telles que B o e i n g , S h e l l O ï l , D u P o n t . R a y t h e o n et C i t i c o r p ont

toutes acquis des licences pour l’utilisation de R SA à des fins internes.
Dans une affaire, P K P a attaqué T R W C o r p o r a t i o n en justice pour avoir utilisé
E l G a m a l sans licence. T R W prétendait ne pas avoir besoin d ’une licence. PK P et
T R W sont arrivés à un arrangement en juin 1992. Les détails de cet arrangement sont
inconnus, mais ils comprenaient un accord de T R W d ’obtenir une licence d ’exploitation
des brevets. Ce n’est pas de bonne augure. T R W peut se payer de bons avocats;
je crois que s’ils avaient pensé pouvoir gagner le procès sans dépenser des sommes
exhorbitantes, ils se seraient battu.
Pendant ce temps, P K P avait ses propres problèmes internes. En juin 1994, C a r o -
K a h n a intenté un procès contre R SA D S I arguant, entre autre, que le brevet RSA
est non valide et non remis en cause [386]. Les deux partenaires essaient d ’annuler leur
collaboration. Les brevets sont-ils valides ou pas? Les utilisateurs de l’algorithme RSA
devront-ils obtenir une licence de C a r o - K a h n ? Qui détiendra le brevet de S c h n o r r ?
Une solution sera sans aucun doute trouvée avant que ce livre ne soit publié.
Les brevets sont valables pour seulement 17 ans et ne sont pas renouvelables. A partir
du 29 mars 1997, l’échange de clef D i f f i e - H e l l m a n (et l’algorithme E l G a m a l ) seront
domaine public. Le 20 septembre 2000, R SA entrera dans le domaine public. Notez-le
sur vos calendriers.
25.6 « International Association for

Cryptologie Research » (IACR)
L’Association internationale pour la recherche cryptologique ((IACR) pour
« International Association for Cryptologie Research ») est l’organisation internatio
nale de recherche en cryptographie. Son but déclaré est de faire avancer la théorie et la
pratique en cryptologie et dans les domaines associés. N’importe qui peut en devenir
membre. L’association parraine deux conférences annuelles, C r y p t o (tenue à Santa
Barbara au mois d’août) et E u r o c r y p t (tenue en Europe en mai), et publie trimes
triellement le journal « The Journal of Cryptology » et le bulletin « IACR Newsletter ».
L’adresse du bureau de l’IA C R change à chaque changement de président. L’adresse ac
tuelle est IACR Business Office, Aarhus Science Park, Gustav Wieds Vej 10,
DK-8000 Aarhus C, Danemark.
25.7 « RACE Integrity Primitives Evalua

tion » (RIPE)
Le programme de recherche et de dévelopement des technologies de communications
avancées en Europe (R A C E pour Research and Development in Advanced Commu
nication Technologies in Europe R A C E ) a été lancé par la Communauté européenne
pour aider les travaux pré-compétitifs et pré-normatifs pour les standards et la tech
nologie des communications, avec comme but de promouvoir l’ « Integrated Broadband
Communication » (IB C ). Dans le cadre de cet effort, R A C E a établi le projet d’éva
luation de procédures d ’intégrité ( RACE Integrity Primitives Evaluation (R IP E ) afin
25.8 « Conditional Access for Europe » (C AFE) 635
de rassembler un ensemble de techniques destinées à satisfaire les niveaux de sécurité

de riB C .
Six groupes européens à la pointe de la recherche cryptographique sont membres
du consortium R IP E : Center for Mathematics and Computer Science, Amsterdam;
Siemens A.G. ; Philips Crypto BV ; Royal P T T Nederland NV, P T T Research ;
Katholieke Universiteit Leuven ; et Aarhus Universitet. Après des appels d’algorithmes
en 1989 et 1991 [1566], 32 soumissions venant du monde entier et un projet d’évaluation
de 350 hommes- mois, le consortium a publié « RIPE Integrity Primitives » [1316, 1343].
Le rapport inclut une introduction, une description des concepts d ’intégrité fondamen
taux et les primitives suivantes: M D C -4 (voir § 14.11), R IP E -MD (voir § 14.8),
R IP E -M A C (voir § 18.14), IB C -H A SH , SK ID (voir § 3.2), R SA , C O M S E T (voir
§ 16.1), et la génération de clefs RSA .
25.8 « Conditional Access for Europe »

(CAFE)
L’Accès conditionnel pour l’Europe (C A F E ) est un projet du programme (E SPR ITde
l’Union Européenne. Les travaux ont commencé en décembre 1992 et devraient se finir
vers la fin 1995. Ce consortium se divise en des groupes pour des études de marché
et des études sociales (« Cardware », « Institut für Sozialforschung »), des fabricants
de matériels et de logiciels (« DigiCash », « Gemplus », « Ingenico », « Siemens ») et
des cryptographes (« C W I Amsterdam », « P T T Research Netherlands », « SPET »,
« Sintef Delab Trondheim », « Universities of Arhus », « Hüdesheim and Leuven »).
Le but est de développer des systèmes d’accès conditionnels, particulièrement les sys
tèmes digitaux de paiement. Les systèmes de paiement doivent pouvoir donner une
certitude légale à tout le monde et à tout moment et doivent demander un minimum
de confiance - cette certitude ne devrait pas dépendre de la résistance à la falsification
d’un quelconque des mécanismes.
La machine de base pour C A F E est un portefeuille électronique: un petit ordinateur
qui ressemble plus ou moins à une calculatrice de poche. Il y a une pile, un clavier,
un écran et un canal infrarouge pour communiquer avec d ’autres portefeuilles. Chaque
utilisateur possède et se sert de son portefeuille qui gère ses droits et garanti sa sécurité.
Une machine avec un clavier et un écran a un avantage sur la carte à puce ; elle peut
fonctionner sans l’aide d ’un terminal. Un utilisateur peut directement rentrer son mot
de passe et le montant du paiement. Il n’a pas à donner son portefeuille pour conclure
une transaction, ce qui n’est pas le cas avec les cartes de crédit.
Les autres caractéristiques sont :
- Des transactions « offline ». Le but de ce système est de remplacer les petites

transactions d’argent ; un système « online » serait trop encombrant.
- Tolérance à la perte. Si un utilisateur perd son portefeuille, si il le casse ou se le

fait voler, il peut récupérer son argent.
- Est compatible avec plusieurs monnaies.

- Une architecture et un système ouverts. Un utilisateur doit être capable de payer

son shopping, le téléphone et les transports publiques en utilisant différents pres-
tateurs de services. Le système doit être compatible entre les différents four
nisseurs d’argent électronique et entre les différents types et constructeurs de
portefeuilles.
- Coût faible.
Il existe déjà une version logicielle de ce système et le consortium travaille d’arrache-

pied pour mettre au point un prototype le réalisant en matériel.
25.9 « ISO /IE C 9979 »

Au milieu des années 1980, ISO a essayé de standardiser DES, qui était déjà un stan
dard FIPS et ANSI. Après des querelles politiques, ISO a décidé de ne pas standardiser
d’algorithmes cryptographiques, mais à la place de les déposer. Seuls des algorithmes
de chiffrement peuvent être déposés; les fonctions de compilation et les schémas de
signatures ne peuvent pas l’être. Toute entité nationale peut soumettre un algorithme
pour inscription.
Au jour d’aujourd’hui, seuls trois algorithmes ont été soumis (voir tableau 25.5). Une
soumission comprend des informations à propos des applications, des paramètres, de
l’exécution, des modes et des vecteurs tests. Une description détaillée est optionnelle ;
il est possible de soumettre des algorithmes secrets pour inscription.
T ab . 25.4 - IS O /IE C 9979
T ab . 25.5 A lg o r ith m es d épo sés
Nom Numéro d’inscription

0001 B-CRYPT
0002 IDEA
0003 LUC
Une inscription d’algorithme n’est ni une garantie sur sa qualité, ni son approbation
par IS O /IE C . L ’inscription indique tout juste qu’une simple entité nationale veut
enregistrer l’algorithme, basé sur un critère considéré par cette entité.
Je ne suis pas emballé par cette idée. L ’inscription bloque le processus de standardisa
tion. Plutôt que d ’accepter quelques algorithmes, ISO autorise l’inscription de tous les
algorithmes, avec si peu de contrôle sur ce qui est inscrit, affirmant qu’un algorithme
« IS O /IE C 9979 Registered » est bien mieux qu’il ne parait être.
Dans tous les cas, le registre est tenu par le National Computer Centre Ltd., Oxford
Road, Manchester, M l 7ED, Royaume-Uni.
5.10 Groupes industriels, de défense des libertés civiles, et professionnelles 637
55.10 Groupes industriels, de défense des

libertés civiles, et professionnelles
Electronic Privacy Information Center » (EPIC)
’EPIC est le centre d’information pour la confidentialité électronique et a été fondé en
394 pour attirer l’attention du public sur les problèmes émergents de la confidentialité
i relation avec le « National Information Infrastructure », tel que la puce Clipper, la
roposition de « Digital Telephony », les numéros et systèmes d ’identité nationale, la
Mifidentialité des dossiers médicaux et la vente de données. E P IC mène des procès,
3onsorise des conférences, produit des rapports, publie « E P IC Alert » et mène des
unpagnes sur les problèmes de la confidentialité.
bute personne désireuse de joindre l’E PIC doit contacter l’Electronic Privacy
nformation Center, 666 Pennsylvania Avenue SE, Suite 301, Washington
.C. 20003, USA, Tél: +1 202 544-9240, Fax: +1 202 547-5482, Internet:
nfo@epic.org.
Electronic Fondation Frontier » (EFF)

a EFF est la fondation de la frontière électronique et se consacre à la protection
es droits civils dans le cyber-espace. En ce qui concerne les règlements du gouver-
ement américain en matière de cryptographie, elle soutient que l’information concer-
ant la cryptographie et son accès sont des droits fondamentaux et qu’ils doivent donc
re libres de toute contrainte gouvernementale. Cette fondation a organisé le groupe
Digital Privacy and Security Working Group », une coalition de 50 organisations.
■e groupe a fait opposition au projet de loi de « Digital Telephony » et à l’initiative
C lip p e r. L’E FF participe également au procès contre les contrôles d ’exportation de
t cryptographie [150].
bute personne désireuse de rejoindre les rangs de l’E FF peut contacter l’Electronic
rontier Foundation, 1001 G Street NW, Suite 950E, Washington D.C.
0001, USA, Tél: +1 202 347-5400, Fax: +1 202 393-5509, Internet:
ff@eff .org.
Association for Computing Machinery » (A C M )

’A C M qui est l’association pour les machines informatiques, est une organisation
îternationale d’industries en informatiques. En 1994, le « U.S. A C M Public Policy
lommitt.ee » a produit un excellent rapport sur la politique américaine de cryp-
jgraphie [946]. Ce rapport devrait être lu par quiconque est intéressé par la po-
tique en cryptographie. Il est disponible via ftp anonyme à : in fo .a cm .o rg in
reports/acm _crypt_\\ stu d y/acm _crypto_study.ps.
Institute of Electrical qnd Electronics Engineers »(IEEE)

i’ IE E E ,
institut des ingénieurs électriciens et électroniciens, est une autre organisation
rofessionnelle. L e bureau am éricain en quête et fait des recom m andation s à p ro p o s des
uestions sur la confidentialité, com pren an t la p olitiq u e de chiffrem ent, les num éros
'identité et les p rotection s d e la confidentialité sur Internet.
« Software Publisher Association » (SPA)

La SPA qui est l’association des éditeurs de logiciels, est un syndicat professionnel
regroupant plus de 1000 entreprises de logiciels pour micro-ordinateurs. Elles ont fait
pression pour faire diminuer les contrôles sur l’exportation de la cryptographie et en
tretiennent une liste de produits étrangers de cryptographie disponibles.
25.11 Sci.crypt
S c i .CRY p t est le forum Usenet pour la cryptologie. Il est lu par à peu près 100000 per
sonnes à travers le monde entier. La plupart des messages ne veulent rien dire ou sont
polémiques, voire les deux ; certains sont de nature politique et le reste consiste princi
palement en des demandes d ’informations ou des questions élémentaires. Occasionnel
lement, il y a des pépites d’informationsneuves et utiles qui sontadressées auforum.
Si vous suivez régulièrement s c i . cryp t, vous apprendrez commentutiliser ce qui s’ap
pelle le « tueur de fichiers ».
Un autre forum Usenet est le sci.scrypt.research, un forum modéré dévoué aux discus
sions sur la recherche cryptologique. Il y a moins de messages et ils sont plus intéres
sants.
25.12 Cypherpunks
Les « CYPHERPUNKS » sont un groupe informel de gens intéressés par l’enseignement
et l’apprentissage de la cryptographie. Ils expérimentent également la cryptographie et
essaient de la mettre en œuvre. De leur point de vue, toute la recherche cryptographique
au monde ne sert à rien pour la société si elle n’est pas mise en œuvre.
Dans « A Cypherpunk’s Manifesto », E r i c H u g h e s écrit [746] :
« Nous, les C y p h e r p u n k s , vouons nos efforts à la construction de systèmes

anonymes. Nous protégeons notre vie privée grâce à la cryptographie, avec
des systèmes d’envois de courriers anonymes, avec des signatures digitales
et avec de l’argent électronique.
« Les C y p h e r p u n k s écrivent un algorithme de chiffrement. Nous savons

que quelqu’un doit écrire un logiciel pour protéger la vie privée, et comme
l’intimité concerne chacun d’entre-nous, nous allons écrire ce programme.
Nous publions notre algorithme de chiffrement afin que nos camarades
de C y p h e r p u n k s puissent s’entraîner et jouer avec. Notre algorithme de
chiffrement est gratuit pour toute utilisation, dans le monde entier. Nous
ne nous soucions guère de savoir si vous approuvez ou pas. Nous savons
qu’un logiciel ne peut être détruit et que des systèmes largement diffusés
ne peuvent pas être arrêtés. »
Les personnes souhaitant être incluses dans la liste courrier des C y p h e r p u n k s sur
Internet peuvent envoyer un courrier à majordomo@toad.com.. Ce listing est archivé à
ftp.csua.berkeley.edu dans /pub/cypherpunks.
25.13 Brevets 639
25.13 Brevets
La problématique des brevets3 en matière de logiciel dépasse largement le cadre de cet
ouvrage. Qu’ils soient bons ou mauvais, ils existent. Les algorithmes, algorithmes cryp
tographiques inclus, peuvent être brevetés aux Etats-Unis. IB M détenait les brevets du
DES [516]. Presque tous les algorithmes de cryptographie à clef publique sont brevetés.
Le N IST a même un brevet pour le D SA . Certains brevets cryptographiques ont été
bloqués à la demande de la NSA, dans le cadre des pouvoirs qui lui sont conférés par
l’« Invention Secrecy Act » de 1940 et le « National Security Act » de 1947. Ceci veut
dire qu’à la place d’un brevet, l’inventeur obtient un ordre de discrétion et il lui est
interdit de discuter de son invention avec qui que ce soit.
La N SA a une dispense spéciale quand il s’agit de brevets. Elle peut faire une demande
de brevet puis bloquer son homologation. Là encore, c’est un ordre de discrétion, mais
la NSA est alors à la fois l’inventeur et l’autorité donnant l’ordre. Quand, bien plus
tard, l’ordre de discrétion est levé, le « Census Office » octroie le brevet pour les 17
années réglementaires. Ceci protège clairement l’invention tout en la gardant secrète.
Si quelqu’un d ’autre invente la même chose, la NSA a déjà fait une demande de brevet.
Si personne d’autre ne fait la même invention, alors elle reste secrète.
Non seulement ce système est une entorse à tout le processus de délivrance des brevets,
qui est censé révéler et protéger les inventions, mais il permet aussi à la NSA de
conserver un brevet pendant plus de 17 ans. Le décompte des années commence en
effet après que le brevet soit délivré, et non pas quand la demande est enregistrée. Les
perspectives d’évolution de ce système, maintenant que les Etats-Unis ont ratifié le
G A T T , ne sont pas claires.
25.14 Réglementation américaine à l’ex

portation
D’après le gouvernement américain4, la cryptographie peut être une munition. Cela
signifie qu’elle est couverte par les mêmes règles qu’un missile anti-tank ou un tank
M l A b r a m s . Si vous vendez de la cryptographie aux Etats-Unis à des acheteurs étran
gers sans licence d’exportation appropriée, alors vous êtes considéré comme trafiquant
d’armes international. A moins que vous ne pensiez qu’un séjour dans un pénitencier
fédéral fasse bonne impression dans votre curriculum vitæ, faites attention à cette
réglementation.
Avec l’avènement de la Guerre Froide en 1949, tous les pays membres de l’OTAN
(excepté l’Islande), et plus tard l’Australie, le Japon et l’Espagne, ont formé le « Coordi-
nating Committee for Multilatéral Export Controls » ( C o C o m ). C ’est une organisation
3. N ote du traducteur : les brevets don t il est question dans cette section sont tous américains.
4. N ote du traducteur : toutes les inform ations reprises dans cette section concernent principalement
les règles d ’exportation américaines. Elles ne s’ appliquent à vous que si vous devez exporter de la
cryptographie hors des Etats-Unis. T outefois ces règles vous concernent mêm e si vous ne vivez pas
aux Etats-Unis car elles conditionnent la nature des dispositifs cryptographiques mis à votre disposition
dans le reste du m onde (quand ceux-ci sont originaires des Etats-Unis bien sûr). Chaque pays a ses
propres réglem entations en m atière de cryptographie. Avant d ’ im porter ou d ’ exporter des dispositifs
cryptographiques, prenez les conseils d ’ une personne avisée et spécialisée en ces matières (il est conseillé
de consulter un b on avocat).
non officielle et non contractuelle, créée pour coordonner les restrictions nationales sur
l’exportation de technologies militaires sensibles vers l’Union Soviétique, vers d’autres
pays du Pacte de Varsovie et vers la République Populaire de Chine. Des exemples de
technologies contrôlées sont les ordinateurs, les machines-outils telles que les fraiseuses
et la cryptographie. Le but recherché était de ralentir le transfert de technologie vers
ces pays, et par conséquent de maintenir leurs forces armées à un niveau inférieur.
Depuis la fin de la Guerre Froide, les pays du C oC om ont réalisé que beaucoup de leurs
contrôles étaient obsolètes. Aussi, ils seraient en train de définir un « New Forum »,
une autre organisation multinationale dont le but sera de stopper le flot de technologies
militaires vers des pays que les membres n’apprécient pas particulièrement.
De toutes façons, la politique américaine d’exportation des biens stratégiques est dé
finie par l’« Export Administration Act », l’« Arms Export Control Act », l’« Atomic
Energy Act » et le « Nuclear Non-Proloferation Act » Les contrôles établis par toutes
ces législations sont effectués par de nombreuses ordonnances, aucune d’entre-elles
n’étant en coordination avec les autres. Plus d’une douzaine d’agences, y compris les
services militaires, effectuent des contrôles ; souvent, leurs programmes s’entremêlent
ou se contredisent.
Les technologies contrôlées apparaissent sur plusieurs listes. La cryptographie a tou
jours été classée comme arme de guerre et apparait sur la « U.S. Munitions List »
(U SM L), la « International Munitions List » (IM L), la « Commerce Control List »
(C C L ) et la « International Industrial List » (HL). Le Département d ’Etat est res
ponsable de la USM L ; elle est publiée dans les « International Traffic in Arms
Régulations » (IT A R ) [472, 473].
Deux agences gouvernementales contrôlent l’exportation de cryptographie. L ’une est
le « Bureau of Export Administration » (B X A ) au Département du Commerce, régie
par les « Export Administration Régulations » (E A R ). L’autre est l’ « Office of Defense
Trade Controls » (D T C ) du Département d’Etat, régie par les IT A R . A vue de nez, le
B X A du Département du Commerce est beaucoup moins exigeant, mais le D T C du
Département d ’Etat (qui prend ses conseils techniques et de sécurité nationale auprès
de la NSA et qui semble toujours suivre ces conseils) analyse toutes les exportations
de cryptographie en premier et peut refuser le transfert de la juridiction au B X A .
Les IT A R règlent ces matières5 ; ce changement de dénomination est probablement
le résultat d ’un effort de relations publiques destiné à nous faire oublier qu’il s’agit
d’armes et de bombes. Historiquement, le D T C était réticent à accorder des licences
d’exportation pour des produits de codage supérieurs à un certain niveau — bien qu’il
n’ait jamais déclaré publiquement quel était ce niveau.
Les paragraphes suivants, qui ont trait à la cryptographie, sont extraits des IT A R [472,
473]6 :
« § 120.10 Données techniques.

« Données techniques » désigne, pour les besoins de ce sous-chapitre :
« (1) Des informations, autres que du logiciel tel que défini par
120.10(d), qui sont nécessaires pour la conception, le développement, la
5. Avant 1990, l’ O ffice de con trôle du com m erce de la défense (« O ffic e o f D e fe n s e Trade C o n tr o ls »)
s’appelait l’O ffice de con trôle des armes (« O ffic e o f M u n itio n s C o n tr o ls »).
6- Note du traducteur : la traduction du docum ent qui suit n’a pas de valeur légale. Si vous devez
être soum is à cette réglem entation, prenez connaissance du docum ent original et, com m e le dit l’auteur,
prenez les conseils d ’ un hom m e de loi qui le com prend.
25.14 Réglementation américaine à l’exportation 641
production, le traitement, la fabrication, l’assemblage, l’utilisation, la ré

paration, l’entretien ou la modification d’articles de défense. Cela inclut,
par exemple, les informations sous formes de projets, de dessins, de pho
tographies, de plans, de modes d ’emploi ou de documentation. (2) Des
informations classées relatives à des articles ou des services de la défense ;
« (3) Des informations couvertes par un ordre de préservation du secret
de l’invention ;
« (4) Le logiciel tel que défini par la section 121.8(f) directement relatif
aux articles de défense ;
« (5) Cette définition n ’inclut pas les informations relevant des prin
cipes généraux scientifiques, mathématiques ou techniques enseignés dans
les écoles, collèges et universités du domaine public comme définit au §
120.11. Elle n’inclut pas non plus les informations commerciales de base
sur la fonction ou l’objet ni la description globale d’articles de défense.
« § 120.11 Domaine public.

« Domaine public » désigne toute information qui a été publiée et qui
est généralement accessible et disponible au public :
« (1) Par la vente en kiosques et en libraires ;
« (2) Par les abonnements qui sont disponibles sans restrictions à qui
conque désire obtenir ou acheter de l’information publiée ;
« (3) Par des mailings de deuxième classe accordés par le gouvernement
américain ;
« (4) Dans les bibliothèques ouvertes au public ou auprès desquelles le
public peut obtenir des documents ;
« (5) Par les brevets disponibles dans tout bureau de brevets ;
« (6) Par la distribution non restreinte lors de conférences, desémi
naires, de foires ou d ’expositions accessibles sans restriction au public, aux
Etats-Unis ;
« (7) Par la publication publique (c’est-à-dire, une publication non res
treinte) sous toute forme (c’est-à-dire, pas nécessairement sous forme pu
bliée) après l’approbation du département ou de l’agence concernée du gou
vernement américain (voir également § 125.4(b)(13)) ;
« (8) Par la recherche fondamentale en sciences et techniques dans des
institutions accréditées d’enseignement supérieur aux Etats-Unis, où les ré
sultats de recherche sont publiés et largement partagés par la communauté
scientifique. La « recherche fondamentale » désigne la recherche élémentaire
et expérimentale en sciences et techniques où les résultats sont publiés et
largement partagés par la communauté scientifique, bien distincte de la re
cherche dont les résultats sont classés secrets pour des raisons de propriété
ou par des contrôles spécifiques d’accès et de dissémination du gouverne
ment américain. La recherche universitaire ne sera pas considérée comme
fondamentale si :
« (i) l’université ou ses chercheurs acceptent d ’autres restrictions sur la
publication des résultats de leurs projets scientifiques ou techniques, ou
« (ii) la recherche a été initiée par le gouvernement américain et des
contrôles spécifiques d’accès et de dissémination protégeant les résultats de
leurs recherches sont applicables.
« § 120.17 Exportation
« Exporter signifie:
« (1) Envoyer ou emporter hors des Etats-Unis de quelque façon que ce
soit des documents liés à la défense, à l’exception des connaissances tech
niques personnelles qui voyagent de par le déplacement de leur détenteur ;
ou
« (2) Transférer un enregistrement, un contrôle ou un titre de propriété
à une personne étrangère d’un avion, d’un navire, ou d’un satellite repris
dans la liste des munitions américaines, que ce soit aux Etats-Unis ou à
l’étranger ; ou
« (3) Divulguer (oralement ou visuellement) ou transférer au sein des
Etats-Unis tout article de défense auprès d ’une ambassade, toute agence
ou représentation d ’un gouvernement étranger (par exemple, les représen
tations diplomatiques) ; ou
« (4) Divulguer (oralement ou visuellement) ou transférer des données
techniques à une personne étrangère, que ce soit aux Etats-Unis ou à l’étran
ger; ou
« (5) Offrir des services liés à la défense à la place de ou pour le bénéfice
d ’une personne étrangère, que ce soit aux Etats-Unis ou à l’étranger.
« (6) Une fusée de lancement ou sa charge utile ne doivent pas, de par
le lancement d ’un tel véhicule, être considérés comme une exportation dans
le sens de ce sous-chapitre. Toutefois, pour certains objectifs restreints (voir
§ 126.1 de ce sous-chapitre), le contrôle de ce sous-chapitre s’applique à la
vente et autres transferts d ’articles ou de services de défense.
« Partie 121— La liste américaine des munitions

« § 121.1 Généralités. La liste américaine des munitions
« Catégorie XIII- -Equipements militaires auxiliaires
« (1) Les systèmes cryptographiques (y compris ceux de gestion de clef),
les équipements, les pièces détachées, les modules, les circuits intégrés, les
composants ou logiciels ayant la capacité de garantir la discrétion et la
confidentialité des informations ou des systèmes d’informations, excepté les
équipement cryptographiques et les logiciels qui sont :
« (i) Délimités aux fonctions de décodage spécialement étudiés pour
pouvoir utiliser des logiciels protégés contre la copie, pourvu que les fonc
tions de déchiffrement ne soient pas accessibles à l’utilisateur.
« (ii) Spécifiquement étudiés, développés ou modifiés pour utilisation
dans des machines bancaires ou des transactions d ’argent, et uniquement
dédiés à de telles transactions. Les machines bancaires ou les transactions
d ’argent incluent les guichets automatiques, les imprimantes automatiques
de position de compte, les terminaux de points de vente ou les équipements
de chiffrage des transactions interbancaires.
« (iii) Basés uniquement sur des techniques analogiques pour fournir
un chiffrement qui assure la sécurité de l’information dans les applications
suivantes...
« (iv) Des cartes à puce personnalisées utilisant la cryptographie dont
l’usage est limité à des équipements ou des systèmes n’étant pas sous le
contrôle de la USML.
25.14 Réglementation américaine à l’exportation 64S
« (v) Limités aux accès contrôlés, tels que les guichets automatiques,
les imprimantes automatiques de position de compte ou les terminaux de
points de vente, protégés par un mot de passe ou un code d ’identification
(Personal Identification Number - PIN) ou des données similaires pour em
pêcher l’accès non autorisé aux installations, mais qui ne permettent pas
le chiffrement de fichiers ou de textes, mis à part ce qui est directement
affecté à la protection du PIN.
« (vi) Limités aux authentifications de données qui calculent un
« Message Authentication Code » (C A M ) ou un résultat similaire pour
s’assurer qu’aucune altération de texte n’est apparue, ou pour identifier
l’utilisateur, mais ne permet pas le chiffrement de données, de textes ou
d’un autre média autre que ceux nécessaires à l’authentification.
« (vii) Limités à des techniques de compression ou de chiffrement de
données fixes.
« (viii) Limités à la réception d ’émissions radios, télévision à péage ou
tout autre émission destinée à un public restreint, sans chiffrement digital et
où le déchiffrement digital est limité à la vidéo, à l’audio ou à des fonctions
de gestion.
« (ix) Des logiciels créés ou modifiés pour se protéger de tout piratage
informatique (un virus par exemple).
« (2) Des systèmes cryptographiques (y compris ceux de gestion de clef),
des équipements, des pièces détachées, des modules, des circuits intégrés,
des composants ou logiciels capables de produire des codes correcteurs pour
des systèmes ou des équipements spectraux de diffusion.
« (3) Des systèmes cryptographiques, des équipements, des pièces dé
tachées, des modules, des circuits intégrés, des composants ou des logiciels.
« § 125.2 Exportations de données techniques non classées.

« (a) Généralités. Une licence (DSP-5) est nécessaire pour l’exportation
de données techniques non classées, à moins que l’exportation soit exempte
des exigences de licence de ce sous-chapitre. Dans le cas d’une visite d ’usine,
les détails des présentations prévues doivent être transmises à l’Office de
contrôle du commerce de la défense pour approbation sur le contenu tech
nique. Sept copies des données techniques ou des détails des présentations
doivent être fournies.
« (b) Brevets. Une licence octroyée par l’Office de contrôle du com
merce de la défense est nécessaire pour l’exportation de données techniques,
chaque fois que les données dépassent ce qui est normalement nécessaire à
l’obtention d ’un brevet domestique, ou à l’obtention d’un brevet à l’étran
ger quand aucune demande domestique n’est faite. Les requêtes pour les
demandes de brevets dans un pays étranger et les requêtes pour l’adjonc
tion d’amendements, de modifications ou de suppléments à de tels brevets
doivent être conformes aux réglementations de l’Office des brevets et des
marques en accord avec l’article 37 CFR partie 5. L ’exportation de données
techniques pour l’obtention et l’enregistrement d’un brevet dans des pays
étrangers est soumise aux réglementations émises par l’Office des brevets
et des marques conformément à l’article 35 U.S.C. 184.
« (c) Divulgations. Sauf exemption explicite reprise dans ce sous-

chapitre, une licence est requise pour la divulgation orale, visuelle ou docu
mentaire de données techniques par des personnes américaines à des per
sonnes étrangères. Une licence est nécessaire indépendamment de la manière
dont les données techniques sont transmises (en personne, par téléphone,
par courrier, par moyens électroniques, etc.). Une licence est nécessaire pour
de telles divulgations par des personnes américaines dans le cadre de visites
à des représentations diplomatiques et à des offices consulaires. »
Et ainsi de suite. Il y a beaucoup d ’autres informations dans ce document. Si vous avez

l’intention d ’exporter de la cryptographie, je vous suggère de vous procurer à la fois
une copie du document complet et un homme de loi qui parle ce langage.
En réalité, la N SA a le contrôle de l’exportation des produits cryptographiques. Si
vous voulez une « Commodity Juridiction » (C J), vous devez soumettre votre produit
à l’approbation de la N SA et soumettre votre demande de CJ au Département d ’Etat.
Après avoir obtenu l’autorisation du Département d ’Etat, l’affaire passe dans la ju
ridiction du Département du Commerce, qui ne s’est jamais vraiment préoccupé de
l’exportation de la cryptographie. Toutefois, le Département d’Etat n’accordera jamais
une CJ sans l’approbation de la NSA et, pour autant que l’on sache, il n’a jamais
refusé ime licence après l’approbation de la NSA.
En 1977, un employé de la NSA appelé Joseph A. M e y e r a écrit une lettre — non
autorisée, d ’après le compte rendu officiel de l’incident — destinée à l’IEEE, les aver
tissant que la présentation prévue de l’article original concernant le R SA violerait la
réglementation IT A R . Voici un extrait de « Puzzle Palace » :
« Il marquait un point. IT A R couvrait toute « information non classée

qui pouvait être utilisée, ou adaptée pour être utilisée, dans la conception,
la production, la fabrication, la réparation, la révision, le traitement, l’in
génierie, le développement, l’opération, l’entretien ou la reconstruction »
des matériels cités, aussi bien que « toute technologie qui permettait l’amé
lioration du nec plus ultra ou établissait un nouvel art dans un domaine
significatif d ’application militaire aux Etats-Unis ». Et exporter comprenait
le transfert d’informations à la fois sous forme écrite ou par des moyens
oraux ou visuels, y compris les briefings et les symposiums auxquels des
étrangers étaient présents.
« Mais, pris à la lettre, les règlements vagues et exagérément étendus
sembleraient indiquer que toute personne désirant prendre la parole publi
quement ou écrire sur un des sujets repris sur la liste des munitions devrait
obtenir l’approbation du Département d’Etat — une perspective peu ré
jouissante qui va manifestement à l’encontre du premier amendement et
qui n’a pas encore été portée en justice. »
En fin de compte, la N SA a désavoué l’acte de M e y e r , et l’article sur le R S A a été

présenté comme prévu. Aucune action n ’a été entamée contre ses inventeurs, bien que
leurs travaux ont bel et bien amélioré les capacités étrangères de cryptographie plus
que tout ce qui a été diffusé depuis.
La déclaration suivante de la NSA concerne l’exportation de la cryptographie [367] :
« La technologie cryptographique est vitale aux intérêts nationaux de

25.14 Réglementation américaine à l’exportation 645
sécurité. Ceux-ci comprennent les intérêts économiques, militaires et des

affaires étrangères
« Nous ne sommes pas d’accord avec les implications de l’audience du
7 mai 1992 du « House Judiciary Committee » et les articles récents pa
rus dans la presse qui prétendent que les lois d ’exportation américaines
empêchent la fabrication et l’utilisation par les firmes américaines d’équi
pements de chiffrement de haute tenue. Nous ne connaissons aucun cas de
société américaine qui aurait été empêchée de fabriquer et d’utiliser des
équipements de chiffrement au sein de ce pays, ou pour un usage par des
sociétés américaines ou ses filiales en des localisations hors Etats-Unis. De
fait, la N SA a toujours soutenu l’utilisation du chiffrement par les sociétés
américaines opérant à l’intérieur et hors de nos frontières pour protéger les
informations sensibles.
« En ce qui concerne l’exportation vers des pays étrangers, la N SA en
tant que composante du Département de la Défense (avec le Département
d ’Etat et le Département du Commerce) analyse les licences d’exporta
tion pour des technologies de sécurité des informations contrôlées par les
« Export Administration Régulations » ou les « International Traffic and
Arms Régulations ». Des systèmes similaires de contrôle des exportations
sont en place dans tous les pays faisant partie du « Coordinating Committee
for Multilatéral Export Controls » (C o C o m ) ainsi que dans de nombreux
pays ne faisant pas partie du C o C o m , car ces technologies sont univer
sellement considérées comme sensibles. De telles technologies ne sont pas
interdites d ’exportation et sont analysées cas par cas. Dans le cadre du
processus d’analyse de demandes d’exportation, des licences peuvent être
nécessaires pour ces systèmes et celles-ci sont analysées pour déterminer
l’impact qu’aurait une telle exportation sur les intérêts de la sécurité na
tionale. Les licences d’exportation sont octroyées ou refusées sur la base du
type d ’équipement impliqué, de l’utilisation finale prévue et de l’utilisateur
final envisagé.
« Notre analyse indique que les Etats-Unis sont les leaders mondiaux
en matière de fabrication et d ’exportation de technologies de sécurité de
l’information. Parmi ces produits cryptologiques soumis à la N SA par le
Département du Commerce pour l’obtention d’une licence d’exportation,
nous en approuvons régulièrement plus de 90 %. Les licences d ’exportation
pour des produits de sécurité de l’information, qui sont sous la juridiction
du Département du Commerce, sont traitées et approuvées sans en référer
à la N SA ou au Département de la Défense. Ceci inclut les produits qui
utilisent des technologies telles que le DSS ou R SA pour offrir des possibi
lités d ’authentification et de contrôle d’accès d’ordinateurs ou de réseaux.
En fait, de par le passé la NSA a joué un rôle majeur en militant avec
succès pour le relâchement des contrôles d’exportation pour le R S A et des
technologies similaires utilisées à des fins d ’authentification. De telles tech
niques sont extrêmement utiles pour lutter contre les pirates et l’utilisation
non autorisée de ressources. »
C’est la règle affirmée de la NSA de ne pas restreindre l’exportation des produits d’au
thentification, seuls les produits de chiffrement étant concernés. Si vous voulez exporter
un produit uniquement d’authentification, l’obtention de l’approbation peut consister

juste à montrer que votre produit n’est pas facilement utilisable pour le chiffrement.
De plus, les procédures administratives sont nettement plus simples pour les produits
d ’authentification que pour les produits de chiffrement. Un produit d ’authentification
a besoin de l’approbation du Département d ’Etat ime fois seulement pour le C J ; un
produit de chiffrement peut nécessiter une approbation pour chaque révision, ou même
pour chaque vente.
Sans un CJ, vous devez demander une autorisation d’exportation à chaque fois que
vous voulez exporter le produit. Le Département d ’Etat n’approuve pas l’exporta
tion de produits avec de puissants chiffrements, même ceux utilisant le DES. Des
exceptions isolées incluent les exportations vers des auxiliaires américains à des fins
de communications vers les Etats-Unis, les exportations pour quelques applications
bancaires et les exportations vers des utilisateurs militaires américains appropriés. La
« Software Publishers Association » (SPA ) a négocié avec le gouvernement pour as
souplir les restrictions d’exportation de licences . Un arrangement de 1992, entre eux
et le Département d ’Etat, a assoupli les règles d’exportation pour les deux algorithmes
RC2 et R C 4, pour autant que la clef soit ait 40 bits ou moins. Voyez la section 7.1
pour plus d ’informations.
En 1993, Maria C a n t w e l l (D -W A ) a déposé un projet de loi sur ordre de l’industrie
informatique pour relâcher les contrôles sur les exportations de logiciels de chiffrement.
Le Sénateur Patty M u r r a y (D W A ) a déposé un projet de loi similaire au Sénat.
Le projet de C a n t w e l l fut annexé à la législation sur le contrôle des exportations
générales passant au Congrès, mais fut supprimé par le « House Intelligence Committe »
après un gros effort de pression de la part de la NSA. Quoi qu’ait pu faire la NSA,
ce fut très impressionnant ; le comité a voté à l’unanimité la suppression du projet de
loi. Je n’arrive pas à me souvenir de la dernière fois où un ensemble de législateurs ont
voté à l’unanimité pour quoi que ce soit.
En 1995, Dan B e r n s t e in , avec l’aide de l’E FF, a attaqué en justice le gouvernement
américain, cherchant ainsi à l’empêcher de restreindre la publication de documents
et de logiciels cryptographiques [150]. Le procès a conclu que les lois de contrôle des
exportations sont anticonstitutionnelles, une "insupportable contrainte à la parole, en
violation avec le Premier Amendement.” Spécifiquement, les charges indiquent que le
procédé actuel de contrôle des exportations
permet aux bureaucrates de restreindre la publication sans jamais aller en cour

de justice,
- procure trop peu de procédures de sécurité pour respecter le Premier

Amendement,
requiert des éditeurs une inscription auprès du gouvernement, créant ainsi une
"presse accréditée” ,
- n’autorise pas la publication générale en exigeant que les destinataires soient

individuellement identifiés,
est trop vague pour que des personnes ordinaires puissent savoir quelle conduite
est autorisée et laquelle ne l’est pas,
25.15 Importation et exportation de cryptographie
- englobe trop de choses car il interdit une conduite qui est clairement protégée
(parler à des étrangers aux Etats-Unis, par exemple),
- est trop largement appliqué, en interdisant l’exportation de logiciels qui ne

contiennent pas de cryptographie, se basant sur la théorie que l’on pourrait ajou
ter de la cryptographie plus tard,
- viole aisément le Premier Amendement en interdisant un discours privé sur la

cryptographie car le gouvernement veut que ce soit son opinion sur la cryptogra
phie qui guide le public,
- dépasse son autorité accordée par le Congrès pour les lois de contrôle des expor
tations, ainsi que celle accordé par la Constitution.
Tout le monde pense que statuer sur ce cas prendra plusieurs années et personne ne
sait comment cela finira.
Entre-temps, le « Computer Security and Privacy Advisory Board », un comité consul
tatif officiel du N IST, a voté en mars 1992 pour recommander la révision des règles
nationales en matière de cryptographie, y compris les règles d ’exportation. Ils disent
que les règlements sont édictés exclusivement par les agences impliquées dans la sécurité
nationale, sans consultation des agences concernées par l’encouragement du commerce.
Les agences préoccupées par la sécurité nationale font tout leur possible pour s’assurer
que ces règlements ne changent pas, mais il va bien falloir qu’ils évoluent.
25.15 Importation et exportation de cryp

tographie
Les autres pays ont leurs propres réglementations sur l’importation et l’exporta
tion [316]. Ce résumé est incomplet et probablement dépassé. Des pays peuvent avoir
une réglementation et l’ignorer, ou ne pas en avoir mais restreindre l’importation, l’ex
portation et l’utilisation de toutes façons.
- L’Australie impose un certificat d ’importation pour la cryptographie à la seule

demande du pays exportateur.
- Le Canada ne procède pas à des contrôles d’importations et les contrôles d’ex

portations sont similaires à ceux effectués par les Etats-Unis. L’exportation de
matériels du Canada peut être sujet à restriction s’ils sont inclus dans l’« Export
Control List », conformément à l’ « Export and Import Permits Act ». Le Canada
se conforme au règlement du C o C o m en ce qui concerne la technologie crypto
graphique. Les systèmes de chiffrement sont décrits dans la catégorie cinq, partie
deux de la réglementation des exportations canadiennes. Ces dispositions sont si
milaires à la catégorie cinq américaine de l’« Export Administration Régulations ».
- La Chine a un plan d’autorisation pour les marchandises importées ; les exporta

teurs doivent déposer un dossier auprès du Ministère du commerce extérieur. Se
basant sur la liste chinoise, établie en 1987, des importations et exportations pro
hibées ou restreintes, la Chine limite l’importation et l’exportation de systèmes
de chiffrement de voix.
- La France n’a pas de règlement spécial pour l’importation de la cryptographie,

mais il y a des règles concernant la vente et l’utilisation de la cryptographie dans
leur pays. Tous les produits doivent être certifiés : soit ils correspondent à une
spécification publiée, soit la spécification de l’entreprise propriétaire est commu
niquée au gouvernement. Le gouvernement peut aussi demander deux unités pour
son propre usage. Les entreprises doivent avoir une autorisation pour vendre de la
cryptographie en France ; cette autorisation spécifie le marché cible. Les utilisa
teurs doivent avoir une autorisation pour acheter et se servir de la cryptographie ;
cette autorisation inclus une clause stipulant que les utilisateurs doivent céder
leurs clefs au gouvernement jusqu’à quatre mois après utilisation. Cette restric
tion peut être levée dans certains cas : les banques, les entreprises importantes,
etc... U n’y a pas de licence d ’exploitation pour la cryptographie exportable des
Etats-Unis.
- L ’Allemagne suit les directives du C o C o m , exigeant une autorisation pour ex

porter la cryptographie. Ils gardent spécifiquement le contrôle des logiciels de
cryptographie dans le domaine publique et le marché de masse.
- Israël a des restrictions sur l’importation, mais personne ne semble les connaître.
- La Belgique, l’Italie, le Japon, la Hollande et le Royaume-Uni se conforment

aux directives du C o C o m sur la cryptographie, exigeant une autorisation pour
exporter.
- Le Brésil, l’Inde, le Mexique, la Russie, l’Arabie-Saoudite, l’Espagne, l’Afrique

du Sud, la Suède et la Suisse n’exercent pas de contrôles sur l’importation ou
l’exportation de cryptographie.
25.16 Légalité
Est-ce que les signatures numériques sont de vraies signatures? Ont-elles une valeur
en justice? Certaines investigations légales préliminaires indiquent que les signatures
numériques pourraient satisfaire les critères de signatures liant leur signataire pour la
plupart des utilisations, notamment l’utilisation commerciale telle que définie par le
« Universal Commercial Code » (U C C ). Une décision du « Government Accounting
Office » (G A O ), prise à la requête du N IST, confirme que les signatures numériques
satisferaient les standards légaux des signatures manuscrites [366].
Le « Utah Digital Signature Act » a pris effet le 1er mai 1995, procurant un cadre légal
pour l’utilisation de signatures digitales dans le système judiciaire. La Californie en
mesure les effets, l’Orégon et Washington écrivent encore le leur. Le Texas et la Floride
suivent derrière. D ’ici à la publication de ce livre, d’autres Etats auront suivi.
L ’ « American Bar Association » (ED I et 1’ « Information Technology Division »
de la « Science and Technology Section ») propose un modèle d ’acte que les Etats
peuvent utiliser pour leur propre législation. Cet acte tente d’incorporer les signa
tures digitales dans l’infrastructure existante légale pour les signatures : le « Uniform
Commercial Code », la règlementation de la « United States Fédéral Reserve », la loi
commune des contrats et signatures, la « United Nations Convention on Contracts for
25.16 Légalité 649
the International Sale of Goods » et la « United Nations Convention on International

Büls of Exchange and International Promissory Committees ». Sont inclus dans cet
acte les responsabilités et les obligations des autorités de certification, les termes de
l’accord, de ses limites et de sa politique
Aux Etats-Unis, les lois sur les signatures, les contrats et les transactions commerciales
sont des lois d’Etat. Le but ultime est un acte fédéral, mais si tout ceci démarre au
niveau de l’Etat, il y a moins de chances pour que la NSA vienne gâcher le travail.
Même ainsi, la validité des signatures numériques n ’a pas encore été mise en doute en
cour de justice ; leur statut légal est encore indéfini. Pour que les signatures numériques
aient la même valeur que des signatures manuscrites, elles doivent primo être utilisées
pour signer mi document liant le signataire de manière légale et elles doivent secundo
être mises en question en justice par l’une des parties. La cour devrait alors juger de
la sécurité du schéma de signature et émettre un jugement. Au fil du temps, comme
il est de coutume, une jurisprudence émergerait concernant les méthodes de signature
numérique et la taille de clef requise pour qu’une signature numérique soit légalement
contraignante. Ceci risque de prendre des années.
En attendant, si deux personnes veulent utiliser des signatures numériques pour des
contrats (ou des bons de commande, ou des demandes de travaux, ou quoique ce soit),
il est recommandé qu’elles signent un contrat papier par lequel elles s’accordent à être
liées dans le futur par tout document qu’elles signeraient numériquement [1105] Ce
document préciserait l’algorithme, la taille de la clef et tout autre paramètre ; il devrait
aussi décrire comment les disputes doivent être résolues.
Postface de Matt Blaze
Un des plus dangereux aspects de la cryptologie (et par extension, de ce livre), est que
vous pouvez presque la mesurer. La connaissance de la longueur de clef, de la méthode
de factorisation et des techniques cryptanalytiques rend possible l’estimation (en l’ab
sence d’une réelle théorie de la conception d’algorithmes de chiffrement) du « facteur
travail » nécessaire pour casser un algorithme de chiffrement particulier. Il est trop
tentant d ’abuser de ces estimations, comme si elles n’étaient en général qu’une sécurité
adaptée aux systèmes dans lesquels elles sont utilisées. Le monde réel offre à l’atta
quant, un menu bien plus riche en options qu’une simple cryptanalyse. Les protocoles
d’attaques sont souvent plus inquiétants, le cheval de Troie, les virus, la surveillance
électromagnétique, les compromis physiques, le chantage et les intimidations des dé
tenteurs de clefs, les bogues des systèmes d’exploitation, les bogues des programmes
d’application, les problèmes de matériels, les erreurs de l'utilisateur, les oreilles indis
crètes, la corruption et la fouille de poubelles, pour en nommer quelques-uns.
Les chiffres et les protocoles de bonne qualité sont des outils importants, mais sont
de pauvres substituts à une réflexion sur ce qui est véritablement protégé et sur les
différentes manières dont une défense peut s’effondrer (les pirates, après tout, se li
mitent rarement aux modèles de menaces propres et bien définis du monde acadé
mique). Ross A n d er so n nous donne des exemples de systèmes cryptographiques forts
(dans le domaine bancaire) qui ont cédé sous des attaques réelles [44, 45]. Même quand
un assaillant n’a accès qu’au texte chiffré, des brèches apparemment mineures dans
d’autres parties du système peuvent laisser fuir assez d ’information pour que de bons
systèmes cryptographiques deviennent inutiles. Les Alliés pendant la Seconde Guerre
Mondiale ont cassé le trafic par E n ig m a allemands en exploitant largement les erreurs
des opérateurs [1589].
Une connaissance employée à la N SA ironise, quand on lui demande si le gouvernement
peut casser le trafic DES, sur le fait que les vrais systèmes sont si peu sûrs qu’ils
n’ont pas besoin de s’en donner la peine. Hélas, il n’existe pas de recette facile pour
rendre un système sûr, aucun substitut à une conception soigneuse et critique, avec une
attention minutieuse. Les bons systèmes cryptographiques ont la propriété de rendre
la vie des assaillants beaucoup plus dure que celle des simples utilisateurs ; ce n’est pas
le cas dans la plupart des autres aspects concernant la sécurité des ordinateurs et des
communications. Regardez la liste suivante des dix plus grandes menaces à la sécurité
des systèmes réels ; toutes sont plus faciles à exploiter qu’à éviter.
1. L’état désastreux du logiciel. Chacun sait que personne ne sait écrire un logiciel.
Les systèmes modernes sont complexes, avec des centaines de milliers de lignes
de codes ; chacune d ’entre-elles a des chances de compromettre la sécurité. Des
652 Postface de Matt Blaze
erreurs fatales peuvent même être très éloignées de la partie dédiée à la protection
du logiciel.
2. Protection inefficace contre les attaques de refus de service. Quelques protocoles

cryptographiques autorisent l’anonymat. Il peut être spécialement dangereux de
déployer des protocoles anonymes s’ils augmentent les opportunités d’interrup
tion de service par des vandales non-identifiés ; les systèmes anonymes ont donc
besoin d ’être tout particulièrement résistant aux attaques de refus de service.
Les réseaux robustes peuvent supporter plus facilement l’anonymat ; pensez que
presque personne ne se soucie beaucoup des millions de points d ’entrée anonymes
à des réseaux plus robustes tels que le système téléphonique ou le service postal,
où il est relativement difficile (ou cher) pour quelqu’un de causer des pannes à
grande échelle.
3. Manque de place pour stocker les secrets. Les systèmes cryptographiques pro
tègent les secrets importants par des plus petits (clefs). Hélas, les ordinateurs
modernes ne sont pas vraiment bons pour protéger même les plus petits secrets.
Les stations de travail multi-utilisateurs en réseau peuvent être infiltrées et leurs
mémoires compromises. Les unités à utilisateur unique peuvent être volées ou
infectées par des virus qui distillent des secrets de façon asynchrone. Les serveurs
isolés, où il peut ne pas y avoir d ’utilisateur pour entrer le mot de passe (voir
menace n5), sont un problème particuüèrement délicat.
4. Génération aléatoire de nombre peu performante. Les clefs et les variables de

session ont besoin de bonnes sources de bits non prévisibles. Un ordinateur qui
fonctionne possède en soi beaucoup d’entropie mais fournit rarement des appli
cations qui en permettent une exploitation pratique et fiable. Un certain nombre
de techniques ont été proposées pour obtenir de vrais nombres aléatoires dans
les logiciels (profiter d ’événements imprévisibles comme les dates d ’arrivées des
entrées-sorties, les décalages des horloges et les chronomètres et même la turbu
lence de l’air à l’intérieur du disque), mais tout ceci est très sensible au moindre
changement d ’environnement dans lequel ils sont utilisés.
5. Faibles phrases-mots de passe. La plupart des programmes cryptographiques

traitent les problèmes de stockage et de génération de clef en se reposant sur
les mots de passe de l’utilisateur, qui sont censés être assez imprévisibles pour
être de bonnes clefs et qui sont aussi assez faciles à retenir pour ne pas avoir à
être stockés. Alors que les attaques des petits mots de passe avec l’aide du dic
tionnaire sont un problème bien connu, on ignore les lignes d’attaque contre des
phrases entières de mots de passe. Selon S h a n n o n , un texte anglais présente à
peine plus d ’un bit d ’entropie par caractère, ce qui semblerait mettre la plupart
des phrases-mots de passe à la portée d ’une recherche exhaustive. On ignore ce
pendant comment énumérer les phrases-mots de passe afin d ’exploiter cela. Tant
que nous ne comprendrons pas mieux la manière d’attaquer les phrases-mots de
passe, nous n’aurons aucune idée de leur robustesse.
6. Une confiance mal placée. La plupart des programmes de cryptographie actuel

lement disponibles supposent que l’utilisateur exerce un contrôle direct sur les
systèmes auxquels il fait appel et emprunte un chemin sûr. Par exemple, les inter
faces vers un programme tel que P G P supposent que la saisie des phrases-mots
Postface de Matt Blaze 653
de passe est toujours opérée par l’utilisateur et par une voie sûre, telle qu’une
console locale. Ce n’est pas toujours le cas, bien sûr ; considérez le problème de
la lecture de votre courrier chiffré quand vous êtes connecté à un réseau. Ce que
l’éditeur de système pense être sûr peut ne pas répondre aux besoins et aux at
tentes des utilisateurs, tout particulièrement quand le logiciel peut être contrôlé
à distance à travers des réseaux peu sûrs.
7. Des interactions de protocole et de service mal comprises. Au fur et à mesure

que les systèmes grossissent et deviennent plus complexes, des fonctionnalités
bénignes reviennent fréquemment nous hanter, et il est dur de savoir où chercher
l’erreur. INTERNET s’est propagé via une fonction obscure et à l’apparence inno
cente qu’est le programme d ’envoi de courrier; combien encore de fonctions dans
combien d’autres programmes ont des conséquences inattendues qui attendent
juste d ’être découvertes?
8. Une évaluation qui n’est pas réaliste de la menace et des risques. Les experts de la
sécurité ont tendance à se concentrer sur les menaces qu’ils connaissent et dont ils
savent se protéger. Hélas, les pirates se concentrent sur ce qu’ils savent exploiter,
et les deux visions sont rarement identiques. De trop nombreux systèmes « sûrs »
sont réalisés sans considérer ce que les pirates sont vraiment susceptibles de faire.
9. Les interfaces qui rendent la sécurité chère et spéciale. Si des fonctions de sécurité
peuvent être utilisées, elles doivent être assez pratiques et transparentes pour que
les gens puissent les activer. Il est facile de réaliser des mécanismes de chiffrement
au seul prix de la performance ou de la facilité d ’emploi, et il est encore plus facile
de réaliser des mécanismes qui poussent à l’erreur. La sécurité devrait être plus
dure à désactiver qu’à activer ; seulement, peu de systèmes fonctionnent vraiment
comme cela.
10. Peu d’engoûment général pour la sécurité. C ’est un problème bien connu de
la plupart de ceux qui ont voulu faire fortune en vendant des produits et des
services de sécurité. Tant qu’il n’y aura pas une large demande pour une sécurité
transparente, les outils et l’infrastructure nécessaires pour la supporter seront
chers et maccessibles pour beaucoup d’applications. C ’est en partie un problème
de compréhension et d’explication des menaces et des risques dans les applications
réelles, mais aussi un défaut des systèmes qui n’incluent pas la sécurité comme
une fonction de base mais plutôt comme un additif.
Une liste et une discussion plus complètes sur ce type de menaces pourrait facilement
remplir un livre de cette taille sans pour autant égratigner la surface du problème. Ce
qui les rend spécialement difficiles et dangereuses est qu’il n’existe pas de techniques
magiques, mis à part une bonne organisation et une surveillance de tous les instants.
La leçon pour un aspirant cryptographe est qu’il faut respecter les limites de l’art.
M att B l a z e
New York, NY
Cinquième partie
Code source
DES
d3des.h
/* d3des.h -
*
* Headers and defines for d3des.c
* Graven Imagery, 1992.
*
* Copyright (c) 1988,1989,1990,1991,1992 by Richard Outerbridge
* (GEnie : OUTER; CIS : [71755,204])
*/
#define D2_DES /* include double-length support */

#define D3_DES /* include triple-length support */
#ifdef D3_DES
#ifndef D2_DES
#define D2.DES /* D2_DES is needed for D3_DES */
#endif
#endif
#define ENO 0 / * MODE == encrypt */

#define DE1 1 /* MODE == decrypt * /
/ * A useful alias on 68000-ish machines, but NOT USED HERE. */
typedef imion {
unsigned long b l o k [2];
unsigned short w o r d [ 4 ] ;
unsigned char byte[8];
> M68K;
typedef union -[
unsigned long d b l ok[4];
unsigned short d w o rd[8];
unsigned char dbyte[16];
> M68K2 ;
extern void deskey(unsigned char *, short);

/* h e x k e y [8] MODE
658 DES
* Sets the internai key register according to the hexadécimal

* key contained in the 8 bytes of hexkey, according to the DES,
* for encryption or decryption according to MODE.
*/
extern void usekey(unsigned long *);

/* c ookedkey[32]
* Loads the internai key register with the data in cookedkey.
*/
extern void cpkey(unsigned long *);

/* cookedkey [32]
* Copies the contents of the internai key register into the storage
* located at fecookedkey[0].
*/
extern void des(unsigned char *, unsigned char *);

/* from[8] to[8]
* Encrypts/Decrypts (according to the key currently loaded in the
* internai key register) one block of eight bytes at address ’f r o m ’
* into the block at address ’t o ’. They can be the same.
*/
#ifdef D2_DES
#define desDkey(a.b) des2key((a), (b))

extern v oid des2key(unsigned char *, short);
* Sets the internai key registerS according to the hexadécimal
* keyS contained in the 16 bytes of hexkey, according to the DES,
* for DOUBLE encryption or decryption according to MODE.
* NOTE: this clobbers ail three key registers!
*/
extern void Ddes(unsigned char *, unsigned char *);

/* from[8] to[8]
* Encrypts/Decrypts (according to the keyS currently loaded in the
* internai key registerS) one block of eight bytes at address ’f r o m ’
* into the block at address ’t o ’ . They can be the same.
*/
extern void D2des(unsigned char *, unsigned char *);

/* from[16] to[16]
* Encrypts/Decrypts (according to the keyS currently loaded in the
* internai key registerS) one block of SIXTEEN bytes at address ’f r o m ’
* into the block at address ’t o ’. They can be the same.
*/
extern void makekey(char *, unsigned char *);

/* *password, single-length k e y [8]
* With a double-length default key, this routine hashes a NULL-terminated
DES 659
* string into an eight-byte random-looking key, suitable for use with the
* deskeyO routine.
*/
#define makeDkey(a,b) make2key((a),(b))

extern void make2key(char *, unsigned char *);
/* *password, double-length k e y [16]
* With a double-length default key, this routine hashes a NULL-terminated
* string into a sixteen-byte random-looking key, suitable for use with the
* des2key() routine.
*/
#ifndef D3_DES / * D2_DES only */
#define useDkey(a) use2key((a))

#define cpDkey(a) cp2key((a))
extern void use2key(unsigned long *);

/* c ookedkey[64]
* Loads the internai key registerS with the data in cookedkey.
* NOTE: this clobbers ail three key registers!
*/
extern void cp2key(unsigned long *) ;

/* cookedkey[64]
* Copies the contents of the internai key registerS into the storage
* located at ftcookedkey[0].
*/
#else /* D3_DES too */
#define useDkey(a) use3key((a))

#define cpDkey(a) cp3key((a))
extern void des3key(unsigned char *, short);

* Sets the internai key registerS according to the hexadécimal
* keyS contained in the 24 bytes of hexkey, according to the DES,
* for DOUBLE encryption or decryption according to MODE.
*/
extern void use3key(unsigned long *);

/* cookedkey[96]
* Loads the 3 internai key registerS with the data in cookedkey.
*/
extern void cp3key(unsigned long *);

/* cookedkey[96]
* Copies the contents of the 3 internai key registerS into the storage
* located at &c o o kedkey[0].
*/
660 D ES
extern void make3key(char *, unsigned char *);

/* *password, triple-length key[24]
* With a triple-length default key, this routine hashes a NULL-terminated
* string into a twenty-four-byte random-looking key, suitable for use with
* the des3key() routine.
*/
#end^f /* D3_DES */
#endif / * D2.DES */
/* d3des.h V 5 .09 rwo 9208.04 15:06 Graven Imagery
d3des.c
/* D3DES (V5.0A) -
*
* A portable, public domain, version of the Data Encryption Standard.

*
* Written with S y m a n t e c ’s THINK (Lightspeed) C by Richard Outerbridge.
* Thanks to: Dan Hoey for his excellent Initial and Inverse permutation
* code; Jim Gillogly & Phil Karn for the DES key schedule code; Dennis
* Ferguson, Eric Young and Dana How for comparing notes; and Ray Lau,
* for humouring me on.
*
* Copyright (c) 1988,1989,1990,1991,1992 by Richard Outerbridge.
* .(GEnie : 0UTER; CIS : [71755,204]) Graven Imagery, 1992.
*/
#include "d3des.h"
static void scrunch(unsigned char *, unsigned long *);

static void unscrun(unsigned long *, unsigned char *);
static void desfunc(unsigned long *, unsigned long *);
static void cookey(unsigned long *);
static unsigned long KnL[32] = { 0L };

static unsigned long KnR[32] = { 0L >;
static unsigned long Kn3[32] = { 0L };
static unsigned char Df_Key[24] = {
0x01,0x23,0x45,0x67,0x89,0xab,0xcd,0xef,
Oxf e ,O x d c ,Oxba,0x98,0x76,0x54,0x32,0x10,
0x89,O x a b ,O x c d ,O x e f ,0x01,0x23,0x45,0x67 };
static unsigned short bytebit [8] = {

0200, 0100, 040, 020, 010, 04, 02, 01 };
static unsigned long bigbyte[24] = {

0 x 8 0 0 0 0 0L, 0 x400000L, 0x200000L, OxlOOOOOL,
DES 661
0 x 8 0 0 0 0 L, 0 x 4 0000L, 0x20000L, OxlOOOOL,

0x8000L, 0x4000L, 0x2000L, OxlOOOL,
0x800L, 0x400L, 0x200L, OxlOOL,
0x80L, 0x40L, 0x20L, OxlOL,
0x8L, 0x4L, Ox2L, OxlL >;
/ * Use the key schedule specified in the Standard (ANSI X3.92-1981). */
static unsigned char pci [56] = -(

56, 48, 40, 32, 24, 16, 8, 0, 57, 49, 41, 33, 25, 17,
9, 1, 58, 50, 42, 34, 26, 18, 10, 2, 59, 51, 43, 35,
62, 54, 46, 38, 30, 22, 14, 6, 61, 53, 45, 37, 29, 21,
13, 5, 60, 52, 44, 36, 28, 20, 12, 4, 27, 19, 11, 3 };
static unsigned char totrot[16] = -[

1,2,4,6,8,10,12,14,15,17,19,21,23,25,27,28 >;
static unsigned char pc2[48] = {

13, 16, 10, 23, 0, 4, 2, 27, 14, 5, 20, 9,
22, 18, 11, 3, 25, 7, 15, 6, 26, 19, 12, 1,
40, 51, 30, 36, 46, 54, 29, 39, 50, 44, 32, 47,
43, 48, 38, 55, 33, 52, 45, 41, 49, 35, 28, 31 };
void deskey(key, edf) /* Thanks to James Gillogly & Phil Karn! */

unsigned char * k e y ;
short e d f ;
1
int i, j, 1, m, n;
unsigned char pclm[56] , pcr[56] ;
unsigned long k n [ 3 2 ] ;
for ( j = 0; j < 56; j++ ) {

1 = pcl[j] ;
m = 1 & 07;
pclm[j] = (key[l » 3] & bytebitDn]) ? 1 : 0;
>
for( i = 0; i < 16; i++ ) {
i f ( edf == DE1 ) m = (15 - i) « 1;
else m = i << 1;
n = m + 1;
kn[m] = kn[n] = OL;
for( j = 0; j < 28; j++ ) {
1 = j + totrot [i] ;
if( 1 < 28 ) pcr[j] = pclm[l] ;
else pcr[j] = pclm[l - 28] ;
>
for( j = 28; j < 56; j++ ) {
1 = j + totrot [i] ;
if( 1 < 56 ) pcr[j] = pclm[l];
else pcr[j] = pclm[l - 28];
>
662 DES
for( j = 0; j < 24; j++ ) {

i f ( pcr [pc2[j]] ) kn[m] 1= bigbyte[j];
i f ( pcr[pc2[j+24]] ) kn[n] |= bigbyte[j];
}
}
cookey(kn);
return;
>
static void cookey(rawl)

unsigned long *rawl;
{
unsigned long *cook, ♦rawO;
unsigned long d ough[32];
int i;
cook = dough;
for( i = 0; i < 16; i++, rawl++ ) {
rawO = rawl++;
♦cook = (♦rawO & OxOOfcOOOOL) « 6;
♦cook 1= (♦rawO & OxOOOOOfcOL) « 10;
♦cook 1= (♦rawl & OxOOfcOOOOL) » 10;
♦cook++ 1= (♦rawl & OxOOOOOfcOL) » 6;
♦cook = (♦rawO & 0x0003f000L) « 12;
♦cook 1= (♦rawO & 0x0000003fL) « 16;
♦cook 1= (♦rawl & OxOO03fOOOL) » 4;
♦cook++ 1= (♦rawl & 0x0000003fL) 1
>
u s ekey(dough);
return;
>
void cpkey(into)
unsigned long *into;
unsigned long *from, ♦endp;
from = KnL, endp = &KnL[ 3 2 ] ;

w h i l e ( from < endp ) *into++ = ♦from+t;
return;
}
void usekey(from)
unsigned long *from;
unsigned long *to, *endp;
to = KnL, endp = & K n L [32];

w h i l e ( to < endp ) *to++ = *from++;
return;
}
DES 663
v o id d e s ( in b lo c k , o u tb lo c k )
u n s ig n e d c h a r * i n b l o c k , * o u tb lo c k ;
u n s ig n e d l o n g w o r k [ 2 ] ;
s c r u n c h (in b lo c k , w o rk );
d e s f u n c ( w o r k , K n L );
u n s c r u n (w o r k , o u tb lo c k );
retu rn ;
>
s t a t i c v o id s c r u n c h (o u to f, in t o )
u n s ig n e d c h a r * o u t o f ;
u n s ig n e d l o n g * i n t o ;
♦i n t o = (♦ O U to f++ ft O x f fL ) « 24;
♦i n t o 1= (♦ O U to f++ & O x ffL ) « 16;
♦ in to 1= ( ♦ o u t o f ++ & O x f fL ) « 8;
♦ in t o + + 1= C * o u t o f ++ & O x f f L ) ;
♦ in to = ( * o u t o f + + k O x f fL ) « 24;
♦ in to 1= ( * o u t o f + + & O x f fL ) « 16;
♦i n t o 1= ( * o u t o f ++ & O x f fL ) « 8;
♦ in to 1= ( * o u t o f & O x ffL );
retu rn ;
>
s t a t i c v o id u n s c r u n (o u t o f, in t o )
u n s ig n e d l o n g * o u t o f ;
u n s ig n e d c h a r * i n t o ;
* in to + + = (u n sig n e d c h a r ) ( ( * o u t o f » 2 4 ) & O x ffL )

* in to + + = (u n s ig n e d c h a r ) ( ( * o u t o f » 1 6 ) & O x f fL )
* i n t o + + = ( u n s ig n e d c h a r ) ( ( * o u t o f » 8 ) k O x f fL )
* in t o + + = ( u n s i g n e d c h a r ) ( * o u t o f ++ k O x f fL )
* in to + + = (u n sig n e d c h a r ) ( ( * o u t o f » 2 4 ) k O x f fL )
* in to + + = (u n s ig n e d c h a r ) ( (♦ o u to f » 1 6 ) k O x f fL )
* in to + + = (u n s ig n e d c h a r ) ( ( * o u t o f » 8 ) k O x f fL )
♦ in to = ( u n s ig n e d c h a r ) ( * o u t o f k O x ffL )
retu rn ;
>
s t a t i c u n s ig n e d l o n g SP1C64] = {
0 x 0 1 0 1 0 4 0 0 L , OxOOOOOOOOL, OxOOOlOOOOL, 0 x 0 1 0 1 0 4 0 4 L ,
0 x 0 1 0 1 0 0 0 4 L , 0 x 0 0 0 1 0 4 0 4 L , 0 x 0 0 0 0 0 0 0 4 L , OxOOOlOOOOL,
0x00000400L , 0x01010400L , 0x01010404L , 0x00000400L ,
0 x 0 1 0 0 0 4 0 4 L , 0 x 0 1 0 1 0 0 0 4 L , OxOlOOOOOOL, 0 x 0 0 0 0 0 0 0 4 L ,
0x00000404L , 0x01000400L , 0x01000400L , 0x00010400L ,
0 x 0 0 0 1 0 4 00 L , OxOlOlOOOOL, OxOlOlOOOOL, 0 x 0 1 0 0 0 4 0 4 L ,
0x00010004L, 0x01000004L, 0x01000004L , 0x00010004L,
OxOOOOOOOOL, 0 x 0 0 0 0 0 4 0 4 L , 0 x 0 0 0 1 0 4 0 4 L , OxOlOOOOOOL,
664 DES
OxOOOlOOOOL, 0x01010404L, 0x00000004L, OxOlOlOOOOL,

0x01010400L, OxOlOOOOOOL, OxOlOOOOOOL, 0x00000400L,
0x01010004L, OxOOOlOOOOL, 0x00010400L, 0x01000004L,
0x00000400L, 0x00000004L, 0x01000404L, 0x00010404L,
0x01010404L, OxOOO10004L, OxOlOlOOOOL, 0x01000404L,
0x01000004L, 0x00000404L, 0x00010404L, 0x01010400L,
0x00000404L, 0x01000400L, 0x01000400L, OxOOOOOOOOL,
0x00010004L, 0x00010400L, OxOOOOOOOOL, 0x01010004L >;
static unsigned long SP2 [64] = {

0x80108020L, 0x80008000L, 0x00008000L, 0x00108020L,
OxOOlOOOOOL, 0x00000020L, 0x80100020L, 0x80008020L,
0x80000020L, 0x80108020L, 0x80108000L, 0x80000000L,
0x80008000L, OxOOlOOOOOL, 0x00000020L, 0x80100020L,
0x80000000L, 0x00008000L, 0x00108020L, 0x80100000L,
0x00100020L, 0x80000020L, OxOOOOOOOOL, 0x00108000L,
0x00008020L, 0x80108000L, 0x80100000L, 0x00008020L,
OxOOOOOOOOL, 0x00108020L, 0x80100020L, OxOOlOOOOOL,
0x80008020L, 0x80100000L, 0x80108000L, 0x00008000L,
0x80100000L, 0x80008000L, 0x00000020L, 0x80108020L,
0x00108020L, 0x00000020L, 0x00008000L, 0x80000000L,
0x00008020L, 0x80108000L, OxOOlOOOOOL, 0x80000020L,
0x00100020L, 0x80008020L, 0x80000020L, 0x00100020L,
0x00108000L, OxOOOOOOOOL, 0x80008000L, 0x00008020L,
0x80000000L, 0x80100020L, 0x80108020L, 0x00108000L };
static unsigned long SP3[64] = {

0x00020008L, 0x08000008L, 0x08000008L, 0x00020000L,
0x08020208L, 0x00020008L, 0x08020000L, 0x00000208L,
0x08000000L, 0x00000008L, 0x08020200L, 0x00000200L,
0x00020200L, 0x08020000L, 0x08020008L, 0x00020208L,
0x08000208L, 0x00020200L, 0x00020000L, 0x08000208L,
0x00000008L, 0x08020208L, 0x00000200L, 0x08000000L,
0x08020200L, 0x08000000L, 0x00020008L, 0x00000208L,
0x00000200L, 0x00020008L, 0x08020208L, 0x08000200L,
0x08000208L, 0x00020000L, 0x08000000L, 0x08020208L,
0x00000008L, 0x00020208L, 0x00020200L, 0x08000008L,
0x08020000L, 0x08000208L, 0x00000208L, 0x08020000L,
0x00020208L, 0x00000008L, 0x08020008L, 0x00020200L >;
static unsigned long SP4 [64] = {

0x00802001L, 0x00002081L, 0x00002081L, 0x00000080L,
0x00802080L, 0x0080008IL, 0x0080000IL, 0x0000200IL,
OxOOOOOOOOL, 0x00802000L, 0x00802000L, 0x0080208IL,
0x0000000IL, 0x00002000L, 0x00800000L, 0x0080200IL,
DES 665
0x00000080L, 0x00800000L , 0x00002001L , 0x00002080L,

0 x 0 0 8 0 0 0 8 1 L , OxOOOOOOOlL, 0 x 0 0 0 0 2 0 8 0 L , 0 x 0 0 8 0 0 0 8 0 L ,
0 x 0 0 0 0 2 0 0 0 L , 0 x 0 0 8 0 2 0 8 0 L , 0 x 0 0 8 0 2 0 8 I L , 0 x 0 0 0 0 0 0 8 IL ,
0x00800080L , 0x00800001L , 0x00802000L , 0x00802081L,
0 x 0 0 0 0 0 0 8 I L , OxOOOOOOOOL, OxOOOOOOOOL, 0 x 0 0 8 0 2 0 0 0 L ,
0 x 0 0 0 0 2 0 8 0 L , 0 x 0 0 8 0 0 0 8 0 L , 0 x 0 0 8 0 0 0 8 1 L , OxOOOOOOOlL,
0x0080200IL , 0x0000208IL , 0x00002081L , 0x00000080L,
0 x 0 0 8 0 2 0 8 1 L , 0 x 0 0 0 0 0 0 8 1 L , OxOOOOOOOlL, 0 x 0 0 0 0 2 0 0 0 L ,
0x0080000I L , 0x00002001L , 0x00802080L , 0x00800081L ,
0x0 0 0 0 20 0 IL , 0x00002080L , 0x00800000L , 0x00802001L ,
0x00000080L , 0x00800000L , 0x00002000L , 0x00802080L > ;
s t a t i c u n s ig n e d l o n g S P 5 [6 4 ] = {
0 x00000100L, 0x02080100L , 0x02080000L , 0x42000100L,
0 x 0 0 0 8 0 0 0 0 L , OxOOOOOlOOL, 0 x 4 0 0 0 0 0 0 0 L , 0 x 0 2 0 8 0 0 0 0 L ,
0x4 0 0 8 0 100L, 0x00080000L , 0x02000100L , 0x40080100L ,
0x42000100L , 0x42080000L , 0x00080100L , 0x40000000L,
0 x 0 2 0 0 0 0 0 0 L , 0 x 4 0 0 8 0 0 0 0 L , 0 x 4 0 0 8 0 0 0 0 L , OxOOOOOOOOL,
0x40000100L , 0x42080100L , 0x42080100L , 0x02000100L ,
0 x 4 2 0 8 0 0 0 0 L , 0 x 4 0 0 0 0 1 0 0 L , OxOOOOOOOOL, 0 x 4 2 0 0 0 0 0 0 L ,
0x02080100L , 0x02000000L , 0x42000000L , 0x00080100L ,
0 x 0 0 0 8 0 0 0 0 L , 0 x 4 2 0 0 0 1 0 0 L , OxOOOOOlOOL, 0 x 0 2 0 0 0 0 0 0 L ,
0x40000000L , 0x02080000L , 0x42000100L , 0x40080100L ,
0 x 0 2 0 0 0 1 0 0 L , 0 x 4 0 0 0 0 0 0 0 L , 0 x 4 2 0 8 0 0 0 0 L , 0 x 0 2 0 8 0 100L ,
0 x 4 0 0 8 0 1 0 0 L , OxOOOOOlOOL, 0 x 0 2 0 0 0 0 0 0 L , 0 x 4 2 0 8 0 0 0 0 L ,
0x42080100L , 0x00080100L , 0x42000000L , 0x42080100L,
0 x 0 2 0 8 0 0 0 0 L , OxOOOOOOOOL, 0 x 4 0 0 8 0 0 0 0 L , 0 x 4 2 0 0 0 0 0 0 L ,
0 x 0 0 0 8 0 100L, 0 x 0 2 0 0 0 100L, 0 x40000100L , 0x00080000L ,
OxOOOOOOOOL, 0 x 4 0 0 8 0 OOOL, 0 x 0 2 0 8 0 1 0 0 L , 0 x 4 0 0 0 0 1 0 0 L > ;
s t a t i c u n s ig n e d l o n g SP6C64] = {
0 x 2 0 0 0 0 0 1 0 L , 0 x 2 0 4 0 0 0 0 0 L , 0 x 0 0 0 0 4 0 0 0 L , 0 x 2 0 4 0 4 0 10L ,
0 x 2 0 4 0 0 0 0 0 L , OxOOOOOOIOL, 0 x 2 0 4 0 4 0 1 0 L , 0 x 0 0 4 0 0 0 0 0 L ,
0x20004000L , 0x00404010L , 0x00400000L , 0x20000010L ,
0x00400010L , 0x20004000L , 0x20000000L , 0x00004010L ,
OxOOOOOOOOL, 0 x 0 0 4 0 0 0 1 0 L , 0 x 2 0 0 0 4 0 1 0 L , 0 x 0 0 0 0 4 0 0 0 L ,
0 x 0 0 4 0 4 0 0 0 L , 0 x 2 0 0 0 4 0 1 0 L , OxOOOOOOIOL, 0 x 2 0 4 0 0 0 1 0 L ,
0x00004010L , 0x00404000L , 0x20404000L , 0x20000000L,
0 x 2 0 0 0 4 0 0 0 L , OxOOOOOOIOL, 0 x 2 0 4 0 0 0 1 0 L , 0 x 0 0 4 0 4 0 0 0 L ,
0x20404010L , 0x00400000L , 0x00004010L , 0x20000010L ,
0x00400000L , 0x20004000L , 0x20000000L , 0x00004010L,
0x20000010L , 0 x 2 0 4 0 40 10L, 0x00404000L , 0x20400000L ,
OxOOOOOOIOL, 0 x 0 0 0 0 4 0 0 0 L , 0 x 2 0 4 0 0 0 0 0 L , 0 x 0 0 4 0 4 0 1 0 L ,
0 x20404000L , 0x20000000L , 0 x00400010L , 0x20004010L > ;
s t a t i c u n s ig n e d l o n g S P 7 [6 4 ] = {
0x00000800L , 0x04000802L , 0x00200802L , 0x04200800L ,
666 DES
0 x00000002L , 0x04000000L , 0 x0 4 2 0 0002L , 0x00000802L ,
0x04000800L , 0x00200802L, 0x00200002L , 0x04000800L,
0x04000002L , 0x04200000L , 0x04200800L , 0x00200002L ,
0x04200000L , 0x00000800L , 0x00000802L , 0x04200802L,
0x00200800L, 0x00000002L, 0x04000000L, 0x00200800L,
0x04000000L, 0x00200800L, 0x00200000L, 0x04000802L,
0x04000802L , 0x04200002L , 0x04200002L , 0x00000002L ,
0x00200002L , 0x04000000L, 0x04000800L , 0x00200000L ,
0x04200800L , 0x00000802L, 0x00200802L , 0x04200800L ,
0x00000802L , 0x04000002L , 0x04200802L, 0x04200000L,
OxOOOOOOOOL, 0 x 0 0 2 0 0 8 0 2L , 0 x 0 4 2 0 0 0 0 0 L , 0 x 0 0 0 0 0 8 0 0 L ,
0 x 0 4 0 0 0002L , 0 x 0 4 0 0 0 8 0 0 L , 0 x 0 0 0 0 0 8 0 0 L , 0 x0 0 2 0 0 0 0 2 L > ;
s t a t i c u n s ig n e d l o n g S P 8 [6 4 ] = -f
0 x l0 0 0 1 0 4 0 L , OxOOOOlOOOL, 0 x 0 0 0 4 0 0 0 0 L , 0 x l0 0 4 1 0 4 0 L ,
OxlOOOOOOOL, 0 x l0 0 0 1 0 4 0 L , 0 x 0 0 0 0 0 0 4 0 L , OxlOOOOOOOL,
0 x 0 0 0 4 0 0 4 0 L , 0 x l0 0 4 0 0 0 0 L , 0 x l0 0 4 1 0 4 0 L , 0 x 0 0 0 4 1 0 0 0 L ,
0 x l0 0 4 1 0 0 0 L , 0 x 0 0 0 4 1 0 4 0 L , OxOOOOlOOOL, 0 x 0 0 0 0 0 0 4 0 L ,
0 x l0 0 4 0 0 0 0 L , 0 x l0 0 0 0 0 4 0 L , OxlOOOlOOOL, 0 x 0 0 0 0 1 0 4 0 L ,
0 x 0 0 0 4 1 0 0 0 L , 0 x 0 0 0 4 0 0 4 0 L , 0 x l0 0 4 0 0 4 0 L , 0 x l0 0 4 1 0 0 0 L ,
0 x 0 0 0 0 1 0 4 0 L , OxOOOOOOOOL, OxOOOOOOOOL, 0 x l0 0 4 0 0 4 0 L ,
0 x l0 0 0 0 0 4 0 L , OxlOOOlOOOL, 0 x 0 0 0 4 1 0 4 0 L , 0 x 0 0 0 4 0 0 0 0 L ,
0 x 0 0 0 4 1 0 4 0 L , 0 x 0 0 0 4 0 0 0 0 L , 0 x l0 0 4 1 0 0 0 L , OxOOOOlOOOL,
0 x 0 0 0 0 0 0 4 0 L , 0 x l0 0 4 0 0 4 0 L , OxOOOOlOOOL, 0 x 0 0 0 4 1 0 4 0 L ,
OxlOOOlOOOL, 0 x 0 0 0 0 0 0 4 0 L , 0 x l0 0 0 0 0 4 0 L , 0 x l0 0 4 0 0 0 0 L ,
0 x l0 0 4 0 0 4 0 L , OxlOOOOOOOL, 0 x 0 0 0 4 0 0 0 0 L , 0 x l0 0 0 1 0 4 0 L ,
OxOOOOOOOOL, 0 x l0 0 4 1 0 4 0 L , O x0 0 0 4 00 4 0 L , 0 x l0 0 0 0 0 4 0 L ,
0 x l0 0 4 0 0 0 0 L , OxlOOOlOOOL, 0 x l0 0 0 1 0 4 0 L , OxOOOOOOOOL,
0 x l0 0 4 1 0 4 0 L , 0 x 0 0 0 4 1 0 0 0 L , 0 x 0 0 0 4 1 0 0 0 L , 0 x 0 0 0 0 1 0 4 0 L ,
0 x 0 0 0 0 1 0 4 0 L , 0 x 0 0 0 4 0 0 4 0 L , OxlOOOOOOOL, 0 x l0 0 4 1 0 0 0 L } ;
s t a t i c v o id d e s fu n e (b lo c k , k e y s)
u n s ig n e d l o n g * b l o c k , * k e y s ;
{
u n s ig n e d l o n g f v a l , w ork , r i g h t , le ftt ;
in t rou n d ;
le ftt = b lo c k C O ];
r i g h t = b l o c k [1 ] ;
w ork = ( ( l e f t t » 4) * r ig h t) & O xO fO fO fO fL ;
r i g h t ~= w o rk ;
le ftt “ = (w o rk « 4 );
w o rk = ( ( l e f t t >> 1 6 ) " r i g h t ) & O xO O O O ffffL ;
r i g h t " = w o rk ;
le ftt “ = (w o rk << 1 6 ) ;
w ork = ( ( r i g h t » 2) “ le ftt) & 0x33333333L;
le ftt “ = w o rk ;
r i g h t ~= (w o rk « 2 );
w ork = ( ( r i g h t » 8) * le f t t ) & O xO O ffO O ffL ;
DES 667
leftt ~= work ;
right ~= (work « 8);
right = ((right « 1) 1 ((right » 31) & IL)) & OxffffffffL;
work = (leftt “ right) & OxaaaaaaaaL;
leftt '= work;
right "= work;
leftt = ((leftt « 1) I ((leftt » 31) & IL)) & OxffffffffL;
for( round = 0; round < 8; round++ ) {

work = (right « 28) | (right » 4);
w ork ~= *keys++;
fval = SP7[ work & 0x3fL];
fval |= S P 5 [(work » 8) & 0 x 3 f L ] ;
fval 1= SP3[(work » 16) & 0x3fL] ;
fval |= SPl[(work » 24) & 0 x 3 f L ] ;
work = right ' *keys++;
fval 1= SP8[ work & 0x3fL];
fval 1= SP6[(work » 8) & 0 x 3 f L ] ;
fval 1= SP4[(work » 16) & 0 x 3fL];
fval 1= SP2[(work » 24) & 0 x 3 f L ] ;
leftt ~= fval;
work = (leftt « 28) I (leftt » 4);
work ~= *keys++;
fval = SP7[ work & 0x3fL];
fval |= SP5[(work » 8) & 0 x 3 f L ] ;
fval 1= SP3[(work » 16) & 0 x 3fL];
fval |= SPl[(work » 24) ft 0 x 3fL];
work = leftt ' *keys++;
fval I= S P 8 [ work & 0 x 3fL];
fval |= SP6[(work » 8) & 0 x 3 f L ] ;
fval 1= SP4[(work » 16) ft 0 x 3 f L ] ;
fval |= SP2[(work » 24) & 0 x 3 f L ] ;
right ~= fval;
>
right = (right « 31) I (right » 1);

work = (leftt * right) & OxaaaaaaaaL;
leftt "= work;
right ~= work;
leftt = (leftt « 31) I (leftt » 1);
work = ((leftt >> 8) ~ right) & OxOOffOOffL;
right *= work;
leftt (work « 8);
work = ((leftt >> 2) “ right) & 0x33333333L;
right '= work;
leftt “= (work « 2);
work = ((right » 16) “ leftt) & OxOOOOffffL;
leftt “= work;
right “= (work « 16);
work = ((right » 4) " leftt) & OxOfOfOfOfL;
leftt “= work;
668 DES
right “= (work << 4);

♦block++ = right;
♦block = leftt;
return;
}
■#ifdef D2_DES
void des2key(hexkey, mode) /♦ stomps on Kn3 too ♦/

unsigned chair ♦hexkey; /♦ unsigned c h a r [16] ♦/
short mode;
{
short revmod;
revmod = (mode == ENO) ? DE1 : ENO;

d eskey(&hexkey[8], rev m o d ) ;
cpkey(KnR);
deskey(hexkey, mode);
c p k e y(Kn3); /♦ Kn3 = KnL ♦/
return;
>
void Ddes(from, into)

unsigned char ♦from, ♦into; /♦ unsigned c h a r [8] ♦/
{
unsigned long w o r k [2];
scrunch(from, w o r k ) ;
desfunc(work, KnL);
desfune(work, KnR) ;
desfunc(work, K n 3 ) ;
unscrun(work, into);
return;
>
void D2des(from, into)

unsigned char ♦from; /♦ unsigned char[16] ♦/
unsigned char ♦into; /♦ unsigned c h a r [16] ♦/
i
unsigned long ♦right, +11, swap;
unsigned long leftt [2], bufR[2] ;
right = bufR;
11 = ftleftt [1];
scrunch(from, l e f t t ) ;
scrunch(&from[8], r i g h t ) ;
d esfune(leftt, K n L ) ;
de s f u n e(right, K n L ) ;
swap = +11;
♦11 = ♦right;
♦right = swap;
DES 669
d e sfune(leftt, K n R ) ;
d esfune(right, K n R ) ;
swap = *11 ;
*11 = *right;
♦right = swap;
d esfune(leftt, K n 3 ) ;
d esfune(right, K n 3 ) ;
unscrun(leftt, into);
unscrun(right, feinto[8]);
return;
}
void makekey(aptr, kptr)

char *aptr; /* NULL-terminated */
unsigned char *kptr; /* unsigned c h a r [8] */
{
unsigned char *store;
int first, i;
unsigned long savek[96];
cpDkey(savek);
des2key(Df_Key, ENO);
for( i = 0; i < 8; i++ ) kptrti] = Df_Key[i] ;
first = 1;
w h i l e ( (*aptr != ’\ 0 ’) Il first ) {
store = kptr;
for( i = 0; i < 8 && (*aptr != ’\ 0 ’); i++ ) {
*store++ ~= *aptr & 0x7f;
*aptr++ = ’\ 0 ’;
>
Ddes(kptr, kptr);
first = 0;
>
useDkey(savek);
return;
>
void ma k e 2 k ey(aptr, kptr)

unsigned char *kptr; /* unsigned c h a r [16) */
{
int first, i;
cpDkey(savek);
d es2key(Df_Key, ENO);
for( i = 0; i < 16; i++ ) kptr[i] = Df_Key[i] ;
first = 1;
w h i l e ( (*aptr != ’\ 0 ’) Il first ) ■[
store = kptr;
670 DES
for( i = 0; i < 16 && (*aptr != ’\ 0 ’); i++ ) {

*store++ "= *aptr & 0x7f;
*aptr++ = ’\ 0 ’;
>
D2des(kptr, kptr);
first = 0;
>
u s e D k ey(savek);
return;
>
#ifndef D3_DES / * D2_DES only */
void cp2key(into)
unsigned long *into; /* unsigned long[64] */
i
unsigned long *from, *endp;
cpkey(into);
into = &into[32];
from = KnR, endp = & K n R[32];
w h i l e ( from < endp ) *into++ = *from++;
return;
>
void use2key(from) /* stomps on Kn3 too */

unsigned long *from; / * unsigned l o n g [64] */
u s e k e y (from);
from = & f r o m [32];
to = KnR, endp = & K n R[32];
c p k e y(Kn3); /* Kn3 = KnL */
return;
y
#else / * D3_DES too */
static void D3des(unsigned char *, unsigned char *);
void d es3key(hexkey, mode)

unsigned char * hexkey; / * unsigned c h a r [24] */
short mode;
{
unsigned char *first, *third;
short revmod;
if( mode == ENO ) {

revmod = D E 1 ;
DES 671
first = hexkey;
third = fchexkey[16];
>
else -[
revmod = ENO;
first = & h exkey[16];
third = hexkey;
}
deskey(fehexkey[8], revmod);
cpkey(KnR);
deskey(third, mode);
c pkey(Kn3);
d e s key(first, mode);
return;
}
void cp3key(into)
unsigned long *i n t o ; /* unsigned l o n g [96] */
unsigned long *from, *endp;
cpkey(into);
into = ftinto[32];
from = KnR, endp = &KnR[32];
w h i l e ( from < endp ) *intc++ =*from++;
from = K n 3 , endp = & K n 3 [32];
w h i l e ( from < endp ) *into++ = *from++;
return;
}
void use3key(from)
unsigned long *from; /* unsigned long[96] */
1
us e key(from);
from = &from[32] ;
to = KnR, endp = & K n R[32];
w h i l e ( to < endp ) *to++ - *from++;
to = Kn3, endp = &Kn3[32];
return;
}
static void D3des(unsigned char*, unsigned c h ar*);
static void D3des(from, into) /* amateur theatrics */

unsigned char *from; /* unsigned c h a r [24] */
unsigned char *into; /* unsigned cha r [24] */
unsigned long swap, l e f t t [2], middl[2], r i g h t [2];

672 DES
scrunch(from, l e f t t ) ;
scrunch(&from[8], m i d d l ) ;
scrunch(&from[16], right);
d e s f u n c(leftt, KnL);
desfune(middl, K n L ) ;
desfunc(right, KnL);
swap = l e f t t [1];
leftt [1] = middl [0];
m i d d l [0] = swap;
swap = m i d d l [1];
middl [1] = right [0];
right [0] = swap ;
desfunc(leftt, KnR);
de sfunc(middl, K n R ) ;
de sfunc(right, K n R ) ;
swap = leftt [1];
leftt [1] = middl [0];
m i d d l [0] = swap;
swap = m i d d l [1];
middl [1] = right [0];
r i g h t [0] = swap;
desfunc(leftt, Kn3);
d e s f u n e(middl, K n 3 ) ;
d e s f u n e(right, K n 3 ) ;
u n s c r u n d e f t t , into);
u nscrun(middl, feinto[8]);
un s c r u n(right, feinto[16]);
return;
}
void mak e 3 k e y ( a ptr, kptr)

unsigned char * k p t r ; /* unsigned c h a r [24] */
f
int first, i;
cp3key(savek);
des3key(Df_Key, ENO);
for( i = 0; i < 24; i++ ) kptr[i] = Df_Key[i] ;
first = 1 ;
while( (*aptr != ’ \ 0 ’ ) Il first ) {
store = kptr;
f o r ( i = 0; i < 24 && (*aptr != ’\ 0 ’); i++ ) {
*store++ "= *aptr & 0 x 7 f ;
*aptr++ = ’\ 0 ’;
>
D3des(kptr, kptr);
first = 0;
DES 673
>
u s e 3 k e y (s a v e k );
retu rn ;
>
# e n d if /* D3_DES * /
# e n d if /* D2_DES * /
/* V a lid a t io n sets:
*
* S in g le -le n g th k ey , s in g le -le n g t h p la in te x t -
* Key : 0123 4567 89ab c d e f
* P la in : 0123 4567 89ab cd e7
* C ip h e r : c95 7 4 4 2 5 6 a 5 e d31d
*
* D o u b le -le n g th k e y , s i n g le -le n g t h p la in t e x t -
* Key : 0123 4567 89ab c d e f f e d c b a 9 8 7 654 3 2 1 0
* P la in : 0123 4567 89ab cd e7
* C ip h e r :7 fld 0 a77 8 2 6 b 8 a f f
*
* D o u b le -le n g th k e y , d o u b le -le n g t h p la in t e x t -
* Key : 0123 4567 89ab c d e f f e d c ba98 7654 3210
* P la in : 0123 4567 89ab c d e f 0123 4567 89ab c d f f
* C ip h e r : 27a0 8440 406a d f6 0 2 7 8 f 4 7 c f 4 2 d 6 15d7
*
* T r ip le -le n g th k ey, s in g le -le n g t h p la in te x t -
* Key : 0123 4567 89ab c d e f f e d c b a 9 8 7 6 5 4 3 2 1 0 8 9 a b c d e f 0 1 2 3 4 567
* P la in : 0123 4567 89ab cd e7
* C ip h e r : deOb 7 c 0 6 a e 5 e 0 ed 5
*
* T r ip le -le n g t h k e y , d o u b le -le n g t h p la in t e x t -
* K ey : 0123 4567 89ab c d e f f e d c b a 9 8 7 6 5 4 3 2 1 0 8 9 a b c d e f 0123 4 567
* P la in : 0123 4567 89ab c d e f 0123 4567 89ab c d f f
* C ip h e r : adOd lb 3 0 a c l 7 c f 0 7 O e d l l c 6 3 8 1 e 4 4 d e5
*
* d 3 d e s V 5.0 A rw o 9 2 1 1 .0 9 1 3 :5 5 G ra ven Im a g ery

LOKI 91
loki.i
/*
* loki.i - contains the fixed permutation and substitution tables
* for a 64 bit L0KI89 & LDKI91 implémentations.
*
* Modifications:
* vl.O original tables Aug 1989 lpb
* v2.0 add various speed/size versions Apr 1990 lpb
* v2.1 install into RCS system for production control 5/90 lpb
* v3.0 L0KI89 & L0KI91 now supported 10/92 lpb
*
* Author: Laurence Brown <lpb@csadfa.oz> Aug 1989

* Computer Science, UC UNSW, ADFA, Canberra, ACT 2600, Australia.
*
* Copyright 1989 by Lawrence Brown and UNSW. Ail rights reserved.

* This program may not be sold or used as inducement to buy a
* product without the written permission of the author.
*/
/ * 32-bit permutation function P */

/* spécifiés which input bit is permuted to output bits */
/* 31 30 29 ... 2 1 0 respectively (ie in MSB to LSB order) */
char P[32] = {
31, 23, 15, 7, 30, 22, 14, 6,
29, 21, 13, 5, 28, 20, 12, 4,
27, 19, 11, 3, 26, 18, 10, 2,
25, 17, 9, 1, 24, 16, 8, 0
>;
/*
* sfn_desc - a desriptor table specifying which irreducible polynomial
* and exponent is to be used for each of the 16 S functions in
* the Loki S-box
*/
typedef struct -{
short gen; /* irreducible polynomial used in this field */
short exp; /* exponent used to generate this s function */
} sfn_desc;
676 L O K I 91
/*
* sfn - the table specifying the irreducible polys & exponents used
* in the Loki S-boxes for the Loki algorithm
*/
sfn_desc sfn[] = {
/* 101 11 0 1 1 1 * / 3 7 5 , 31}
/* 101111011 * / 3 7 9 , 31}
/* 110 00 0 1 1 1 * / 3 9 1 , 31}
/* 110001011 * / 3 9 5 , 31}
/* 110 00 1 1 0 1 * / 3 9 7 , 3 1 }
/* 1 1 0 011111 * / 4 1 5 , 3 1 }
/* 1 10 10 0 0 1 1 * / 4 1 9 , 3 1 }
/* 110101001 * / 4 2 5 , 31}
/* 1 1 0 11 0 0 0 1 * / 4 3 3 , 31}
/* 1 1 0 11 1 1 0 1 * / 4 4 5 , 31}
/* 11 1 00 0 0 1 1 * / 4 5 1 , 31}
/* 1 1 1 00 1 1 1 1 * / 4 6 3 , 31}
/* 111010111 * / 4 7 1 , 31}
/* 111011101 * / 4 7 7 , 3 1 }
/* 111100111 * / 4 8 7 , 3 1 }
/* 111110011 * / 4 9 9 , 31}
00, 00}
loki. h
/*
* loki.h - spécifiés the interface to the LOKI encryption routines.
* This library proviloki routines to expand a key, encrypt and
* decrypt 64-bit data blocks. The LOKI D ata Encryption Algorithm
* is a block cipher which ensures that its output is a complex
* function of its input and the key.
*
* Authors: Lawrie Brown <Lawrie.Brown@adfa.oz.au> Aug 1989
* Matthew Kwan <mkwan@cs.adfa.oz.au> Sep 1991
*
* Computer Science, UC UNSW, Australian Defence Force Academy,
* Canberra, ACT 2600, Australia.
*
* Version:
* vl.O - of loki64.o is current 7/89 lpb
* v2.0 - of loki64.c is current 9/91 mkwan
* v3.0 - now have loki89.c & loki91.c 10/92 lpb
*
* Copyright 1989 by Lawrie Brown and UNSW. Ail rights reserved.
* This program may not be sold or used as inducement to buy a
*
* Description:
L O K I 91 677
* The routines provided by the library are:

*
* lokikey(key) - expands a key into subkey, for use in
* char k e y [8]; encryption and decryption opérations.
*
* enloki(b) - main LOKI encryption routine, this routine
* char b [8]; encrypts one 64-bit block b with subkey
*
* deloki(b) - main LOKI decryption routine, this routine
* char b [ 8 ] ; decrypts one 64-bit block b with subkey
*
* The 64-bit d ata & key blocks used in the algorithm are specified as eight
* unsigned chars. For the purposes of implementing the LOKI algorithm,
* these MUST be word aligned with bits are numbered as follows:
* [63.-56] [55..48] ... [7..0]
* in b[0] b[l] b[2] b[3] b[4] b[5] b[6] b[7]
*/
#define LOKIBLK 8 /* Ko of bytes in a LOKI data-block */

#define ROUNDS 16 /* Ko of LOKI rounds */
typedef unsigned long Long; /* type spécification for aligned LOKI blocks */
extern Long lokikey[2]; /* 64-bit key used by LOKI routines */

extern char *loki_lib_ver;/* String with version no. & copyright */
#ifdef STDC /* déclaré prototypes for library functions */

extern void enloki(char b[LOKIBLK]);
extern void deloki(char b[LOKIBLK]);
extern void setlokikey(char key[LOKIBLK] ) ;
#else /* else just déclaré library functions extern */
extern void e n l o k i O , d e l o k i O , setlokikey() ;
#endif __STDC__
loki91.c
/*
* loki91.c - library routines for a 64 bit L0KI89 implémentation
*
* Designed b y Matthew Kwan <mkwan@crypto.cs.adfa.oz.au> and
* Lawrence Brown <lpb@cs.adfa.oz.au>
* Modifications:
* v2.0 - original set of code by mkwan 9/91
* v3.0 - support both L0KI89 & L0KI91 versions 10/92 lpb
*
* Copyright 1991 by Lawrence Brown and UNSW. Ail rights reserved.
* This prograin may not be sold or used as inducement to buy a
*
678 L O K I 91
* nb: if this program is compiled on a little-endian machine (eg Vax)

* #define LITTLE_ENDIAN
* in order to enable the byte swapping routines
*
* if a detailed trace of L0KI91 function f is required for debugging
* #define TRACE=n n=l print blocks, n=2 print fn f also
* n=3 print individual S-box cales also
*
* these routines assume that the 8-byte char arrays used to pass
* the 64-bit blocks fall on a word boundary, so that the blocks
* may be read as longwords for efficiency reasons. If this is
* not true, the load & save of the parameters will need changing.
*/
#include <stdio.h>
#include "loki.h" /* include Interface Spécification header file */
#include "loki.i" /* include Interface Spécification header file */
/*
* string specifying version and copyright message
*/
char *loki_lib_ver =
"L0KI91 library v3.0, Copyright (C) 1991 Lawrence Brown & UNSW";
Long loki_subkeys[ROUNDS]; /* subkeys at the 16 rounds */

static Long f (); /* déclaré LOKI function f */
static short sO; /* déclaré LOKI S-box fn s */
/*
* R0L12(b) - macro to rotate 32-bit block b left by 12 bits
* R0L13(b) - macro to rotate 32-bit block b left by 13 bits
*/
#define R0L12(b) b = ((b « 12) I (b » 20));

#define R0L13(b) b = ((b « 13) I (b » 19));
/*
* bswap(b) - exchanged bytes in each longword of a 64-bit data block
* on little-endian machines where byte order is reversed
*/
#ifdef LITTLE.ENDIAN
#define bswap(cb) -[ \
register char c; \
c = cb[0] ; cb [0] = cb [3] ; cb [3] = c ;
c = cb[l] ; cb[l] = cb[2]; cb [2] = c ;
c = c b [4] ; cb[4] = cb [7] ; cb[7] = c;
c = cb [5] ; cb [5] = cb [6] ; cb[6] = c;
>
#endif
L O K I 91 679
/*
* setlokikey(key) - save 64-bit key for use in encryptions & décryptions
* and compute sub-keys using the key schedule
*/
void
setlokikey(key)
char k e y[LOKIBLK]; /* Key to use, stored as an array of Longs */
i
register i;
register Long KL, KR;
#ifdef LITTLE_ENDIAN
b s w a p(key); /* swap bytes round if little-endian * /
#endif
#if TRACE >= 1

fprintf (stderr, " keyinit(%081x, */,081x) \n “ ,
((Long *)key)[0], ((Long *)key)[l]);
#endif
KL = ((Long * ) key)[0];
K R = ((Long *)key) [1];
for (i=0; i<R0UNDS; i+=4) { / * Generate the 16 subkeys */

loki_subkeys[i] = K L ;
R0L12 (KL);
loki_subkeys[i+l] = KL;
RDL13 (KL);
loki_subkeys[i+2] = KR;
R0L12 (KR);
loki_subkeys[i+3] = KR;
R0L13 (KR);
>
Jfifdef LITTLE_ENDIAU
bswap(key); /* swap bytes back if little-endian */
#endif
}
/*
* enloki(b) - main L0KI91 encryption routine, this routine encrypts one
* 64-bit block b using the LDKI91 algorithm with loki^subkeys
*
* nb: The 64-bit block is passed as two longwords. For the
* purposes of the L0KI89 algorithm, the bits are numbered:
* [6362 .. 33 32] [31 30 ... 1 0]
* The L (left) half is b[0], the R (right) half is b[l]
*
680 L O K I 91
*/
void
enloki (b)
char b [LOKIBLK];
{
register i;
register Long L, R; /* left & right data halves */
bswap(b); /* swap bytes round if little-endian */
#endif
#if TRACE >= 1

fprintf (stderr, " enlo k i ( ’/,0 8 1 x , y,081x)\n",
((Long *)b) [0] , ((Long *)b)[l]);
#endif
L = ((Long * ) b ) [0];
R = ((Long *)b) [1] ;
for (i=0; i<R0UNDS; i+=2) { /* Encrypt with the 16subkeys */

L ~= f (R, loki_subkeys[i]);
R “= f (L, loki_subkeys[i+1] );
}
((Long *)b) [0] = R; /* Y = swap(LR) */

((Long * ) b ) [1] = L;
#if TRACE >= 1

fprintf (stderr," enloki returns "/.081x, %081x\n",
((Long *)b) [0] , ((Long *)b)[l]);
#endif
bswap(b); /* swap bytes round if little-endian * /
#endif
>
/*
* deloki(b) - main L0KI91 decryption routine, this routine decrypts one
* 64-bit block b using the L0KI91 algorithm with loki_subkeys
*
* Decryption uses the same algorithm as encryption, except that
* the subkeys are used in reverse order.
*/
void
deloki(b)
char b [LOKIBLK];
L O K I 91 681
register i;
register Long L, R; /* left ft right data halves */
bswap(b); /* swap bytes round if little-endian */
#endif
#if TRACE >= 1

fprintf (stderr, " deloki(y,081x, °/„081x)\nM ,
((Long *)b)[0], ((Long *)b)[l]);
#endif
L = ((Long * ) b ) [0]; / * LR = X XOR K */

R = ((Long * ) b ) [1];
for (i=R0UNDS; i>0; i-=2) { / * subkeys in reverse order */

L ~= f(R, loki_subkeys[i-l]);
R ~= f(L, loki_subkeys[i-2]);
1
((Long * ) b ) [0] = R; /* Y = LR XOR K */

((Long *)b)[l] = L;
#if TRACE >= 1

fprintf (stderr, " deloki returns 7,081x, °/.081x\n",
( (Long *)b) [0] , ( (Long *)b) [1] ) ;
#endif
#ifdef LITTLE.ENDXAK
b s w a p ( b ); /* swap bytes round if little-endian */
#endif
}
/*
* f(r, k) - is the complex non-linear LOKI function, whose output
* is a complex function of both input data and sub-key.
*
* The d ata is XORed with the subkey, then expanded into 4 x 12-bit
* values, which are fed into the S-boxes. The 4 x 8-bit outputs
* from the S-boxes are permuted together to form the 32-bit value
* which is returned.
*
* In this implémentation the outputs from the S-boxes have been
* pre-permuted and stored in lookup tables.
*/
«define M A S K 12 OxOfff / * 12 bit mask for expansion E */
static Long
f (r, k)
682 L O K I 91
register Long r; /* Data value R(i-l) */

Long k; /* Key K(i) */
{
Long a, b, c; /* 32 bit S-box output, & P output */
a = r ' k; /* A = R(i-l) XOR K(i) */
/ * want to use slow speed/small size version * /

/* B = S(E(R(i-l))'K(i)) */
b = ((Long)s((a & MASK12)) ) I
((Long)s(((a » 8) & MASK12)) « 8) I
((Long)s(((a » 16) & MASK12)) « 16) I
((Long)s((((a » 24) I (a « 8)) & MASK12)) « 24);
perm32(&c, &b, P ) ; /* C = P(S( E(R(i-l)) XOR K(i))) */
#if TRACE >= 2 /* If Tracing, dump A, K(i), and f(R(i-l),K(i)) */

fprintf (stderr," fC/.081x, %081x) = P.S(*/„081x) = PC/.081x) = •/.081x\n",
r, k, a, b, c ) ;
#endif
r e t u r n (c); /* f returns the resuit C */

}
/*
* s(i) - return S-box value for input i
*/
static short s(i)
register Long i; / * return S-box value for input i */
{
register short r, c, v, t;
short exp8(); / * exponentiation routine for GF(2“8) */
r = ( ( i » 8 ) & Oxc) I (i & 0x3); /* row value-top 2 & bottom 2 */

c = (i»2) & Oxff; /* column value-middle 8 bits */
t = (c + ((r * 17) * Oxff)) & Oxff; /* base value for Sfn */
v = exp8(t, sfn[r].exp, sfn[r].gen); / * Sfn[r] = t “ exp m od gen */
#if TRACE >= 3
fprintf (stderr, " s(Xlx= [*/,d,’
/,d] ) = 7,x sup ’
/id m o d Xd = ’
/.x\n" ,
i, r, c, t, sfn[r].exp, sfn[r] .gen, v) ;
#endif
r e t u r n ( v);
}
/*
* perm32(out, in, perm) is the général permutation of a 32-bit input
* block to a 32-bit output block, under the control of a
* permutation array perm. Each element of perm spécifiés which
* input bit is to be permuted to the output bit with the same
* index as the array ele m e n t .
L O K I 91 683
* nb: to set bits in the output word, as mask with a single 1 in it is

* used. On each step, the 1 is shifted into the next location
*/
ffdefine MSB 0x80000000L /* MSB of 32-bit word */
perm32(out, in perm)
Long *out; /* Output 32-bit block to be permuted */
Long *in; /* Input 32-bit block after permutation */
char perm[32]; /* Permutation array */
{
Long mask = MSB; /* mask used to set bit in output */
register int i, o, b; /* input bit no, output bit no, value */
register char *p = perm; / * ptr to permutation array */
*out = 0; /* clear output block */

for (o=0; o<32; o++) { / * For each output bit position o */
i =(int)*p++; /* get input bit permuted to output o */
b = (*in » i) 01;/* value of input bit i */
if (b) /* If the input bit i is set */
*out |= mask; /* OR in mask to output i */
m ask » = 1; /* Shift mas k to next bit */
/*
* mult8(a, b, gen) - returns the product of two binary
* strings a and b using the generator gen as the modulus
* mult = a * b mod gen
* gen generates a suitable Galois field in GF(2~8)
*/
#define SIZE 256 /* 256 elements in GF(2~8) */
short mult8(a, b, gen)

short a, b; /* operands for multiply */
short gen; /* irreducible polynomial generating Galois Field */
{
short product = 0 ; /* resuit of multiplication */
while(b != 0) { /* while multiplier is non-zero */

if (b & 01)
product “= a; /* add multiplicand if LSB of b set */
a « = 1; /* shift multiplicand one place */
if (a >= SIZE)
a ~= gen; /* and modulo reduce if needed */
b »= 1; /* shift multiplier one place */
>
return(product);
684 L O K I 91
>
/*
* exp8( b ase, exponent, gen) - returns the resuit of
* exponentiation given the base, exponent, generator of GF,
* exp = base " exp mod gen
*/
short exp8(base, exponent, gen)

short base; /* base of exponentiation +/
short exponent; /* exponent */
short gen; / * irreducible polynomial generating Galois Field * /
short accum = base; / * superincreasing sequence of base */

short resuit = 1 ; / * resuit of exponentiation */
if (base == 0) /* if zéro base specified then */

r e turn(O); / * the resuit is "0" if base = 0 */
while (exponent != 0) { / * repeat while exponent non-zero * /

if (( exponent & 0x0001) == 0x0001) /* multiply if exp 1 */
resuit = mult8(result, accum, gen);
exponent » = 1; /* shift exponent to next digit */
accum = mult8(accum, accum, gen); / * & square */
y
return(result);
>
IDEA
usuals.h
/ * usuals.h - The usual typedefs, etc.
*/
#ifndef USUALS /* Assures no redéfinitions of usual t y p e s . . . * /
#define USUALS
typedef unsigned char boolean; /* values are TRUE or FALSE */

typedef unsigned char byte; /* values are 0-255 */
typedef byte *byteptr; /* pointer to byte */
typedef char *string; /* pointer to ASCII character string */
typedef unsigned short wordl6; /* values are 0-65535 * /
#ifdef alpha
typedef unsigned int word32; /* values are 0-4294967295 */
#else
typedef unsigned long word32; /* values are 0-4294967295 */
#endif
#ifndef TRUE
#define FALSE 0
#define TRUE (!FALSE)
#endif /* if TRUE not already defined */
#ifndef min /* if min macro not already defined */

#define min(a.b) (((a)<(b)) ? (a) :(b) )
#define max(a.b) (((a)>(b)) ? (a) :(b) )
#endif /* if min macro not already defined */
/ * void for use in pointers */

#ifndef N0_V0ID_STAP.
ffdefine VOID void
#else
#define VOID char
#endif
/* Zero-fill the byte buffer. */

#define fillOCbuffer,count) memsetC buffer, 0, count )
/* This macro is for burning sensitive data. Many of the

686 ID E A
file I/O routines use it for zapping buffers */

#define burn(x) fillOCCVOID *)&(x).sizeof(x))
#endif /* if USUALS not already defined */
randpool.h
#include "usuals.h"
/* Set this to whatever you need (must be > 512) */

#define RANDPOOLBITS 3072
void randPoolStir(void);
void randPoolAddBytes(byte const *buf, unsigned l e n ) ;
void randPoolGetBytesCbyte *buf, unsigned len);
byte randPoolGetByte(void);
idea.h
#ifndef IDEA_H
#define IDEA.H
/*
* idea.h - header file for idea.c
*/
#include "usuals.h" /* typedefs for byte, wordl6, boolean, etc. */
#define IDEAKEYSIZE 16
#define IDEABLOCKSIZE 8
#define IDEAROUNDS 8
#define IDEAKEYLEN (6*IDEAR0UNDS+4)
/*
* iv[] is used as a circular buffer. bufleft is the number of
* bytes at the end which have to be filled in before we crank
* the block cipher again. We do the block cipher opération
* lazily: bufleft may be 0. When we need one more byte, we
* crank the block cipher and set bufleft to 7.
*
* oldcipherl] holds the previous 8 bytes of ciphertext, for use
* by i d e a C f b S y n c O and P h i l 1s, ahem, unique (not insecure, just
* unusual) way of doing CFB encryption.
*/
struct IdeaCfbContext {
byte o ldcipher[8];
byte iv[8] ;
wordl6 key[IDEAKEYLEN];
ID E A 687
int bufleft;
>;
struct IdeaRandContext {
byte o u t b u f [8];
wordl6 key[IDEAKEYLEN];
int bufleft;
byte i n ternalbuf[8];
>;
void ideaCfbReinit(struct IdeaCfbContext *context, byte const * i v ) ;

void ideaCfblnit(struct IdeaCfbContext *context, byte const (key[16]));
void ideaCfbSync(struct IdeaCfbContext *context);
void ideaCfbDestroy(struct IdeaCfbContext *context);
void ideaCfbEncrypt(struct IdeaCfbContext *context,
byte const *src, byte *dest, int count);
void ideaCfbDecrypt(struct IdeaCfbContext *context,
byte const *src, byte *dest, int count);
void ideaRandlnit(struct IdeaRandContext *context, byte const (key[16]),
byte const (seed[8]));
byte ideaRandByte(struct IdeaRandContext *c) ;
void ideaRandWash(struct IdeaRandContext * c , struct IdeaCfbContext *c f b ) ;
void ideaRandState(struct IdeaRandContext *c, byte k e y [16], byte seed[8]);
#endif /* ÎIDEA_H */
idea.c
/*
* idea.c - C source code for IDEA block cipher.
* IDEA (International Data Encryption Algorithm), formerly known as
* IPES (Improved Proposed Encryption Standard).
* Algorithm developed by Xuejia Lai and James L. Massey, of ETH Zurich.
* This implémentation modified and derived from original C code
* developed by Xuejia Lai.
* Zero-based indexing added, names changed from IPES to IDEA.
* CFB functions added. Random number routines added.
*
* Extensively optimized and restructured by Colin Plumb.
*
* There are two adjustments that can be made to this code to

* speed it up. Defaults may be used for PCs. Only the -DIDEA32
* pays off significantly if selectively set or not s e t .
* Experiment to see what works best for your machine.
*
* Multiplication: default is inline, -DAVOID_JUMPS uses a
* différent version that does not do any conditional
* jumps (a few percent worse on a S P ARC), while
* -DSMALL_CACHE takes it out of line to stay
* within a small on-chip code cache.
688 ID E A
* V a x i a b l es: normally, 16-bit variables are used, but some

* machines (notably RISCs) do not have 16-bit registers,
* so they do a great deal of masking. -DIDEA32 uses "int"
* register variables and masks explicitly only where
* necessary. On a SPARC, for example, this boosts
* performace by 307..
*
* The IDEA(tm) block cipher is covered by patents held by ETH and a
* Swiss company called Ascom-Tech AG. The Swiss patent number is
* PCT/CH91/00117, the European patent number is EP 0 482 154 Bl, and
* the U.S. patent number is US005214703. IDEA(tm) is a trademark of
* Ascom-Tech AG. There is no license fee required for noncommercial
* use. Commercial users may obtain licensing détails from Dieter
* Profos, Ascom Tech AG, Solothurn Lab, Postfach 151, 4502 S o l o t h u m ,
* Switzerland, Tel +41 65 242885, Fax +41 65 235761.
*
* The IDEA block cipher uses a 64-bit block size, and a 128-bit key
* size. It breaks the 64-bit cipher block into four 16-bit words
* because ail of the primitive inner opérations are done with 16-bit
* arithmetic. It likewise breaks the 128-bit cipher key into eight
* 16-bit words.
*
* For further information on the IDEA cipher, see the book:

* Xuejia Lai, "On the Design and Security of Block Ciphers",
* ETH Sériés on Information Processing Ced. J.L. Massey) Vol 1,
* Hartung-Gorre Verlag, Konstanz, Switzerland, 1992. ISBN
* 3-89191-573-X.
*
* This code runs on arrays of bytes by taking pairs in big-endian

* order to make the 16-bit words that IDEA uses internally. This
* produces the same resuit regard]ess of the byte order of the
* native CPU.
*/
#include “idea.h"
#include “randpool.h"
#ifdef IDEA32 / * Use > 16-bit temporaries */

#define lowl6(x) ((x) & OxFFFF)
typedef unsigned int uintl6; /* at LEAST 16 bits, maybe more */
#else
#define lowl6(x) (x) /* this is only ever applied to u i n t l 6 ’s */
typedef wordl6 uintl6;
#endif
#ifdef _GNUC_
/* const simply means there are no side effects for this function,
* which is useful info for the gcc optimizer
*/
#define CONST const__
#else
ID E A 689
#define CONST
#endif
/*
* Multiplication, modulo (2**16)+1
* Note that this code is structured on the assumption that
* untaken branches are cheaper than taken branches, and the
* compiler d o e s n ’t schedule branches.
*/
#ifdef SMALL_CACHE
CONST static uintl6
mul(register uintl6 a, register uintl6 b)
register word32 p;
p = (word32)a * b;
if (p) {
b = l o w l6(p);
a = p»16;
return (b - a) + (b < a) ;
} else if (a) {
return 1-b;
} else {
return 1-a;
>
)■ /* inul * /
#endif /* SMALL_CACHE */
/*
* Compute the multiplicative inverse of x, modulo 65537, using E u c l i d ’s
* algorithm. It is unrolled twice to avoid swapping the registers each
* itération, and some subtracts of t have been changed to adds.
*/
CONST static uintl6
mullnv(uintl6 x)
uintl6 tO, tl;

uintlô q, y;
if (x <= 1)
return x; /* 0 and 1 are self-inverse */
tl = OxlOOOlL / x; /* Since x >= 2, this fits into 16 bits */
y = OxlOOOlL '/. x;
if (y = = 1)
return lowl6(l-tl);
tO = 1;
do {
q = x / y;
x = x 7. y;
tO += q * tl;
if (x == 1)
690 ID E A
return tO;
q = y / x;
y = y ’/. x ;
tl += q * tO;
> while (y != 1);
return lowl6(l-tl);
} / * muklnv */
/*
* Expand a 128-bit user key to a working encryption key EK
*/
static void
ideaExpandKey(byte const *userkey, wordl6 *EK)
int i , j ;
for (j=0; j<8; j++) {

EK[j] = ( u s e r key[0]«8) + userkey [1] ;
userkey += 2;
>
for (i=0; j < IDEAKEYLEN; j++) {
i++;
EK[i+7] = EK[i & 7] « 9 I EK[i+l & 7] » 7;
EK += i k 8;
i &= 7;
>
J /* ideaExpandKey */
/*
* Compute IDEA decryption key DK from an expanded IDEA encryption key EK
* Note that the input and output may be the same. Thus, the key is
* inverted into an internai buffer, and then copied to the output.
*/
static void
ideaInvertKey(wordl6 const *EK, wordl6 DK[IDEAKEYLEN])
int i;
uintl6 tl, t2, t3;
wordl6 temp[IDEAKEYLEN];
wordl6 *p = temp + IDEAKEYLEN;
tl = m u lInv(*EK++);
t2 = -*EK++;
t3 = -*EK++;
*— p = mulInv(*EK++);
*— p = t3;
*— p = t2;
*— p = tl;
for (i = 0; i < IDEAR0UNDS-1; i++) {

tl = *EK++;
ID E A 691
*— p = *EK++;
* — p = tl;
tl = mulInv(*EK++);
t2 = -*EK++;
t3 = -*EK++;
*— p = mul!nv(*EK++);
*— p = t2;
*— p = t3;
*— p = tl;
}
tl = ♦EK++;
*— p = *EK++;
*— p = tl;
tl = m u lInv(*EK++);
t2 = -*EK++;
t3 = - * E K + + ;
* P = mulInv(*EK++);
* P = t3;
*— p = t2;
* P = tl;
/* Copy and destroy temp copy */
memcpyCDK, temp, sizeof(temp));
bu r n (temp);
}■ /* idealnvertKey */
/*
* MUL(x,y) computes x = x*y, modulo 0x10001. Requires two temps,
* tl6 and t32. x is modified, and must me a side-effect-free lvalue.
* y m a y be anything, but unlike x, must be strictly 16 bits even if
* lowl6() is #defined.
* Ail of these are équivalent - see which is faster on your machine
*/
#ifdef SMALL_CACHE
#define MÜL(x,y) (x = mul(lowl6(x),y))
#else /* !SMALL_CACHE */
#ifdef AV0ID_JUMPS
#define MÜL(x,y) (x = lowl6(x-l), tl6 = lowl6((y)-l), \
t32 = Cword32)x*tl6 + x + tl6 + 1, x = lowl6(t32), \
tl6 = t 3 2 » 1 6 , x = (x-tl6) + (x<tl6) )
#else /* !AV0ID_JUMPS (default) */
#define MÜL(x,y) \
( (tl6 = (y)) ? \
(x=lowl6(x)) ? \
t32 = (word32)x*tl6, \
x = lowl6(t32), \
tl6 = t 3 2 » 1 6 , \
x = (x-tl6)+(x<tl6) \
: \
(x = l - t l 6 ) \
692 ID E A
: \
(x = 1-x))
#endif
#endif
/* IDEA encryption/decryption algorithm */

/ * Note that in and out can be the same buffer * /
static void
ideaCipher(byte const (inbuf[8]), byte (outbuf[8]), wordl6 const *key)
{
register uintl6 xl, x2, x3, x4, s2, s3;
wordl6 *in, * o u t ;
#ifndef SMALL_CACHE
register uintl6 tl6; / * Temporaries needed by MÜL macro */
register word32 t32;
#endif
int r = IDEAROUNDS;
in = (wordl6 *)inbuf;
xl = *in++; x2 = *in++;
x3 = *in++; x4 = *in;
#ifndef HIGHFIRST
xl = ( x l » 8 ) I (xl«8) ;
x2 = ( x 2 » 8 ) I (x2«8) ;
x3 = ( x 3 » 8 ) I (x3«8);
x4 = ( x 4 » 8 ) I (x4«8);
#endif
do {
MUL(xl,*key++) ;
x2 += *key++;
x3 += *key++;
MUL(x4, * key++);
s3 = x3;
x3 *= xl;
MUL(x3, *key++);
s2 = x2;
x2 "= x4;
x2 += x3;
MUL(x2, *key++);
x3 += x2;
xl "= x2; x4 “= x3;
x2 "= s3; x3 “= s2;

} while (— r ) ;
MUL(xl, *key++);
x3 += *key++;
x2 += *key++;
MUL(x4, *k e y ) ;
ID E A 693
out = (wordl6 *)outbuf;

#ifdef HIGHFIRST
♦out++ = x l ;
♦out++ = x3;
*out++ = x2;
♦out = x4;
#else /♦ .'HIGHFIRST ♦/
xl = lowl6(xl);
x2 = 1 o w 16( x 2);
x3 = 1 o w 16( x 3);
x4 = lowl6(x4);
♦out++ = ( x l » 8 ) I (xl«8);
♦out++ = ( x 3 » 8 ) I (x3«8);
♦out++ = ( x 2 » 8 ) I (x2«8) ;
♦out = (x4»8) I Cx4<<8) ;
#endif
} /♦ ideaCipher ♦/
/* */
#ifdef TEST
#include <stdio.h>
#include <time.h>
/♦
♦ This is the number of Kbytes of test data to encrypt.
♦ It defaults to 1 MByte.
♦/
#ifndef BLOCKS
#ifndef KBYTES
#define KBYTES 1024
#endif
#define BLOCKS (64+KBYTES)
#endif
int
main(void)
{ /♦ Test driver for IDEA cipher ♦/
int i, j, k;
byte userkey [16];
wordl6 EK[IDEAKEYLEN], DK[IDEAKEYLEN];
byte XX [8], YY[8] , ZZ[8];
clock_t start, end;
long 1;
/♦ Make a sample user k ey for testing... ♦/

for(i=0; i<16; i++)
userkey[i] = i+1;
/♦ Compute encryption subkeys from user key... ♦/

ideaExpandKey(userkey, EK);
694 ID E A
p r i n t f ("\nEncryption key subblocks: ”);

for (j=0; j<IDEAR0UNDS+1; j++) {
printf ("\nround "/.d: ", j+1) ;
if (j < IDEAROUNDS)
for(i=0; i<6; i++)
printf (" ’
/.6u" , EK [j *6+i] ) ;
else
for(i=0; i<4; i++)
printf C y.6u", EK [j*6+i] ) ;
}
/* Compute decryption subkeys from encryption subkeys... */

idealnvertKey(EK, D K ) ;
p r i n t f ("\nDecryption key subblocks: ");
for (j=0; j<IDEAROUNDS+l; j++) {
p r i n t f ("\nround '/.A: ", j+1);
if (j < IDEAROUNDS)
for(i=0; i<6; i++)
printf (" */,6u", DK [j *6+i] ) ;
else
for(i=0; i<4; i++)
printf (" V.6u", DK [j *6+i] ) ;
}
/* Make a sample plaintext pattern for t e s ting... */

for (k=0; k<8; k++)
XX [k] = k;
printf("\n Encrypting y.d bytes (*/.ld blocks)...", BL0CKS*16, BLOCKS);

fflush(stdout);
start = c l o c k O ;
memcpy(YY, XX, 8);
for ( 1 = 0 ; 1 < BLOCKS; 1++)
ideaCipher(YY, YY, E K ) ; /* repeated encryption */
memcpy(ZZ, YY, 8);
for ( 1 = 0 ; 1 < BLOCKS; 1++)
ideaCipher(ZZ, ZZ, D K ) ; /* repeated decryption */
end = c l o c k O - start;
1 = end / (CL0CKS_PER_SEC/1000) + 1;
i = 1/1000;
j = 15C1000;
1 = (16 * BLOCKS * (CL0CKS_PER_SEC/1000)) / (end/1000);
printf ("Xd.y,03d seconds = V.ld bytes per second\n", i, j, 1);
printf("\nX */.3u y.3u y.3u ’

/.3u ’
/.3u */.3u y.3u y.3u\n",
X X [0], XX [1], XX [2], XX [3], XX [4], XX [5], XX [6] , XX [7]);
printf ("\nY y.3u */.3u y.3u */.3u ‘
/.3u y,3u y.3u y.3u\n",
YY[0] , YY[1] , YY[2] , YY[3] , YY[4], YY[5] , YY[6] , YY[7]);
printf ("\nZ V.3u 7.3u y,3u ”/,3u */,3u */,3u "/,3u y,3u\n” ,
ZZ[0], ZZ[1], ZZ[2], ZZ[3] , ZZ[4] , ZZ[5] , ZZ[6] , ZZ[7]);
ID E A 695
/ * Now decrypted ZZ should be same as original XX */

for (k=0; k<8; k++)
if (XX [k] != ZZ [k] ) {
p r i n t f ("\n\07Error! Noninvertable encryption.\n");
exit(-l); /* error exit */
>
printf (“\nNormal exit A n " ) ;
return 0; /* normal exit */
}- /* main */
#endif /* TEST */
Z * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /
void
ideaCfbReinit(struct IdeaCfbContext *context, byte const *iv)
if (iv)
memcpy(context->iv, iv, 8);
else
fillO(context->iv, 8);
context->bufleft = 0;
}
void
ideaCfblnit(struct IdeaCfbContext *context, byte const (key[16]))
ideaExpandKey(key, context->key);
ideaCfbReinit(context,0);
>
void
ideaCfbDestroy(struct IdeaCfbContext *context)
burn(*context);
>
/*
* Dkay, explanation time:
* Phil invented a unique way of doing CFB t h a t ’s sensitive to semantic
* boundaries within the data being encrypted. One way to phrase
* CFB en/decryption is to say that you XOR the current 8 bytes with
* IDEA(previous 8 bytes of ciphertext). Normally, you repeat this
* at 8-byte intervais, but Phil decided to resync things on the
* boundaries between elements in the stream being encrypted.
*
* That is, the last 4 bytes of a 12-byte field are en/decrypted using
* the first 4 bytes of IDEA(previous 8 bytes of ciphertext), but then
* the last 4 bytes of that IDEA computation are thrown away, and the
* first 8 bytes of the next field are en/decrypted using
696 ID E A
* IDEA(last 8 bytes of ciphertext). This is équivalent to using a

* shorter feedback length (if y o u ’re familiar with the général CFB
* technique) briefly, and d o e s n ’t weaken the cipher any (using shorter
* CFB lengths makes it stronger, actually), it just makes it a bit unusual.
*
* Anyway, to accomodate this behaviour, every time we do an IDEA
* encrpytion of 8 bytes of ciphertext to get 8 bytes of XOR mask,
* we remember the ciphertext. Then if we have to resync things
* after having processed, say, 2 bytes, we refill the iv buffer
* with the last 6 bytes of the old ciphertext followed by the
* 2 bytes of new ciphertext stored in the front of the iv buffer.
*/
void
ideaCfbSync(struct IdeaCfbContext *context)
{
int bufleft = context->bufleft;
if (bufleft) {
memmove(context->iv+bufleft, context->iv, 8-bufleft);
memcpy(context->iv, context->oldcipher+8-bufleft, bufleft);
>
>
/*
* Encrypt a buffer of data, using IDEA in CFB mode.
* There are more compact ways of writing this, but this is
* written for speed.
*/
void
ideaCfbEncrypt(struct IdeaCfbContext *context, byte const *src,
byte *dest, int count)
{
byte *bufptr = context->iv + 8-bufleft;
/* If there are no more bytes to encrypt that there are bytes

* in the buffer, XOR them in and return.
*/
if (count <= bufleft) {
context->bufleft = bufleft - count;
while (count— ) {
*dest++ = *bufptr++ ~= *src++;
>
return;
>
count -= bufleft;
/* Encrypt the first bufleft (0 to 7) bytes of the input by XOR
* with the last bufleft bytes in the iv buffer.
*/
while (bufleft— ) {
ID E A 697
*dest++ = (*bufptr++ *src++);

>
/* Encrypt middle blocks of the input by cranking the cipher,
* XORing 8-byte blocks, and repeating until the count
* is 8 or less.
*/
while (count > 8) {
bufptr = context->iv;
memcpy(context->oldcipher, bufptr, 8);
ideaCipher(bufptr, bufptr, context->key);
bufleft = 8;
count -= 8;
do {
*dest++ = (*bufptr++ *= *src++);
} while (— b u f left);
}
/* Do the last 1 to 8 bytes */
context->bufleft = 8-count;
do I
*dest++ = (*bufptr++ “= * src++);
> while (— count);
}
/*
* Decrypt a buffer of data, using IDEA in CFB mode.
* There are more compact ways of writing this, but this is
* written for speed.
*/
void
ideaCfbDecrypt(struct IdeaCfbContext *context, byte const *src,
byte *dest, int count)
{
static byte *bufptr;
byte t;
bufptr = context->iv + (8-bufleft);

if (count <= bufleft) -f
context->bufleft = bufleft - count;
while (count— ) {
t = *bufptr;
*dest++ = t ~ (*bufptr++ = * src++);
>
return;
}
count -= bufleft;
while (bufleft— ) {
698 ID E A
t = *bufptr;
*dest++ = t (*bufptr++ = * src++);
}
while (count > 8) {
bufleft = 8;
count -= 8;
do {
t = *bufptr;
*dest++ = t " (*bufptr++ = *src++);
} while (— bufleft) ;
>
m emcpy(context->oldcipher, bufptr, 8);
context->bufleft = 8-count;
do {
t = *bufptr;
*dest++ = t “ (*bufptr++ = * src++);
} while (— coun t ) ;
>
/ ********************************************************************/
/*
* Cryptographically strong pseudo-random-number generator.
* The design is from Appendix C of ANSI X9.17, "Financial
* Institution Key Management (Wholesale)", with IDEA
* substituted for the DES.
*/
/*
* Initialize a cryptographie random-number generator.
* key and seed should be arbitrary.
*/
void
ideaRandlnit(struct IdeaRandContext *context, byte const (key[16]),
byte const (seed[8]))
{
int i;
ideaExpandKey(key, context->key);
m emcpy(context->internalbuf, seed, 8);
>
/*
* Read out the R N G ’s state.
ID E A 699
*/
void
ideaRandState(struct IdeaRandContext *context, byte k e y [16], byte seed[8])
int i;
memcpyCseed, c o n t e x t - > i n t e m a l b u f , 8);

for (i = 0; i < 8; i++) {
key[2*i] = context->key[i] » 8;
key[2*i+l] = context->key[i] ;
>
>
/*
* Encrypt the R N G ’s state with the given CFB encryptor.
*/
void
ideaRandWash(struct IdeaRandContext *context, struct IdeaCfbContext *cfb)
{
byte k eyseed[16+8];
int i;
ideaRandState(context, keyseed, keyseed+16);

ideaCfbEncrypt(cfb, keyseed, keyseed, 16+8);
ideaRandInit(context, keyseed, keyseed+16);
memset(keyseed, 0, 16+8);
}
/*
* Cryptographie pseudo-random-number generator, used for generating
* session keys.
*/
byte
ideaRandByte(struct IdeaRandContext *c)
£
int i;
if (!c->bufleft) {
byte timestamp[8] ;
/* Get some true-random noise to help */

randPoolGetBytes(timestamp, sizeof(timestamp));
/* Compute next 8 bytes of output */

for (i=0; i<8; i++)
c->outbuf[i] = c->internalbuf [i] ~ timestamp[i] ;
ideaCipher(c->outbuf, c->outbuf, c ->key);
/* Compute new seed vector */
for (i=0; i<8; i++)
700 ID E A
c->internalbuf[i] = c->outbuf[i] ~ timestamp[i];

ideaCipher(c->internalbuf, c->internalbuf, c->key);
burn(timestamp);
c->bufleft = 8;
>
return c ->outbuf[— c->bufleft];
>
/* end of idea.c */
GOST
gost.c
/*
* The GOST 28147-89 cipher
*
* This is based on the 25 Movember 1993 draft translation

* by Aleksandr Malchik, with Whitfield Diffie, of the Government
* Standard of the U.S.S.R. GOST 28149-89, "Cryptographie Transformation
* Algorithm", effective 1 July 1990. (Wïiitfield.Diffie®eng.sun.com)
*
* That is a draft, and may contain errors, which will be faithfully
* reflected here, along with possible exciting new bugs.
*
* Some détails have been cleared up by the paper "Soviet Encryption

* Algorithm" by Josef Pieprzyk and Leonid Tombak of the University
* of Wollongong, New South Wales. (josef/leoScs.adfa.oz.au)
*
* The standard is written by A. Zabotin (project leader), G.P. Glazkov,

* and V.B. Isaeva. It was accepted and introduced into use by the
* action of the State Standards Committee of the USSFt on 2 June 89 as
* No. 1409. It was to be reviewed in 1993, but whether anyone wishes
* to take on this obligation from the USS R is questionable.
*
* This code is placed in the public domain.
*/
/*
* If you r ead the standard, it belabors the point of copying corresponding
* bits from point A to point B quite a b i t . It helps to understand that
* the standard is uniformly little-endian, although it numbers bits from
* 1 rather than 0, so bit n has value 2~(n-l). The least significant bit
* of the 32-bit words that Eure manipulated in the algorithm is the first,
* lowest-numbered, in the bit string.
*/
/* A 32-bit data type */

#ifdef alpha /* Any other 64-bit machines? */
typedef unsigned int word32;
102 GOST
#else
typedef unsigned long word32;
#endif
/*
* The standard does not specify the contents of the 8 4 bit->4 bit
* substitution boxes, saying t h e y ’re a parameter of the network
* being set up. For illustration purposes here, I have used
* the first rows of the 8 S-boxes from the DES. (Note that the
* DES S-boxes are numbered starting from 1 at the msb. In keeping
* with the rest of the GOST, I have used little-endian numbering.
* T h u s , k8 is S-box 1.
*
* Obviously, a careful look at the cryptographie properties of the cipher
* must be undertaken before "production" substitution boxes are defined.
*
* The standard also does not specify a standard bit-string représentation
* for the contents of these blocks.
*/
static unsigned char const k8[16] = {
14, 4, 13, 1, 2, 15, 11 , 8, 3, 10, 6, 12, 5, 9, 0, 7 >
15, 1, 8, 14, 6, 11, 3 , 4, 9, 7, 2, 13, 12, 0, 5, 10 >
10, 0, 9, 14, 6, 3, 15 5, 1, 13, 12, 7, u , 4, 2, 8 >
static unsigned char const k 5 [16] = {
7, 13, 14, 3, 0, 6, 9 10, 1, 2, 8, 5, 11, 12, 4, 15 >
2, 12, 4, 1, 7, 10, 11 6, 8, 5, 3, 15, 13, 0, 14, 9 >
12, 1, 10, 15, 9, 2, 6 8, 0, 13, 3, 4, 14, 7, 5, 11 >
4, U , 2, 14, 15, 0, 8 13, 3, 12, 9, 7, 5, 10, 6, 1 >
static unsigned char const k l [16] = {
13, 2, 8, 4, 6, 15, U 1, 10, 9, 3, 14, 5, 0, 12, 7 >
/* Byte-at-a-time substitution boxes */

static unsigned char k 8 7 [256];
static unsigned char k65[256];
static unsigned char k43[256];
static unsigned char k 2 1 [256];
/*
* Build byte-at-a-time subtitution tables.
* This must be called once for global setup.
*/
void
kboxinit(void)
{
int i;
for (i = 0; i < 256; i++) {
GOST 703
k87[i] = k8 [i » 4] « 4 Ik7[i ft 15]

k65 [i] = k6ti » 4] « 4 Ik5[i & 15]
k43[i] = k4[i » 4] « 4 Ik3[i & 15]
k21[i] = k2[i » 4] « 4 Ikl[i & 15]
>
}
/*
* Do the substitution and rotation that are the core of the opération,
* like the expansion, substitution and permutation of the DES.
* It would be possible to perform DES-like optimisations and store
* the table entries as 32-bit words, already rotated, but the
* efficiency gain is questionable.
*
* This should be inlined for maximum speed

*/
#if GNUC__
inline__
#endif
static word32
f(word32 x)
{
/* Do substitutions */
#if 0
/* This is annoyingly slow */
x = k 8 [ x » 2 8 k 15] 28 1 k 7 [ x » 2 4 k 15] 24
A
A
A
A
k 6 [ x » 2 0 k 15] « 20 1 k 5 [ x » 1 6 k 15] « 16
k 4 [ x » 1 2 & 15] « 12 1 k3 [ x » 8 k 15] « 8
k 2 [ x » 4 & 15] « 4 1 kl[x k 15];i
#else
/* This is faster */
x = k 8 7 [ x » 2 4 & 255] « 24 I k 6 5 [ x » 1 6 & 255] « 16 I
k 4 3 [ x » 8 k 255] « 8 I k21[x k 255];
#endif
/* Rotate left 11 bits */

return x « l l I x»(32-ll);
>
/*
* The GOST standard defines the input in terms of bits 1..64, with
* bit 1 being the lsb of in[0] and bit 64 being the msb of i n [ l ] .
*
* The keys are defined similarly, with bit 256 being the msb of k e y [7].
*/
void
gostcrypt(word32 const in [ 2 ] , word32 o u t [2], word32 const k e y [8])
{
register word32 ni, n2; /* As named in the GOST */
ni = in [0] ;
704 GOST
n2 = in[l] ;
/ * Instead of swapping halves, swap names each round */

n2 f ( n l + k e y [0] )
ni f (n2+key [1] )
n2 ~= f (nl+key [2])
ni “= f (n2+key [3] )
n2 "= f (nl+key [4])
ni "= f ( n 2 + k e y [5])
n2 '= f (nl+key [6])
ni "= f ( n 2 + k e y [7])
n2 “= f ( n l + k e y [0] )
ni "= f (n2+key[l])
n2 '= f ( n l + k e y [2])
ni "= f(n2+key [3])
n2 "= f ( n l + k e y [4])
ni "= f (n2+key [5] )
n2 *= f(nl+key [6])
ni f ( n 2 + k e y [7] )
n2 *= f (nl+key [0])
ni "= f (n2+key[l])
n2 '= f ( n l + k e y [2])
ni '= f( n 2 + k e y [3])
n2 “= f(nl+key [4])
ni '= f (n2+key [5] )
n2 '= f ( n l + k e y [6])
ni "= f ( n 2 + k e y [7])
n2 -= f (nl+key [7])
ni f(n2+key [6])
n2 f ( n l + k e y [5])
ni ~= f ( n 2 + k e y [4])
n2 “= f(nl+key [3] )
ni *= f ( n 2 + k e y [2])
n2 ~= f ( n l + k e y [1])
ni *= f ( n 2 + k e y [0])
/* There is n o swap after the last round */

out[0] = n2;
out[l] = ni;
}
/*
* The ke y schedule is somewhat différent for decryption.
* (The key table is used once forward and three times backward.)
* You could define an expanded key, or just write the code twice,
* as done here.
*/
GOST 705
void
gostdecrypt(word32 const in[2], word32 o u t [2], word32 const k e y [8])
register word32 ni, n2; /* As named in the GOST */
ni = in [0] ;
n2 = in[l] ;
n2 '= f(nl+key [0]);

ni "= f (n2+key[l]) ;
n2 “= f (nl+key [2]) ;
ni ~= f ( n 2 + k e y (3]);
n 2 '= f(nl+key [4]);
ni “= f ( n 2 + k e y [5]);
n2 ~= f(nl+key [6]);
ni “= f( n 2 + k e y [7]);
n2 “= f ( n l + k e y [7]);
ni "= f(n2+key [6] ) ;
n2 "= f ( n l + k e y [5]);
ni f ( n 2 + k e y [4]);
n2 “** f(nl+key [3]);
ni "= f ( n 2 + k e y (2]);
n2 '= f ( n l + k e y [1] ) ;
ni “= f ( n 2 + k e y [0]);
n2 f ( n l + k e y [7]);
ni '= f(n 2 + k e y [ 6] ) ;
n2 '= f(nl+key [5]);
ni “= f(n2+key[4]);
n2 "= f(n l + k e y [3]);
ni "= f (n2+key [2] ) ;
n2 ~= f ( n l + k e y [1]);
ni “= f(n2+key [0] ) ;
n2 '= f (nl+key [7]) ;

ni “= f (n2+key [ 6 ] ) ;
n2 “= f (nl+key [5]);
ni "= f ( n 2 + k e y [4]);
n2 “= f(n l + k e y [3]);
ni “= f ( n 2 + k e y [2]);
n2 "= f (nl+key [1]) ;
ni "= f ( n 2 + k e y [0]);
out [0] = n2 ;
out[l] = ni;
>
/*
* The GOST "Output feedback" standard. It seems d o s e r morally
* to the counter feedback mode some people have proposed for DES.
706 GOST
* The avoidance of the short cycles that are possible in OFB seems
* like a Good Thing.
*
* Calling it the stream mode makes more sense.
*
* The IV is encrypted with the key to produce the initial counter value.
* Then, for each output block, a constant is added, modulo 2*32-1
* (0 is represented as all-ones, not all-zeros), to each half of
* the counter, and the counter is encrypted to produce the value
* to XOR with the output.
*
* Le n is the number of b l o c k s . Sub-block encryption is
* left as an exercise for the user. Remember that the
* standard defines everything in a little-endian manner,
* so you want to use the low bit of g a m m a [0] first.
*
* OFB is, of course, self-inverse, so there is only one f u n ction.
*/
/ * The constants for addition */

#define Cl 0x01010104
#define C2 0x01010101
void
gostofb(word32 const *in, word32 *out, int len,
word32 const i v [ 2 ] , word32 const k e y [8])
{
word32 temp [2]; /* Counter */
word32 g a m m a [2]; /* Output XOR value * /
/ * Compute starting value for counter */

gostcrypt(iv, temp, key);
while (len— ) {
temp[0] += C2;
if (temp[0] < C2) /* Wrap modulo 2 “32? * /
temp[0]++; / * Make it modulo 2*32-1 */
temp[l] += Cl;
if (temp[l] < Cl) /* Wrap modulo 2*32? * /
temp[l]++; / * Make it modulo 2*32-1 */
gostcrypt(temp, gamma, key);
*out++ = *in++ ' g a m m a [0];

*out++ = *in++ “ g a m m a [1];
>
>
/*
* The CFB mode is just what y o u ’d expect. Each block of ciphertext y[] is
* derived from the input x[] by the following pseudocode:
GOST 707
* y[i] = x[i] * gostcrypt (y [i-l])

* x[i] = y [i] " gostcrypt (y [i-l])
* Where y[-l] is the IV.
*
* The IV is modified in place. Again, len is in *blocks*.
*/
void
gostcfbencrypt(word32 const *in, word32 *ont, int len,
word32 iv [2], word32 const k e y [8])
{
while (len— ) {
gostcrypt(iv, iv, key);
iv[0] = *out++ *= iv[0];
iv[l] = *out++ *= iv[l] ;
>
}
void
gostcfbdecrypt(word32 const *in, word32 *out, int len,
word32 i v [2], word32 const k e y [8])
word32 t;
while (len— ) -{
gostcrypt(iv, iv, key);
t = *out;
*out++ “= iv[0];
iv[0] = t;
t = *out;
*out++ '= iv [1];
iv[l] = t;
>
}
/*
* The message suthetication code uses only 16 of the 32 rounds.
* There *is* a swap after the 16th round.
* The last block should be padded to 64 bits with zéros.
* len is the number of *blocks* in the input.
*/
void
gostmac(word32 const *in, int len, word32 o u t [2], word32 const k e y [8])
i
register word32 ni, n2; /* As named in the GOST * /
ni = 0;
n2 = 0;
while (len— ) {
ni ~= *in++;
708 GOST
n2 = *in++;
/* Instead of swapping halves, swap names each round */

n2 “= f ( n l + k e y [0]);
ni “= f ( n 2 + k e y [1]);
n2 “= f ( n l + k e y [2]);
ni “= f ( n 2 + k e y [3]);
n2 ~= f ( n l + k e y [4]);
ni "= f (n2+key [5] ) ;
n2 "= f (nl+key [6] ) ;
ni "= f ( n 2 + k e y [7]);
n2 *= f ( n l + k e y [0]);
ni ~= f (n2+key[l]);
n2 “= f ( n l + k e y [2]);
ni "= f (n2+key [3] ) ;
n2 ~= f ( n l + k e y [4]);
ni ~= f(n2+key [5]);
n 2 ~= f(n l + k e y [6]);
ni ~= f(n 2 + k e y [7]);
}
out [0] = ni ;
outül] = n2;
}
#ifdef TEST
#include <stdio.h>
#include <stdlib.h>
/* Designed to cope with 15-bit r a n d Q implémentations * /

#define RAND32 ((word32)rand() « 17 “ (word32)rand() « 9 rarndO)
int
main(void)
{
word32 k e y [8];
word32 plain [2];
word32 c i p h e r [2];
int i, j;
kboxinitO ;
printf("GOST 21847-89 test driver.\n");
for (i = 0; i < 1000; i++) {

for (j = 0; j < 8; j++)
keytj] = RAND32;
p l a i n [0] = R A N D 3 2 ;
p l a i n [1] = RAND32;
GOST 709
printf ("73d\r", i) ;
Cflush(stdout);
gostcrypt(plain, cipher, key);

for (j = 0; j < 99; j++)
gostcrypt(cipher, cipher, key);
for (j = 0; j < 100; j++)
gostdecrypt(cipher, cipher, key);
if (plain[0] != c i p h e r [0] Il plain[l] != c i p h e r [1]) {

fprintf (st d e r r , "\nError! i = 7,d\n", i) ;
return 1;
>
}
printf("Ail tests passed.\n");
return 0;
}
(fendif /* TEST */
Blowfish
blowfîsh.c
#include <jnath.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#ifdef little_endian /* Eg: Intel */

#include <alloc.h>
#endif
#include <ctype.h>
#ifdef little_endian /* Eg: Intel */

#include <dir.h>
#include <bios.h>
#endif
#ifdef big_endian
#include <Types.h>
#endif
typedef struct {
unsigned long S [4] [256] , P[18] ;
> blf_ctx;
#define MAXKEYBYTES 56 /* 448 bits */

/*// #define little-endian 1 / * Eg: Intel * /
#define big_endian 1 /* Eg: Motorola */
void Blowfish_encipher(blf_ctx * c , unsigned long *xl, unsigned long * x r ) ;

void Blowfish_decipher(blf_ctx * c , unsigned long *xl, unsigned long * xr);
short InitializeBlowfish(blf_ctx *c, char k e y [ ] , short k e ybytes);
#define N 16
#define noErr 0
#define DATAERROR -1
#define KEYBYTES 8
712 B l o w f is h
unsigned long F(blf_ctx * b c , unsigned long x)

{
unsigned short a;
unsigned short b;
unsigned short c;
unsigned short d;
unsigned long y;
d = x & OxOOFF;
x »= 8;
c = x & OxOOFF;
x >>= 8;
b = x ft OxOOFF;
x » = 8;
a = x & OxOOFF;
/*// y = C (bc->S [0] [a] + bc->S[l] [b] ) ' bc->S [2] [c] ) + b c - > S [3] [d] ; */
y = bc->S[0] [a] + bc->S[l] [b] ;
y = y “ bc->S [2] [c] ;
y = y + bc->S [3] [d] ;
return y;
>
void B lowfish_encipher(blf_ctx *c, unsigned long *xl, unsigned long *xr)

{
unsigned long XI;
unsigned long Xr;
unsigned long temp;
short i;
XI = *xl;
Xr = * x r ;
for (i = 0; i < N; ++i) {

XI = XI ' c->P[i] ;
Xr = F(c,Xl) ' Xr;
temp = XI;
XI = Xr;
Xr = temp;
>
temp = XI;
XI = Xr;
Xr = temp;
Xr = Xr " c->P[N] ;
XI = XI * c->P [N + 1] ;
*xl = XI;
*xr = Xr;
Bl o w f is h 713
toid Blowfish_decipher(blf_ctx *c, unsigned long *xl, unsigned long *xr)

[
unsigned long XI;
unsigned long Xr;
unsigned long temp;
short i;
XI = *xl;
Xr = * x r ;
for ( i = N + l ; i > l ; — i) {
XI = XI " c->P[i] ;
Xr = F(c,Xl) ' Xr;
/ * Exchange XI and X r */
temp = XI;
XI = Xr;
Xr = temp;
>
/* Exchange XI and Xr */
temp = XI;
XI = Xr;
Xr = temp;
Xr = Xr “ c->P[i];
XI = XI * c - > P [0];
*xl = XI;
*xr = Xr;
>
short InitializeBlowfish(blf_ctx *c, char k e y [ ] , short keybytes)

i
short i;
short j;
short k;
short error;
short numread;
unsigned long data;
unsigned long datai;
unsigned long datar;
unsigned long ks0[] = -t

0xdl310ba6, 0x98dfb5ac, 0x2ffd72db, 0xd01adfb7, 0xb8elafed, 0x6a267e96,
0xba7c9045, 0xfl2c7f99, 0x24al9947, 0xb3916cf7, 0x801f2e2, 0x858efcl6,
0x636920d8, 0x71574e69, 0xa458fea3, 0xf4933d7e, 0xd95748f, 0x728eb658,
0x718bcd58, 0x82154aee, 0x7b54a41d, 0xc25a59b5, 0x9c30d539, 0x2af26013,
0xc5dlb023, 0x286085f0, 0xca417918, 0xb8db38ef, 0x8e79dcb0, 0x603al80e,
714 B l o w f is h
0x6c9e0e8b, 0xb01e8a3e, 0xd71577cl 0xbd314b27, 0x78af2fda, 0x55605c60,

0xe65525f3, 0xaa55ab94, 0x57489862 0x63e81440, Ox55ca396a, 0x2aabl0b6,
0xb4cc5c34, 0xll41e8ce, 0xal5486af 0x7c72e993, 0xb3eel411, 0x636fbc2a,
0x2ba9c55d, 0x741831f6, 0xce5c3ei6 0x9b87931e, 0xafd6ba33, 0x6c24cf5c,
0x7a325381, 0x28958677, 0x3b8f4898 0x6b4bb9af, 0xc4bfe81b, 0x66282193,
0x61d809cc, 0xfb21a991, 0x487cac60 0x5dec8032, 0xef845d5d, 0xe98575bl,
0 x d c 262302, 0xeb651b88, 0x23893e81 0xd396acc5, 0xf6d6ff3, 0x83f44239,
0x 2 e 0b4482, 0xa4842004, 0x69c8f04a Ox9elf9b5e, 0x21c66842, 0xf6e96c9a,
0x670c9c61, 0xabd388f0, 0x6a51a0d2 0xd8542f68, 0x960fa728, 0xab5133a3,
0x6eef0b6c, 0xl37a3be4, 0xba3bf050 0x7efb2a98, 0xalfl651d, 0x39af0176,
0x66ca593e, 0x82430e88, 0x8cee8619 0x456f9fb4, 0x7d84a5c3, 0x3b8b5ebe,
0xe06f75d8, 0x85cl2073, 0x401a449f: 0x56cl6aa6, 0x4ed3aa62, 0x363f7706,
Oxlbfedf72, 0x429b023d, 0x37d0d724 0xd00al248, 0xdb0fead3, 0x49flc09b,
0x75372c9, 0x80991b7b, 0x25d479d8, 0xf6e8def7, 0xe3fe501a, 0xb6794c3b,
0x976ce0bd, 0x4c006ba, 0xcla94fb6, 0x409f60c4, 0x5e5c9ec2, 0xl96a2463,
0 x 6 8 fb6faf, 0x3e6c53b5, 0xl339b2eb; 0x3b52ec6f, Ox6dfc511f, 0x9b30952c,
0xcc814544, 0xaf5ebd09, 0xbee3d004; 0xde334afd, 0x660f2807, 0xl92e4bb3,
0xc0cba857, 0x45c8740f, 0xd20b5f39; 0xb9d3fbdb, 0x5579c0bd, 0xla60320a,
0xd6al00c6, 0x402c7279, 0x679f25fe, 0xfblfa3cc, 0x8ea5e9f8, 0xdb3222f8,
0x3c75 1 6 d f , 0xfd616bl5, 0x2f501ec8, 0xad0552ab, 0x323db5fa, 0xfd238760,
0x53317b48, 0x3e00df82, 0x9e5c57bb 0xca6f8ca0, Oxla87562e, 0xdfl769db,
0xd542a8f6, 0x287effc3, 0xac6732c6, 0x8c4f5573, Ox695b27bO, 0xbbca58c8,
0xelffa35d, 0xb8f011a0, 0xl0fa3d98, 0xfd2183b8, 0x4afcb56c, 0x2ddld35b,
0x9a53e479, 0xb6f84565, 0xd28e49bc, 0x4bfb9790, 0xelddf2da, 0xa4cb7e33,
0x62fbl341, 0xcee4c6e8, 0xef20cada 0x36774c01, 0xd07e9efe, 0x2bfllfb4,
0x95dbda4d, 0xae909198, 0xeaad8e71. 0x6b93d5a0, 0xd08edld0, 0xafc725e0,
0 x 8 e 3c5b2f, 0x8e7594b7, 0x8ff6e2fb Oxf2122b64, 0x8888b812, 0x900df01c,
0x4fad5ea0, 0x688fc31c, Oxdlcff191. 0xb3a8clad, 0x2f2f2218, 0xbe0el777,
0xea752dfe, 0x8b021fal, 0xe5a0cc0f, 0xb56f74e8, 0xl8acf3d6, 0xce89e299,
0xb4a84fe0, 0xfdl3e0b7, 0x7cc43b81; 0xd2ada8d9, 0xl65fa266, 0x80957705,
0 x 9 3 cc7314, 0x211al477, 0xe6ad2065: 0x77b5fa86, Oxc75442f5, 0xfb9d35cf,
OxebcdafOc, 0x7b3e89a0, 0xd6411bd3; 0xaele7e49, 0x250e2d, 0x2071b35e,
0x226800bb, 0x57b8e0af, 0x2464369b, 0xf009b91e, 0x5563911d, 0x59dfa6aa,
0x78cl4389, 0xd95a537f, 0x207d5ba2, 0x2e5b9c5, 0x83260376, 0x6295cfa9,
0xllc81968, 0x4e734a41, 0xb3472dca, 0x7bl4a94a, 0xlb510052, 0x9a532915,
0xd60f573f, 0xbc9bc6e4, 0x2b60a476, 0x81e67400, Ox8ba6fb5, 0x571be91f,
Oxf296ec6b, 0x2a0dd915, 0xb663652i, 0xe7b9f9b6, Oxff34052e, 0xc5855664,
0x53b02d5d, 0xa99f8fal, 0x8ba4799, 0x6e85076a};
unsigned long ksi [] = {

0x4b7a70e9, 0xb5b32944, 0xdb75092e, 0xc4192623, Oxad6ea6bO, 0x49a7df7d,
0x9cee60b8, 0x8fedb266, 0xecaa8c71, 0x699al7ff, 0x5664526c, 0xc2bl9eel,
0xl93602a5, 0x75094c29, 0xa0591340, 0xe4183a3e, 0x3f54989a, 0x5b429d65,
0x6b8fe4d6, 0x99f73fd6, 0xald29c07, 0xefe830f5, 0x4d2d38e6, 0xf0255dcl,
0x4cdd2086, 0x8470eb26, 0x6382e9c6, 0x21ecc5e, Ox9686b3f, 0x3ebaefc9,
0x3c971814, 0x6b6a70al, 0x687f3584, 0x52a0e286, 0xb79c5305, 0xaa500737,
0x3e07841c, 0x7fdeae5c, 0x8e7d44ec, 0x5716f2b8, 0xb03ada37, 0xf0500c0d,
0xf01clf04, 0x200b3ff, 0xae0cf51a, 0x3cb574b2, 0x25837a58, 0xdc0921bd,
0xdl9113f9, 0x7ca92ff6, 0x94324773, 0x22f54701, 0x3ae5e581, 0x37c2dadc,
0xc8b57634, 0x9af3dda7, 0xa9446146, 0xfd0030e, 0xecc8c73e, 0xa4751e41,
0 x e 2 38cd99, 0x 3bea0e2f, 0x3280bbal, 0xl83eb331, 0x4e548b38, 0x4f6db908,
B l o w f is h 715
0x6f420d03, 0xf60a04bf, 0x2cb81290 , 0x24977c79, 0x5679b072, 0xbcaf89af,

Ûxde9a77if, 0xd9930810, 0xb38bael2 , 0xdccf3f2e, 0x5512721f, 0x2e6b7l24,
0x501adde6, 0x9f84cd87, 0x7a584718 , 0x7408dal7, 0xbc9f9abc, 0xe94b7d8c,
0xec7aec3a, 0xdb851dfa, 0x63094366 , 0xc464c3d2, 0xeflcl847, 0x3215d908,
0xdd433b37, 0x24c2bal6, 0xl2al4d43 , 0x2a65c451, 0x50940002, 0xl33ae4dd,
0x71dff89e, 0xl0314e55, 0x81ac77d6 , 0x5f11199b, 0x43556f1, 0xd7a3c76b,
0x3clll83b, 0x5924a509, 0xf28fe6ed , 0x97flfbfa, 0x9ebabf2c, 0xlel53c6e,
0x86e34570, 0xeae96fbl, 0x860e5e0a , 0x5a3e2ab3, 0x771fe71c, 0x4e3d06fa,
0x2965dcb9, 0x99e71d0f, 0x803e89d6 , 0x5266c825, 0x2e4cc978, 0x9cl0b36a,
0xc6150eba, 0x94e2ea78, 0xa5fc3c53 , 0xle0a2df4, 0xf2f74ea7, 0x361d2b3d,
0xl939260f, 0xl9c27960, 0x5223a708 , 0xf71312b6, 0xebadfe6e, 0xeac31f66,
0xe3bc4595, 0xa67bc883, 0xbl7f37dl , 0xl8cff28, 0xc332ddef, 0xbe6c5aa5,
0x65582185, 0x68ab9802, 0xeecea50f , 0xdb2f953b, 0x2aef7dad, 0x5b6e2f84,
0x152lb628, 0x29076170, 0xecdd4775 , 0x6l9f1510, 0xl3cca830, 0xeb61bd96,
0x334fele, 0xaa0363cf, 0xb5735c90, 0x4c70a239, 0xd59e9e0b, 0xcbaadel4,
0xeecc86bc, 0x60622ca7, 0x9cab5cab , 0xb2f3846e, 0x648bleaf, 0xl9bdf0ca,
0xa02369b9, 0x655abb50, 0x40685a32 , 0x3c2ab4b3, 0x319ee9d5, 0xc021b8f7,
0x9b540bl9, 0x875fa099, 0x95f7997e , 0x623d7da8, Oxf837889a, 0x97e32d77,
0xlled935f, 0x16681281, 0xe358829, 0xc7e61fd6, 0x96dedfal, 0x7858ba99,
0x57f584a5, 0xlb227263, 0x9b83c3ff: 0xlac24696, 0xcdb30aeb, 0x532e3054,
0x8fd948e4, 0x6dbc3128, 0x58ebf2ef 0x34c6ffea, 0xfe28ed61, 0xee7c3c73,
0 x 5 d 4al4d9, 0xe864b7e3, Ox42105dl4. 0x203el3e0, 0x45eee2b6, 0xa3aaabea,
0xdb6c4f15, 0xfacb4fd0, 0xc742f442; 0xef6abbb5, 0x654f3bld, 0x41cd2105,
0xd81e799e, 0x86854dc7, 0xe44b476a: 0x3d816250, 0xcf62alf2, 0x5b8d2646,
0xfc8883a0, 0xclc7b6a3, 0x7fl524c3. 0x69cb7492, 0x47848a0b, 0x5692b285,
0x95bbf00, 0xadl9489d, 0xl462bl74, 0x23820e00, 0x58428d2a, 0xc55f5ea,
0xldadf43e, 0x233f7061, 0x3372f092, 0 x8d937e41, 0xd65fecfl, 0x6c223bdb,
0x7cde3759, 0xcbee7460, 0x4085f2a7, 0xce77326e, 0xa6078084, 0xl9f8509e,
0xe8efd855, 0x61d99735, 0xa969a7aa, 0xc50c06c2, 0x5a04abfc, 0x800bcadc,
0x9e447a2e, 0xc3453484, 0xfdd56705, 0xele9ec9, 0xdb73dbd3, 0xl05588cd,
0x675fda79, 0xe3674340, 0xc5c43465, 0x713e38d8, 0x3d28f89e, 0xfl6dff20,
0xl53e21e7, 0x8fb03d4a, 0xe6e39f2b 0xdb83adf7>;
unsigned long ks2[] = {

0xe93d5a68, 0x948140f7, 0xf64c261c, 0x94692934, 0x411520f7, 0x7602d4f7,
0xbcf46b2e, 0xd4a20068, 0xd4082471, 0x3320f46a, 0x43b7d4b7, 0x500061af,
0xle39f62e, 0x97244546, 0xl4214f74, 0xbf8b8840, 0x4d95fcld, 0x96b591af,
0x70f4ddd3, 0x66a02f45, 0xbfbc09ec, 0x3bd9785, 0x7fac6dd0, 0x31cb8504,
0x96eb27b3, 0x55fd3941, 0xda2547e6, 0xabca0a9a, 0x28507825, 0x530429f4,
0xa2c86da, 0xe9b66dfb, 0x68dcl462, 0xd7486900, 0x680ec0a4, 0x27al8dee,
0x4f3ffea2, 0xe887ad8c, 0xb58ce006, 0x7af4d6b6, 0xaacele7c, 0xd3375fec,
0xce78a399, 0x406b2a42, 0x20fe9e35, 0xd9f385b9, 0xee39d7ab, 0x3bl24e8b,
0xldc9faf7, 0x4b6dl856, 0x26a36631, 0xeae397b2, 0x3a6efa74, 0xdd5b4332,
0x6841e7f7, 0xca7820fb, 0xfb0af54e, 0xd8feb397, 0x454056ac, 0xba489527,
0x55533a3a, 0x20838d87, 0xfe6ba9b7, 0xd096954b, 0x55a867bc, 0xall59a58,
0xcca92963, 0x99eldb33, 0xa62a4a56, 0x3f3125f9, 0x5ef47elc, 0x9029317c,
Oxfdf8e802, 0x4272f70, 0x80bbl55c, 0x5282ce3 , 0x95cll548, 0xe4c66d22,
0x48cll33f, 0xc70f86dc, 0x7f9c9ee, 0x41041fOf, 0x404779a4, 0x5d886el7,
0x325f51eb, 0xd59bc0dl, 0xf2bccl8f, 0x41113564, 0x257b7834, 0x602a9c60,
0xdff8e8a3, 0xlf636clb, 0xel2b4c2, 0x2el329e, 0xaf664fdl, 0xcadl8115,
0x6b2395e0, 0x333e92el, 0x3b240b62, 0xeebeb922, 0x85b2a20e, 0xe6ba0d99,
716 B l o w f ish
0xde720c8c, 0x2da2f728, 0xd0127845, 0x95b794fd, 0x647d0862, 0xe7ccf5f0,

0x5449a36f, 0x877d48fa, 0xc39dfd27, 0xf33e8dle, 0xa476341, 0x992eff74,
0x3a6f6eab, 0xf4f8fd37, 0xa812dc60, 0xalebddf8, 0x991bel4c, 0xdb6e6b0d,
0xc67b5510, 0x6d672c37, 0x2765d43b, 0xdcd0e804, Oxf1290dc7, 0xcc00ffa3,
0xb5390f92, 0x690fed0b, 0x667b9ffb, 0xcedb7d9c, 0xa091cf0b, 0xd9155ea3,
0xbbl32f88, 0x515bad24, 0x7b9479bf, 0x763bd6eb, 0x37392eb3, 0xccll5979,
0x8026e297, 0xf42e312d, 0x6842ada7, 0xc66a2b3b, 0xl2754ccc, 0x782efllc,
0x6al24237, 0xb79251e7, 0x6albbe6, 0x4bfb6350, 0xla6bl018, Oxllcaedfa,
0x3d25bdd8, 0xe2elc3c9, 0x44421659, 0xal21386, 0xd90cec6e, 0xd5abea2a,
0x64af674e, 0xda86a85f, 0xbebfe988, 0x64e4c3fe, 0x9dbc8057, 0xf0f7c086,
0x60787bf8, 0x6003604d, 0xdlfd8346, 0xf6381fb0, 0x7745ae04, 0xd736fccc,
0x83426b33, 0xf01eab71, 0xb0804187, 0x3c005e5f, 0x77a057be, 0xbde8ae24,
0x55464299, 0xbf582e61, 0x4e58f48f, 0xf2ddfda2, 0xf474ef38, 0x8789bdc2,
0x5366f9c3, 0xc8b38e74, 0xb475f255, 0x46fcd9b9, 0x7aeb2661, 0x8blddf84,
0x846a0e79, 0x915f95e2, 0x466e598e, 0x20b45770, 0x8cd55591, 0xc902de4c,
0xb90bacel, 0xbb8205d0, 0xlla86248, 0x7574a99e, 0xb77fl9b6, 0xe0a9dc09,
0x662d09al, 0xc4324633, 0xe85alf02, 0x9f0be8c, 0x4a99a025, 0xld6efel0,
0xlab93dld, 0xba5a4df, 0xal86f20f, 0x2868fl69, 0xdcb7da83, 0x573906fe,
0xale2ce9b, 0x4fcd7f52, 0x50115e01, 0xa70683fa, 0xa002b5c4, 0xde6d027,
0x9af88c27, 0x773f8641, 0xc3604c06, 0x61a806b5, 0xf0177a28, 0xc0f586e0,
0x6058aa, 0x30dc7d62, 0xlle69ed7, 0x2338ea63, 0x53c2dd94, 0xc2c21634,
0xbbcbee56, 0x90bcb6de, 0xebfc7dal, 0xce591d76, 0x6f05e409, 0x4b7c0188,
0x39720a3d, 0x7c927c24, 0x86e3725f, 0x724d9db9, 0xlacl5bb4, 0xd39eb8fc,
0xed545578, 0x8fca5b5, 0xd83d7cd3, 0x4dad0fc4, 0xle50ef5e, 0xbl61e6f8,
0xa28514d9, 0x6c51133c, 0x6fd5c7e7, 0x56el4ec4, 0x362abfce, 0xddc6c837,
0xd79a3234, 0x92638212, 0x670efa8e, 0x406000e0>;
unsigned long ks3[] = {

0x3a39ce37, 0xd3faf5cf, 0xabc27737, 0x5ac52dlb, 0x5cb0679e, 0x4fa33742,
0xd3822740, 0x99bc9bbe, 0xd5118e9d, 0xbf0f7315, 0xd62dlc7e, 0xc700c47b,
0xb78clb6b, 0x21al9045, 0xb26eblbe, 0x6a366eb4, 0x5748ab2f, 0xbc946e79,
0xc6a376d2, 0x6549c2c8, 0x530ff8ee, 0x468dde7d, 0xd5730ald, 0x4cd04dc6,
0x2939bbdb, 0xa9ba4650, 0xac9526e8, 0xbe5ee304, 0xalfad5f0, 0x6a2d519a,
0x63ef8ce2, 0x9a86ee22, 0xc089c2b8, 0x43242ef6, 0xa51e03aa, 0x9cf2d0a4,
0x83c061ba, 0x9be96a4d, 0x8fe51550, 0xba645bd6, 0x2826a2f9, 0xa73a3ael,
0x4ba99586, 0xef5562e9, 0xc72fefd3, 0xf752f7da, 0x3f046f69, 0x77fa0a59,
0x80e4a915, 0x87b08601, 0x9b09e6ad, 0x3b3ee593, 0xe990fd5a, 0x9e34d797,
0x2cf0b7d9, 0x22b8b51, 0x96d5ac3a, 0xl7da67d, 0xdlcf3ed6, 0x7c7d2d28,
0xlf9f25cf, 0xadf2b89b, 0x5ad6b472, 0x5a88f54c, 0xe029ac71, 0xe019a5e6,
0x47b0acfd, 0xed93fa9b, 0xe8d3c48d, 0x283b57cc, 0xf8d56629, 0x79132e28,
0x785f0191, 0xed756055, 0xf7960e44, 0xe3d35e8c, 0xl5056dd4, 0x88f46dba,
0x3al6125, 0x564f0bd, 0xc3eb9el5, 0x3c9057a2, 0x97271aec, 0xa93a072a,
0xlb3f6d9b, 0xle6321f5, 0xf59c66fb, 0x26dcf319, 0x7533d928, 0xbl55fdf5,
0x3563482, 0x8aba3cbb, 0x28517711, 0xc20ad9f8, 0xabcc5167, 0xccad925f,
0x4de81751, 0x3830dc8e, 0x379d5862, 0x9320f991, 0xea7a90c2, 0xfb3e7bce,
0x5121ce64, 0x774fbe32, 0xa8b6e37e, 0xc3293d46, 0x48de5369, 0x6413e680,
0xa2ae0810, 0xdd6db224, 0x69852dfd, 0x9072166, 0xb39a460a, 0x6445c0dd,
0x586cdecf, 0xlc20c8ae, 0x5bbef7dd, 0xlb588d40, 0xccd2017f, 0x6bb4e3bb,
0xdda26a7e, 0x3a59ff45, 0x3e350a44, 0xbcb4cdd5, 0x72eacea8, 0xfa6484bb,
0x8d6612ae, 0xbf3c6f47, 0xd29be463, 0x542f5d9e, 0xaec2771b, 0xf64e6370,
0x740e0d8d, 0xe75bl357, 0xf8721671, 0xaf537d5d, 0x4040cb08, 0x4eb4e2cc,
B l o w f is h 111
0x34d2466a, 0xll5af84, 0xelb00428, Ox95983ald, 0x6b89fb4, 0xce6ea048,

0x6f3f3b82, 0x3520ab82, 0xllald4b, 0x277227f8, 0x611560bl, 0xe7933fdc,
0xbb3a792b, 0x344525bd, 0xa08839el , 0x51ce794b, 0x2f32c9b7, 0xa01fbac9,
0xeûlcc87e, 0xbcc7dlf6, 0xcfûlllc3 , 0xale8aac7, 0xla908749, Oxd44fbd9a,
OxdOdadecb, 0xd50ada38, 0x339c32a, 0xc6913667, 0x8df9317c, 0xe0bl2b4f,
0xf79e59b7, 0x43f5bb3a, 0xf2d519ff , 0x27d9459c, 0xbf97222c, 0xl5e6fc2a,
0xf91fc71, 0x9b941525, 0xfae59361, 0xceb69ceb, 0xc2a86459, 0xl2baa8dl,
0xb6cl075e, 0xe3056a0c, 0xl0d25065 , 0xcb03a442, 0xe0ec6e0e, 0xl698db3b,
0x4c98a0be, 0x3278e964, 0x9flf9532 , 0xe0d392df, 0xd3a0342b, 0x8971f21e,
0xlb0a7441, 0x4ba3348c, 0xc5be7120 , 0xc37632d8, 0xdf359f8d, 0x9b992f2e,
0xe60b6f47, 0xfe3flld, 0xe54cda54, 0xledad891, 0xce6279cf, 0xcd3e7e6f,
0xl618bl66, 0xfd2cld05, 0x848fd2c5, Oxf6fb2299, 0xf523f357, 0xa6327623,
0x93a83531, 0x56cccd02, Oxacf08162, 0x5a75ebb5, 0x6el63697, 0x88d273cc,
Oxde966292, 0x81b949d0, 0x4c50901b, 0x71c65614, 0xe6c6c7bd, 0x327al40a,
0x45eld006, 0xc3f27b9a, 0xc9aa53fd, 0x62a80f00, 0xbb25bfe2, 0x35bdd2f6,
0x71126905, 0xb2040222, 0xb6cbcf7c, 0xcd769c2b, 0x53113ec0, 0xl640e3d3,
0x38abbd60, 0x2547adf0, 0xba38209c, 0xf746ce76, 0x77afalc5, 0x20756060,
0x85cbfe4e, 0x8ae88dd8, 0x7aaaf9b0, 0x4cf9aa7e, 0xl948c25c, 0x2fb8a8c,
0xlc36ae4, 0xd6ebelf9, 0x90d4f869, 0xa65cdea0, 0x3f09252d, 0xc208e69f,
0xb74e6132, 0xce77e25b, 0x578fdfe3, 0x3ac372e6};
/ * Initialize S-boxes without file read. */

for(i = 0; i < 256; ++i){
c->S[0][i] = ks0[i];
c->S[l][i] = k s l [ i ] ;
c->S [2] [i] = ks2 [i] ;
c->S[3][i] = k s 3 [ i ] ;
>
j = 0;
for (i = 0; i < N + 2 ; ++i) {
data = 0x00000000;
for (k = 0; k < 4; ++k) {
data = (data « 8) I key[j] ;
j = j + i;
if (j >= keybytes) {
j = 0;
>
}
c->P[i] = c->P[i] * data;
>
datai = 0x00000000;
datar = 0x00000000;
for (i = 0; i < N + 2; i += 2) C
Blowfish_encipher(c.fedatal, fcdatar);
c->P[i] = datai;
718 B lo w f is h
c->P[i + 1] = datar;
>
for (i = 0; i < 4; ++i) {

for (j = 0 ; j < 256; j += 2) {
Blowfish_encipher(c,&datal, ftdatar);
c->S[i][j] = datai;
c->S[i] [j + 1] = datar;
}
>
void blf_key(blf_ctx *c, char *k, int len){

InitializeBlowfish(c,k,len);
>
void blf_enc(blf_ctx *c, unsigned long *data, int b l o c k s M

unsigned long *d;
int i;
d = data;
for(i = 0; i < blocks; i++){
B lowfxsh_encipher(c,d,d+l);
d += 2;
>
>
void blf_dec(blf_ctx *c, unsigned long *data, int blocks){

unsigned long *d;
int i;
d = data;
for(i = 0; i < blocks; i++){
Blowfish_decipher(c,d,d+l);
d += 2;
>
y
void main(void){
blf_ctx c;
char key[] = "AAAAA" ;
unsigned long d a t a[10];
int i;
for(i = 0; i < 10; i++) data[i] = i;
blf_key(&c,key,5);
blf_enc(&c,data,5);
blf_dec(&c,data,l);
B l o w f is h 719
blf_dec(&c,data+2,4);
for(i = 0; i < 10; i += 2) printf("Block XOld decrypts to:
y.081x y.081x.\n", i/2, data[i] , data[i+l]);
3-Way
3way.c
#define STRT_E OxObOb /* round constant of first encryption round */
#define STRT_D Oxblbl /* round constant of first decryption round */
#define NMBR 11 / * number of rounds is 11 */
#ifdef alpha /* Any other 64-bit machines? * /

typedef unsigned int word32;
#else
typedef unsigned long word32;
#endif
/* the program only works correctly if long = 32bits */
void mu(word32 *a) / * inverts the order of the bits of a */

t
int i ;
word32 b[3] ;
b[0] = b[l] = b[2] = 0 ;

for( i=0 ; i<32 ; i++ )
{
b[0] <<= 1 ; b[l] « = 1 ; b[2] «= 1 ;
if(a[0]&l) b[2] 1= 1 ;
if(a[l]fcl) b[l] 1= 1 ;
if(a[2]&l) b[0] 1= 1 ;
a[0] » = 1 ; a[l] » = 1 ; a[2] »= 1 ;
>
a[0] = b[0] ; a[l] = b[l] ; a[2] = b[2] ;

>
void gaimna(word32 *a) /* the nonlinear step */

t
word32 b [3] ;
b[0] = a[0] * (a[l]|(~a[2]))

b[l] = a[l] ' (a[2] I(~a[0]))
b[2] = a[2] * (a[0]|('a[l]>)
122 3 -W ay
a[0] = b[0] ; a[l] = b[l] ; a[2] = b[2] ;

>
void theta(word32 *a) /* the linear step */

{
word32 b [ 3 ] ;
b[0] = a[0] (a[0] » 1 6 ) " (a[l]«16) (a[l]»16) *“• ( a [ 2 ] « 1 6 )

(a[l]»24) " (a[2]«8) (a[2]»8) (a[0]«24)
(a [ 2 ] » 1 6 ) * (a[0]«16) (a [2] » 2 4 ) (a[0]«8) »
b[l] = a[l] - (a[l]»16) ' (a[2]«16) (a [2] » 1 6 ) (a[0]«16)
(a [ 2 ] » 2 4 ) ' (a[0]«8) (a[0] » 8 ) * (a[l]«24) **
(a[0]»16) " (a[l]«16) (a[0] » 2 4 ) (a[l]«8) 9
b[2] = a [2] ‘ (a[2]»16) ‘ (a[0]«16) (a[0]»16) (a[l]«16) **
(a[0]»24) ‘ (a[l]«8) (a[l]»8) (a [2] « 2 4 )
(a[l]»16) * (a[2]«16) (a[l]»24) (a[2]«8) î
a[0] = b[0] ; a[l] = b[l] ; a [2] = b[2] ;

>
void pi_l(word32 *a)

{
a[0] » (a[0]»10) * (a[0]«22);
a [2] = (a[2]«l) * (a [ 2 ] » 3 1 ) ;
>
void pi_2(word32 *a)

{
a[0] = (a[0]«l) ' (a[0]»31) ;
a [2] =( a [ 2 ] » 1 0 ) * (a[2]«22);
>
void rho(word32 *a) /* the round function */

{
thêta(a) ;
pi_l(a) ;
gamma(a) ;
pi_2(a) ;
}
void rndcon_gen(word32 strt,word32 *rtab)

{ /* generates the round constants */
int i ;
for(i=0 ; i<=NMBR ; i++ )

{
rtab[i] = strt ;
strt « = 1 ;
if( strt&OxlOOOO ) strt “= 0x11011 ;
î- W a y 723
y
y
roid encrypt (word32 *a, word32 *k)

[
Lnt i ;
ïord32 rcon [NMBR+1] ;
rndcon_gen(STRT_E,rcon) ;
Cor( i=0 ; K N M B R ; i++ )
atO] “= k[û] * (rcon [i] « 1 6 ) ;

a[l] “= k[l] ;
a [2] ~= k[2] ' rcon[i] ;
rho(a) ;
y
i[0] “= k[0] “ (rcontNMBR] « 1 6 ) ;
itl] '= k[l] ;
i[2] “= k[2] * rcontNMBR] ;
b h eta(a) ;
Y
iroid decrypt(word32 *a, word32 *k)

(
int i ;
ïord32 ki[3] ; /* the ‘i nverse’ key */
»ord32 rconfNMBR+1] ; / * the ‘in v e r s e ’ round constants * /
kifO] = ktO] ; ki[l] = ktl] ; kit2] = k[2] ;

theta(ki) ;
Bu(ki) ;
rndcon_gen(STRT_D,rcon) ;
mu(a) ;
for( i=0 ; i<NMBR ; i++ )
{
a[0] ~= ki[0] * (rcon [i] « 1 6 ) ;
a[l] ~= ki[l] ;
a [2] '= ki[2] * rcon[i] ;
rho(a) ;
>
atO] “= kifO] * (rcon[NMBR] <<16) ;
a[l] ~= ki[l] ;
a [2] ~= k i [2] * rcontNMBR] ;
theta(a) ;
mu(a) ;
>
#ifdef TEST
724 3 -W ay
#include <stdio.h>
ttinclude <stdlib-h>
#define RAND32 ((word32)rand() « 17 ' (uord32)rand() « 9 * randO)
void printvec(word32 *a)

i.
#ifdef alpha
printf ("*/i08x ’
/,08x */.08x\nM ,a[2] ,atl] ,a[0] ) ;
#else
printf ( '7.081x 7.081x 7.081x\n",a [2] ,a tl] ,a [0] ) ;
#endif
>
void m a i n O
{
word32 vector[3], key [3] ,plain [3] ;
int i , j ;
p r intf(”3-way test run\nM);

for (i = 0; i < 10; i++) {
for (j = 0; j < 3; j++) {
key [j] = RAND32 ;
p l a i n [j]=vector tj] = R A N D 3 2 ;
>
printf ("7.3d\r", i) ;
fflush(stdout);
for (j = 0; j < 100; j++)

encrypt(vector,key);
for (j = 0; j < 100; j++)
decrypt(vector.key);
if (vector[0] != plaintO] Il vectortl] != plaintl] Il

vector[2] != plain [2] ) t
fprintf (stderr, "\nError! i = '/.d\n", i);
exit(l);
}
>
printf("Ail tests passed.\n");
key[0]=4; key[l]=5; k e y [2] =6;
vector[0]=l; vectortl] =2; vectorf2]=3;
e ncrypt(vector.key);
printvec(vector);
>
#endif
/* TEST VALUES
key : 00000000 00000000 00000000
plaintext : 00000001 00000001 00000001
3 -W ay 725
ciphertext : ad21ecf7 83ae9dc4 4059c76e
key : 00000004 00000005 00000006

plaintext : 00000001 00000002 00000003
ciphertext : cab920cd d6144138 d2f05b5e
key : bcdef012 456789ab def01234

plaintext : 01234567 9abcdef0 23456789
ciphertext : 7 cdb76b2 9cdddb6d 0aa55dbb
key : cab920cd d6144138 d2f05b5e

plaintext : ad21ecf7 83ae9dc4 4059c76e
ciphertext : 15bl55ed 6bl3f17c 478ea871
RC5
rc5.c
/* RC5REF.C — Reference implémentation of RC5-32/12/16 in C. */
/ * Copyright (C) 1995 RSA Data Security, Inc. */
#include <stdio.h>
#include <time.h>
typedef unsigned long int WORD; /* Should be 32-bit = 4 bytes */
#define w 32 /* word size in bits */
#define r 12 /* number of rounds */
#define b 16 / * number of bytes in key */
#define c 4 / * number words in key = ceil(8*b/w)*/
#define t 26 / * size of table S = 2*(r+l) words */
WORD S [ t ] ; / * expanded key table */
WORD P = 0xb7el5163, Q = 0x9e3779b9; / * magic constants */
/ * Rotation operators. x must be unsigned, to get logical right shift*/
#define ROTL(x,y) ( ( (x)«(y&(w-l))) I ((x)»(w-(y&(w-l)))))
#define ROTR(x,y) C ( ( x ) » (y&(w-1))) I ((x)«(w-(y&(w-l)))))
void RC5_ENCRYPT(W0RD *pt, WORD *ct) /* 2 WORD input pt/output ct */

{ WORD i, A=pt [0] + S [0] , B = p t [1] + S [1] ;
for (i=l; i<=r; i++)
{ A = R0TL(A"B,B)+S[2*i] ;
B = R0TL(B“A,A)+S[2*i+1];
>
ct[0] = A; ct[l] = B;
>
void RC5_DECRYPT(W0RD *ct, WORD *pt) /* 2 WORD input ct/output pt */

l WORD i, B = c t [1], A = c t [0];
for (i=r; i>0; i— )
{ B = R0TR(B-S[2*i+1],A)-A;
A = R0TR(A-S[2*i],B)"B;
y
pt[l] = B-S[l] ; pt[0] = A-S[0] ;
void RC5_SETUP(unsigned char *K) /* secret input key K[0...b-1] */

{ WORD i, j, k, u=w/8, A, B, L[c];
/* Initialize L, then S, then mix key into S */
728 RC5
for (i=b-l,L[c-l]=0; i !=—1 ; i— ) L[i/u] = (L[i/u]«8)+K[i] ;

for (S[0]=P,i=l; i<t; i++) S[i] = S[i-1]+Q;
for (A=B=i=j=k=0; k<3*t; k++,i=(i+l)y.t, j = (j+l)V.c) /* 3*t > 3*c */
{ A = S[i] = ROTL(S[i] + (A+B) ,3) ;
B = L[j] = ROTL(L[j] + (A+B) , (A+B)) ;
>
void m a i n O
{ WORD i, j, p t l [2] , p t 2 [2] , ct[2] = {0,0};
unsigned char key[b];
time_t tO, tl;
if (sizeof(WORD)!=4)
printf ("RC5 error: WORD has '/.d bytes.\n".sizeof (WORD)) ;
printf("RC5-32/12/16 examples:\ n ”);
for (i=l;i<6;i++)
{ /* Initialize ptl and key pseudorandomly based on previous ct */
pt 1 [0] =ct [0] ; pt 1 [1] =ct [1] ;
for (j=0; j<b; j++) key[j] = ct[0]7.(255-j) ;
/* Setup, encrypt, and decrypt */
RC5_SETUP(key);
RC5_ENCRYPT(pt1,c t ) ;
RC5_DECRYPT(ct,pt2);
/ * Print out results, checking for decryption failure */
p r i n t f ("\nJCd. key = ",i);
for (j=0; j<b; j++) p r i n t f 2 X ” ,key[j]);
printf("\n plaintext */,.81X V..81X > ciphertext X.81X X.81X \n",
ptl[0], ptl[l], ct[0], ct [1] ) ;
if (ptl [0] !=pt2 [0] Il ptl[l] !=pt2[l] )
printf("Decryption Error!");
>
time (&t0);
for (i=l;i<100000;i++)
R C5.ENCRYPT(ct,c t ) ;
time (fttl);
printf ("\n Time_t for 100000 blocks: V.ld \ n " , tl-tO) ;
A5
a5.c
static int threshold(rl, r2, r3)
unsigned int rl;
unsigned int r2;
unsigned int r3;
{
int total;
total = (((rl » 9) & 0x1) == 1) +

(((r2 » 11) & 0x1) == 1) +
(((r3 » 11) fc 0x1) == 1);
if (total > 1)
return (0);
else
return (1);
}
unsigned long clock_rl(ctl, rl)

int ctl;
unsigned long rl;
{
unsigned long feedback;
/*
* Primitive polynomial x**19 + x**5 + x**2 + x + 1
*/
ctl “= ((rl » 9) & 0x1);

if (ctl)
{
feedback = (rl » 18) ' (rl » 17) " (rl » 16) ' (rl » 13);
rl = (rl « 1) & 0 x7ffff;
if (feedback fe 0x01)
rl "= 0x01;
}
return (rl);
730 A5
unsigned long clock_r2(ctl, r2)

int ctl;
unsigned long r2;
{
/*
*/
ctl '= ((r2 » 11) ft 0x1);

if (ctl)
{
feedback = (r2 » 21) “ (r2 » 20) * (r2 » 16) ~ (r2 » 12);
r2 = (r2 « 1) & 0x3fffff;
if (feedback & 0x01)
r2 "= 0x01;
}
return (r2);
>
unsigned long clock_r3(ctl, r3)

int ctl;
unsigned long r3;
/*
*/
ctl ~= ((r3 » 11) & 0x1);

if (ctl)
{
feedback = (r3 » 22) * (r3 » 21) * (r3 » 18) “ (r3 » 17);
r3 = (r3 « 1) & 0x7fffff;
if (feedback ft 0x01)
r3 *= 0x01;
>
return (r3);
int keystream(key, frame, alice, bob)

unsigned char *key; /* 64 bit session key */
imsigned long frame; /* 22 bit frame sequence number */
unsigned char *alice; / * 114 bit Alice to Bob key stream */
unsigned char *bob; /* 114 bit Bob to Alice key stream */
C
unsigned long rl; / * 19 bit shift register */
A5_________________________________________________________________________ 731
unsigned long r2; /* 22 bit shift register */

unsigned long r3; /* 23 bit shift register */
int i; /* counter for loops */
int clock_ctl; /* xored with clock enable on each shift register */
unsigned char *ptr; / * current position in keystream * /
unsigned char byte; /* byte of keystream being assembled * /
unsigned int bits; /* number of bits of keystream in byte */
unsigned int bit; /* bit output from keystream generator * /
/ * Initialise shift registers from session key */
rl = (key[0] I (key[l] « 8) I (key [2] « 16) ) fe 0x7ffff;

r2 = ((key[2] » 3) I (key[3] « 5) I (key[4] « 13) I (key[5] « 21))
fe 0x3fffff ;
r3 = ((keyt5] » 1) I (key [6] « 7) I (key[7] « 15) ) fe 0x7fffff;
/ * Merge frame sequence number into shift register State, by x o r ’ing it

* into the feedback path
*/
for (i=0;i<22;i++)
i
clock_ctl = threshold(rl, r2, r 2 ) ;
rl = clock_rl(clock_ctl, r l ) ;
r2 = clock_r2(clock_ctl, r 2 ) ;
if (frame fe 1)
{
rl *= 1;
r2 *- 1;
r3 *= 1;
>
frame = frame » 1;
>
/ * Rini shift registers for 100 clock ticks to allow frame nimber to
* be diffused into ail the bits of the shift registers
*/
for (i=0;i<100;i++)
{
clock_ctl = threshold(rl, r2, r 2 ) ;
rl = clock_rl(clock_ctl, rl);
>
/* Produce 114 bits of Alice->Bob key stream */
ptr = alice;
732 A5
bits = 0;
byte = O;
for (i=0;i<114;i++)
{
clock_ctl = thresholdCrl, r2, r 2 ) ;
rl = clock_rl(clock_ctl, rl);
r3 = clock_r3(clock.ctl, r 3 ) ;
bit = ((rl » 18) " (r2 » 21) * (r3 » 22)) & 0x01;
byte = (byte « 1) I bit;
bits++;
if (bits == 8)
*ptr = byte;
ptr++;
bits = 0;
byte = 0;
>
>
if (bits)
*ptr = byte;
/* Run shift registers for another 100 bits to hide relationship between
* Alice->Bob key stream and Bob->Alice key stream.
*/
for (i=0;i<100;i++)
{
clock.ctl = threshold(rl, r2, r 2 ) ;
rl = clock_rl(clock_ctl, r l ) ;
r3 « clock_r3(clock_ctl, r 3 ) ;
/ * Produce 114 bits of Bob->Alice key stream */
ptr = bob;
bits = 0;
byte = 0;
for (i=0;i<114;i++)
{
clock.ctl * threshold(rl, r2, r2) ;
rl =■ clock_rl(clock_ctl, rl) ;
r2 « clock_r2(clock_ctl, r 2 ) ;
r3 * clock_r3(clock_ctl, r 3 ) ;
bit » ((rl » 18) * (r2 » 21) " (r3 » 22)) t 0x01;

byte * (byte « 1) I bit;
bits++;
if (bits " 8)
A5 733
i
*ptr = byte;
ptr++;
bits = 0;
byte = 0;
}
>
if (bits)
*ptr = byte;
return (0);
>
SEAL
seal.c
/ * SEAL */
#define ALG_OK 0
#define ALG.NOTOK 1
#define WORDS_PER_SEAL_CALL 1024
typedef struct {
unsigned long t[520]; /* 512 rounded up to a multiple of 5 + 5*/
unsigned long s [265]; / * 256 rounded up to a multiple of 5 + 5*/
unsigned long r [ 2 0 ] ; /* 16 rounded u p to multiple of 5 * /
unsigned long counter; / * 32-bit synch value. */
unsigned long ks_buf[WORDS_PER_SEAL_CALL];
int ks_pos;
}- seal_ctx;
#define R0T2(x) (((x) » 2 ) I ((x) « 30))

#define R0T8(x) (((x) » 8 ) I ((x) « 24))
#define R0T9(x) (((x) » 9 ) I ((x) « 23))
#define R0T16(x) (((x) » 16) I ((x) « 16))
#define R0T24(x) (((x) » 24) I ((x) « 8))
#define R0T27(x) (((x) » 27) I ((x) « 5))
#define WORD(cp) ( (cp[0] « 2 4 ) I(cp[l) « 1 6 ) I (cp[2] « 8 ) I(cp[3] ))
#define Fl(x, y, z) (((x) & (y)) I ((“ (x)) & (z)))

#define F2(x, y, z) ((x) ' (y) * (z))
#define F3(x, y, z) (((x) & (y)) I ((x) fe (z)) I ((y) & (z)))
#define F4(x, y, z) ((x) ~ (y) ~ (z))
int g(in,i,h)
unsigned chaur *in;
int i;
unsigned long *h;
{
unsigned long h0,hl,h2,h3,h4,a,b,c,d,e,temp;

unsigned char *kp;
736 SEAL
unsigned long w [ 8 0 ] ;
kp = in;
hO = WDRD(kp); kp += 4;
hl = WOR D ( k p ) ; k p += 4;
h2 = WORD(kp); kp += 4;
h3 = WORD(kp); kp += 4;
h4 = W ORD(kp); k p += 4;
w[0] = i;
for (i=l;i<16;i++) u[i] = 0;
for (i=16;i<80;i++) w[i] = v[i-3] ~w[i-8] ~w[i-14] ~w[i-l6] ;
a = hO; b * hl; c = h2; d = h3; e = h4;
for(i=0;i<20;i++) {
temp = R0T27(a) + Fl(b, c, d) + e + w[i] + 0x5a827999;
e = d; d = c; c = R 0 T 2 ( b ) ; b = a; a = temp;
>
for (i=20;i<40;i++) {
temp = R0T27(a) + F2(b, c, d) + e + w[i] + 0x6ed9ebal;
e = d; d = c; c = R0T2(b); b = a; a = temp;
>
for (i=40;i<60;i++) {
temp = R0T27(a) + F3(b, c, d) + e + w[i] + 0x8flbbcdc;
>
for (i=60;i<80;i++) {
temp = R0T27(a) + F4(b, c, d) + e + w[i] + 0xca62cld6;
>
h[0] = hO+a; h[l] = hl+b; h[2] = h2+c; h[3] = h3+d; h[4] = h4+e;
return (ALG_0K);
}
unsigned long gamma (a,i)

unsigned char *a;
int i;
{
unsigned long h [5];
(void) g(a, i/5, h);

return h[i 7, 5] ;
>
int seal_init( seal_ctx *result, unsigned char »key )

{
SEAL 737
int i;
unsigned long h [ 5 ] ;
for (i=0;i<510;i+=5)
g(key, i/5, fc(result->t[i]));
/* horrible spécial case for the end */
g(key, 510/5, h);
for(i=510;i<512;i++)
result->t[i] = h[i-510] ;
/* 0x1000 mo d 5 is +1, so have horrible spécial case for the staxt */
g(key, (-1+0x1000)/5, h);
for (i=0;i<4;i++)
result->s[i] = h[i+l] ;
for (i=4;i<254;i+=5)
g(key, (i+0xl000)/5, &(result->s[i])) ;
g(key, (254+0xl000)/5, h);
for (i=254;i<256;i++)
result->s[i] = h [ i - 2 5 4 ] ;
/* 0x2000 m o d 5 is +2, so have horrible spécial case at the start */
g(key, (-2+0x20005/5, h);
for(i=0;i<3;i++)
result->r[i] = h[i+2] ;
for (i=3;i<13;i+=5)
g ( k e y ,(i+0x2000)/5,fe(result->r[i]));
g (key, ( 1 3 + 0 x 2 0 0 0 /5, h);
for (i=13;i<16;i++)
result->r[i] = h[i-13] ;
return (ALG_0K);
}
int seal(seal_ctx *key, unsigned long in, unsigned long *out)

{
int i , j ,1;
unsigned long a,b,c,d,nl,n2,n3,n4.*wp;
unsigned short p,q;
«p = out;
for (1=0;1<4;1++) {
a = in key->r [4*1] ;
b = R0T8(in) * k e y - > r [4*1+1];
c = R0T16(in) * k e y - > r [4*1+2];
d = R0T24(in) “ k e y - > r [4*1+3];
>
for (j=0;j<2;j++) {
p= a & 0x7fc;
b += key->t [p/4] ;
a = R0T9(a) ;
738 SEAL
p = b & 0x7fc;
c += k e y ->t[p/4];
b = R0T9(b);
p = c & 0x7fc;
d += key->t[p/4];
c = R0T9(c) ;
p = d & 0x7fc;
a += key- > t [ p / 4 ];
d = R0T9(d);
ni = d; n2=b; n3=a; n4=c;
p = a & 0x7fc;
b += key->t[p/4];
a = R0T9(a);
p = b & 0x7fc;
c += key->t[p/4];
b = R0T9(b);
p = c & 0x7fc;
d += key->t[p/4];
c = R0T9(c);
p = d & 0x7fc;
a += key->t [p/4];
d = R0T9(d);
/* This generates 64 32-bit words, or 256 bytes of keystream. */

for Ci=0;i<64;i++) {
p = a & 0x7fc;
b += key->t[p/4];
a = R0T9(a);
b “= a;
q = b k 0x7fc;
c “= k e y ->t[q/4];
b = R0T9(b);
c += b;
p = (p+c) & 0x7fc;

d += key->t[p/4];
c = R0T9(c);
d *= c;
q = Cq+d) k 0x7fc;
a "= k e y - >t[q/4];
d = R0T9(d);
SEAL 739
a += d;
p = Cp+a) & Ox7fc;

b ~= key->t[p/4] ;
a = R0T9(a);
q = Cq+b) & 0x7fc;

c += key->t[q/4];
b = R0T9(b);
p = (p+c) k Ox7fc;
d “= key->t[p/4];
c = RQT9(c);
q = (q+d) & 0x7fc;

a += k e y - >t[q/4];
d = R0T9(d);
*wp = b + key->s[4*i]; wp++;

*wp = c “ key->s[4*i+l] ; wp++;
*wp = d + k ey - >s[4*i+2]; wp++;
*vrp = a key->s [4*i+3] ; wp++;
if(i&l) {
a += n3;
c += n4;
} else {
a += ni;
c += n2;
}
y
return (ALG_OK);
>
/ * Added call to refill ks_buf and reset counter and ks_pos. * /

void seal_refill_buffer(seal_ctx *c){
seal(c,c->counter,c->ks_buf);
c->counter++;
c->ks_pos = 0;
}
void seal_key(seal_ctx *c, unsigned char *key){

seal_init(c,key);
c->counter = 0 ; /* By default, init to zéro. */
c->ks_pos = WORDS_PER_SEAL_CALL;
/ * Refill keystream buffer on next call. * /
>
/* This encrypts the next w words with SEAL. */

SEAL
void seal_encrypt(seal_ctx * c , unsigned long *data_ptr, int w){

int i;
f or (i=0 ;i<w; i++) •{

if(c->ks_pos>=WORDS_PER_SEAL_CALL) seal_refill_buffer(c);
data_ptr[i]~=c->ks_buf[c->ks_pos];
c->ks_pos++;
>
>
void seal_decrypt(seal_ctx *c, unsigned long *data_ptr, int w) {

seal_encrypt(c,data_ptr,w);
>
void seal_resynch(seal_ctx *c, unsigned long synch_word){

c->counter = synch_word;
c->ks_pos = WORDS_PER_SEAL_CALL;
}
void main(void){
seal_ctx sc;
unsigned long b u f [1000],t;
int i.flag;
unsigned char key[] = { 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19 };
p r intf("l\n");
seal_key(&sc,k e y ) ;
printf("2\n");
for(i=0;i<1000;i++) buf[i]=0;
p rintf("3\n");
seal_encrypt(ftsc,buf,1000);
pr intf("4\n");
t = 0;
for(i=0;i<1000;i++) t = t " buf[i];

printf ("XOR of buf is 5C081x. \n ” ,t) ;
seal_key(&sc,key);
seal_decrypt(ftsc,buf,1);
seal_decrypt(ftsc,buf+l,999);
flag - 0;
for(i=0;i<1000;i++) if(buf[i]!=0)flag=l;
if(flag) printf("Decrypt failed.\n");
else printf ("Decrypt s u c c e e d e d A n " ) ;
}
Lexique anglais—français
All-or-Nothing Disclosure O f Secrets (A N D O S ) : divulgation tout ou rien de

secrets
Data Encryption Standard (D ES): standard de chiffrement de données
Elliptic Curve M ethod (E C M ) : méthode des courbes elliptiques
Euler phi function : fonction d’Euler
Euler totient function : fonction d’Euler
M A C (Message Authentification Code) : code d ’authentification de messages
Number Field Sieve (N FS) : crible sur corps numérique
Pollard’s M onte Carlo algorithm : algorithme Monte-Carlo de Pollard
Secure Hash Algorithm (SH A ) : algorithme de hachage sûr
Secure Hash Standard (SHS) : standard de hachage sûr
absolute rate o f the language : taux absolu du langage
accréditation : accréditation
adaptative-chosen-plaintext attack: attaque à texte en clair choisi adaptative,

attaque à texte en clair choisi dynamique
birthday attack : attaque des anniversaires
blob : pâté
block chaining : chaînage de blocs
block cipher : algorithme de chiffrement par blocs
block replay : attaque par blocs rejoués
breakable : vulnérable, cassable
brute-force attack : attaque exhaustive
chosen-ciphertext attack : attaque à texte chiffré choisi

Lexique anglais-français
chosen-key attack : attaque à clef choisie
chosen-plaintext attack: attaque à texte en clair choisi, attaque à texte en clair

choisi statique
chosen-text attack : attaque à texte choisi
cipher : algorithme cryptographique, chiffre, chiffrement, code
ciphertext : texte chiffré, cryptogramme
ciphertext-only attack : attaque à texte chiffré seulement
cleartext : texte en clair
codebook : livre des codes, carnet de codage
coin ffipping : jouer à pile ou face
compromise : compromission
computationally secure algorithm : algorithme invulnérable par calcul, algorith

me fort
continued fraction : fraction continue
cryptanalysis : cryptanalyse
cryptanalyst : cryptanalyste
cryptographer : cryptographe
cryptographie algorithm : algorithme cryptographique, chiffre, chiffrement, code
cryptography : cryptographie
cryptologist : cryptologue
cryptology: cryptologie
cryptosystem : système cryptographique, cryptosystème, chiffre, code
decrypt (to) : déchiffrer
decryption : déchiffrement, décryptage, décodage
decryption algorithm : algorithme de déchiffrement
designated confirmer signature : signature à vérificateur dédié
dictionary attack : attaque par dictionnaire
double large prime variation o f the multiple polynomial quadratic sieve :

variante à 2 grands facteurs premiers du crible quadratique multipolynomial
eavesdropper : oreille indiscrète, espion, mouchard

encrypt (to) : chiffrer
encryption: chiffrement, encryption, codage
encryption algorithm : algorithme de chiffrement
end-to-end encryption : chiffrement de bout en bout233
entrusted undeniable signature : signature incontestable arbitrée
error extension : amplification d’erreur
feedback with carry shift register : registre à décalage à rétroaction avec retenue
framing : encadrement
gloabal déduction : obtentionn globale
group signature : signature collective
hard : difficile, dur
homophonie substitution cipher : chiffre à substitution homophonique, chiffre à

substitution simple à représentation multiple
host computer : ordinateur hôte
implémentation : réalisation
information déduction : obtention d ’information
initialization vector : vecteur d ’initialisation
interlock protocol : protocole à cliquets
intractable : non soluble
introducer : parrain
key: clef
key crunching : broyage de clef186
key management : gestion des clefs
keyspace : espace des clefs
keystream generator : générateur de codons
knapsack algorithm : algorithme à empilement
knapsack problem : problème d ’empilement
known-plaintext attack : attaque à texte en clair connu
linear congruential generators : générateurs linéaires congruentiels

linear feedback shift register : registre à décalage à rétroaction linéaire
link-by-Iink encryption : chiffrement lien par lien
linking protocol : protocole de filiation
login: accès
man-in-the-middle attack : attaque de l’intercepteur
meet-in-the-middle attack : attaque par collisions
message: message
mimic function : fonction mimétique
minimum-disclosure proof : preuve à divulgation minimale
mix-and-mash : mélange-et-broie
multiple encryption: surchiffrement
multiple polynomial quadratic sieve : crible quadratique multipolynomial
multispeed inner-product generator : générateur multivitesse à produit scalaire
nonce : nombre aléatoire
obfuscation : dissimulation
oblivious transfer : transfert inconscient
obtention locale : obtention locale
one-key algorithm : algorithme à clef secrète
one-time pad : masque jetable
padding : remplissage
password : mot de passe
plaintext : texte en clair
polyalphabetic substitution cipher : chiffre à substitution polyalphabétique
polygram substitution cipher : chiffre à substitution simple par polygrammes
privacy : vie privée, confidentialité
private key : clef privée, clef secrète
probabilistic encryption : chiffrement probabiliste
proxy signature : signature par procuration
public key : clef publique

public-key algorithm : algorithme à clef publique, algorithme à clef révélée
quadratic sieve : crible quadratique
random noise : bruit aléatoire, bruit blanc
rate of the language : taux du langage
receiver: destinataire
relativized cryptography : cryptographie relativisée
restricted algorithm : algorithme restreint
reverse engineering: reconstruction
rotor machine : machine à tambours, machine à rotors
sait : sel, salage
secrecy : confidentialité
secret sharing : partage de secret
secret splitting : morcellement de secret, répartition de secret
secret-key algorithm : algorithme à clef secrète
secure multiparty computation : calcul réparti sûr
seed : germe
self-decimated generator : générateur auto-cadencé
self-recovering : auto-récupérant
self-shrinking generator : générateur à auto-réduction
sender : expéditeur, émetteur
shrinking generator : générateur à réduction
simple substitution cipher : chiffre à substitution simple
single-key algorithm : algorithme à clef secrète
smart card : carte à puce
stop-and-go generator : générateur à signal d’arrêt
stream cipher : algorithme de chiffrement en continu
strong algorithm : algorithme invulnérable par calcul, algorithme fort
strong prime : nombre premier fort
substitution cipher : chiffre à substitution

Bibliographie
superincreasing : super-croissant
symmetric algorithm : algorithme à clef secrète
tap sequence : séquence de dérivation
threshold generator : générateur à seuil
threshold scheme : schéma à seuil
timestamp : datation (substantif ), dater (verbe)
timestamping service : service de datation
total break : cassage complet
tractable : soluble
trustée: dépositaire, fidéicommissaire
uncertainty : incertitude
unconditionally secure : inconditionnellement sûr, absolument sûr
undeniable signature : signature incontestable
unicity distance : distance d’unicité
unicity point : point d’unicité
work factor : effort
working frame : cadre courant
zero-knowledge proof : preuve à divulgation nulle

Cryptographie TP

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cryptographie TP

Transféré par

Droits d'auteur :

Formats disponibles

Bruce Schneier

Traduction de Laurent Viennot

1 P rin cip e s d e base 1

2 B riqu es élém en taires 23

3.8 Protection cryptographique de bases dedonnées.................................... 80

II Techniques cryptographiques 161

7 L on g u eu r des clefs 163

8 G e stio n des clefs 181

10 U tilisa tion des a lgorith m es 227

III Algorithmes cryptographiques 245

11 R u d im en ts m ath ém a tiqu es 247

11.5 Génération de nombres premiers ............................................................ 274

13 A u tres a lgorith m es d e ch iffrem en t par b lo cs 321

14 E n co re d ’au tres algorith m es de ch iffrem ent par b lo c s 351

15 C o m b in a iso n d ’ algorith m es de ch iffrem ent par b lo cs 377

15.8 Combiner plusieurs algorithmes de chiffrement par b l o c s ................... 389

16 G én érateu rs de su ites aléa toires et ch iffrem ent en con tin u 391

17 A u tre s algorith m es d e ch iffrem en t e n con tin u et générateurs

18 F on ction s d e hachage à sens u n iqu e 453

18.13 Choix d’une fonction de hachage à sensu n i q u e .................................... 479

19 A lg o rith m e s à c le f p u b liq u e 485

20 A lg o rith m e s d e sign atu re n u m ériqu e à c le f p u b liq u e 509

21 Schém as d ’ id en tifica tion 531

22 A lg o rith m e s d ’éch an ge d e clefs 541

23 A lg o rith m e s sp éciau x p o u r p r o to c o le s 555

23.7 Pile ou face équitable................................................................................. 570

IV Le monde réel 587

25.13 Brevets......................................................................................................... 639

V Code source 655

Il existe deux types de cryptographie dans le monde: la cryptographie qui empêche

donner au gouvernement la possibilité de mener des surveillances électroniques.

Comment lire ce livre

partie la plus difficile de la cryptographie, et est souvent le tendon d’Achille de systèmes

Bruce S c h n e ie r est le président de C o u n t e r p a n e S y s t e m s , une entreprise de conseil

FlG. 1.1 — Chiffrement et déchiffrement

L’art et la science de garder le secret de messages est appelé cry p to g ra p h ie pratiquée

La fonction inverse, notée D, de déchiffrement transforme C en A i :

Authentification, intégrité, non désaveu

1. A u th e n tifica tio n . Le destinataire d ’un message doit pouvoir s’assurer de son

Ces fonctions vérifient la propriété suivante (voir la figure 1.2): :

FlG. 1.2 - Chiffrement et déchiffrement avec une clef

Certains algorithme utilisent des clefs différentes pour le chiffrement et le déchiffre-

F ig. 1.3 - Chiffrement et déchiffrement avec deux clefs

Algorithmes à clef secrète

Algorithmes à clef publique

tâche du cryptanalyste est de retrouver le texte en clair du plus grand nombre

2. L ’a tta q u e à te x te en cla ir con n u . Le cryptanalyste a non seulement accès aux

R eq u is : Soit k, soit un algorithme permettant de déduire A f,+ i à partir de

3. L ’a ttaq u e à te x te en cla ir c h o is i7. Non seulement le cryptanalyste a accès

4. L ’attaq u e à te x te en clair ch oisi a d a p ta tiv e 8. C ’est un cas particulier de

Il y a au moins trois autres types d’attaques cryptanalytiques.

1. L ’ atta qu e à te x te ch iffré choisi. Le cryptanalyste peut choisir différents textes

D o n n é e s: C i,A li = £>a..(Ci),C2,A12 = D k (C 2) , —, C i , M t = D k (C i).

2. L ’a ttaq u e à c le f ch oisie. Cela n’est pas une attaque où le cryptanalyste peut

Sécurité des cryptosystèmes

1. C assage co m p le t. Un cryptanalyste trouve la clef k telle que Dk(C) = Ai.

2. O b te n tio n g lob a le. Un cryptanalyste trouve un algorithme de remplacement

3. O b te n tio n locale. Un cryptanalyste trouve le texte en clair d ’un message chiffré

4. O b te n tio n d ’ in fo rm a tio n Un cryptanalyste glane quelque information à pro­

On peut mesurer la compiexité(voir la section 7.1) d ’une attaque de l’une ou l’autre

3. C o m p le x ité en esp a ce. La quantité de mémoire nécessaire à l’attaque.

un message innoffensif et dissimule un message secret dans la même feuille de papier.

1.3 Substitution et transposition

- Un ch iffre à su b stitu tio n h o m o p h o n iq u e (ou chiffre à su b stitu tion sim ple

4. O b te n tio n d ’ in fo rm a tio n Un cryptanalyste glane quelque information à pro

FILE fi, fo;

1. Découvrir la longueur de la clef par un procédé appelé c o m p ta g e d e coïn

- DES (standard de chiffrement de données) « Data Encryption Standard » : l’al

- R SA (d’après le nom de ses concepteurs : R i v e s t , S h a m ir et A d l e m a n ) : l’al