Diskussion:Diffie-Hellman-Schlüsselaustausch/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Diffie-Hellman-Schlüsselaustausch/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Diffie-Hellman-Schl%C3%BCsselaustausch/Archiv#Thema_1

Name des Artikels

Ein angemessenerer Titel wäre "Schlüsselvereinbarung", da wie schon erwähnt Schlüssel nicht getauscht, sondern vereinbart(!) werden. Dies ist ein grundsätzlicher Unterschied. siehe Beutelspacher, Moderne Verfahren der Kryptographie - Gruß, Kai

Diese diskussion steht bereits einige zeilen weiter unten. die bezeichnung schlüsselaustausch hat sich im zuge der zeit als am gebräuchlichsten erwiesen, obwohl sie nicht ganz korrekt ist. aber dieser punkt - dass es kein schlüsselaustausch ist - steht ja bereits in der einleitung. im englischen artikel findet man weitere synonyme. gruß --Murkel ^(anmurkeln) 12:17, 13. Sep 2006 (CEST)

Vielleicht sollte man den Artikel "Diffie-Hellman Schlüsselgenerator" nennen, da kein Schlüssel getauscht wird. Es werden lediglich Informationen getauscht, die es ermöglichen, an beiden Kommunikationsendpunkten den selben Schlüssel zu genierieren. Mann kann zb nicht sagen, ich tausche den Schlüssel "X2sf45a" mit meinem gegenüber aus.

Abgesehen vom dann fehlenden Bindestrich ist die Bezeichnung "Schlüsselaustausch" wohl die gebräuchlichste. Ich plane, wenn es meine Zeit zulässt, ohnehin den Artikel stark zu erweitern. Tatsächlich dient das Verfahren ja nicht zum Generieren eines Schlüssels, sondern zum Austausch bzw. zur Einigung auf einen Schlüssel, der nur den beiden Parteien bekannt ist. Stern !? 18:16, 22. Okt 2004 (CEST)

gebräuchlich: ja stimmt. richtig aber eher nicht. im englsichen findet sich meist "key agreement". aber ist wahrscheinlich unwichtig, da man sowieso nach "diffie-hellman" sucht.

Zur Funktionsweise: Sollte man in 5. statt "...kann nun auf beiden Seiten ein Schlüssel z generiert werden..." nicht eher "...kann nun auf beiden Seiten der Schlüssel z generiert werden..." sagen? Entscheidend ist doch, dass nun jeder denselben Schlüssel besitzt.

Eventuell könnte man schon vorher in 2. die Zufallszahlen x indizieren, also etwa $x_{A}$ für Alice und $x_{B}$ für Bob. Im nächsten Schritt berechnen dann entsprechend beide $y_{A}=g^{x_{A}}{\bmod {p}}$ und $y_{B}=g^{x_{B}}{\bmod {p}}$. Im letzten Schritt schließlich berechnet jeder den Schlüssel z aus dem y des Gegenüber und seinem eigenen x, und wegen $(g^{x_{A}})^{x_{B}}=(g^{x_{B}})^{x_{A}}{\bmod {p}}$ kommt bei beiden dasselbe heraus. (Ist natürlich nur ein Vorschlag...) --Dondon 15:00, 29. Okt 2004 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:54, 7. Nov. 2016 (CET)

Arithmethische Frage

Wieso ist $(g^{a}{\bmod {p}})^{b}{\bmod {p}}=g^{ab}{\bmod {p}}$ Ich habe das Rechengesetz nicht gefunden. -- Michael Uhl 10:05, 27. Feb. 2008 (CET)

Genügt die folgende Herleitung?

$(g^{a}{\bmod {p}})^{b}{\bmod {p}}=((g^{a})^{b}{\bmod {p}}){\bmod {p}}=(g^{ab}{\bmod {p}}){\bmod {p}}=g^{ab}{\bmod {p}}$

--Stefan Birkner 21:07, 27. Feb. 2008 (CET)

Nein eigentlich nicht

Die letzten beiden Schritte sind klar. Der erste nicht. Warum ist

$a^{n}{\bmod {c}}=(a{\bmod {c}})^{n}$

Übrigens: Der Beweis für $(a{\bmod {c}}){\bmod {c}}=a{\bmod {c}}$ ist in Wikipedia auch nicht zu finden

-- MartinBrunn 11:44, 29. Feb. 2008 (CET)

Dann gibt’s eine etwas ausführlichere Erklärung ;-)

Es sei $a'=a{\bmod {c}}$. Dann existiert ein $k\in \mathbb {Z}$ mit $a=a'+k\cdot c$. Demnach ist unter Anwendung des Binomischen Lehrsatzes

${\begin{aligned}a^{n}&=(a'+k\cdot c)^{n}\\&=\sum _{k=0}^{n}{n \choose k}(a')^{n-k}(k\cdot c)^{k}\\&=(a')^{n}+\sum _{k=1}^{n}{n \choose k}(a')^{n-k}(k\cdot c)^{k}\\&=(a')^{n}+{\Bigl [}\sum _{k=1}^{n}{n \choose k}(a')^{n-k}(k\cdot c)^{k-1}{\Bigr ]}\cdot k\cdot c\end{aligned}}$

Der rechte Summand in der letzten Zeile ist ein Vielfaches von $c$ und deshalb gilt

$a^{n}{\bmod {c}}=(a')^{n}{\bmod {c}}=(a{\bmod {c}})^{n}{\bmod {c}}$

Ist jetzt alles klar? Und nachdem du anscheinend den Artikel aufmerksam gelesen hast: Was könnte man deiner Meinung nach noch verbessern? Welche Abschnitte waren schwer verständlich? --Stefan Birkner 11:58, 1. Mär. 2008 (CET)

Jetzt ist zwar alles klar, aber anscheinend hat sich da ein kleiner Fehler eingeschlichen. Das k sollte nicht ausserhalb der Reihenklammer stehen. Müsste es nicht heissen:

${\begin{aligned}(a')^{n}+{\Bigl [}\sum _{k=1}^{n}{n \choose k}(a')^{n-k}\cdot k^{k}\cdot c^{k-1}{\Bigr ]}\cdot c\end{aligned}}$

--MartinBrunn 20:51, 4. Mär. 2008 (CET)

Beides ist richtig. Ich wollte durch das Ausklammern von $k$ nur explizit darstellen, dass die ganze Summe ein Vielfaches von $k$ ist. --Stefan Birkner 22:43, 4. Mär. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:55, 7. Nov. 2016 (CET)

Fehler in Funktionsweise ?

Ist es nicht so, dass im ersten Punkt der Funktionsweise nicht eine Primitivwurzel $g$ modulo $p$ mit $2\leq g\leq p-2$ gefordert sein müsste, sondern eine Primitivwurzel derart, das $2\leq g^{a}{\bmod {p}}\leq p-2$ bzw. $2\leq g^{b}{\bmod {p}}\leq p-2$? In dem Fall, das das nicht erfüllt ist, müsste dann der Kommunikationspartner, der dies bemerkt nach Schritt 3 abbrechen? So (oder so ähnlich) ist es zumindest im englischen Artikel zu SPEKE ([Punkt 6]) erklärt, was im Wesentlichen ja auch nur ein bischen mehr als ein Diffie-Hellman-Schlüsselaustausch ist, oder?

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:55, 7. Nov. 2016 (CET)

Link

Dieser Eintrag wahr auf der Hauptseite unerwünscht.

Falls es dennoch Interessenten gibt, hier noch mal der Link in dieses Wiki:

• kleiner Taschenrechner mit RSA und DH Funktion und kurzer Erklärung.

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:55, 7. Nov. 2016 (CET)

Änderung

Da waren ohnehin ganze Teile etwas verkürzt. Ich habe das Verfahren nochmal auf hoffentlich genauere Weise beschrieben. Vielleicht könntet Ihr es nochmal gegenlesen. Stern !? 11:37, 30. Okt 2004 (CEST)

Von mir aus alles bestens! --Dondon 14:13, 2. Nov 2004 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:55, 7. Nov. 2016 (CET)

Unbennenung in Diffie-Hellman-Merkle-Schlüsselaustausch?

Nach der englischen Wikipedia hat Martin Hellman in 2002 vorgeschlagen, das ganze in Diffie-Hellman-Merkle-Schlüsselaustausch unzubennenen. Gute Idee?

