Discussion:Échange de clés Diffie-Hellman

Point de terminologie

Il serait peut-être plus précis de parler d'accord de clé plutôt que d'échange (key agreement). Chaque partie génére la clé secrète de son côté. La clé secrète ne circule pas de manière protégée entre les deux parties, comme c'est le cas avec RSA par exemple.
Matieux 2 décembre 2005 à 17:11 (CET)

Suppression du tableau

Est-ce qu'on doit vraiment se conformer aux limitations d'IE ? Je le trouvais utile, ce tableau. Gene.arboit 16 décembre 2005 à 22:41 (CET)

Alice Sec Calc  p, g  a ga(mod p)    (gbmod p)a mod p

→ ← =

Bob Calc Sec  p, g  b   gb(mod p)  (gamod p)b mod p

Tableau correct ?

Tel que je comprend le texte, g^a et g^b sont publics mais g^(ab) ne l'est pas. Ce n'est pas en accord avec le tableau. Pppetpp (d) 26 mai 2010 à 16:46 (CEST)

Tout à fait. Il est très mal fait, ce tableau. Mais j'ai pas le temps de corriger. Vaudrait presque mieux le cacher pour l'instant , d'autant qu'il sert pas à grand chose vu le diagramme au dessus --Dfeldmann (d) 26 mai 2010 à 20:41 (CEST)

l'exemple n'est pas tout à fait exact

L'exemple choisit les nombres g=3 et p=23. Or il se trouve que 3 n'est pas un générateur du groupe multiplicatif ((Z/23Z)*, .). Ceci contredit le principe général de Diffie-Helman que l'exemple entendait illustrer. Je pense qu'il vaudrait mieux utiliser g=5 et p=23, ou bien g=7 et p=23. --2001:861:4680:4F0:ED37:669F:40CC:BA70 (discuter) 22 avril 2019 à 16:56 (CEST)

Très bonne remarque, si elle était correcte, mais 3 est bien un générateur de (Z/23Z)*, puisqu'il est premier avec 22 (pour vous faire plaisir, j'ai quand même remplacé par g=5 avant de me rendre compte de l'inutilité de la chose ) --Dfeldmann (discuter) 17 mai 2019 à 09:52 (CEST)

Merci, Dfeldmann, d'avoir effectué la correction dans le texte. Toutefois je me permets d'insister : cette correction était justifiée. En effet, il est impossible de générer le groupe multiplicatif (Z/23Z)* à partir de 3. Pour cela il faudrait que l'ordre de 3 soit égal à 22, cardinal de (Z/23Z)*. Or 3^11=1 modulo 23. Donc l'ordre de 3 est au plus égal à 11 (il est égal à 11, d'ailleurs). Donc 3 n'est pas générateur du groupe multiplicatif (Z/23Z)*. Si vous doutez toujours, une autre façon de voir est de chercher les solutions de l'équation 3^n = 14 modulo 23 : il n'y en a pas donc impossible de générer 14 à partir de 3 (dans Z/23Z). Pour terminer, je vous livre l'ensemble des éléments du sous-groupe de (Z/23Z*, x) engendré par 3: {1;2;3;4;6;8;9;12;13;16;19}. Il est bien différent de Z/23Z*. — Le message qui précède, non signé, a été déposé par 90.80.76.252 (discuter), le 12 juillet 2019 à 16:52‎.

Ah ben oui, suis-je nul... J'ai tout simplement confondu avec le groupe additif :-( --Dfeldmann (discuter) 14 juillet 2019 à 11:55 (CEST)

c'est grâce à votre article que j'ai enfin compris DH, donc merci à vous, Dfeldmann. Et non, il n'y a rien de nul à se tromper parfois :). Bien cordialement.

L'homme du milieu

Il serait beaucoup mieux de presenter le Diffie-Hellman en meme temps que sa faille majeure (lorsqu'on n'authentifie pas les messages) : l'attaque de l'homme du milieu ! Voir http://www.securite.teamlog.com/publication/9/20/27/26/ par exemple pour une brève description.

Fait depuis (cette entrée est assez ancienne)--Dfeldmann (discuter) 20 mai 2019 à 10:02 (CEST)

N'exagérons pas cette "faille". A moins d'avoir son compte e-mail piraté, il y a peu de chance que C prenne la place de A ou de B. Le RSA a aussi ses failles. 90.6.165.45 (discuter) 14 mai 2019 à 13:22 (CEST) Ianop

Tiens, j'en profite pour commenter un peu ça : vous êtes sûr de vous, là aussi ?--Dfeldmann (discuter) 20 mai 2019 à 10:01 (CEST)

Et vous ? ... 86.204.3.228 (discuter) 21 mai 2019 à 09:28 (CEST) Yann Coudert

Voir au-dessus--Dfeldmann (discuter) 21 mai 2019 à 11:01 (CEST)

L'homme du milieu ?

Le problème n'est pas tant l'homme du milieu que la fragilité de la phase 1. Dans l'exemple : 5^6 mod 23 = 8, c'est la connaissance publique de 8 qui pose problème. En effet, rien de plus simple que de résoudre l'équation : 5^x mod 23 = 8, ce qui vous donne x = 6 + 22n (c'est à dire la liste de tous les exposants (a) potentiels de g). 90.40.213.124 (discuter) 25 novembre 2021 à 13:05 (CET) Ianop

