Diskussion:Elliptic Curve DSA

standards

ein De-facto-Standard ist etwas voellig anderes als gemeint war, deshalb habe ich den abschnitt rausgenommen. um einen gemeinsamen nenner aller institutionen zu finden, muesste erstmal klargestellt werden, wer mit "alle" gemeint ist. ich weiss nicht, wer alles standards fuer ECDSA verfasst hat. dafuer brauechten wir erstmal eine vollstaendige liste aller standards. mir ist auch nicht klar, ob es sinnvoll ist, eine solche schnittmenge zu bilden; was waere der gewinn dabei? --Mario d 11:52, 18. Aug. 2011 (CEST)

Habe es als "de-facto" eingestellt da es anhand der REF der gemeinsame Nenner ist.

Standarisierungs-Gremien wären hier ANSI, NSA, SAG, NIST, ECC BrainPool bzw die Implementierungen in IPSec, OpenPGP, ZRTP, Kerberos, SSL/TLS. Lt en:Elliptic_Curve_DSA sind diese Standards angegeben "ANS X9F1 · CRYPTREC · IEEE P1363 · NESSIE · NSA Suite B"

Die Schnittmenge ist nicht unbedingt notwendig, erleichtert aber dem dem Leser die Gemeinsamkeiten zu erkennen. Interessant ist die Thematik z.B. für Entwickler bei der Frage, welche Standards in den Applikationen unterstützt werden sollen.

LG --Majx 22:46, 18. Aug. 2011 (CEST)

ich waere dafuer, erst einmal die von dir aufgezaehlten standards sorgfaeltig zu beschreiben, da gibt es ja noch einiges zu tun. ein entwickler wird sich eher an den standard fuer seine anwendung halten, die kurven, die TLS usw. unterstuetzen muessen sind ja definiert. --Mario d 23:03, 18. Aug. 2011 (CEST)

Protokoll: Überprüfung einer Signatur

Das bei "Überprüfung einer Signatur" dargestellte Protokoll und eine Textpassage sind fehlerbehaftet. 1. Im zweiten Satz wird sinngemäß gesagt: Wenn Bob der Quelle von Alice's öffentlichem Schlüssel nicht vertraut, muss er prüfen, ob es sich um einen korrekten Schlüssel handelt. Das ist sachlich falsch. Wenn Bob der Quelle des Schlüssels nicht vertraut, muss er die Verifizierung der Unterschrift vergessen und braucht gar nichts zu prüfen. Einen wohlgeformten Schlüssel kann jeder erzeugen. Vertrauen in die Echtheit von Alice's Schlüssel ist eine elemantare Grundvoraussetzung, ohne die jede Fortsetzung der Prozedur sinnlos wäre.

Es kann m.E. zwei Gründe für die Verifikation der formalen Korrektheit des Schlüssels geben: a) Man ist sich nicht sicher über die Kompetenz von Alice, korrekte Schlüssel zu erzeugen und/oder korrekt zu übertragen und befürchtet, dass Verifizierungsprogramm könnte "abstürzen", wenn ein inkorrekter Schlüssel verwendet wird. Bei korrektem Verifizierungsprogramm würde ein z.B. durch Übertragungsfehler entstandener, formal falscher Schlüssel mit überwältigender Wahrscheinlichkeit zur Ablehnung der Signatur führen.

b) Man befürchtet, ein Angreifer kenne eine Schwachstelle im Verifizierungsalgorithmus und könnte über einen präparierten, inkorrekten Schlüssel das Programm zum Abstruz bringen und unter Nutzung dieser Eintrittspforte das System kompromittieren.

Ob man das Programm durch einen formal inkorrekten Schlüssel zur fälschlichen Verifikation einer Unterschrift bringen kann ist irrelevant. Wenn der Angreifer einen präparierten Schlüssel als Alices Schlüssel einschleusen kann, könnte er auch einfach einen eigenen, formal korrekten Schlüssel einschleusen. Das wäre wesentlich einfacher und effektiver.

2. Selbst wenn wir mal unterstellen, die Validierung des Schlüssels als formal korrekt sei auf Protokollebene nötig(Ich habe da meine Zweifel), ist der dritte Schritt der Schlüsselvalidierung: Test, ob n*Qa = neutr. El überflüssig.