Ja. M.M.n. ist es auch vollkommen unwichtig, dass sich Diffie-Hellman eingebürgert hat, denn Ehre, wem Ehre gebührt. In Simon Singhs Book of Ciphers ist jedenfalls von Diffie-Hellman-Merkle die Rede - wie relevant das ist, vermag ich allerdings nicht zu beurteilen. --80.144.125.16

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:56, 7. Nov. 2016 (CET)

Fehler in der Formel bei Schritt 4 zur Erklärung der Funktionsweise

In der Formel, die beide Komm.partner ausführen kommen sowohl a als auch b vor, die ja nur jeweils einem von beiden Komm.partnern bekannt sind.

Da das Verfahren offensichtlich funktioniert wird hier ein Fehler bei der Notierung der Formel gemacht worden sein. Ich habe grad keine Zeit das nachzuschlagen, wollte aber dennoch darauf hinweisen.

--> EDIT: Habe mich beim schnellen übersehen vertan. Ist alles in Ordnung, sorry.

MfG

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:56, 7. Nov. 2016 (CET)

Fehler in Bild

In dem kürzlich zu gefügten Schaubild hat sich ein Fehler eingeschlichen. Am unteren Bildrand heisst es $K=A^{b}=B^{a}$. Das ist falsch, es muss $K=A^{b}{\bmod {p}}=B^{a}{\bmod {p}}$ sein. Die korrekte Form findet sich auch im Text unter dem Bild.

Verstehe nicht, was da falsch sein soll. Könntest Du das bitte ausführen. Ich kann keinen Fehler erkennen. A und B sind doch auch im Bild ganz klar definiert. Stern 00:51, 3. Aug 2006 (CEST)

Das "mod p" fehlt im Bild 4 mal. --Physikr 10:31, 3. Aug 2006 (CEST)

A und B sind im Bild als $A=g^{a}{\bmod {p}}$ und $B=g^{b}{\bmod {p}}$ definiert, das ist auch richtig. Weiterhin ist im Bild aber K falsch definiert! Es steht dort $K=B^{a}$ und $K=A^{b}$. Es muss heissen $K=B^{a}{\bmod {p}}$ und $K=A^{b}{\bmod {p}}$. Dort fehlt also zweimal das ${\bmod {p}}$. Auch in der untersten Zeile des Bildes steckt dieser Fehler, dort fehlt auch das ${\bmod {p}}$. Ganz so, wie es Phyikr gesagt hat... Der Text zur Funktionsbeschreibung enthält diesen Fehler nicht. Wenn du der Urheber des Bildes bist, ändere es bitte. Um nicht einen Widerspruch im Artikel bzw. falsche Angaben zu verbreiten, hatte ich das Bild gelöscht. (nicht signierter Beitrag von 194.25.143.58 (Diskussion) 10:32, 3. Aug. 2006)

Tut mir leid, dass ich zunächst so barsch reagiert habe. Mir ist der Fehler nun eingeleuchtet und ich hatte endlich auch die Zeit, ihn zu korrigieren. Ich hoffe, nun ist alles korrekt! Stern 22:26, 9. Aug 2006 (CEST)

Kein Problem. Ich habe mal bei der englischen Wikipedia nachgeschaut, da war ja das gleiche Diagramm drin. Schau dir mal die Diskussion dazu an: http://en.wikipedia.org/wiki/Talk:Diffie-Hellman_key_exchange Beginne bei "I may be wrong, but isn't this article .. wrong?". Dort ist zu lesen, dass ohne das ${\bmod {p}}$ eine Verallgemeinerung vorliegt, mit ${\bmod {p}}$ ist es ein Sonderfall. Das hätte in unserem Artikel aber erwähnt werden müssen. Mit dem jetzigen Zustand bin ich vollauf einverstanden.

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:56, 7. Nov. 2016 (CET)

Rote Fehler

Was soll denn der Mist mit den Parserfehlern...?

Die Fehler verwundern mich auch, zumal der Formelsatz in anderen Artikeln zu funktionieren scheint. Die Fehlermeldungen schränken die Lesbarkeit schon ein wenig ein ;)

Nach "Seite Bearbeiten - Vorschau - Speichern" sind die Fehler verschwunden.--Penczek 17:01, 17. Jul. 2007 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:57, 7. Nov. 2016 (CET)

Mehr als zwei Teilnehmer

Diffie-Hellman kann man auch mit mehr als zwei Kommunikationsteilnehmern nutzen. Vielleicht könnte das (und wie das dann genau geht) noch ergänzt werden. --Fischbuerger 22:31, 18. Aug 2006 (CEST)

Das ist insofern begrüßenswert, als dass hier DH einen echten Vorteil gegenüber anderen Verfahren zum symmetrischen Schlüsselaustausch bietet. Es müssen für n Teilnehmer nur n Werte veröffentlicht werden und nicht etwa n*(n-1) Nachrichten versendet. --87.234.96.4 21:17, 10. Okt. 2007 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:57, 7. Nov. 2016 (CET)

Link zu Ueli Maurer

Der Link zu Ueli Maurer im Abschnitt Quellen ist falsch. Er verweist derzeit auf den SVP-Parteipräsidenten. Der Ueli Maurer, welcher das Papier "Towards the equivalence of breaking the Diffie-Hellman protocol and computing discrete logarithms." (Advances in Cryptology - Crypto '94. Springer-Verlag, 1994, S. 271−281) verfasst hat, ist Professor am Institut für Theoretische Informatik des Departementes Informatik der ETH in Zürich. Siehe Link http://www.crypto.ethz.ch/~maurer/

Ich hab den Link mal rausgenommen bis es eine Seite über den Ueli Maurer der ETH gibt.

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:57, 7. Nov. 2016 (CET)

Station-to-Station-Protokoll ? (erl.)

Hallo! Vorlage {{Quelle}} eingefügt, wegen Station-to-Station-Protokoll, das in Version 21452279 vom 00:31, 14. Sep. 2006 eingebracht wurde (Änderung „erw Diffie-Hellman-Problem“). Offenbar ist damit kein Synonym zu Point-to-Point Protocol gemeint, aber was dann? Oder doch? Benutzer benachrichtigt.

-- 84.143.161.222 11:38, 9. Mai 2007 (CEST)

Sieh mal unter en:Station-to-Station protocol oder im Stinson nach. --Stefan Birkner 11:49, 9. Mai 2007 (CEST)

Ah, Danke! Jetzt weiss ich Bescheid. Ich hatte diesen Begriff noch nicht gehört. Er taucht in der deutschen Wikipedia in dem Zusammenhang nicht auf, und in der englischen bin ich leider bei en:Station-to-station hängengeblieben.

Interessant.

-- 84.143.161.222 12:14, 9. Mai 2007 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:57, 7. Nov. 2016 (CET)

Fehler im anderen Bild

Ich bin mir da nicht sicher, aber könnte es sein, dass das Bild mit Mallorys Attacke einen kleinen Fehler enthält? Bobs Antwort auf Mallorys Nachricht müsste doch eigentlich $B=g^{b}{\bmod {p}}$ sein, statt $B=Z^{b}{\bmod {p}}$, oder?

Du hast recht. Ich habe das Bild entsprechend korrigiert. --Stefan Birkner 17:02, 29. Jul. 2007 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:57, 7. Nov. 2016 (CET)

Formulierung richtitg?

Als Diffie-Hellman-Problem bezeichnet man die folgende Aufgabenstellung :

   Wenn ein Element g und die Werte gx und gy gegeben sind, welchen Wert hat dann gxy? 

Also mein TR rechnet das ganz schön schnell...ich denke, da ist was bei der Formulierug falsch:

Beispiel:

g = 3 g^x = 243 g^y = 19683

dann folgt:

x = ln(243)/ln(3) y = ln(19683)/ln(3)

x = 5 y = 9

x*y = 35

folgt 3^35...das packt mein Taschenrechner gerade nicht mehr, aber leicht zu berechnen.

Wo ist jetzt bitteschön das diskrete Logarithmus-Problem?

sry, dass ich nicht angemeldet bin, aber das ertemal das ich so einen (vermeindlichen) Fehler finde...

doppelpost

dein einwand ist berechtigt. auf den ersten blick scheint das problem trivial zu sein, aber: alle berechnungen finden in einer Gruppe und nicht nur in einem Körper statt. dein taschenrechner bleibt also aussen vor, weil hier "gewohntes" Rechnen nicht anwendbar ist. mein edit, der dies an entsprechender stelle vermerkt, wurde leider wieder revertiert. gruß --Murkel ^(anmurkeln) 09:54, 24. Sep. 2007 (CEST)

ich verstehe das schon, aber das wirkliche Problem ist doch eigentlich dass 13%3=1 das selbe Ergebnis liefert wie 16%3=1 und selbst 19 liefert das gleiche Ergebnis...also, meine Meinung als kritischer Nutzer ist: Der Satz kann/darf so nicht stehen bleiben. Es muss aufjedenfall hinzugefügt werden. Denn so wie der Datz dort nun steht , ist er falsch! Man gebe mir 2 Zahlen und g und ich löse euch das Problem... ;)