Bonjour 90.40.213.124  ; vous auriez parfaitement raison si la base (et la clé publique) étaient assez petits, mais ce n'est pas du tout le cas en pratique : il s'agit du problème du logarithme discret, tout aussi difficile (si ce n'est plus) que celui de la factorisation.--Dfeldmann (discuter) 25 novembre 2021 à 13:43 (CET)

Bonjour, d'accord, je vais tester mon calculateur pour voir jusqu'où il peut aller. Pour l'instant, il me donne toujours la plus petite valeur de x (avec le nombre de fois n à ajouter pour trouver les valeurs supérieures). Ce serait quand même mieux si on ne trouvait pas aussi facilement x, même pour des petits nombres. 90.40.213.124 (discuter) 25 novembre 2021 à 15:58 (CET)

Ne vous fatiguez pas : ces méthodes n'ont aucun intérêt à la calculette. Les clés usuelles pour des applications vraiment sécurisées sont des nombres de 600 chiffres (2048 bits) (voir le paragraphe Fondement mathématique)...--Dfeldmann (discuter) 25 novembre 2021 à 16:11 (CET)

5^x mod 387094521067438089786327105791 (P) = 145964737329597169828654776762 (A)

x = 43987952078706080984589192440n + 3654773 (calcul instantané)

Une clé de 30 chiffres me semble déjà suffisamment sûre. Dommage que cet algo ne soit efficace qu'avec des P dinosauriens, ce qui n'empêchera pourtant pas l'ordinateur quantique de trouver la clé. Dans l'idéal, Il faudrait que A et B ne soient pas échangés en public. 90.40.108.24 (discuter) 27 novembre 2021 à 11:42 (CET)

Bravo pour votre obstination, et de fait, pas étonnant qu'on prenne des clés autrement plus longues, mais en pratique, ce genre de chose combine des clés assez longues (et qu'on sait fabriquer très vite, et sans avoir besoin de super-ordinateurs) avec un renouvellement de ces clés à chaque nouvel échange (toutes les minutes, par exemple). Cela dit, inutile de compter avant fort longtemps sur des ordinateurs quantiques : pour les seuls problèmes de ce genre pour lesquels on dispose d'algorithmes (genre algorithme de Shor), il faut pour des applications intéressantes disposer de milliers, voire de dizaines de milliers de qubits (avec une décohérence suffisamment lente) ; comme on n'en est qu'à moins de cent, faudra sans doute patienter longtemps, ou attendre l'émergence d'une technologie révolutionnaire... Pour plus de détails et une vision plus réaliste de ce que peut et ne peut pas faire un ordinateur quantique, voir les travaux de Scott Aaronson, par exemple cet article.--Dfeldmann (discuter) 27 novembre 2021 à 11:59 (CET)

diffie-hellman et PFS

je debut dans wikipedia et je suis pas bien voyant le graphisme orthographe et moi on est fache !

donc je soumet a la discution avant d'essayer de modifier

je lis dans larticle DH qu'une solution de attaque de l'homme dans le millieu est la signature par clef asymetrique de la clef symetrique

ET que bob et Alice sont sur alors de leurs identitees reciproques mais Eve qui est a l'ecoute elle aussi en est sure ! et ca pour moi c'est pas bon !

---