Wenn die Domäne Valide ist und der öffentliche Schlüssel formal korrekt ist, d.h. der Punkt auf der elliptischen Kurve liegt, dann muß n*Qa das neutrale Element sein. Das geht gar nicht anders. Was soll die Überprüfung bringen? Testen, ob die Mathematik der elliptischen Kurven korrekt ist? Tatsächlich wäre dieser Test Teil der Validierung der Domänenparameter und muss in dieser oder einer verwandten Form bei der Validierung der Domänenparameter auch ausgeführt werden, aber nicht bei der Validierung des Schlüssels. Er wäre übrigens auch algorithmisch aufwändig - die Punktmultiplikation ist die langsamste Berechnung im EC-Kryptosystem.

Wenn denn hier eine Domänenvalidierung durchgeführt werden sollte(Ich hielte das für Blödsinn), so müssten auch weitere zum Teil sehr aufwändige Tests durchgeführt werden, die ingesamt auf einem sehr schnellen Rechner Minuten dauern würden und absolut nicht praktikabel (und auch nicht nötig) wären.

Mein Vorschlag: 1. Das dritte Kriterium der Schlüsselvalidierung ersatzlos streichen. 2. Den zweiten Satz umzuformulieren. Etwa: Wenn Bob sicherstellen will, dass sein System nicht durch einen formal unkorrekten Schlüssel in einen undefinierten Zustand gebracht wird, muss er überprüfen.........

Eine größere Lösung für den 2. Punkt wäre, die Validierung des Schlüssels auf Protokollebene ganz wegzulassen und ganz irdisch auf die Korrektheit der Implementation der Punktmultiplikation zu vertrauen. Aus natürlicher Zurückhaltung würde ich aber diese Variante nur wählen, wenn ich ausdrücklich dazu ermuntert werde ;-)

Wenn in nächster Zeit hier keine ernstzunehmenden Gegenargumente gefunden und formuliert werden, werde ich das in ein-zwei Wochen so einpflegen.

--Micha137c (Diskussion) 14:59, 15. Apr. 2013 (CEST)

zu deinem vorschlag 1: der letzte kurvenparameter ist der kofaktor (cofaktor?) h = (anz. der punkte)/n. weglassen kann man den schritt 3 nur fuer h = 1.

zu vorschlag 2: prinzipiell bin ich mit dir (fast) einer meinung. fuer die uebepruefung auf bitfehler ist das die falsche protokollschicht/abstraktionsebene. gegen das weglassen spricht allerdings, dass ECDSA ein standard ist und wir ihn auch so beschreiben sollten, wie er standardisiert ist.

der standard ist leider nicht frei verfuegbar und der FIPS verweist leider nur auf den X9.62, aber im literaturabschnitt ist ein dokument von Certicom aufgefuehrt. in abschnitt 4.1.2 steht dort: "Entity V must receive an assurance that the elliptic curve public key QU is valid using one of the methods specified in Section 3.2.2". im abschnitt 3.2.2 steht dann letzten endes das gleich wie im artikel, nur besser erklaert (bspw. die sache mit dem schritt 3). als grund fuer die ueberpruefung wird dort angegeben (abschnitt 3.2.2): "either to prevent malicious insertion of an invalid public key to enable attacks like small subgroup attacks, or to detect inadvertent coding or transmission errors". da der (mit-?)autor Daniel Brown immerhin teil des X9-kommitees war (ANS X9.62–2005 S. x), gehe ich davon aus, dass das auch so im standard steht oder zumindest der grund fuer die aufnahme der checks war.

die begruendung mag etwas abwegig klingen, aber grundpfeiler der WP ist nunmal die darstellung belegbarer fakten. auch wenn deine argumentation schluessig ist, koennen wir uns nicht darauf berufen, sondern muessen reputable quellen auftreiben. viele lehrbuecher behandeln ECDSA gar nicht, ich habe nur eines gefunden, in dem er ohne die checks vorgestellt wird. schoen waere es, wenn es zur sinnhaftigkeit der checks noch aussagen gaebe. ich wuerde mal bei der englischen WP nachfragen, vielleicht wissen die mehr. verbessern kann man den abschnitt aber sicher noch. --Mario d 19:25, 15. Apr. 2013 (CEST)