Die Tabelle aus der englischen Version ist zudem ganz nett und sollte hier mit übernommen werden!

dann ändere den artikel doch so, wie du es für richtig hältst. gruß --Murkel ^(anmurkeln) 19:32, 26. Sep. 2007 (CEST)

Die Formulierung des Problems ist richtig. Allerdings ist es nicht in allen Gruppen schwer. Ich spreche deshalb im Artikel nur von bestimmten Gruppen. Welche das genau sind, weiß ich nicht. Da muss ich mich erst tiefer einlesen. Dass die Gruppen von Primzahlordnung dazugehören ist mir allerdings schon geläufig ;-) --Stefan Birkner 08:34, 11. Okt. 2007 (CEST)

es sind afaik die gruppen, in denen das logarithmieren nicht analytisch vorgenommen werden kann. gruß --Murkel ^(anmurkeln) 20:51, 11. Okt. 2007 (CEST)

Entscheidend ist einfach nur, dass bei Größenordnung von $2^{256}$ und wesentlich höher, das eben nicht mehr mit dem Taschenrechner geht, sondern man schon 100 handelsübliche Rechner parallel schalten muss, um in ein paar Stunden die Lösung zu haben... Niemand sagt, dass es unmöglich ist, es dauert eben nur (zu) lange.--Juliabackhausen 09:26, 29. Apr. 2008 (CEST)

das ist falsch. das logarithmieren im körper der reellen zahlen also mit den angesprochenen $2^{256}$ ist in null komma nichts erledigt. das problem liegt tatsächlich nur in der wahl der gruppe, in der eben nicht analytisch logarithmiert werden kann (sondern nur diskret). gruss --Murkel ^(anmurkeln) 09:43, 29. Apr. 2008 (CEST)

Zitat: --Juliabackhausen 09:26, 29. Apr. 2008 (CEST)

"Entscheidend ist einfach nur, dass bei Größenordnung von $2^{256}$ und wesentlich höher, das eben nicht mehr mit dem Taschenrechner geht, sondern man schon 100 handelsübliche Rechner parallel schalten muss, um in ein paar Stunden die Lösung zu haben... Niemand sagt, dass es unmöglich ist, es dauert eben nur (zu) lange."

Das ist nebenbei deshalb schon quatsch weil, selbst wenn man dafür viel Rechenpower benötigen würde, das Ganze mit der obengenannten Formel mathematisch einfach gelöst werden könnte. Ein Problem ist in der Mathematik afaik dann gelöst wenn einer eine Lösung kennt, egal ob man da mehr oder weniger viel zu rechnen hat und das Diffie-Hellman-Problem ist ganz sicher nicht gelöst.

btw sry das ich nicht angemeldet bin aber schreibe sonst eigentlich nichts

Nunja "gelöst" oder nicht ist sone Sache. Es gibt Algorithmen, um den diskreten Logarithmus zu ermitteln, aber die sind eben nicht in Polynomalzeit zu berechnen, weil sie auf Iteration basieren. 217.94.213.213 18:45, 5. Dez. 2008 (CET)

Es handelt sich hier um Prime Restklassengruppen. --Cspan64 12:51, 9. Jul. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:58, 7. Nov. 2016 (CET)

Absichern gegen den Mittelsmann?

"Um einen solchen Man-In-The-Middle-Angriff auszuschließen, müssen die ausgetauschten Nachrichten authentifiziert werden. Dazu verwendet man digitale Signaturen und Message Authentication Codes." << Muss für die Erstellung von Message Authentication Codes nicht vorher ein geheimer Schlüssel ausgetauscht worden sein? Damit sind wir ja beim "Henne-Ei-Problem". Man kann einen sicheren Schlüsseltausch per Diffie-Hellman-Verfahren nur dann durchführen, wenn vorher ein geheimer Schlüssel zum Erstellen der Message Authentication Codes ausgetauscht wurde, ansonsten ist das Verfahren anfällig gegen einen Man-In-The-Middle-Angriff. Der Schlüssel zum Erstellen und Prüfen der MACs darf aber nicht über unsichere Kanäle übertragen werden. Wie entrinnt man dieser Zwickmühle? Selbst wenn wir den Schlüsseltausch durch asymmetrische Verfahren absichern, kann ein Mittelsmann ja immernoch den öffentlichen Schlüssel unseres Gegenüber fälschen, wenn er über den unsicheren Kanal übetragen wird. 217.94.233.207 21:02, 10. Nov. 2008 (CET)

Nachdem ich den Beitrag das erste Mal las, fiel mir ebenso dieser Aspekt auf. Erläuterungen der Vorgehensweisen unter Verwendung einer Signatur beziehungsweise eines MACs sind wünschenswert. Meiner Meinung sind alle Aussagen dieser Art zu erläutern und in den Gesamtzusammenhang einzuordnen. Eine Erklärung der Vorgehensweisen ist in einem anderen Wikipedia-Artikel nachlesbar. Das nachfolgende Zitat dient lediglich als Beleg der Aussage, nicht ihrer Erläuterung. -- Kunsv 15:42, 10. Sep. 2010 (CEST)

Stimme zu. Meiner Meinung nach funktioniert, dies mit MAC nicht. Diffie-Hellman soll ja einen geheimen Schlüssel für beide Kommunikationspartner erzeugen.

Für MAC brauche ich aber auch einen geheimen Schlüssel. Das macht also keinen Sinn.

Authentisierung über asymmetrische Verfahren ist hier dann wohl sinnvoll => Signatur mit privaten Schlüssel des Signierenden => Prüfung der Signatur über öffentlichen Schlüssel

Korrektheitsbeweis des öffentlichen Schlüssel über Zertifikate

ich ändere das mal ab, falls es jemand wieder löscht bitte begründen :-)

mfg Sven --109.84.225.177 20:30, 11. Feb. 2013 (CET)

ich habe die MACs ganz rausgenommen, fuer die aussage hier ist es einfacher, sich auf digitale signaturen zu beschraenken. ansonsten muesste man aufgabentrennung bei schluesseln und forward secrecy noch mitbeschreiben, das ist vielleicht ein bischen viel. --Mario d 22:42, 11. Feb. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:58, 7. Nov. 2016 (CET)

Bildbeschreibung fehlt bei [[Bild:Man-in-the-middle_attack_of_Diffie-Hellman_key_agreement.svg]]

Der Artikel enthält ein Bild, dem eine Bildbeschreibung fehlt, überprüfe bitte, ob es sinnvoll ist, diese zu ergänzen. Gerade für blinde Benutzer ist diese Information sehr wichtig. Wenn du dich auskennst, dann statte bitte das Bild mit einer aussagekräftigen Bildbeschreibung aus. Suche dazu nach der Textstelle [[Bild:Man-in-the-middle_attack_of_Diffie-Hellman_key_agreement.svg]] und ergänze sie.

Wenn du eine fehlende Bildbeschreibung ergänzen willst, kannst du im Zuge der Bearbeitung folgende Punkte prüfen:

• Namensraum Datei: Bilder sollte im Namensraum Datei liegen. Bitte ändere die alten Bezeichnungen Bild: und Image: in Datei:.
• Skalierung: Außerhalb von Infoboxen sollten keine festen Bildbreiten (zum Beispiel 100px) verwendet werden. Für den Fließtext im Artikelnamensraum gibt es Thumbnails in Verbindung mit der automatischen Skalierung. Um ein Bild/eine Grafik in besonderen Fällen dennoch größer oder kleiner darzustellen, kann der „upright“-Parameter verwendet werden. Damit erfolgt eine prozentuale Skalierung, die sich an den Benutzereinstellungen orientiert. --SpBot 22:07, 1. Mär. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:58, 7. Nov. 2016 (CET)

