DHKE Mehrfachverwendung der öffentlichen Parameter

D

Darkslide

0
Hallo,

ich bin dabei in einem Programm einen DHKE zu implementieren. Laut

http://tools.ietf.org/html/rfc2412#page-46

sind ja für p, g empfohlene Primzahlen:

Code: 
p=179769313486231590770839156793787453197860296048756011706444
423684197180216158519368947833795864925541502180565485980503
646440548199239100050792877003355816639229553136239076508735
759914822574862575007425302077447712589550957937778424442426
617334727629299387668709205606050270810842907692932019128194
467627007

g=22

Ist es unsicher wenn diese öffentlichen Parameter fest ins Programm
integriert und dann öfters verwendet werden?Die geheimen Parameter
a, b würde ich dann per Zufallszahlen erzeugen.
 
welche vorteile kann ein angreifer aus der festen primzahl und dem festen generator ziehen?

er könnte eine art dictionary oder rainbowtable aufbauen ...

sofern g ein guter generator in p ist (ich geh mal davon aus das du fehlerfrei copypasta machen kannst), sollte daraus kein nennenswerter nachteil entstehen

es schadet aber auch nicht wenn du dir ne andere große primzahl und einen entsprechenden generator nimmst, falls du befürchtest, dass gerade zu diesen zahlen dictionaries existieren ... je nach grad der paranoia
 
Hallo,
der Generator ist g=2 und nicht 22 laut dem RFC.

Siehe dazu Seite 45:
Using 2 as a generator is efficient for some modular
exponentiation algorithms. [Note that 2 is technically not a
generator in the number theory sense, because it omits half of the
possible residues mod P. From a cryptographic viewpoint, this is a
virtue.]
Zum Vergrößern anklicken....

Die 22 gibt soweit ich das erkennen kann nur die Bezeichnung des Feldes im Protokoll an, wo der Wert für den Generator steht.


Ansonsten sollte es keine wirklich relevanten Nachteile geben, eine feste Primzahl und einen festen Generator zu verwenden. Dies hat den Vorteil, dass man sich keine Sorgen machen muss dass man Fehler bei der Erzeugung dieser Zahlen macht und diese Zahlen sind besonders effizient für die Berechnung von Diffie-Hellman.
 
mit dem besagten nachteil, dass 2 halt KEIN generator ist (die von 2 aufgespannte gruppe ist kleiner als maximal möglich)
 
GrafZahl hat gesagt.:
mit dem besagten nachteil, dass 2 halt KEIN generator ist (die von 2 aufgespannte gruppe ist kleiner als maximal möglich)
Zum Vergrößern anklicken....
Das ist richtig. Die 2 erzeugt eine (echte) Untergruppe, die nur die Hälfte der Größe besitzt.

Dies ist aber weiter nicht relevant. Man hat zwar eine 1024 Bit Primzahl, aber nur die ungefähre Sicherheit von einer 1023 Bit Primzahl mit echtem Generator.

Echte Generatoren für die 1024 Bit Primzahl wären z.B. 5, 11 oder auch 22 (laut Maple).

Wenn g=2 aber bessere Performance bringt, sollte man diese auch verwenden. Das 1 Bit weniger Sicherheit macht keinen großen Unterschied und ist in dem RFC auch bedacht.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben