Diskussion:Elliptic Curve Cryptography
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen.521 oder 512?
[Quelltext bearbeiten]521 ist richtig. einfach beim dort verlinkten EN nachschauen. diesen hinweis bitte stehenlassen, der fehler wird oft gemacht (s. versionsgeschichte)--Mario d Diskussion:Elliptic Curve Cryptography#c-MarioS-2011-10-20T08:51:00.000Z-521 oder 512?11
1.2 Choice of Underlying Fields
For each cryptovariable length, there are given two kinds of fields.
A prime field is the field GF(p) which contains a prime number p of elements. The elements of this field are the integers modulo p, and the field arithmetic is implemented in terms of the arithmetic of integers modulo p. A binary field is the field GF(2m) which contains 2m elements for some m (called the degree of the field). The elements of this field are the bit strings of length m, and the field arithmetic is implemented in terms of operations on the bits. The following table gives the sizes of the various underlying fields. By ||p|| is meant the length of the binary expansion of the integer p.
Symmetric Example CV Length Algorithm Prime Field Binary Field 80 SKIPJACK ||p|| = 192 m = 163
112 Triple-DES ||p|| = 224 m = 233
128 AES Small ||p|| = 256 m = 283
192 AES Medium ||p|| = 384 m = 409
256 AES Large ||p|| = 521 m = 571
2 Sekunden nachdenken und 5 Minuten Googlen. 2k bei k=256 ist 512 und nicht 521.
http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.doc
- NIST hat eine 521-bit kurve standardisiert. wenn du es nicht glaubst, kannst du auch einfach direkt im standard die bits zaehlen: FIPS 186-3. --Mario d Diskussion:Elliptic Curve Cryptography#c-MarioS-2012-06-08T16:53:00.000Z-521 oder 512?11
Nachteil
[Quelltext bearbeiten]Hallo, ich habe da noch eine Frage, die vielleicht interessant wäre, im Artikel zu beantworten: Welches sind die Nachteile des EKK-Verfahrens? Warum wird trotzdem meistens RSA oder ähnliches verwendet, wenn EKK trotz kürzerer Schlüssel und schnellerer Berechnung gleich sicher ist? Schöne Grüße, --Siegmaralber 21:52, 23. Nov. 2007 (CET)
Weil die schnellere Berechnung ein Trugschluss ist, eine Multiplikation auf einer elliptischen Kurve ist wesentlich komplizierter als eine "normale" Multiplikation. Ich habe das mal ergänzt. Außerdem hat sich RSA als de facto Standard überall durchgesetzt, jede Software hat sich auf RSA eingeschossen, es wäre ein riesiger Aufwand diese alle auf ECC zu migrieren. ECC würden wohl erst beim RSA-GAU (wenn neue Methoden gefunden werden, um RSA zu knacken) richtig durchstarten. --LetsGetLauth Diskussion:Elliptic Curve Cryptography#c-LetsGetLauth-2008-04-23T08:30:00.000Z-Nachteil11
- Ist das Noch drin? 89.27.199.75 Diskussion:Elliptic Curve Cryptography#c-89.27.199.75-2009-03-26T03:31:00.000Z-LetsGetLauth-2008-04-23T08:30:00.000Z11
Der Standard wurde bereits erwähnt, was sich einmal etabliert hat, verschwindet nicht so schnell. Ansonsten könnte ich mir auch durchaus vorstellen, dass die Kurven leicht komplizierter zu implementieren/handhaben sind und deswegen viele Entwickler die Finger davon lassen :) --84.147.54.101 Diskussion:Elliptic Curve Cryptography#c-84.147.54.101-2010-04-30T08:40:00.000Z-Nachteil11
- zur implementierung: wie man's "nicht" macht siehe beispiel PlayStation_3#Software :) --Majx Diskussion:Elliptic Curve Cryptography#c-Majx-2011-07-29T21:39:00.000Z-84.147.54.101-2010-04-30T08:40:00.000Z11
ElGamal?
[Quelltext bearbeiten]Was hat das Beispiel mit dem Elgamal-Kryptosysytem zu tun (außer dem zu Grunde liegendem Problem)? Für mich sieht das eher wie ein Schlüsseltausch (Diffie-Hellman) aus. Elgamal funktioniert AFAIK doch so, dass zwei Chiffre-Texte erzeugt werden, wo in einem die Nachricht quasi "maskiert" vorliegt. Der Empfänger kann dann entschlüsseln, indem er sein wissen einsetzt um die Maske weg zu kürzen. Ich persönlich finde es gut, das hier nicht zu bringen, da es soweit ich weiß ja schon nicht ganz einfach ist, die zu verschlüsselnde Nachricht in einen Punkt auf der Kurve zu transformieren. Ich würde dann bei dem "Beispiel" (das Wort taucht später auch nicht mehr auf) nur lieber nicht auf Elgamal verweisen (wenn ich Recht habe), sondern auf Diffie-Hellman-Schlüsseltausch. --Pamtrs Diskussion:Elliptic Curve Cryptography#c-Pamtrs-2008-12-11T08:39:00.000Z-ElGamal?11
- Du hast recht, das was da unter „Funktionsprinzip“ steht ist das Diffie-Hellman-Protokoll auf Basis elliptischer Kurven, also eher ein Beispiel, als eine allgemeine Erklärung zu ECC. Ich habe das mal darüber ergänzt. Generell könnte man das aber mal etwas umschreiben, weil das Funktionsprinzip ja eigentlich oben in der Einleitung erklärt wird. --Bananenfalter Diskussion:Elliptic Curve Cryptography#c-Bananenfalter-2010-08-11T13:21:00.000Z-Pamtrs-2008-12-11T08:39:00.000Z11
- logisch ist elGamal einfach eine zeitlich entzerrte DH-Schlüsselvereinbarung. Deshalb finde ich den Verweis hier ganz ok --micha137c Diskussion:Elliptic Curve Cryptography#c-Micha137c-2011-04-28T20:10:00.000Z-Pamtrs-2008-12-11T08:39:00.000Z11
Elliptische-Kurven-Kryptografie
[Quelltext bearbeiten]Gibt es einen Grund, warum das englische Lemma gewählt wurde und nicht das Deutsche Elliptische-Kurven-Kryptografie, das derzeit lediglich eine Weiterleitung ist? Ich plädiere für eine Verschiebung. 85.179.137.25 Diskussion:Elliptic Curve Cryptography#c-85.179.137.25-2010-12-31T10:53:00.000Z-Elliptische-Kurven-Kryptografie11
- Ich würde das unterstüzen. Der deutsche Begriff ist durchaus geläufig. --Mojo1442 Diskussion:Elliptic Curve Cryptography#c-Mojo1442-2011-07-24T14:19:00.000Z-85.179.137.25-2010-12-31T10:53:00.000Z11
bin für beibehaltung des englischen ausdrucks da dieser geläufiger ist und die recherche erleichtert --Majx Diskussion:Elliptic Curve Cryptography#c-Majx-2011-07-29T21:41:00.000Z-Elliptische-Kurven-Kryptografie11
- wie wird es in der einschlaegigen deutschsprachigen literatur benannt? --Mario d Diskussion:Elliptic Curve Cryptography#c-MarioS-2011-07-30T20:10:00.000Z-Majx-2011-07-29T21:41:00.000Z11
- Annette Werner (Literaturhinweis habe ich hinzugefügt) spricht kein einziges mal von ECC, auch in anderer Literatur ist nie von ECC die Rede - wobei es natürlich nicht besonders viel deutschsprachiges zu dem Thema gibt. Allerdings ist auch von "Elliptische-Kurven-Kryptografie" nicht die Rede. Es ist kein eigentlicher Begriff geprägt, meist ist von "(Public-Key-)Kryptographie mit/auf elliptischen Kurven" oder "elliptische Kurven in der Kryptographie" die Rede. Ich würde daher für eine dieser Varianten plädieren - in jedem Fall aber gegen den jetzigen Titel. Englisch ist hier unnötig --Walfisch5 (Diskussion) Diskussion:Elliptic Curve Cryptography#c-Walfisch5-2013-02-23T21:13:00.000Z-MarioS-2011-07-30T20:10:00.000Z11
- "elliptische Kurven in der Kryptographie" ist nicht das gleiche wie ECC, bei ersterem geht es um die kurven, bei letzterem um die krypto. "Elliptische-Kurven-Kryptographie" wird zumindest vom BSI verwendet [1], "Kryptographie mit/auf elliptischen Kurven" gibt es auch. die frage ist, was haeufiger verwendet wird. --Mario d Diskussion:Elliptic Curve Cryptography#c-MarioS-2013-02-24T11:01:00.000Z-Walfisch5-2013-02-23T21:13:00.000Z11
- Du hast Recht, das ist nicht dasselbe. Leider mischt der Artikel es aber auch. Anfang ist allgemein von "asymmetrische Kryptosysteme, die Operationen auf elliptischen Kurven über endlichen Körpern verwenden" die Rede und dann werden unterschiedliche Verfahren genannt - anderseits wird von dem Standard geredet. Man sollte sich entscheiden, was Gegenstand des Artikels sein soll: Entweder der ECC-Standard oder dasjenige Teilgebiet der mathematischen Kryptographie, das die Gruppenstruktur elliptischer Kurven ausnützt. Eventuell sind auch seperate Artikel sinnvoll. --Walfisch5 (Diskussion) Diskussion:Elliptic Curve Cryptography#c-Walfisch5-2013-02-24T15:37:00.000Z-MarioS-2013-02-24T11:01:00.000Z11
- ich habe den artikel etwas umgearbeitet, die standards koennte man sicher noch durchschauen und in die artikel ueber die entsprechenden verfahren einpflegen, falls sie zu speziell sind. --Mario d Diskussion:Elliptic Curve Cryptography#c-MarioS-2013-02-25T15:47:00.000Z-Walfisch5-2013-02-24T15:37:00.000Z11
- Du hast Recht, das ist nicht dasselbe. Leider mischt der Artikel es aber auch. Anfang ist allgemein von "asymmetrische Kryptosysteme, die Operationen auf elliptischen Kurven über endlichen Körpern verwenden" die Rede und dann werden unterschiedliche Verfahren genannt - anderseits wird von dem Standard geredet. Man sollte sich entscheiden, was Gegenstand des Artikels sein soll: Entweder der ECC-Standard oder dasjenige Teilgebiet der mathematischen Kryptographie, das die Gruppenstruktur elliptischer Kurven ausnützt. Eventuell sind auch seperate Artikel sinnvoll. --Walfisch5 (Diskussion) Diskussion:Elliptic Curve Cryptography#c-Walfisch5-2013-02-24T15:37:00.000Z-MarioS-2013-02-24T11:01:00.000Z11
- "elliptische Kurven in der Kryptographie" ist nicht das gleiche wie ECC, bei ersterem geht es um die kurven, bei letzterem um die krypto. "Elliptische-Kurven-Kryptographie" wird zumindest vom BSI verwendet [1], "Kryptographie mit/auf elliptischen Kurven" gibt es auch. die frage ist, was haeufiger verwendet wird. --Mario d Diskussion:Elliptic Curve Cryptography#c-MarioS-2013-02-24T11:01:00.000Z-Walfisch5-2013-02-23T21:13:00.000Z11
- Annette Werner (Literaturhinweis habe ich hinzugefügt) spricht kein einziges mal von ECC, auch in anderer Literatur ist nie von ECC die Rede - wobei es natürlich nicht besonders viel deutschsprachiges zu dem Thema gibt. Allerdings ist auch von "Elliptische-Kurven-Kryptografie" nicht die Rede. Es ist kein eigentlicher Begriff geprägt, meist ist von "(Public-Key-)Kryptographie mit/auf elliptischen Kurven" oder "elliptische Kurven in der Kryptographie" die Rede. Ich würde daher für eine dieser Varianten plädieren - in jedem Fall aber gegen den jetzigen Titel. Englisch ist hier unnötig --Walfisch5 (Diskussion) Diskussion:Elliptic Curve Cryptography#c-Walfisch5-2013-02-23T21:13:00.000Z-MarioS-2011-07-30T20:10:00.000Z11
Schreibfehler, oder gewollt?
[Quelltext bearbeiten]"Das n-fache Addieren eines Punktes P mit sich selbst wird mit nP bezeichnet und entspricht einer Exponentiation xn im ursprünglichen Verfahren."
| | | im Original steht x hoch n
Müsste an dieser Stelle denn dann nicht Multiplizieren und nicht Addieren stehen?
Gruß Lasse (nicht signierter Beitrag von 217.86.151.146 (Diskussion) Diskussion:Elliptic Curve Cryptography#c-217.86.151.146-2011-06-21T07:33:00.000Z-Schreibfehler, oder gewollt?11)
das n-fache addieren eines punktes mit sich selbst ist das gleiche wie eine multiplikation mit n, der satz ist also korrekt. vielleicht kann er trotzdem noch leichter verstaendlich gemacht werden. --Mario d Diskussion:Elliptic Curve Cryptography#c-MarioS-2011-06-21T10:52:00.000Z-Schreibfehler, oder gewollt?11
Im Text steht jetzt aber nicht "das -fache Addieren eines Punktes mit sich selbst" sondern "das -fache Addieren eines Punktes zu sich selbst". Wenn man einen Punkt zweimal zu sich selbst addiert, erhält man meiner Ansicht nach und nicht (man lese den Text auch mal mit ). Selbst das verkürzte "das -fache Addieren eines Punktes " ergibt . Richtig ist wahrscheinlich nur "die Addition von Summanden ". --Ann (Diskussion) Diskussion:Elliptic Curve Cryptography#c-Annie Yousar-2021-05-07T10:05:00.000Z-Schreibfehler, oder gewollt?11
"Aus diesem Grund sind Kryptosysteme, die auf elliptischen Kurven beruhen, langsamer." <- ?
[Quelltext bearbeiten]Hallo, ich habe nicht soviel Ahnung von Krypto, aber "Aus diesem Grund sind Kryptosysteme, die auf elliptischen Kurven beruhen, langsamer." hört sich für mich komisch an, wenn ich sowas sehe: Curve25519: new Diffie-Hellman speed records - jemand hier, der mehr weiß? --TheJH disk Diskussion:Elliptic Curve Cryptography#c-TheJH-2011-06-30T15:44:00.000Z-"Aus diesem Grund sind Kryptosysteme, die auf elliptischen Kurven beruhen, langs11
- Die Aussage ist in der Regel nicht richig. Ich habe das korrigiert.--Mojo1442 Diskussion:Elliptic Curve Cryptography#c-Mojo1442-2011-07-24T17:44:00.000Z-TheJH-2011-06-30T15:44:00.000Z11
Vergleich der Verschlüsselungsstärken
[Quelltext bearbeiten]die NIST-tabelle sorgt immer wieder fuer verwirrung, weil NIST eine 521-bit kurve standardisiert hat:
Symmetric Key Size (bits) | RSA and Diffie-Hellman Key Size (bits) | Elliptic Curve Key Size (bits) |
---|---|---|
80 | 1024 | 160 |
112 | 2048 | 224 |
128 | 3072 | 256 |
192 | 7680 | 384 |
256 | 15360 | 521 |
eine moeglichkeit waere, statt NIST als quelle ECRYPT zu nehmen und derern zahlen zu verwenden:
Symmetric Key Size (bits) | RSA and Diffie-Hellman Key Size (bits) | Elliptic Curve Key Size (bits) |
---|---|---|
80 | 1248 | 160 |
112 | 2432 | 224 |
128 | 3248 | 256 |
192 | 7936 | 384 |
256 | 15424 | 512 |
ich faende es noch besser, beide zu verwenden und die herkunft der unterschiedlichen zahlen zu erklaeren:
Sicherheitsniveau | RSA/DH (NIST) | RSA/DH (ECRYPT) | ECDH |
---|---|---|---|
80 | 1024 | 1248 | 160 |
112 | 2048 | 2432 | 224 |
128 | 3072 | 3248 | 256 |
192 | 7680 | 7936 | 384 |
256 | 15360 | 15424 | 512[3] |
um die tabelle nicht zu breit werden zu lassen, wuerde ich die spaltenueberschriften abkuerzen, das muesste dann eben im text erklaert werden. --Mario d Diskussion:Elliptic Curve Cryptography#c-MarioS-2012-06-10T10:03:00.000Z-Vergleich der Verschlüsselungsstärken11
- ↑ a b The Case for Elliptic Curve Cryptography. 15. Januar 2009, abgerufen am 3. November 2011 (englisch).
- ↑ a b ECRYPT II: ECRYPT II Yearly Report on Algorithms and Keysizes (2010-2011). 2011, S. 30 (www.ecrypt.eu.org/documents/D.SPA.7.pdf [PDF]).
- ↑ NIST hat nur eine 521-bit Kurve standardisiert und gibt daher als äquivalentes Sicherheitsniveau 521 bit an.
Unsicherer als RSA?
[Quelltext bearbeiten]Unter 1 wird Bruce Schneier zitiert, dass er ECC für unsicherer hält, da ähnlich wie bei DES, bestimmte Details von NSA&Co. spezifiziert wurden.--Mager (Diskussion) Diskussion:Elliptic Curve Cryptography#c-Mager-2013-09-06T19:52:00.000Z-Unsicherer als RSA?11
- der vergleich mit DES ist quatsch, der ist auch nicht von Schneier. die NSA hat DES verbessert, weil sie kurze schluessel durchsetzen konnte. ECC ist nicht an sich unsicherer, nur wenn man konstanten benutzt, die nicht von einer vertrauenswuerdigen instanz gewaehlt wurden. das muss man schon differenziert betrachten. --Mario d Diskussion:Elliptic Curve Cryptography#c-MarioS-2013-09-07T12:32:00.000Z-Mager-2013-09-06T19:52:00.000Z11
- Also das die NSA DES "verbessert" hat, indem sie kürzeren Schlüssel durchgesetzt hat, ist schon aus logischen Gründen Unsinn. Ein kürzerer Schlüssel bedeutet einen kleineren Schlüsselraum und deshalb mit Brute-Force-Methode11 angreifbarer. Genau das Richtige für die überbordene NSA-Hardware. 31.19.64.224 15:55, 7. Sep. 2013 (CEST) (`Tschuldigung Signatur vergessen.) 31.19.64.224 Diskussion:Elliptic Curve Cryptography#c-31.19.64.224-2013-09-07T13:55:00.000Z-MarioS-2013-09-07T12:32:00.000Z11
- die NSA konnte kurze schluessel durchsetzen, deshalb konnte sie es sich erlauben, den algorithmus selbst zu verbessern. bei ECC hat sie keinen einfluss auf die schluessellaenge, also ein interesse an einer backdoor.--Mario d Diskussion:Elliptic Curve Cryptography#c-MarioS-2013-09-07T18:30:00.000Z-31.19.64.224-2013-09-07T13:55:00.000Z11
- Also das die NSA DES "verbessert" hat, indem sie kürzeren Schlüssel durchgesetzt hat, ist schon aus logischen Gründen Unsinn. Ein kürzerer Schlüssel bedeutet einen kleineren Schlüsselraum und deshalb mit Brute-Force-Methode11 angreifbarer. Genau das Richtige für die überbordene NSA-Hardware. 31.19.64.224 15:55, 7. Sep. 2013 (CEST) (`Tschuldigung Signatur vergessen.) 31.19.64.224 Diskussion:Elliptic Curve Cryptography#c-31.19.64.224-2013-09-07T13:55:00.000Z-MarioS-2013-09-07T12:32:00.000Z11
Seitenkanalangriffe
[Quelltext bearbeiten]Das ist doch kein Angriff auf den ECDSA-Algorithmus, sondern auf eine spezifische Implementierung, oder? Dann wuerde das hier nicht hinpassen. Gibts einen Artikel "Liste von Kryptofails"? :)
--37.48.65.71 Diskussion:Elliptic Curve Cryptography#c-37.48.65.71-2015-01-28T20:29:00.000Z-Seitenkanalangriffe11
- seitenkanalangriffe sind immer angriffe auf eine spezifische implementierung. da es sich hier um openssl handelt, würde ich das schon drinlassen. --Mario d Diskussion:Elliptic Curve Cryptography#c-MarioS-2015-01-29T14:46:00.000Z-37.48.65.71-2015-01-28T20:29:00.000Z11
Tabellen zusammen fassen?
[Quelltext bearbeiten]Im Abschnitt Elliptic Curve Cryptography#Effizienz und Sicherheit finden sich direkt untereinander 2 Tabellen, deren linke Spalten identisch sind ("Sicherheitsniveau"). Könnte man die Tabellen nicht zu einer zusammen ziehen? Also die rechte Spalte der unteren Tabelle ("Verhältnis bei DH : ECDH") mit in die obere Tabelle rein bauen? --79.236.136.13 Diskussion:Elliptic Curve Cryptography#c-79.236.136.13-20221113053900-Tabellen zusammen fassen?11
In der deutscher Sprache sollte der deutsche Begriff zuerst genannt werden.
[Quelltext bearbeiten]Ich habe den ersten Absatz entsprechend geändert. --Franz Scheerer aus Wiesbaden (Diskussion) Diskussion:Elliptic Curve Cryptography#c-Franz Scheerer aus Wiesbaden-20230214105700-In der deutscher Sprache sollte der deutsche Begriff zuerst genannt werden.11
- Der deutsche Begriff, die englische Übersetzung und dann die Abkürzung, die sich aus der englischen Version ableitet. So ist es am einfachsten zu verstehen, glaube ich. --Franz Scheerer aus Wiesbaden (Diskussion) Diskussion:Elliptic Curve Cryptography#c-Franz Scheerer aus Wiesbaden-20230214110000-Franz Scheerer aus Wiesbaden-2023021410570011