g ungleich p-1

Bei der Funktionsweise, wird ja beschrieben, dass $2\leq g\leq p-2$, also $g\neq p-1$. Warum ist das so? Ich habe in Schneier, Practical Crypography, S.213 gelesen, dass p-1 durch 2 teilbar ist (logisch) und deshalb irgendwie eine kleinere Untergruppe erzeugt werden könnte. Wobei ich nicht verstehe, warum da eine kleinere Untergruppe erzeugt wird. Dass die kleinere Untergruppe dann dazu führt, dass es weniger mögliche Schlüssel gibt und das natürlich die Sicherheit verringert erscheint mir dann wieder logisch. Falls jemand die Erklärung weiß oder versteht, könnte man die ja vielleicht noch hinzufügen, da die Einschränkung sonst meiner Meinung nach etwas willkürlich daher kommt. --Bananenfalter 18:05, 11. Aug. 2010 (CEST)

Also ich glaube so ungefähr verstehe ich es jetzt: Wenn g ein Generator modulo p ist, dann kann man damit jede Zahl in $Z_{p}$ erzeugen, z. B. $h=g^{x}$. Das ist dann z. B. der öffentliche Schlüssel von Bob. Wenn jetzt h wieder als Generator verwendet wird (z. B. potenzieren mit Geheimnis von Alice), dann kann dies nur eine der Zahlen aus der von h erzeugten Gruppe ergeben. Die von h erzeugte Gruppe habe die Ordnung q. Dann gilt $h^{q}\equiv g^{xq}\equiv 1{\pmod {p}}$. Dann muss $xq\equiv 0{\pmod {p-1}}$ gelten, wegen Kleiner fermatscher Satz. Dann ist q = (p-1)/ggT(p-1, x) und q ist damit ein Teiler von p-1. Also könnten in dem Falle, dass g=p-1 beim Berechnen des gemeinsamen Schlüssels aus $g^{b}$ und a nur Elemente erzeugt werden, die in einer Untergruppe sind, deren Ordung ein Teiler von p-1 ist. Da p-1 durch 2 teilbar ist, könnte es sein, dass diese Untergruppe nur 2 Elemente hat, also nur 2 mögliche Schlüssel.

Falls jemand diese Erklärung für richtig befindet und sie in eine verständlichere Fassung bringen kann, dann sollte sie meiner Meinung nach unbedingt in den Artikel. --Bananenfalter 22:11, 11. Aug. 2010 (CEST)

Also Laut http://www-ee.stanford.edu/~hellman/publications/24.pdf (siehe Seite 6 des Dokuments bzw. Seite 649) ist $2\leq g\leq p-2$ einfach falsch. Richtig wäre $1\leq g\leq p-1$. Außerdem ist g keine Primwurzel sondern ein Primitives Element. In der Englischen Wikipedia ist der Unterschied zwischen Privitiem Element und Primwurzel aufgeführt. (nicht signierter Beitrag von 2001:7C0:409:6898:A457:3A6A:6F7B:E2BA (Diskussion | Beiträge) 20:43, 6. Mai 2014 (CEST))

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:59, 7. Nov. 2016 (CET)

Decisional Diffie-Hellmann-Annahme

Es fehlt noch ein Abschnitt für die DDH (decisional diffie-hellmann) - Annahme. Also in kurzen Worten darüber: - bekannt g^a und g^b - gegeben g^(ab) und g^z - entscheide welches von beidem ((g^a)^b) ist. Ein Abschnitt hierüber wäre notwendig um den Artikel über ElGamal zu korrigieren/verbessern. -- 141.3.208.93 12:36, 30. Nov. 2010 (CET)

Nimm doch einfach Decisional Diffie Hellman. --Mario d 21:00, 30. Nov. 2010 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:59, 7. Nov. 2016 (CET)

Aussprache

wie zum Teufel soll ich das (Diffie-Hellman-Problem) aussprechen??? hat jemand Lautschrift???

gruß 23:38, 29. Aug. 2011 (CEST)~

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:59, 7. Nov. 2016 (CET)

Abschnitte "Andere Gruppen"

Was soll denn der Hinweise auf die "primen Restklassengruppen (Z/pZ,*)" im Abschnitt "Andere Gruppen"? Das ist doch genau das gleiche wie das was im Artikel schon überall verwendet wird, nur dass man einmal sagt "wir rechnen jetzt in Z/pZ statt Z" und sich das Hinschreiben von "mod p" überall spart. Im Prinzip ist das nur eine andere Art der Notation. -- 77.186.214.192 23:47, 25. Jun. 2013 (CEST)

danke fuer den hinweis. --Mario d 09:09, 26. Jun. 2013 (CEST)

Die neue Version sieht gut aus. Kleinigkeit: "modulo einer Primzahl" steckt eigentlich schon in "primer Restklassengruppe" drin. -- 77.186.196.1 20:55, 27. Jun. 2013 (CEST)

du kannst aenderungen auch gerne selbst vornehmen, falls du fragen hast, kannst du sie auf meiner diskussionsseite oder auf den hilfeseiten stellen. eine uebersicht findest du auf Wikipedia:Fragen zur Wikipedia. --Mario d 23:11, 27. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 09:59, 7. Nov. 2016 (CET)

DH/EDH

Was ist der Unterschied zwischen Diffie-Hellman und Ephemeral Diffie-Hellman? (nicht signierter Beitrag von 188.99.227.227 (Diskussion) 16:51, 12. Feb. 2014 (CET))

Bei DH leiten sich die Parameter aus dem Zertifikat ab und sind statisch. Bei DHE werden die Parameter temporär erzeugt und verwendet (ephemeral = flüchtig). DH ist performanter, da die Parametererzeugung CPU-Zeit kostet. DHE bietet Perfect Forward Secrecy und ist damit sicherer. --Matthäus Wander 19:36, 12. Feb. 2014 (CET)

Wenn ich den Artikel richtig verstehe, bietet doch DH an sich schon Forward Secrecy, weil nur die Parameter übertragen werden, aber nicht der Schlüssel. Oder habe ich da was überlesen? Die englische Wikipedia unterscheidet auch zwischen FS (gleiche Parameter über die gesamte Sitzung) und PFS (regelmäßige Parameteränderung während der Sitzung). Ich bin verwirrt. (nicht signierter Beitrag von 188.99.227.227 (Diskussion) 21:51, 12. Feb. 2014 (CET))

DH mit statischen Parametern bietet keine Forward Secrecy, weil man aus dem öffentlichen und privaten Schlüssel die geheimen DH-Parameter und damit auch den Sitzungsschlüssel herleiten kann. --Matthäus Wander 23:04, 12. Feb. 2014 (CET)

gerade bei der thematik wuerde ich die parameter, welche die verwendete gruppe bezeichnen, von den schluesseln unterscheiden. bei DH enthaelt das serverzertifikat einen oeffentlichen DH-schluessel. da sich der dazugehoerige geheime schluessel nicht aendert, gibt es keine PFS. bei DHE enthaelt das serverzertifikat einen verifikationsschluessel eines signaturverfahrens, mit dem die per-session DH-schluessel signiert werden. die unterscheidung zwischen FS und PFS in en-WP finde ich fragwuerdig, mWn gibt es keine einheitliche definition. --Mario d 10:29, 13. Feb. 2014 (CET)

@Matthäus Wander: Ich verstehe den Begriff "statische Parameter" nicht ganz. Laut Artikel werden a und b zufällig gewählt, können also nicht aus dem Serverzertifikat abgeleitet worden sein. Beschreibt der Artikel also DHE? @Mario: Inwiefern enthält das Serverzertifikat einen DH-Schlüssel? Wenn ich mit OpenSSL ein RSA-Schlüsselpaar erzeuge, habe ich soweit ich weiß nicht die Option, einen DH-Schlüssel integrieren zu lassen. Funktioniert immer mit DH, DHE und ohne. (nicht signierter Beitrag von 188.99.248.2 (Diskussion) 16:52, 13. Feb. 2014 (CET))