DH est fait pour etablir une connexion entre deux inconnus (a l'abri de ecoute de Eve et de ...) il est donc normal que DH soit attaqaable dans le millieu ! (puisque A et B ne se connaisent pas

 sinon c'est pas logique !)

---

il est necessaire de separer la couche cryptage DH

de authentification

on s'interconnecte d'abord en DH et a l'abris des ecoutes et on echanges des authentification serieuse ensuite

et la je voudrais introduire mentionner article PFS : Perfect Forward Secrecy

 en assci simple j'ai exprime ca dans
  ca.trousperdu.org GLOSAIRE PFS

non pas pour ameliorer DH mais pourmonter le maque de discretion des clef publique

— Le message qui précède, non signé, a été déposé par Imcp.ba (discuter), le 14 mars 2022 à 15:54‎.

Je ne comprends pas bien votre message, mais je vous ferais une première remarque : Diffie-Hellman est un protocole d’échange de clé et ne fait pas d'hypothèse sur le protocole cryptographique sous-jacent. Celui-ci peut être a clé symétrique ou a clé asymétrique. Je pense qu'il n'est donc pas opportun de citer ces notions. En revanche, le protocole de Diffie-Hellman ou un protocole de la même famille a pour but d'échanger une clé avant d’entamer une session d'échanges chiffrés (comme vous le dites). La dite clé est a priori symétrique puisqu'Alice et Bob possèdent la même, mais cela ne fait pas partie du protocole de Diffie-Hellman.

Deuxième remarque: vous dites qu'Alice et Bob ne se connaissent pas. Pourtant, il faut qu'ils se connaissent et doivent pouvoir s'authentifier. Il faut qu'Alice s'assure qu’elle parle à Bob et que Bob s'assure qu'il parle à Alice, cela s'appelle l'authentification, mais le protocole de Diffie-Hellman ne la traite pas. L'absence d'authentification est ce qui permet l'attaque par l'homme au milieu. --Pierre de Lyon (discuter) 14 mars 2022 à 18:50 (CET)

J’ai essayé une réponse plus technique sur la page de discussion de Imcp.ba, mais je crains bien qu’il s’agisse d’un dialogue de sourds… Dfeldmann (discuter) 14 mars 2022 à 21:36 (CET)

daccords avec vous

DH premet de generer en commun une clef aleatoire

symetrique de codage destine a eviter les currieux

et permet ensuite dans ce canal de discute a abris EVE

identifis ou pas ...

mais la redaction de article telle que je le percois

dans sont PLAN

stipule que DH est attaqable par le H milleu( ce qui est previsible )

et le paragraphe SOLUTION traditionelle

sugere un peut trop a mon gout :

que l'on ne doit plus utilser DH et

passer directement a une procedure identificcation publique !

(qui a vas renseigne Eve beaucoup plus !)

c'est ce 'biais' que je veut mettre en evidance dans le plan de article

et pouvoir faire un lien avec un article si il existe de style

PFS PFS : Perfect Forward Secrecy

ou la DH a toute son importance

( vis a vis des clef publique RSA )

pourquoi etre obliger de choisr entre confidentialite et authetification

je mets DH au dessu de authenti rsa chap

Mais on me reponds que wikipedia n'est pas un lieu pour exposser ce probleme ?? Imcp.ba (discuter) 14 mars 2022 à 23:07 (CET)

Bonjour Imcp.ba  ; relisant vos interventions depuis le début, je comprend enfin le malentendu. La confidentialité porte sur le contenu des messages et non sur leur s auteurs : Alice et Bob se connaissent et sont connus de tous (au sens où ils correspondent à des personnes physiques ou morales répertoriées, par exemple, dans un annuaire de clés publiques) mais Ève peut non seulement espionner leurs communications (électroniques) mais aussi leur envoyer des messages imitant leur identité (électronique). Diffie-Hellman ne permet pas a priori de parer à ce type d'attaque, d'où la nécessité d'ajouter des signatures qui (grâce à la notion de cké asymétrique) seront infalsifiables. Quand au fait que tout cela ne devrait pas être discuté ici, cela vient cette fois de la nature même de Wikipédia : imaginons que vous ayez découvert une faille de sécurité dans DH : il est évident que ce n'est pas dans nos pages de discussion que vous devez en parler, mais dans n'importe quelle revue à comité de lecture. De même, si Wikipédia avait existé à son époque, c'est tout de même à Frege que Russel aurait dû envoyer son paradoxe, car a priori seul un expert peut juger de l'intérêt (ou non) d'une telle remarque, et notre rôle est seulement, ensuite, de transmettre ce qui sera devenu une connaissance établie. Cordialement, --Dfeldmann (discuter) 15 mars 2022 à 07:22 (CET)

 Imcp.ba et PIerre.Lescanne : Cela dit, le problème de la PFS est conu et abordé sur Wikipédia : voir notre article Confidentialité persistante ; il ne serait pas absurde de mentionner ce point (mais de manière tyrès secondaire) dans cet article-ci. --Dfeldmann (discuter) 15 mars 2022 à 07:54 (CET)

Couleur brun, couleur bleu, ...

Quand on écrit « couleur brun » ou « couleur bleu », brun et bleu sont des noms attributs de couleur et ne s'accordent pas.

Ai-je raison ? Pierre Lescanne (discuter) 15 mai 2024 à 10:36 (CEST)