Ok, 1. Ich hatte Kofaktoren ungleich 1 nicht mehr auf dem Radar. Da hast Du natürlich recht, wenn die beim Standard erfasst werden sollen(praktisch werden ja meines Wissens eigentlich nur noch Domänenparameter mit Kofaktor 1 verwendet), muss das natürlich berücksichtigt werden.

2. Ja es geht um den Standard und mir leuchtet ein, dass an dieser Stelle in WP der Standard wiederzugeben ist.

Ich werde also keine Änderungen eingeben. Danke für die schnelle und kompetente Antwort in der Diskussion. --Micha137c (Diskussion) 10:23, 16. Apr. 2013 (CEST)

keine ursache und vielen dank fuer den denkanstoss. ich habe die ergebnisse der diskussion im artikel ergaenzt, es gibt ja sicher noch andere leute die sich beim durchlesen die gleichen fragen stellen. --Mario d 10:53, 16. Apr. 2013 (CEST)

ECGDSA

Gerade in der deutschen Wikipedia wäre eine nähere Beschreibung der Besonderheiten der deutschen Variante ECGDSA sehr wünschenswert. Bisher wird diese lediglich in einem Nebensatz erwähnt. --Scy (Diskussion) 09:06, 24. Okt. 2013 (CEST)

Also d_A ist der "private key" und Q_A der öffentliche?

1. Ist das so?
2. Falls ja: Wenn d_A eine 160-Bit-Zufallszahl ist, wie sieht dann Q_A aus?
3. Wie berechnet man Q_A? Ein Beispiel wäre sicher schön, ähnlich wie es bei RSA erklärt wird. --RokerHRO (Diskussion) 15:04, 14. Sep. 2014 (CEST)

Wer hats erfunden?

Wer hats erfunden? Mich würde dies schon interessieren (es wäre eine Vertrauesfrage).

Wann - in welchem Jahr wurde es vorgestellt?

Wer hat es wie Zertifiziert / oder wenn ja wo und in welchem Standard wurde es Zertifiziert?

Wie vertrauenswürdig sind die Kurven? Da ich nicht gerade der Crypto experte bin würde mich interessieren ob hier immer auf feststehende Kurven (also ein und die selbe) zurückgegriffen wird, oder ob diese zufällig ausgewählt werden.

Ist die NSA hier involviert? Da es ja einer Weiterentwickelte Version von DSA Standard ist.

Wäre hier ein Verweis auf den ed25519 Standard empfehlenswert? (nicht signierter Beitrag von 80.153.75.166 (Diskussion) 12:56, 14. Apr. 2015 (CEST))

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://caccioppoli.mac.rub.de/website/papers/multiexp.pdf
  • Netzwerk-Fehler (6) andere Artikel, gleiche Domain
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/http://caccioppoli.mac.rub.de/website/papers/multiexp.pdf
• http://www.secg.org/download/aid-780/sec1-v2.pdf
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.secg.org/download/aid-780/sec1-v2.pdf

– GiftBot (Diskussion) 00:24, 1. Feb. 2016 (CET)

Falsche Formulierung?

"Dieser Fehler in der Verschlüsselung wurde z. B. verwendet, um die Verschlüsselung in der Spielkonsole PlayStation 3 zu berechnen [...]"

Die Formulierung "die Verschlüsselung [...] zu berechnen" klingt merkwürdig. Ich würde vorschlagen "den privaten Schlüssel der Verschlüsselung [...] zu berechnen" oder "die Verschlüsselung [...] zu brechen".

Ist "Verschlüsselung" hier eigentlich das richtige Wort, oder geht es nur um Signaturen von "offiziell veröffentlichter Software", wie es das Ende des Satzes nahelegt? Dann wäre "Dieser Fehler im Signaturverfahren wurde z. B. verwendet, um den privaten Schlüssel für Signaturen für die Spielkonsole PlayStation 3 zu berechnen und damit die Beschränkung auf offiziell veröffentlichte Software auszuhebeln." vermutlich eine gute Formulierung.

Vielleicht kann jemand der die Details des Vorfalls besser kennt, den Satz umformulieren. --193.159.71.106 15:58, 4. Jun. 2016 (CEST)

Sicherheit

Kann jemand was zur Sicherheit sagen? Derzeit scheint ja Microsoft von der NSA deswegen eins auf die Mütze zu bekommen (nicht signierter Beitrag von 89.12.51.240 (Diskussion) 19:47, 15. Jan. 2020 (CET))