die schluessel im serverzertifikat werden auch zufaellig gewaehlt. der artikel geht auf den unterschied zwischen DH und DHE nicht ein, weil das zu TLS gehoert. http://wiki.openssl.org/index.php/Diffie_Hellman : "Fixed Diffie-Hellman embeds the server's public parameter in the certificate, and the CA then signs the certificate. That is, the certificate contains the Diffie-Hellman public-key parameters, and those parameters never change." --Mario d 17:19, 13. Feb. 2014 (CET)

Danke für den Link. Trotzdem könnte auch bei Fixed DH jemand, der die Kommunikation mitschneidet und den Signierschlüssel in die Finger bekommt, nichts nachträglich entschlüsseln, weil ihm ja immer noch der geheime Parameter a fehlt, oder? (nicht signierter Beitrag von 188.99.236.78 (Diskussion) 18:09, 14. Feb. 2014 (CET))

Der Signierschlüssel ist bei statischem DH der geheime Parameter a, siehe [1]. --Matthäus Wander 19:47, 14. Feb. 2014 (CET)

nochmal zur klarstellung: bei DHE enthaelt das zertifikat einen signaturschluessel, mit dem die bei jeder sitzung neu erzeugten DH-schluessel signiert werden. bei DH enthaelt das zertifikat einen DH-schluessel, der fuer jede sitzung verwendet wird. --Mario d 11:00, 15. Feb. 2014 (CET)

Wenn ich mit OpenSSL ein Schlüsselpaar erzeuge, dann fällt dabei ein öffentlicher Schlüssel ("Zertifikat") und ein geheimer Schlüssel (zum Signieren) raus. Daß das Zertifikat auch den geheimen Schlüssel enthält, wäre ein ziemlich übler Bug. Naja, egal, ich geb's auf, das verstehen zu wollen. Wird schon irgendwie richtig sein. (nicht signierter Beitrag von 188.99.243.68 (Diskussion) 19:06, 15. Feb. 2014 (CET))

Vielleicht wirds so deutlicher: bei DHE enthält das Zertifikat den öffentlichen Teil eines Signaturschlüsselpaars, mit dem die bei jeder Sitzung neu erzeugten DH-Schlüsselpaare signiert werden. Um die Signierung durchzuführen, benötigt der Schlüsselinhaber den dazu entsprechenden privaten Teil des Signaturschlüsselpaars, der separat zum Zertifikat gespeichert wird. Bei DH enthält das Zertifikat den öffentlichen Teil des DH-Schlüsselpaars, der für jede Sitzung verwendet wird. Um DH durchzuführen, benötigt der Schlüsselinhaber den entsprechenden privaten Teil des DH-Schlüsselpaars, der separat zum Zertifikat gespeichert wird. --Matthäus Wander 12:32, 16. Feb. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 10:00, 7. Nov. 2016 (CET)

Formel Grundlegend Falsch

Also Laut http://www-ee.stanford.edu/~hellman/publications/24.pdf (siehe Seite 6 des Dokuments bzw. Seite 649) ist $2\leq g\leq p-2$ einfach falsch. Richtig wäre $1\leq g\leq p-1$. Außerdem ist g keine Primwurzel sondern ein Primitives Element. In der Englischen Wikipedia ist der Unterschied zwischen Privitiem Element und Primwurzel aufgeführt. (nicht signierter Beitrag von 2001:7C0:409:6898:A457:3A6A:6F7B:E2BA (Diskussion | Beiträge) 20:43, 6. Mai 2014 (CEST))

