Diskussion:Elliptic Curve Cryptography

Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 4. April 2019 um 12:42 Uhr durch 109.90.225.208 (Diskussion) (Die nächste Herausforderung - the next challenge). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Letzter Kommentar: vor 6 Jahren von 109.90.225.208 in Abschnitt Die nächste Herausforderung - the next challenge

521 oder 512?

521 ist richtig. einfach beim dort verlinkten EN nachschauen. diesen hinweis bitte stehenlassen, der fehler wird oft gemacht (s. versionsgeschichte)--Mario d 10:51, 20. Okt. 2011 (CEST)Beantworten

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 18:53, 8. Jun. 2012 (CEST)Beantworten

Nachteil

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 10:30, 23. Apr. 2008 (CEST)Beantworten

Ist das Noch drin? 89.27.199.75 04:31, 26. Mär. 2009 (CET)Beantworten

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 10:40, 30. Apr. 2010 (CEST)Beantworten

zur implementierung: wie man's "nicht" macht siehe beispiel PlayStation_3#Software :) --Majx 23:39, 29. Jul. 2011 (CEST)Beantworten

ElGamal?

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 09:39, 11. Dez. 2008 (CET)Beantworten

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 15:21, 11. Aug. 2010 (CEST)Beantworten
logisch ist elGamal einfach eine zeitlich entzerrte DH-Schlüsselvereinbarung. Deshalb finde ich den Verweis hier ganz ok --micha137c 22:10, 28. Apr. 2011 (CEST)Beantworten

Elliptische-Kurven-Kryptografie

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 11:53, 31. Dez. 2010 (CET)Beantworten

Ich würde das unterstüzen. Der deutsche Begriff ist durchaus geläufig. --Mojo1442 16:19, 24. Jul. 2011 (CEST)Beantworten

bin für beibehaltung des englischen ausdrucks da dieser geläufiger ist und die recherche erleichtert --Majx 23:41, 29. Jul. 2011 (CEST)Beantworten

wie wird es in der einschlaegigen deutschsprachigen literatur benannt? --Mario d 22:10, 30. Jul. 2011 (CEST)Beantworten
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) 22:13, 23. Feb. 2013 (CET)Beantworten
"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 12:01, 24. Feb. 2013 (CET)Beantworten
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) 16:37, 24. Feb. 2013 (CET)Beantworten
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 16:47, 25. Feb. 2013 (CET)Beantworten

Schreibfehler, oder gewollt?

"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) 09:33, 21. Jun. 2011 (CEST)) Beantworten

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 12:52, 21. Jun. 2011 (CEST)Beantworten

"Aus diesem Grund sind Kryptosysteme, die auf elliptischen Kurven beruhen, langsamer." <- ?

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 17:44, 30. Jun. 2011 (CEST)Beantworten

Die Aussage ist in der Regel nicht richig. Ich habe das korrigiert.--Mojo1442 19:44, 24. Jul. 2011 (CEST)Beantworten

Vergleich der Verschlüsselungsstärken

die NIST-tabelle sorgt immer wieder fuer verwirrung, weil NIST eine 521-bit kurve standardisiert hat:

Vergleich der Verschlüsselungsstärken[1]
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:

Vergleich der Verschlüsselungsstärken[2]
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:

Vergleich der Verschlüsselungsstärken[1][2]
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 12:03, 10. Jun. 2012 (CEST)Beantworten

  1. a b The Case for Elliptic Curve Cryptography. 15. Januar 2009, abgerufen am 3. November 2011 (englisch).
  2. 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]).
  3. NIST hat nur eine 521-bit Kurve standardisiert und gibt daher als äquivalentes Sicherheitsniveau 521 bit an.

Unsicherer als RSA?

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) 21:52, 6. Sep. 2013 (CEST)Beantworten

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 14:32, 7. Sep. 2013 (CEST)Beantworten
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 kürzeren Scvhlüsselraum und deshalb mit Brute Force-Angriff 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 15:55, 7. Sep. 2013 (CEST)Beantworten
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 20:30, 7. Sep. 2013 (CEST)Beantworten