Ich habe die Formel noch einmal angepasst, weil sie unverständlich war. g ist ein primitives Element aus GF(p) (primitive Elemente: http://en.wikipedia.org/wiki/Primitive_element_(finite_field) ), das bedeutet aber NICHT, dass g jeden Wert aus GF(p) annehmen kann. g kann nur die Werte annehmen für die g auch ein primitives Element ist. 1 und p-1 sind keine primitiven Elemente, sind aber dennoch im Körper GF(p)

"und ein primitives Element g in dieser Gruppe" <= das ist Falsch, g ist wenn ein primitives Element des endlichen Körpers GF(p). Es müsste heißen: "g ist das erzeugende Element der zyklischen Gruppe" (nicht signierter Beitrag von 2001:7C0:409:6898:9EE:179A:2BC2:F92A (Diskussion | Beiträge) 15:52, 23. Mai 2014 (CEST))

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 10:00, 7. Nov. 2016 (CET)

Motivation

Der Artikel erklaert nicht, wozu das ganze Verfahren ueberhaupt nuetzlich ist:
Warum kann der Initiator der Kummunikation nicht einfach einen zufaelligen Schluessel waehlen und, verschluesselt mit dem Public Key des Kommunikationspartners, senden ? Schliesslich ist ja, wie der Artikel erklaert, zur Authentifizierung des Kommunikationspartners ohnehin eine zusaetzliche PKI erforderlich, um Man-in-the-Middle-Attacken zu verhindern. Falls neben dem Kommunikationspartner auch der Initiator der Kommunikation einen Public Key besitzt, koennte der gesendete Schluessel zusaetzlich mit diesem signiert werden, um auch den Initiator gegenueber dem Kommunikationspartner zu authentifizieren.
Also: Welchen Nachteil besaesse diese einfachere Vorgegehensweise gegenueber dem komplizierteren Diffie-Hellmann-Verfahren ?
Oder gibt es vielleicht doch auch Anwendungen, die ohne PKI auskommen ? -- Juergen 80.132.187.49 16:14, 26. Jul. 2014 (CEST)

Das ist weniger eine Frage nach der Motivation und mehr ein Vergleich mit einem alternativen Ansatz, der demselben Zweck dient. Warum sollte asymmetrische Verschlüsselung einfacher sein als DH? RSA finde ich etwa gleich kompliziert wie DH. ECC finde ich wesentlich komplizierter. Mit DH ist zudem Forward Secrecy möglich und ist damit gegen eine bestimmte Klasse von Angriffen immun, die man gegen verschlüsselt übertragene Sitzungsschlüssel ausführen kann (auf Forward Secrecy "müsste man mal" im Artikel verweisen). Es gibt tatsächlich Anwendungen für Verschlüsselung ohne PKI, sogar ganz ohne Authentifizierung: Opportunistische Verschlüsselung (en:opportunistic encryption), z. B. verwendet von tcpcrypt (en:tcpcrypt). --Matthäus Wander 22:07, 26. Jul. 2014 (CEST)

Es gibt auch Anwendungen, die ohne PKI auskommen. Nehmen wir z.B. an, Du betreibst in der Firma einen Webservice mit HTTP Basic Authentication und jemand an einem anderen Standort möchte einen Nutzeraccount haben. Dann erzeugt Ihr per OpenSSL auf der Kommandozeile die öffentlichen Parameter, tauscht sie per Mail aus und einigt Euch am Telefon, wie Ihr aus dem gemeinsamen Geheimnis ein Paßwort generiert. Oder Du hast irgendwo einen Dedicated Server gemietet und die Festplatte verschlüsselt und möchtest die Passphrase ändern (weil Du sie beim letzten Booten auf der Remote-Konsole eingegeben hast, wenn auch über eine verschlüsselte Verbindung). Funktioniert genauso (mache ich z.B. so). Der Vorteil von Diffie-Hellman ist, daß niemals eine geheime Information über die Leitung geht - auch nicht verschlüsselt. (nicht signierter Beitrag von 131.220.244.13 (Diskussion) 17:41, 13. Sep. 2014 (CEST))

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 10:00, 7. Nov. 2016 (CET)

Lainen-Frage(n)

Ich hab keine Ahnung von höherer Mathematik, das voraus. Ich hab von PFS gelesen und hab gehofft, hier eine verständliche Erklärung dazu zu finden, wie dieses "Wunder" funktioniert, Infos über einen öffentlichen Kanal auszutauschen, ohne daß Mithörer damit etwas anfangen können.

Erste Frage bezügl. des Bildes mit den Farben: auf den ersten Blick leuchtet ja ein, daß die "geheime Farbe" nicht über die Leitung geht, aber wenn ich es richtig verstanden habe, ist ja die "gemeinsame Farbe" öffentlich bekannt, und wenn das Rechenverfahren zum "Zusammenmixen" der beiden Farben bekannt ist, und dessen jeweiliges Ergebnis durch die "öffentliche Übertragung" auch, muß sich doch die "geheime Farbe" daraus wieder errechnen lassen?

Hab ich da was falsch verstanden, oder kann das Beispiel mit den Farben den Vorgang nicht adäquat darstellen ("hinkender" Vergleich?)? Oder ist dieses Rechenverfahren nicht zurückrechenbar, ähnlich wie ein Hash?

---

Zweite Frage: nach der Diskussion weiter oben muß die Übertragung gegen M.i.t.M-Attacken ja durch eine Signatur abgesichert werden. Dabei beißt sich der Hund doch aber in den Schwanz, weil der öffentliche Schlüssel und die Signatur der Nachricht vom M.i.t.M auch wieder gegen eine eigene ausgetauscht werden können?

Außerdem ist man zur Prüfung der Signatur gezwungen, der PKI zu vertrauen, und welche epic Fails (gestohlene geheime Schlüssel) es da gerade in letzter Zeit bei diversen Anbietern gab, ist ja bekannt.

Ist somit die Schlußfolgerung richtig, daß PFS es einem Angreifer zwar schwerer, aber immer noch nicht unmöglich macht, die Komunikation zu belauschen? (Angriff auf geheimen Schlüssel der PKI; M.i.t.M.-Attacke auf Signatur) --78.52.134.100 06:24, 24. Nov. 2014 (CET)

Erklärungsversuch (zu frage 1 --Mario d 11:25, 20. Okt. 2015 (CEST)): Es ist tatsächlich so, dass es sich berechnen lässt, aber es ist ein hartes mathematisches Problem. Du müsstest wiederholt multiplizieren und den Divisionsrest ermitteln und zwar so oft, dass es mit normaler Hardware bei entsprechender Schlüssellänge viel zu lange dauern würde, um das wirklich praktisch nutzen zu können. Man nennt so etwas Falltürenfunktionen. Es ist einfach in eine Richtung, aber in die andere unvorstellbar schwer, wenn man den Schlüssel nicht kennt. Es ist ähnlich wie beim RSA-Verfahren, bei dem das Produkt zweier großer Primzahlen als Schlüsselbestandteil verwendet wird. Man kann die Primfaktoren wieder ermitteln. Selbst mit neueren Methoden (z.B. Zahlkörpersieb) geht das aber noch viel zu langsam, um es für große Schlüssellängen praktisch anwenden zu können. (80.149.113.199 14:57, 19. Okt. 2015 (CEST) jb)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 10:01, 7. Nov. 2016 (CET)

Mathematische Notation

Die Notation ist mathematisch gesehen nicht ganz korrekt. Es sollte das Kongruenz-Symbol verwendet werden, wenn man Restklassen meint (alles, wo (mod p) steht). Das Kongruenz-Symbol sieht aus, wie ein Gleichheitszeichen, hat aber drei parallele Striche. Die Schreibung würde so einfacher verständlich, weil das (mod p) dann immer nur einmal am Ende einer Zeile stehen müsste und es dann keine Missverständnisse geben würde. Man könnte dann ja die grundlegende Rechenregel für Kongruenzen kurz erklären.

https://de.wikipedia.org/wiki/Kongruenz_(Zahlentheorie) (80.149.113.199 14:57, 19. Okt. 2015 (CEST) jb)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 10:01, 7. Nov. 2016 (CET)

Logjam

Der Logjam-Angriff (Abschnitt Diffie-Hellman-Schlüsselaustausch#US-Exportbeschränkung (DHE_EXPORT)) passt eher in den Artikel Transport Layer Security, da es ausschließlich ein Angriff auf TLS ist. Die Schwäche liegt in der Authentifizierung der TLS-Handshake-Nachrichten, was nicht Aufgabe von DH ist.
Die Entdecker des Logjam-Angriffs [2] beschreiben daneben noch den allgemeinen Angriffsvektor, dass man den diskreten Logarithmus für $p$ nur 1x teuer vorberechnen muss, um anschließend jeden DH-Schlüsselaustausch mit jenem $p$ mit geringem Rechenaufwand brechen zu können. Das betrifft DH allgemein (auch IPSec, SSH etc.) und könnte im Artikel erwähnt werden, unabhängig von Logjam und Export-Chiffren in TLS. --Matthäus Wander 08:45, 10. Jan. 2016 (CET)

Ist geändert. --Matthäus Wander 04:18, 11. Jan. 2016 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 10:01, 7. Nov. 2016 (CET)

Seitenkanalattacke

Was ist im Abschnitt Seitenkanalattacke der Seitenkanal? Das statische $p$ ist keine geheime Information und die Nutzung dessen daher kein Seitenkanalangriff. Der Angriff betrifft auch nicht nur TLS-Implementierungen; weiter unten werden VPN und SSH genannt. --Matthäus Wander 17:23, 26. Mär. 2016 (CET)

erledigt --Matthäus Wander 23:24, 8. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 10:01, 7. Nov. 2016 (CET)

Anschauliche Illustration wurde entfernt

Noch vor ein paar Monaten gab es eine anschauliche Illustration des Schlüsselaustauschs, das auch für mathematisch nicht so versierte Menschen sehr anschaulich war. Dort wurde der Schlüsselaustausch anhand von Farbmischung demonstriert. Ich vermisse diese Illustration sehr und hätte sie gerne zurück, kann aber den Quelltext nicht bearbeiten.

Aus der Versionsgeschichte geht hervor, dass die Illustration in einem Ergänzungs-Marathon vom Benutzer Didia nebenbei wegeditiert wurde, ohne Begründung oder einer vorher stattgefundenen Diskussion. Der betreffende Versionsunterschied ist Spezial:Diff/154233245/next, obwohl auch in vorigen Bearbeitungen die Illustration immer weiter nach unten gerutscht ist. Die betreffende Illustration ist Datei:Diffie-Hellman_Key_Exchange_(de).svg.

Da alle anderen Bilder mathematischer Natur sind, bin ich der Meinung, dass diese Illustration unbedingt wieder rein muss. --2003:71:F3D:CF00:E97D:F34:1849:DF55 16:09, 6. Nov. 2016 (CET)

Tatsächlich ist diese Illustration ziemlich anschaulich, auch für mathematisch nicht versierte Menschen. Ich hatte sie damals herausgenommen, da sie in keinem direkten Bezug zum Text steht (das war auch vor meiner Bearbeitung so). Der Text arbeitet ja nur mit einfachen Zahlenbeispielen. Es müssten zumindest in der Bildunterschrift weitere Erläuterungen hin, ansonsten habe ich nicht das Gefühl, dass die Darstellung einen Mehrwert hat, d.h. ich weiss nicht, ob sie sich ohne weitere Erläuterungen dem Leser sofort erschliesst. Ich mache aber folgenden Vorschlag: Ich teile den Abschnitt „Funktionsweise“ in zwei Unterabschnitte „Veranschaulichung der Grundidee anhand gemischter Farben“ und "Mathematische Funktionsweise" auf. Im ersten Abschnitt kann dann genauer auf die Illustration eingegangen werden. --Didia (Diskussion) 08:38, 7. Nov. 2016 (CET)

Die Illustration wurde nun mit entsprechenden Erläuterungen wieder in den Artikel eingebaut. Sollte ich bei den Farbbezeichnungen daneben gegriffen haben, bitte ich um Korrektur ;-). --Didia (Diskussion) 09:39, 7. Nov. 2016 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 07:59, 7. Mär. 2018 (CET)

Merkel-POV

Ich habe die Grafik mit Merkel, Erdogan und Clinton wegen verstoß gegen WP:NPOV entfernt. Man könnte auch mit der Qualität der Grafik argumentieren, aber das umgeht den Ernst der Angelegenheit. Siehe dazu auch hier. @Didia: Was hat dich denn da geritten? --Aalfons (Diskussion) 14:09, 8. Nov. 2016 (CET)

Ein bisschen Humor darf doch selbst in der WP noch sein. Das ist doch eher satirisch zu sehen... Also ich würde das nicht zu ernst nehmen, aber wenn das andere anders sehen, bitte... Zur Urheberschaft: Diese wurde übrigens in der Diskussion zur Grafik bereits angegeben. Sie setzt sich aus drei Bildern zusammen, die alle auf Wikimedia gefunden werden können...--Didia (Diskussion) 16:34, 8. Nov. 2016 (CET)

Ich hab nicht gelacht. Solche unterschweligen politischen Aussagen sollten wir unterlassen. --DWI (Diskussion) 16:42, 8. Nov. 2016 (CET)

+1, zumal wo sie nichts mit dem Thema zu tun haben. --YMS (Diskussion) 16:43, 8. Nov. 2016 (CET)

+1, das hier ist eine Enzyklopädie. --Gestrandete 55-cm-Geschirrspülmaschine (Diskussion) 16:46, 8. Nov. 2016 (CET)

+1, bitte ein neutrales Bild oder auch kein Bild verwenden. --Fomafix (Diskussion) 16:50, 8. Nov. 2016 (CET)

Habe die Grafik entfernt. --Felistoria (Diskussion) 17:10, 8. Nov. 2016 (CET)

Nun gut, wenn sich hier tatsächlich Leute angegriffen fühlen oder darin ernsthafte politische Aussagen sehen, dann belassen wir es dabei ;-).--Didia (Diskussion) 18:28, 8. Nov. 2016 (CET)

Auf den FsA-Demos laufe ich selbst mit einer lustigen Parole herum, es geht hier weder um Humorlosigkeit noch deine beiden Gründe, sondern rein ums Enzyklopädische. Aber nu iss auch gut. Frohes Schaffen noch. --Aalfons (Diskussion) 18:34, 8. Nov. 2016 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Didia (Diskussion) 07:59, 7. Mär. 2018 (CET)

Implementierung mit der Programmierspreche Python

Von der @84.118.82.226: wurde der untenstehende Python-Code als Ergänzung zum Abschnitt "Elliptic Curve Diffie-Hellman (ECDH)" hinzugefügt. Ich habe ihn (vorerst) wieder entfernt und hierhin kopiert. Ich glaube nicht, dass es sinnvoll ist, hier reinen Code zu posten. Dafür gibt es z.B. GitHub. Zumindest müsste man m.E. den Code etwas besser kommentieren, damit er hier einen Mehrwert bietet. Ausserdem müsste er mit "syntaxhighlight" versehen werden. --Didia (Diskussion) 07:57, 7. Mär. 2018 (CET)

import math

# must be of the form 4k + 3 = 4(k+1) - 1

prime = 2**607 - 1

def inv(b,m):

 s = 0
 t = 1
 a = m
 while b != 1:
   q = a/b
   aa = b
   b = a % b
   a = aa
   ss = t
   t = s - q*t
   s = ss
 if t < 0:
   t = t + m
 return t

def genP(x,a,b):

  if (4*a*a*a + 27*b*b) % prime == 0:
     b = b + 1
  while pow(x**3 + a*x + b, (prime - 1)/2, prime) != 1:
    x = x + 1  
  return [x % prime, pow(x**3 + a*x + b, (prime + 1)/4, prime)]

def ts(x,y,a):

 return ((3*(x**2) + a) * inv(2*y, prime)) % prime

def dpoint(P,a):

 x = P[0]
 y = P[1]
 s = ts(x,y,a)
 xr = (s**2 - 2*x) % prime
 yr = (-y + s * (x-xr)) % prime
 return [xr , yr]

def addP(P,Q,a):

 if P == Q:
   return dpoint(P,a)
 x1 = P[0]
 x2 = Q[0]
 y1 = P[1]
 y2 = Q[1]
 while x1 < x2:
    x1 = x1 + prime
 while y1 < y2:
    y1 = y1 + prime
 s = ((y1-y2) * inv(x1-x2, prime)) % prime
 xr = s**2 - x1 - x2
 yr = s * (x1-xr) - y1
 return [xr % prime,yr % prime]

def mulP(P,n,a):

 isFirst = True
 resP = P
 bsize = 20
 while 2**bsize < n:
    bsize = bsize + 1
 PP = resP
 for b in range(bsize + 1):
    if (n & (1 << b) != 0):   
        if isFirst:
           resP = PP
           isFirst = False
        else:
           resP = addP(resP,PP,a)
    PP = dpoint(PP,a) 
 return resP

# The parameters of the Elliptic Curve.

a=4834892389
b=34858911111111

# x-value of the starting point

x=123234354388937

# The starting point which is added many times to itself

P = genP(x,a,b)

# The public keys

privAlice = 85743857348573489891704994859049170499485904
privBob = 455457456346534563457893499994859049170499485904

# We calulate the public keys

pubkAlice = mulP(P, privAlice, a)
print "Public Key from Alice \n", pubkAlice  
pubkBob = mulP(P, privBob, a)
print "Public Key from Bob \n", pubkBob  

shareBob   = mulP(pubkAlice, privBob, a)
shareAlice = mulP(pubkBob, privAlice, a)

print "\n\nThe shared key as calculated from Alice\n", shareAlice 

print "\n\n"
print "Verification: Are the shared keys equal? ", shareAlice == shareBob

DH mit vorgegebenem K?

Wenn ich das richtig verstehe, weiss man nicht, was für ein K am Ende herauskommt. Könnte man DH so verwenden, dass z.B. Alice K vorgibt und die Parameter so wählt, dass Bob ebendieses K errechnet?

Nein, dann müsste Alice ja diskrete Logarithmen berechnen können, was ja eben nicht effizient möglich ist (sein soll). --Didia (Diskussion) 12:13, 25. Aug. 2019 (CEST)

Computational-Diffie-Hellman-Problem (CDH)

Im Text steht „mit mehreren hundert Dezimalstellen“. Sind die verwendeten Zahlen nicht ausschließlich ganze Zahlen, also Zahlen gerade ohne Dezimalstellen? - Chris (Diskussion) 10:01, 22. Mär. 2019 (CET)

Das stimmt. Habs mal korrigiert. --Didia (Diskussion) 12:25, 25. Aug. 2019 (CEST)

Genearator g

Im Artikel steht: „Da die Hälfte aller Zahlen kleiner p solche Generatoren sind, gibt es genug Auswahl.“ openssl dhparam erlaubt nur die Generatoren 2, 3, und 5, was nicht nach „genug Auswahl“ klingt. (nicht signierter Beitrag von 92.211.103.145 (Diskussion) 22:01, 24. Aug. 2019 (CEST))

Gemäss dieser Seite ist bei openssl der DH Parameter g immer 2, was aber nicht heisst, dass auch andere Möglich sind. Im Gegensatz zur Primzahl p muss die Wahl ja nicht unbedingt zufällig und gross sein. --Didia (Diskussion) 12:10, 25. Aug. 2019 (CEST)

Die Anzahl Primitivwurzeln ist nicht die Hälfte, sondern genau φ ( p − 1 ) , wie beim Kapitel Mathematische Grundlagen erwähnt. (nicht signierter Beitrag von 62.202.180.91 (Diskussion) 23:11, 17. Aug. 2022 (CEST))

Das Artikelbild

... ist mehr als irreführend und gibt den Schlüsselaustausch zudem falsch wieder. Das vermischen zweier unterschiedlicher Schlüssel wie in dem Bild wird alleine nie zu einem gemeinsamen Geheimnis führen. Das Bild sollte daher entfernt werden --2003:CE:6726:7700:C8A7:931F:C9A1:A02C 11:48, 4. Apr. 2020 (CEST)

Ich sehe das Problem nicht. Wie umseitig in Diffie-Hellman-Schlüsselaustausch#Mathematische_Funktionsweise genauer beschrieben, wählen Alice und Bob je einen geheimen Schlüssel, generieren daraus je einen öffentlichen Schlüssel und übermitteln diesen an den anderen. Sie kombinieren dann ihren eigenen geheimen Schüssel mit dem öffentlichen Schlüssel, den sie von dem anderen erhalten haben und bestimmen so das gemeinsame Geheimnis. --Count Count (Diskussion) 11:57, 4. Apr. 2020 (CEST)

Public-Key-Kryptoverfahren

Laut Artikel handelt es sich bei dem DH um ein Public-Key-Kryptoverfahren. Von mir aus können wir es als "asymmetrisches Kryptoverfahren" stehen lassen, doch laut dem (sogar verlinkten) Artikel zu asymm. Krypto. ist "Ein Public-Key-Verschlüsselungsverfahren [...] ein Verfahren, um mit einem öffentlichen Schlüssel einen Klartext in einen Geheimtext umzuwandeln, aus dem der Klartext mit einem privaten Schlüssel wiedergewonnen werden kann." Dies trifft nicht auf DH zu, da