Seitenkanalangriffe

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 21:29, 28. Jan. 2015 (CET)Beantworten

seitenkanalangriffe sind immer angriffe auf eine spezifische implementierung. da es sich hier um openssl handelt, würde ich das schon drinlassen. --Mario d 15:46, 29. Jan. 2015 (CET)Beantworten

GiftBot (Diskussion) 08:16, 3. Dez. 2015 (CET)Beantworten

4.9.18, 10:00, Ich habe 2 defekte Weblinks korrigiert. In dem Fall "Freie Implementation des „Elliptic Curve DSA“ für Windows und Linux, Download und Anleitung(englisch)" ist die angegebene Seite zu einer eigenen Domain migriert und die ursprüngliche hochschulbasierte(meine Hochschule) Seite ist bis auf weiteres nicht erreichbar. Auch falls die ursprüngliche Hochschulwebseite wieder erreichbar sein sollte(wir arbeiten dran), ist das neue Link aus meiner Sicht die bessere Wahl.

In dem Fall ECC-Arbeitsgruppe, Domainparameter kenne ich die Interna bezüglich der ursprünglichen Webseite, die nicht mehr erreichbar ist, nicht, habe aber eine einigermaßen permanent aussehende Stelle gefunden, die das exakt gleiche Dokument zeigt. Die ursprüngliche Seite ist schon seit mindestens einigen Tagen nicht erreichbar und ich vermute, dass das auch so bleiben wird. Die neu verlinkte Seite der Teletrust wirkt so, als wäre eine gewisse Permanenz zu erwarten. Es gibt andere Links zu den gleichen Inhalten, z.B. https://tools.ietf.org/html/rfc5639, die neuer sind und vielleicht noch seriöser wirken. Das Dokument dort ist aber ein anderes, nicht so schön gesetzt und deshalb weniger gut lesbar. Ich wollte gegenüber der ursprünglichen Form inhaltlich möglichst wenige Änderungen vornehmen.

Außerdem habe ich beide Links auf https umgestellt.

7.9. 7:00 Hallo, kann mal bitte jemand sich um die Prüfung und die Freischaltung der Reparaturen kümmern? Die vermeintliche ECC-Brainpool Seite ist schon länger anscheinend durch eine kommerzielle Werbungsseite gekapert. Das zweite kaputte Link zum Programm zeigt einfach nur auf eine 404 der Hochschuldomäne. Meine Änderung ist wirklich nur eine ganz defensive Reparatur.

Vereinfachte kubische Kurven

Tatsächlich ist alles ganz einfach, unfassbar einfach. Die Terme ax und b werden überhaupt nicht benötigt, wir können sie einfach weglassen.

 

Die Zahl der Punkte auf der Kurve inklusive dem Punkt im Unendlichen ist dann exakt gleich der Primzahl p. Damit können keine kurzen Perioden auftreten, die Punktfolge auf der Kurve

 

wiederholt sich erst nach p Addtionen. Dabei ist

 

Bei einer Bitlänge von 120 ist nach heutigem Stand der sogenannte diskrete Logarithmus bereits nicht mehr berechenbar. Jede Primzahl hinreichender Größe ist geeignet. Es gibt unendlich viele Primzahlen und es ist überhaupt nicht schwierig geeignete Primzahlen zu finden. Eindeutig, denn sie sind viel kleiner als beim RSA-Kryptosystem erforderlich.

Zu schön um wahr zu sein - nein es stimmt. … oder wer möchte widersprechen? --109.90.225.208 11:46, 22. Mär. 2019 (CET)Beantworten

Bei den vereinfachten Kurven (a = b = 0) können verschiedene Punkte benannt werden (1,1), (4,8) und (9,27), die unabhängig von der Wahl der Primzahl p auf der Kurve liegen und als Startpunkt dienen können.

Implementierung einer vereinfachten Kurve in Python

import sys, math, hashlib
def writeNumber(number, fnam):
 f = open(fnam, 'wb')
 n = number
 while n > 0:
   byte = n % 256
   n = n / 256
   f.write(chr(byte))
 f.close()