1. weder irgendein Klartext in einen Geheimtext umgewandelt wird, geschweige denn aus einem Geheimtext in den ursprünglichen Klartext.

2. Die Privaten Schlüssel (x, y) die öffentlichen Schlüssel (g^x, g^y) nicht einmal invertieren können.

Die Bezeichnung ist daher irreführend. (nicht signierter Beitrag von 95.90.202.31 (Diskussion) 09:39, 2. Jun. 2020 (CEST))

Das diskrete Logarithmusproblem

Die entscheidende Frage aber lautet, ist die Berechnung des diskreten Logarithmus hinreichend schwierig, so dass eine Berechnung praktisch unmöglich ist. Dazu siehe Schnorr-Signatur.

Ist es möglich x aus dem Wert y zu berechnen?

$y=g^{x}\mod n$ (nicht signierter Beitrag von Franz Scheerer aus Wiesbaden (Diskussion | Beiträge) 12:07, 30. Jan. 2023 (CET))

Siehe Diffie-Hellman-Schlüsselaustausch#Prime_Restklassengruppe_und_Primitivwurzel. --Matthäus Wander 12:17, 30. Jan. 2023 (CET)

Wir können aber die Zahlen mit einem gemeinsamen Primteiler von n ausschließen, falls n keine Primzahl ist. Dann ist wieder alles in Ordnung. --Franz Scheerer aus Wiesbaden (Diskussion) 16:36, 30. Jan. 2023 (CET)

Der Gedanke ist eigentlich banal

$g^{ab}\mod n=(g^{a})^{b}\mod n=(g^{b})^{a}\mod n$

Nein - n muss keine Primzahl sein! --Franz Scheerer aus Wiesbaden (Diskussion) 09:24, 29. Jan. 2023 (CET)

Das Diffie-Hellman-Verfahren ist so definiert, dass n eine Primzahl ist, siehe Paper. Gibt man die Eigenschaft auf, ist es kein Diffie-Hellman mehr, sondern eine davon abgeleitete Variante. Die prime Eigenschaft ist notwendig für die Sicherheit des Verfahrens, siehe Abschnitt Diffie-Hellman-Schlüsselaustausch#Prime_Restklassengruppe_und_Primitivwurzel. Eine prime Restklassengruppe mit Primitivwurzel als Generator ergibt die Werte 0 bis n-1 als mögliches Geheimnis. Wenn n nicht prim ist, ist das nicht sichergestellt: die nicht-prime Restklassengruppe kann weniger Elemente haben, demnach gibt es eine geringere Anzahl an Geheimnissen, die ein Angreifer durchprobieren muss. --Matthäus Wander 12:13, 30. Jan. 2023 (CET)

Die Anzahl der Geheimnisse ist die Eulersche Phi-Funktion. Sie ist in der Tat maximal für eine Primzahl. Der Unterschied ist bei größeren Zahlen jedoch relativ gering und kann durch die Wahl eines größeren Wertes für n leicht ausgeglichen werden. Das Verfahren funktioniert jedenfalls auch für ein nicht-primes n. Alice und Bob können sich trotzdem auf ein gemeinsames Passwort verständigen. Claus Peter Schnorr schlägt vor eine Primzahl p zu wählen, so dass (p-1), die Phi-Funktion, einen hinreichend großen Primfaktor q besitzt. Dann kann g als Generator einer Untergruppe mit q Elementen gewählt werden. Dann nimmt $g^{x}\mod p$ insgesamt q verschiedene Werte an. Wenn q > $2^{256}$ ist, ist das sehr sicher. Aber n muss gar keine Primzahl sein, sofern die Eulersche Phi-Funktion einen solch großen Primfaktor q besitzt. Wir könnten n = $q^{2}$ wählen. --Franz Scheerer aus Wiesbaden (Diskussion) 16:10, 30. Jan. 2023 (CET)

$phi(n)$ gibt erstmal nur die Anzahl der Gruppenelemente in der primen Restklassengruppe wieder. Das entspricht nur dann der Anzahl Geheimnisse, wenn eine Primitivwurzel für die prime Restklassengruppe existiert, also ein Generator, aus dem sich jedes Element der Gruppe erzeugen lässt. Eine Primitivwurzel existiert nicht für jedes beliebige $n$. --Matthäus Wander 20:05, 30. Jan. 2023 (CET)

Die Eulersche Phi-Funktion hat zunächst einmal, von der Definition, noch gar nichts mit Gruppentheorie zu tun. Es ist einfach die Anzahl zu n teilerfremder Zahlen größer oder gleich 1 und kleiner n. Wir können jetzt genau diese teilerfremden Zahlen und die Verknüpfung, Mulitiplikation modulo n, verwenden, um eine Gruppe (im Sinne der Mathematik) zu definieren. Die teilerfremden Zahlen sind dann die Gruppenelemente. Es gibt noch viel mehr Gruppen, die wir betrachten könnten. Die Gruppenelemente sind im Allgemeinen keine Zahlen. Es können zum Beispiel Punkte auf einer Kurve sein. Bei endlichen Gruppen gibt es immer eine definierte Anzahl an Gruppenelementen, die Gruppenordnung. Aber für die Kryptographie brauchen wir so tief indie Gruppentheorie nicht einsteigen. Die Gruppe mit den teilerfremden Zahlen und die Multiplikation modulo n genügt uns eigentlich völlig. --Franz Scheerer aus Wiesbaden (Diskussion) 09:26, 31. Jan. 2023 (CET)

Die Antwort ist für das Diskussionsthema (muss n prim sein? Gibt phi(n) die Anzahl Geheimnisse wieder?) irrelevant. --Matthäus Wander 14:06, 31. Jan. 2023 (CET)

Um ein gemeinsames Passwort zu vereinbaren wird eine Primzahl definitiv nicht benötigt. Die oben genannte Gleichung gilt nämlich für alle großen natürlichen Zahlen. Damit es sicher ist, müssen die Zahlen hinreichend groß sein. --178.202.60.40 18:59, 31. Jan. 2023 (CET)

Nein nicht n sollte eine Primzahl sein, sondern die Ordnung der Gruppe. Die Eulersche Phi-Funktion ist jedoch für größere Zahlen keine Primzahl. Das Problem lösen wir, indem wir als Gruppe eine Untergruppe benutzen. Dazu muss die Eulersche-Phi-Funktion einen hinreichend großen Primfaktor enthalten. --178.202.60.40 19:06, 31. Jan. 2023 (CET)

Es stimmt, der Diffie-Hellman-Schlüsselaustausch wurde mit einer Primzahl als Modulus vorgeschlagen. Wenn wir eine zusammengesetzte Zahl verwenden, ist es ein modifiziertes Verfahren. Wir können auch durchaus eine Primzahl verwenden mit einer Untergruppe deren Ordnung eine kleinere Primzahl q ist, wie es Claus Peter Schnorr vorgeschlagen hat. Für q genügt eine Primzahl mit 256 Binärschnittstellen. --Franz Scheerer aus Wiesbaden (Diskussion) 10:45, 1. Feb. 2023 (CET)

Das ist aus meiner Sicht die beste Lösung. Wir wählen zwei Primzahlen p und q wie es Professor Schnorr vorgeschlagen hat. Das ist dann konform mit dem Diffie-Hellman-Schlüsselaustausch und nicht zu knacken, wenn die Gruppenordnung q größer $2^{256}$ gewählt wird. --Franz Scheerer aus Wiesbaden (Diskussion) 10:48, 2. Feb. 2023 (CET)

Auf der anderen Seite, warum sollten wir ein Verfahren verwenden, dass exakt so im Lehrbuch steht. Wir können jedenfalls die Primzahl p durch eine etwa gleich große zusammengesetzte Zahl n ersetzen. Der Schlüsselaustausch funktioniert weiterhin. Falls die Gruppenordnung der Untergruppe eine hinreichend große Primzahl q ist und wir g als einen Generator der Untergruppe wählen, ist das sicher. Es ist auch vollkommen egal, was das Lehrbuch sagt. Der ausgetauschte Schlüssel soll schließlich geheim sein. Idealer Weise ist auch das Schlüsselaustausch-Protokoll geheim, aber auch dann noch sicher, wenn es der Angreifer kennt. --Franz Scheerer aus Wiesbaden (Diskussion) 10:27, 4. Feb. 2023 (CET)