def readNumber(fnam):
 f = open(fnam, 'rb')
 txt = f.read()
 f.close()
 number = 0 
 for c in reversed(txt):
   number = (number << 8) + ord(c)
 return number

# VERIFY SCHNORR
prime = 2**127 - 1
def h(x):
 dx = hashlib.sha256(x).digest()
 res = 0
 for cx in dx:
   res = (res<<8) ^ ord(cx)
 return res % prime
def addP(P,Q):
 x1 = P[0]
 x2 = Q[0]
 y1 = P[1] 
 y2 = Q[1] 
 if x1 == x2:
    s = (3*(x1**2) * pow(2*y1, prime-2, prime)) % prime
 else:
    s = ((y1-y2) * pow(x1-x2, prime-2, prime)) % prime
 xr = s**2 - x1 - x2
 yr = s * (x1-xr) - y1 
 return [xr % prime, yr % prime]
def mulP(P,n):
 isFirst = True
 resP = P
 PP = resP
 while n > 0:
    if (n & 1) != 0:   
        if isFirst:
           resP = PP
           isFirst = False
        else:
           resP = addP(resP,PP)
    PP = addP(PP, PP)
    n = n >> 1 
 return resP
P = [1,1]
f = open(sys.argv[1],'r')
message = f.read()
f.close()


sig = [readNumber('s0'), readNumber('s1')]
y = [readNumber('y0'), readNumber('y1')]
print "test Schnoor ", h(str(addP(mulP(P,sig[0]),mulP(y,sig[1]))[0]) + 
message) == sig[1]

--Scheerer Software (Wiesbaden) (Diskussion) 20:21, 22. Mär. 2019 (CET) --Scheerer Software (Wiesbaden) (Diskussion) 20:34, 22. Mär. 2019 (CET)Beantworten

y^2 = x^3 mod p mit p = 2^127 - 1

Der Punkt [1,1] multipliziert mit fx ergibt den Punkt

[21353994076912748866010120212563195911L, 
146971301775098436526143901479083352829L]

Die Herausforderung: Finde fx.

Der Punkt wurde so berechnet:

print mulP([1,1],randomX('fdjskfdkfjkl'))

Die Funktion randomX() liefert eine Zufallszahl und wurde natürlich modifiziert. Sie kann nicht im Internet mit Google gefunden werden.

Es ist, theoretisch zumindest, möglich den fx Wert zu finden:

https://ecc-challenge.info/

Hmmmmmm - aber wie sollten wir das knacken? Bei zufälligem fx haben wir auch rein zufällig einen Punkt auf der Kurve

 

ausgewählt, einen aus einer gigantischen Anzahl, hier etwa zwei hoch 127, die auf der Kurve liegen.

Wie sollten wir jetzt daraus fx berechnen? Wir müssen auf eine zufällige Übereinstimmung hoffen.

Wir können die beiden Punkte [1,1] und


[21353994076912748866010120212563195911L, 
146971301775098436526143901479083352829L]

jeweils mit Zufallszahlen multiplizieren. Wenn die Ergebnisse übereinstimmen, können wir daraus unser fx berechnen.

Aber dies erfordert eine gigantische Anzahl an Berechnungen, bis wir zu einer zufälligen Übereinstimmung gelangen. Bei noch größeren Primzahlen,  , ist das praktisch vollkommen unmöglich.


--Scheerer Software (Wiesbaden) (Diskussion) 17:39, 25. Mär. 2019 (CET)Beantworten

Ich habe es überprüft, der Punkt liegt auf der Kurve.

Python 2.7.14rc1 (default, Sep  5 2017, 18:16:23) 
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> y= 146971301775098436526143901479083352829L
>>> x= 21353994076912748866010120212563195911L
>>> (y*y - x*x*x) % (2**127 - 1)
0L

--109.90.225.208 22:26, 30. Mär. 2019 (CET)Beantworten

Genau - wir könnten, theoretisch, die Primzahl von Certicom/Bitcoin übernehmen

Bitcoin verwendet eine berühmte Kurve secp256k1. Die Primzahl p darin könnten wir übernehmen, auch wenn wir eine vereinfachte Kurve mit a und b gleich null verwenden. Die Additionsformeln zur Berechnung einer Punktsumme, aus zwei Punkten, bleibt dann vollkommen identisch, da der Parameter b dort gar nicht auftriff, weil die Tangentensteigung von diesem Parameter nicht abhängig ist. Der Parameter a ist ebenfalls null. Ist auch die Primzahl identisch, ist die Rechenvorschrift für die Punktsumme tatsächlich exakt identisch zur berühmten Kurve secp256k1.

Klar, wäre das sicher, wenn Secp256k1 sicher wäre. Die Zykluslänge ist nämlich nahezu (nicht ganz exakt) unverändert.

Noch besser, niemand, außer dem Prüfer kennt überhaupt die Kurve. Der Hacker, der die Kurve nicht kennt, kann auch nichts knacken. Alles was zählt ist der Paramenter n mit der sich die Punktfolge wiederholt. Ist der 2^160 oder größer, kann der ECDLP nicht berechnet werden - Punkt aus.

--Scheerer Software (Wiesbaden) (Diskussion) 10:12, 27. Mär. 2019 (CET)Beantworten

Das Bitcoin-Netzwerk basiert auf einer von den Teilnehmern gemeinsam verwalteten dezentralen Datenbank (der Blockchain), in der alle Transaktionen verzeichnet sind.

Ok, eine dezentrale Datenbank. --Scheerer Software (Wiesbaden) (Diskussion) 10:19, 27. Mär. 2019 (CET)Beantworten

Noch allgemeiner, eine Datenbank, mit digital unterschriebenen Verträgen oder Aufrägen.

https://twitter.com/eccchallenge?lang=en

Uuuuups - 2011 - das ist ja schon eine Weile her. Da scheint doch etwas nicht zu stimmen?

Die Challenge sollte doch längst schon geknackt sein, was ist da los? --109.90.225.208 12:04, 31. Mär. 2019 (CEST)Beantworten

Oh Gott, wie ist das nur möglich?

>>> P=[100,1000]
>>> mulP(P,10)
[1L, 1L]
>>> P=[pow(10,200,prime),pow(10,300,prime)]
>>> mulP(P,pow(10,100,prime))
[1L, 1L]

... damit is das ja tatsächlich quasi identisch, zu dem ursprünglichen Diffie-Hellman mit der Multiplikation von Zahlen modulo Primzahl.

Ja, damit ist das DLP quasi schon gelöst, für Primzahlen bis 768 Bits.

Ja, schon wieder habe ich meine eigene Challenge geknackt.

--109.90.225.208 16:32, 31. Mär. 2019 (CEST)Beantworten

Klar, wir müssen nur den Exponenten von der x-Koordinate finden und das ist möglich bis zu etwa 768 Bits.

Die nächste Herausforderung - the next challenge

Ich probiere es jetzt einmal mit a = -3 wie bei secp256r1, die berühmte Kurve von NIST/NSA.

y^2 = x^3 - 3x mod p,
p =  168072688293053835593423755762372547260432242528667
P = [130856624321058429921182615641720983765315821325564L, 
     8973046713210233695102642652101362050129444123170L]
fx P = [100376914504676782572605608924439065076465539147024L, 
        91224746372904699712316600954303309024769482701807L]
Challenge: Find fx

Die Primzahl 115*(2^160) + 86427 ist etwas kleiner, das hilft aber nicht weiter. Die Primzahl p und der Punkt P wurden so gewählt, dass (p+1)/4 wieder eine Primzahl ist und die Periode mit der sich die Punktfolge

P, 2P, 3P, 4P. ...

wiederholt, genau gleich der großen Primzahl (p+1)/4 ist.

Wer die Aufgabe richtig löst gewinnt 100 Euro. Nur der erste Einsender gewinnt, es gilt das Datum des Poststempels. Der Rechtsweg ist ausgeschlossen.

--109.90.225.208 11:48, 4. Apr. 2019 (CEST)Beantworten