Zum Hauptinhalt springen

RFC 6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) (Deterministische Verwendung des Digital Signature Algorithm (DSA) und Elliptic Curve Digital Signature Algorithm (ECDSA))

  • Status: Informational
  • Veröffentlicht: August 2013
  • Stream: INDEPENDENT
  • Errata: Keine Errata

Abstract (Zusammenfassung)​

Dieses Dokument definiert ein deterministisches Verfahren zur Erzeugung digitaler Signaturen. Solche Signaturen sind kompatibel mit standardmäßigen Digital Signature Algorithm (DSA)- und Elliptic Curve Digital Signature Algorithm (ECDSA)-Signaturen und können mit unveränderten Verifikatoren verarbeitet werden, die das hierin beschriebene Verfahren nicht kennen müssen. Deterministische Signaturen behalten die kryptografischen Sicherheitsmerkmale bei, die mit digitalen Signaturen verbunden sind, können aber in verschiedenen Umgebungen einfacher implementiert werden, da sie keinen Zugriff auf eine Quelle hochwertiger Zufälligkeit benötigen.

Status of This Memo (Status dieses Dokuments)​

Dieses Dokument ist keine Internet Standards Track-Spezifikation, es wird zu Informationszwecken veröffentlicht.

Dies ist ein Beitrag zur RFC-Serie, unabhängig von jedem anderen RFC-Stream. Der RFC-Editor hat beschlossen, dieses Dokument nach eigenem Ermessen zu veröffentlichen und macht keine Aussage über seinen Wert für die Implementierung oder Bereitstellung. Von dem RFC-Editor zur Veröffentlichung genehmigte Dokumente sind keine Kandidaten für irgendeine Stufe eines Internet-Standards, siehe Abschnitt 2 von RFC 5741.

Informationen über den aktuellen Status dieses Dokuments, eventuelle Errata und wie man Feedback dazu geben kann, können unter http://www.rfc-editor.org/info/rfc6979 abgerufen werden.

Copyright (c) 2013 IETF Trust und die als Dokumentautoren identifizierten Personen. Alle Rechte vorbehalten.

Dieses Dokument unterliegt BCP 78 und den rechtlichen Bestimmungen des IETF Trust in Bezug auf IETF-Dokumente (http://trustee.ietf.org/license-info), die zum Zeitpunkt der Veröffentlichung dieses Dokuments in Kraft sind. Bitte lesen Sie diese Dokumente sorgfältig durch, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben.

Contents​

1. Introduction (Einführung)​

DSA [FIPS-186-4] und ECDSA [X9.62] sind zwei standardmäßige digitale Signaturverfahren. Sie bieten Datenintegrität und verifizierbare Authentizität in verschiedenen Protokollen.

Eine Eigenschaft von DSA und ECDSA ist, dass sie für jede Signaturerzeugung einen frischen Zufallswert erzeugen müssen (im Folgenden als k bezeichnet). Für effektive Sicherheit muss k zufällig und gleichmäßig aus einer Menge modularer Ganzzahlen ausgewählt werden, unter Verwendung eines kryptografisch sicheren Prozesses. Selbst geringfügige Verzerrungen in diesem Prozess können in Angriffe auf die Signaturverfahren umgewandelt werden.

Die Notwendigkeit einer kryptografisch sicheren Zufallsquelle erweist sich als Hindernis für die Bereitstellung von DSA- und ECDSA-Signaturverfahren in einigen Architekturen, in denen die sichere Zufallszahlengenerierung eine Herausforderung darstellt, insbesondere in eingebetteten Systemen wie Smartcards. In diesen Systemen wird der RSA-Signaturalgorithmus, wie in Public-Key Cryptography Standards (PKCS) #1 [RFC3447] spezifiziert (mit "type 1" Padding, nicht dem Probabilistic Signature Scheme (PSS)) und ISO 9796-2 [ISO-9796-2], oft bevorzugt, obwohl er rechnerisch aufwendiger ist, da RSA (mit solchen Padding-Schemata) deterministisch ist und daher keine Zufallsquelle erfordert.

Die randomisierte Natur von DSA und ECDSA macht Implementierungen auch schwieriger zu testen. Automatische Tests können nicht zuverlässig erkennen, ob die Implementierung eine Zufallsquelle von ausreichend hoher Qualität verwendet. Dies macht den Implementierungsprozess anfälliger für katastrophale Fehler, die oft erst entdeckt werden, nachdem das System bereitgestellt und erfolgreich angegriffen wurde.

Es ist möglich, DSA und ECDSA in deterministische Verfahren umzuwandeln, indem ein deterministischer Prozess zur Erzeugung des "zufälligen" Wertes k verwendet wird. Dieser Prozess muss einige kryptografische Eigenschaften erfüllen, um die Eigenschaften der Verifizierbarkeit und Unfälschbarkeit beizubehalten, die von Signaturverfahren erwartet werden, nämlich: Für jeden, der den privaten Signaturschlüssel nicht kennt, muss die Abbildung von Eingabenachrichten auf die entsprechenden k-Werte rechnerisch nicht unterscheidbar sein von dem, was eine zufällig und gleichmäßig gewählte Funktion (von der Menge der Nachrichten zur Menge der möglichen k-Werte) zurückgeben würde.

Dieses Dokument beschreibt ein solches Verfahren. Es hat die folgenden Eigenschaften:

  • Erzeugte Signaturen bleiben vollständig kompatibel mit einfachem DSA und ECDSA. Entitäten, die die Signaturen verifizieren, müssen nicht geändert werden oder nicht einmal über den zur Erzeugung von k verwendeten Prozess informiert sein.

  • Die Schlüsselpaarerzeugung wird nicht verändert. Bestehende private Schlüssel können mit deterministischem DSA und ECDSA verwendet werden.

  • Die Verwendung von deterministischem DSA und ECDSA impliziert keine zusätzliche Speicheranforderung für geheime oder öffentliche Werte.

  • Deterministisches DSA und ECDSA können auf die gleichen Eingaben wie einfaches DSA und ECDSA angewendet werden, nämlich einen Hash-Wert, der über die zu signierende Nachricht berechnet wird, mit einer kryptografisch sicheren Hash-Funktion.

Einige relativ willkürliche Entscheidungen wurden bei der Definition von deterministischem (EC)DSA, wie in diesem Dokument spezifiziert, getroffen, dies wurde getan, um es so universell anwendbar wie möglich zu machen und so die Nützlichkeit der enthaltenen Testvektoren zu maximieren. Siehe Abschnitt 3.6 für eine Diskussion einiger möglicher Varianten.

Es ist zu beachten, dass die Schlüsselpaarerzeugung immer noch eine Zufallsquelle erfordert. In eingebetteten Systemen, in denen die Qualität der Zufälligkeit ein Problem ist, kann oft arrangiert werden, dass die Schlüsselpaarerzeugung unter kontrollierteren Bedingungen erfolgt (z.B. während eines speziellen Smartcard-Initialisierungsverfahrens oder unter physischer Kontrolle vereidigter Agenten) oder der Schlüssel könnte sogar anderswo erzeugt und in das Gerät importiert werden. Deterministisches DSA und ECDSA befassen sich nur mit der Notwendigkeit der Zufälligkeit zum Zeitpunkt der Signaturerzeugung.

1.1. Requirements Language (Anforderungssprache)​

Die Schlüsselwörter "MUST" (MUSS), "MUST NOT" (DARF NICHT), "REQUIRED" (ERFORDERLICH), "SHALL" (SOLL), "SHALL NOT" (SOLL NICHT), "SHOULD" (SOLLTE), "SHOULD NOT" (SOLLTE NICHT), "RECOMMENDED" (EMPFOHLEN), "MAY" (KANN) und "OPTIONAL" (OPTIONAL) in diesem Dokument sind zu interpretieren wie in RFC 2119 [RFC2119] beschrieben.

2. DSA and ECDSA Notations (DSA- und ECDSA-Notationen)​

In diesem Abschnitt beschreiben wir kurz DSA und ECDSA und definieren unsere Notationen. Die vollständigen Spezifikationen für DSA und ECDSA können in [FIPS-186-4] bzw. [X9.62] gefunden werden.

2.1. Key Parameters (Schlüsselparameter)​

DSA und ECDSA arbeiten über einer großen Gruppe von Primzahlgröße, in der die Gruppenoperation einfach zu berechnen ist, aber der diskrete Logarithmus mit existierender und absehbarer Technologie rechnerisch nicht durchführbar ist. Die Definition der Gruppe wird als "Schlüsselparameter" bezeichnet. Schlüsselparameter können zwischen verschiedenen Schlüsselpaaren ohne negative Auswirkungen auf die Sicherheit geteilt werden, dies ist insbesondere bei ECDSA der übliche Fall.

DSA verwendet die folgenden Schlüsselparameter:

p - eine große Primzahl (mindestens 1024 Bits)

q - eine ausreichend große Primzahl (mindestens 160 Bits), die auch ein Teiler von p-1 ist

g - ein Generator für die multiplikative Untergruppe der Ordnung q von Ganzzahlen modulo p

Die Gruppe, über der DSA berechnet wird, besteht aus den Werten 'g^j mod p', wobei '^' Potenzierung bezeichnet und j von 0 bis q-1 (einschließlich) reicht. Die Größe der Gruppe ist q.

ECDSA verwendet die folgenden Schlüsselparameter:

E - eine elliptische Kurve, definiert über einem gegebenen endlichen Körper

q - eine ausreichend große Primzahl (mindestens 160 Bits), die ein Teiler der Kurvenordnung ist

G - ein Punkt von E mit der Ordnung q

Die Gruppe, über der ECDSA berechnet wird, besteht aus den Kurvenpunkten jG (Multiplikation des Punktes G mit der Ganzzahl j), wobei j von 0 bis q-1 reicht. G ist so, dass qG = 0 (der "Punkt im Unendlichen" auf der Kurve E). Die Größe der Gruppe ist q. Beachten Sie, dass diese Notationen sich geringfügig von denen in [X9.62] unterscheiden, wir verwenden sie, um mit denen für DSA übereinzustimmen.

2.2. Key Pairs (Schlüsselpaare)​

Ein DSA- oder ECDSA-privater Schlüssel ist eine Ganzzahl x modulo q. Die relevanten Standards schreiben vor, dass x nicht 0 sein soll, daher ist x eine Ganzzahl im Bereich [1, q-1].

Ein DSA- oder ECDSA-öffentlicher Schlüssel wird aus dem privaten Schlüssel x und den Schlüsselparametern berechnet:

  • Für DSA ist der öffentliche Schlüssel die Ganzzahl: y = g^x mod p

  • Für ECDSA ist der öffentliche Schlüssel der Kurvenpunkt: U = xG

2.3. Integer Conversions (Ganzzahlkonvertierungen)​

Sei qlen die binäre Länge von q. qlen ist die kleinste Ganzzahl, sodass q kleiner als 2^qlen ist. Dies ist die Größe der binären Darstellung von q ohne ein Vorzeichenbit (beachten Sie, dass q, da es eine große Primzahl ist, ungerade ist und somit jede Mehrdeutigkeit über die Länge einer Ganzzahl gleich einer Potenz von 2 vermieden wird). Wir definieren fünf Konvertierungsfunktionen, die mit Zeichenfolgen von Bits, Oktetten und Ganzzahlen modulo q arbeiten. qlen ist der Hauptparameter für diese Konvertierungen.

In den folgenden Unterabschnitten verwenden wir zwei andere Längen, genannt blen und rlen. rlen ist gleich qlen, aufgerundet auf das nächste Vielfache von 8 (wenn qlen bereits ein Vielfaches von 8 ist, dann ist rlen gleich qlen, andernfalls ist rlen etwas größer, bis zu qlen+7). Beachten Sie, dass rlen nicht mit dem Wert r zusammenhängt, der ersten Hälfte einer erzeugten Signatur. blen ist die Länge (in Bits) einer Eingabesequenz von Bits und kann zwischen Aufrufen variieren. blen kann kleiner, gleich oder größer als qlen sein.

2.3.1. Bits and Octets (Bits und Oktette)​

Formal sind alle Operationen auf Sequenzen von Bits definiert. Eine Sequenz ist geordnet, das erste Bit wird als das am weitesten links stehende bezeichnet, während das letzte Bit das am weitesten rechts stehende ist.

Auf den meisten Softwaresystemen werden Bits in Oktetten (Sequenzen von acht Bits) gruppiert. Binärdaten, z.B. die Ausgabe einer Hash-Funktion, sind als eine Sequenz von Oktetten verfügbar. Wo anwendbar, betrachten wir, dass Bits innerhalb eines Oktetts vom höchstwertigen zum niedrigstwertigen geordnet sind: Das erste (am weitesten links stehende) Bit innerhalb eines Oktetts hat den numerischen Wert 128, während das letzte (am weitesten rechts stehende) den numerischen Wert 1 hat.

2.3.2. Bit String to Integer (Bit-Zeichenfolge zu Ganzzahl)​

Die bits2int-Transformation nimmt als Eingabe eine Sequenz von blen Bits und gibt eine nicht-negative Ganzzahl aus, die kleiner als 2^qlen ist. Sie besteht aus den folgenden Schritten:

  1. Die Sequenz wird zuerst auf die Länge qlen gekürzt oder erweitert:

    • wenn qlen < blen, dann werden die qlen am weitesten links stehenden Bits behalten und nachfolgende Bits werden verworfen;

    • andernfalls werden qlen-blen Bits (mit dem Wert null) links von der Sequenz hinzugefügt (d.h. vor den Eingabebits in der Sequenzordnung).

  2. Die resultierende Sequenz wird dann unter Verwendung der Big-Endian-Konvention in einen Ganzzahlwert konvertiert: Wenn die Eingabebits b_0 (am weitesten links) bis b_(qlen-1) (am weitesten rechts) genannt werden, dann ist der resultierende Wert:

    b_0*2^(qlen-1) + b_1*2^(qlen-2) + ... + b_(qlen-1)*2^0

Die bits2int-Transformation kann auch auf folgende Weise beschrieben werden: Die Eingabebitsequenz (der Länge blen) wird unter Verwendung der Big-Endian-Konvention in eine Ganzzahl transformiert. Wenn dann blen größer als qlen ist, wird die resultierende Ganzzahl durch zwei hoch blen-qlen geteilt (Euklidische Division: Der Rest wird verworfen). In vielen Softwareimplementierungen der Arithmetik für große Ganzzahlen entspricht diese Division einem "Rechtsshift" um blen-qlen Bits.

2.3.3. Integer to Octet String (Ganzzahl zu Oktett-Zeichenfolge)​

Ein Ganzzahlwert x kleiner als q (und insbesondere ein Wert, der modulo q genommen wurde) kann in eine Sequenz von rlen Bits konvertiert werden, wobei rlen = 8*ceil(qlen/8). Dies ist die Sequenz von Bits, die durch Big-Endian-Kodierung erhalten wird. Mit anderen Worten, die Sequenzbits x_i (für i im Bereich von 0 bis rlen-1) sind so, dass:

x = x_0*2^(rlen-1) + x_1*2^(rlen-2) + ... + x_(rlen-1)

Wir nennen diese Transformation int2octets. Da rlen ein Vielfaches von 8 ist (das kleinste Vielfache von 8, das nicht kleiner als qlen ist), ist die resultierende Sequenz von Bits auch eine Sequenz von Oktetten, daher der Name.

2.3.4. Bit String to Octet String (Bit-Zeichenfolge zu Oktett-Zeichenfolge)​

Die bits2octets-Transformation nimmt als Eingabe eine Sequenz von blen Bits und gibt eine Sequenz von rlen Bits aus. Sie besteht aus den folgenden Schritten:

  1. Die Eingabesequenz b wird durch die bits2int-Transformation in einen Ganzzahlwert z1 konvertiert:

    z1 = bits2int(b)

  2. z1 wird modulo q reduziert, was z2 ergibt (eine Ganzzahl zwischen 0 und q-1, einschließlich):

    z2 = z1 mod q

    Beachten Sie, dass diese modulare Reduktion, da z1 kleiner als 2^qlen ist, mit einer einfachen bedingten Subtraktion implementiert werden kann: z2 = z1-q, wenn dieser Wert nicht-negativ ist, andernfalls z2 = z1.

  3. z2 wird durch Anwendung von int2octets in eine Sequenz von Oktetten (eine Sequenz von rlen Bits) transformiert.

2.3.5. Usage (Verwendung)​

Es ist bemerkenswert, dass int2octets nicht die Umkehrung von bits2int ist, da int2octets die Reduktion modulo q einschließt.

2.1. Key Parameters (Schlüsselparameter)​

Für DSA werden die Schlüsselparameter durch eine Gruppe der Primordnung definiert. Die Parameter sind (p, q, g), wobei p eine große Primzahl ist, q ein Primteiler von p-1 ist und g ein Element der multiplikativen Gruppe Z*p der Ordnung q ist.

Für ECDSA werden die Schlüsselparameter durch eine elliptische Kurve und einen Basispunkt G auf dieser Kurve definiert. Die Ordnung von G (Anzahl der Punkte in der durch G erzeugten Untergruppe) ist eine große Primzahl, die mit q bezeichnet wird.

2.2. Key Pairs (Schlüsselpaare)​

Ein (EC)DSA-Schlüsselpaar besteht aus einem privaten Schlüssel x und einem öffentlichen Schlüssel. Der private Schlüssel ist eine ganze Zahl im Bereich [1, q-1]. Bei DSA ist der öffentliche Schlüssel y = g^x mod p. Bei ECDSA ist der öffentliche Schlüssel Q = xG (Skalarprodukt des Basispunkts G mit dem privaten Schlüssel x).

2.3. Integer Conversions (Integer-Konvertierungen)​

Wir benötigen Funktionen zur Konvertierung zwischen ganzen Zahlen, Bit-Sequenzen und Oktett-Sequenzen. Diese Konvertierungen sind essentiell für die Implementierung des deterministischen k-Generierungsalgorithmus.

2.3.1. Bits and Octets (Bits und Oktette)​

2.3.2. Bit String to Integer (Bit-String zu Integer)​

2.3.3. Integer to Octet String (Integer zu Oktett-String)​

2.3.4. Bit String to Octet String (Bit-String zu Oktett-String)​

2.3.5. Usage (Verwendung)​

2.3.1. Bits and Octets (Bits und Oktette)​

Eine Bit-Sequenz ist eine geordnete Folge von Bits. Bit-Sequenzen werden von links nach rechts nummeriert, beginnend mit Bit 0. Beispielsweise ist in der 8-Bit-Sequenz "10110001" Bit 0 gleich 1, Bit 1 gleich 0, Bit 2 gleich 1, und so weiter.

Ein Oktett ist eine Sequenz von 8 Bits. Eine Oktett-Sequenz ist eine geordnete Folge von Oktetten, beginnend mit Oktett 0 und aufsteigend. In einer Oktett-Sequenz bezeichnet "Oktett 0" das ganz linke (erste) Oktett.

2.3.2. Bit String to Integer (Bit-String zu Integer)​

Die Funktion bits2int transformiert eine Bit-Sequenz in eine ganze Zahl. Sie wird wie folgt definiert:

Die Sequenz ist zunächst auf die qlen linkesten Bits gekürzt (wenn die Sequenz länger als qlen Bits ist) oder unverändert gelassen (wenn ihre Länge bereits höchstens qlen Bits beträgt). Die Sequenz wird dann als Big-Endian-Darstellung einer ganzen Zahl interpretiert.

2.3.4. Bit String to Octet String (Bit-String zu Oktett-String)​

Die Funktion bits2octets transformiert eine Bit-Sequenz in eine Oktett-Sequenz und reduziert sie gleichzeitig modulo q. Sie wird wie folgt definiert:

bits2octets(b1) = int2octets(bits2int(b1) mod q)

Diese Funktion wird verwendet, um die gehashte Nachricht vor der Signaturberechnung zu verarbeiten.

2.3.5. Usage (Verwendung)​

Die oben definierten Konvertierungsfunktionen werden im deterministischen k-Generierungsalgorithmus verwendet, um sicherzustellen, dass:

  • Der private Schlüssel x korrekt in eine Oktett-Sequenz kodiert wird (int2octets)
  • Die gehashte Nachricht H(m) auf die richtige Länge gekürzt oder erweitert wird (bits2octets)
  • Die generierten zufälligen Bits korrekt in den Kandidatenwert k umgewandelt werden (bits2int)

Diese Konvertierungen sind unabhängig von der verwendeten Felddarstellung (Prime Field oder Binary Field) und funktionieren korrekt mit Gruppen beliebiger Ordnung q.

2.4. Signature Generation (Signaturerzeugung)​

Die Signaturerzeugung verwendet eine kryptografische Hash-Funktion H und eine Eingabenachricht m. Die Nachricht wird zuerst von H verarbeitet, was den Wert H(m) ergibt, der eine Sequenz von Bits der Länge hlen ist. Normalerweise wird H so gewählt, dass seine Ausgabelänge hlen ungefähr gleich qlen ist, da die Gesamtsicherheit des Signaturverfahrens von dem kleineren Wert von hlen und qlen abhängt. Die relevanten Standards unterstützen jedoch alle Kombinationen von hlen und qlen.

Die folgenden Schritte werden dann angewendet:

  1. H(m) wird unter Verwendung der bits2int-Transformation und einer zusätzlichen modularen Reduktion in eine Ganzzahl modulo q transformiert:

    h = bits2int(H(m)) mod q

    Wie in der Beschreibung von bits2octets angemerkt wurde, ist die zusätzliche modulare Reduktion nicht mehr als eine bedingte Subtraktion.

  2. Ein Zufallswert modulo q, genannt k, wird erzeugt. Dieser Wert darf nicht 0 sein, daher liegt er im Bereich [1, q-1]. Der größte Teil des Rests dieses Dokuments wird sich um den Prozess drehen, der zur Erzeugung von k verwendet wird. In einfachem DSA oder ECDSA sollte k durch eine Zufallsauswahl ausgewählt werden, die einen Wert unter den q-1 möglichen Werten mit gleichmäßiger Wahrscheinlichkeit wählt.

  3. Ein Wert r (modulo q) wird aus k und den Schlüsselparametern berechnet:

    • Für DSA:

      r = g^k mod p mod q

      (Die Potenzierung wird modulo p durchgeführt, was eine Zahl zwischen 0 und p-1 ergibt, die dann weiter modulo q reduziert wird.)

    • Für ECDSA: Der Punkt kG wird berechnet, seine X-Koordinate (ein Element des Körpers, über dem E definiert ist) wird in eine Ganzzahl konvertiert, die modulo q reduziert wird, was r ergibt.

    Wenn sich r als null herausstellt, sollte ein neues k ausgewählt und r erneut berechnet werden (dies ist ein äußerst unwahrscheinliches Ereignis).

  4. Der Wert s (modulo q) wird berechnet:

    s = (h+x*r)/k mod q

    Das Paar (r, s) ist die Signatur. Wie eine Signatur kodiert werden soll, wird nicht von den DSA- und ECDSA-Standards selbst abgedeckt. Eine übliche Methode ist die Verwendung einer DER-kodierten ASN.1-Struktur (eine SEQUENCE von zwei INTEGERs, für r und s, in dieser Reihenfolge).

3. Deterministic DSA and ECDSA (Deterministisches DSA und ECDSA)​

Deterministisches (EC)DSA ist der Prozess der Erzeugung einer (EC)DSA-Signatur über einer Eingabenachricht m durch Verwendung des standardmäßigen (EC)DSA-Signaturerzeugungsprozesses (diskutiert im vorherigen Abschnitt), außer dass der Wert k, anstatt zufällig erzeugt zu werden, durch den in diesem Abschnitt beschriebenen Prozess erhalten wird.

Wir verwenden die in Abschnitt 2 beschriebenen Notationen.

3.1. Building Blocks (Bausteine)​

3.1.1. HMAC​

HMAC [RFC2104] ist eine Konstruktion eines Message Authentication Code unter Verwendung einer Hash-Funktion und eines geheimen Schlüssels. Hier verwenden wir HMAC mit derselben Hash-Funktion H wie derjenigen, die zur Verarbeitung der Eingabenachricht vor der Signaturerzeugung oder -verifizierung verwendet wird.

Wir bezeichnen den Prozess der Anwendung von HMAC mit Schlüssel K auf Daten V durch:

HMAC_K(V)

was eine Sequenz von Bits der Länge hlen zurückgibt (die Ausgabelänge der zugrunde liegenden Hash-Funktion H).

3.2. Generation of k (Erzeugung von k)​

Bei der Eingabenachricht m wird der folgende Prozess angewendet:

a. Verarbeite m durch die Hash-Funktion H, was ergibt:

h1 = H(m)

(h1 ist eine Sequenz von hlen Bits).

b. Setze:

V = 0x01 0x01 0x01 ... 0x01

sodass die Länge von V in Bits gleich 8*ceil(hlen/8) ist. Zum Beispiel wird auf einem oktetbasierten System, wenn H SHA-256 ist, V auf eine Sequenz von 32 Oktetten mit dem Wert 1 gesetzt. Beachten Sie, dass wir in diesem Schritt und allen folgenden Schritten dieselbe H-Funktion wie die in Schritt 'a' zur Verarbeitung der Eingabenachricht verwendete verwenden. Diese Wahl wird in Abschnitt 3.6 ausführlicher diskutiert.

c. Setze:

K = 0x00 0x00 0x00 ... 0x00

sodass die Länge von K in Bits gleich 8*ceil(hlen/8) ist.

d. Setze:

K = HMAC_K(V || 0x00 || int2octets(x) || bits2octets(h1))

wobei '||' Verkettung bezeichnet. Mit anderen Worten, wir berechnen HMAC mit Schlüssel K über die Verkettung des Folgenden in dieser Reihenfolge: der aktuelle Wert von V, eine Sequenz von acht Bits mit dem Wert 0, die Kodierung des (EC)DSA-privaten Schlüssels x und die gehashte Nachricht (möglicherweise gekürzt und erweitert wie durch die bits2octets-Transformation spezifiziert). Das HMAC-Ergebnis ist der neue Wert von K. Beachten Sie, dass der private Schlüssel x im Bereich [1, q-1] liegt, daher eine korrekte Eingabe für int2octets ist, was rlen Bits Ausgabe ergibt, d.h. eine ganzzahlige Anzahl von Oktetten (rlen ist ein Vielfaches von 8).

e. Setze:

V = HMAC_K(V)

f. Setze:

K = HMAC_K(V || 0x01 || int2octets(x) || bits2octets(h1))

Beachten Sie, dass das "interne Oktett" diesmal 0x01 ist.

g. Setze:

V = HMAC_K(V)

h. Wende den folgenden Algorithmus an, bis ein geeigneter Wert für k gefunden wird:

  1. Setze T auf die leere Sequenz. Die Länge von T (in Bits) wird als tlen bezeichnet, somit ist an diesem Punkt tlen = 0.

  2. Solange tlen < qlen, führe das Folgende aus:

    V = HMAC_K(V)
    T = T || V

  3. Berechne:

    k = bits2int(T)

    Wenn dieser Wert für k geeignet ist (d.h. wenn k im Bereich [1, q-1] liegt und für DSA oder ECDSA geeignet ist), dann wird dieser Wert von k verwendet.

  4. Andernfalls berechne:

    K = HMAC_K(V || 0x00)
    V = HMAC_K(V)

    und kehre zu Schritt h.1 zurück, wobei versucht wird, einen neuen Wert für k zu erzeugen.

3.2. Generation of k (Erzeugung von k)​

Bei der Eingabenachricht m wird der folgende Prozess angewendet:

a. Verarbeite m durch die Hash-Funktion H, was ergibt: h1 = H(m)

b. Setze V = 0x01 0x01 0x01 ... 0x01 (sodass die Länge von V in Bits gleich 8*ceil(hlen/8) ist)

c. Setze K = 0x00 0x00 0x00 ... 0x00 (sodass die Länge von K in Bits gleich 8*ceil(hlen/8) ist)

d. Setze K = HMAC_K(V || 0x00 || int2octets(x) || bits2octets(h1))

e. Setze V = HMAC_K(V)

f. Setze K = HMAC_K(V || 0x01 || int2octets(x) || bits2octets(h1))

g. Setze V = HMAC_K(V)

h. Wende den folgenden Algorithmus an, bis ein geeigneter Wert für k gefunden wird. Siehe RFC 6979 Abschnitt 3.2 für vollständige Details.

3.3. Alternate Description of the Generation of k (Alternative Beschreibung der Erzeugung von k)​

This compatibility page redirects readers to 3.3. Alternate Description of the Generation of k (Alternative Beschreibung der Erzeugung von k).

3.4. Usage Notes (Verwendungshinweise)​

Bei DSA oder ECDSA wird der Wert k zur Berechnung der ersten Hälfte der Signatur verwendet, genannt r (siehe Abschnitt 2.4). Die Standards DSA und ECDSA verlangen, dass falls r null ist, ein neuer Wert für k ausgewählt werden muss. In dieser Situation gibt dieses Dokument an, dass der Wert k "ungeeignet" ist und der Erzeugungsprozess weiter schleifen sollte.

Dieses Ereignis ist äußerst unwahrscheinlich. Tatsächlich würde es erheblichen rechnerischen Aufwand erfordern (ähnlich dem Brechen der Preimage-Resistenz der Hash-Funktion), um einen privaten Schlüssel und eine Nachricht zu finden, die zu einem Null-Wert für r führen. Rein zufällig auf einen solchen Fall zu stoßen, wird daher als unmöglich betrachtet, und ein Angreifer kann es nicht mit sorgfältig gestalteten Nachrichten erzwingen. In der Praxis wird ein solcher Code-Pfad nicht ausgelöst und kann daher mit minimalen Optimierungen implementiert werden.

3.5. Rationale (Begründung)​

Der in den vorherigen Abschnitten beschriebene Prozess ahmt das "Approved"-Verfahren zur Erzeugung von k nach, das in Anhang D von [X9.62] mit dem "HMAC_DRBG"-Pseudozufallszahlengenerator beschrieben ist. Der Hauptunterschied besteht darin, dass wir die Verkettung des privaten Schlüssels x und der gehashten Nachricht H(m) als Seed für den Pseudozufallszahlengenerator (PRNG) verwenden. Bei Verwendung einer "Sicherheitsstufe" von n Bits sollte HMAC_DRBG mit einer Seed-Entropie von mindestens n+64 Bits verwendet werden. Der Schlüssel x sollte jedoch ebenfalls mit dieser Entropie erzeugt worden sein, und die Länge von x ist qlen, die mindestens gleich 2*n und somit größer als n+64 ist (DSA und ECDSA, wie von den Standards spezifiziert, erfordern qlen >= 160). Es kann daher argumentiert werden, dass deterministisches ECDSA die Entropieanforderungen von Anhang D von [X9.62] erfüllt.

Wir verwenden bits2octets(H(m)) anstelle von H(m), um die Integration zu erleichtern. Tatsächlich lagern viele bestehende Signatursysteme das Nachrichten-Hashing aus. Die Signatur-Engine (die Zugriff auf den privaten Schlüssel hat) erhält nur H(m). In einigen Anwendungen, wo die Datenbandbreite eingeschränkt ist, werden nur die ersten qlen Bits von H(m) zur Signatur-Engine übertragen, auf der Grundlage, dass die bits2int-Transformation nachfolgende Bits ohnehin ignoriert. Möglicherweise könnte in einigen Systemen das gekürzte H(m) extern modulo q reduziert werden, da dies das Erste ist, was (EC)DSA mit der gehashten Nachricht durchführt. Mit der Definition von bits2octets kann deterministisches (EC)DSA mit derselben Eingabe angewendet werden.

3.6. Variants (Varianten)​

Viele Teile der Spezifikation von deterministischem (EC)DSA sind ziemlich willkürlich, aber die Wahl wurde aus Interoperabilitätsgründen getroffen. Dieser Abschnitt diskutiert einige mögliche Varianten.

Die verwendete Hash-Funktion H wird im Signaturerzeugungsprozess für zwei verschiedene Zwecke verwendet: erstens zur Verarbeitung der Eingabenachricht und zweitens als Basis für HMAC (das selbst auch eine Hash-Funktion ist). In diesem Dokument spezifizieren wir die Verwendung derselben Hash-Funktion für beide Zwecke. Dies ist jedoch nicht zwingend erforderlich; es ist möglich, unterschiedliche Funktionen für diese beiden Rollen zu verwenden. Der Hauptnachteil besteht darin, dass Testvektoren nicht alle Kombinationen abdecken können; die Verwendung einer einzigen Hash-Funktion vereinfacht Interoperabilitätstests.

Die Definitionen von int2octets und bits2octets führen zu einer Ausgabe von rlen Bits (d.h. qlen aufgerundet auf das nächste Vielfache von 8), und sie erzeugen bei ihrer Verwendung tatsächlich höchstens qlen Bits Entropie. Es wäre möglich, dieselben Funktionen so zu definieren, dass sie genau qlen Bits ausgeben; dies würde jedoch die Implementierung etwas komplizierter machen, da viele Programmiersprachen und Frameworks dazu neigen, mit Sequenzen von Oktetten statt mit Bit-Sequenzen zu arbeiten. Andererseits erhöht das Aufrunden von qlen höchstens 7 Bits, was im Kontext eines PRNG-Seeds vernachlässigbar ist.

In dieser Spezifikation geben wir einen Prozess an, der in Sonderfällen schleift, in denen k (erhalten aus T durch bits2int) nicht im geeigneten Bereich liegt oder zur Erzeugung eines Null-Werts für r führen würde. Beide Fälle treten jedoch praktisch nie auf. Der letztere Fall (ein berechnetes r von Null) kann nur aufgrund eines Software-Fehlers auftreten (z.B. Elliptic-Curve-Parameter werden während der Programmlaufzeit beschädigt). Implementierungen können daher wählen, solche Fälle einfach als nicht behebbare Fehler zu behandeln und die Signaturberechnung einfach abzubrechen, anstatt zu schleifen.

4. Security Considerations (Sicherheitsüberlegungen)​

Die ordnungsgemäße Implementierung und Verwendung eines kryptografischen Signaturalgorithmus erfordert die Berücksichtigung vieler Parameter. Insbesondere sind die Erzeugung, Speicherung, Zugriffskontrolle und Entsorgung privater Schlüssel sensible Operationen, die dieses Dokument in keiner Weise behandelt. Deterministisches (EC)DSA zeigt, wie die Sicherheitsmerkmale eines standardmäßigen DSA- oder ECDSA-Signaturverfahrens erreicht werden können, während die Notwendigkeit einer Quelle starker Zufälligkeit oder sogar jeglicher Zufälligkeit während der Signaturerzeugung beseitigt wird.

Die Erzeugung privater Schlüssel erfordert jedoch absolut eine solch stark zufällige Quelle. In Situationen, in denen deterministisches (EC)DSA aufgrund des Fehlens einer geeigneten Zufallsquelle verwendet werden soll, muss angenommen werden, dass der private Schlüssel extern erzeugt und in das Signaturerzeugungssystem importiert wurde oder in einem Kontext erzeugt wurde, in dem Zufälligkeit verfügbar war. Man kann sich beispielsweise eine Smartcard vorstellen, die ihren privaten Schlüssel noch in der Fabrik unter kontrollierten Umgebungsbedingungen erzeugt, für die jedoch keine Zufallsdatenerzeugung garantiert werden kann, sobald sie im Feld eingesetzt ist, wenn sie sich physisch in den Händen potenzieller Angreifer befindet.

Sowohl die Beseitigung der Anforderung an eine Zufallsquelle als auch die Fähigkeit, eine Implementierung gegen Testvektoren zu testen, verbessern die Sicherheit von DSA- und ECDSA-Signer-Implementierungen, indem sie helfen, schwer zu testende Fehlerbedingungen zu vermeiden. Deterministische Signaturverfahren können auch in anderen Situationen helfen, z.B. um falsche Duplikate zu vermeiden, wenn dasselbe Datenelement mehrmals mit demselben Schlüssel signiert wird: Mit einem deterministischen Signaturverfahren wird jedes Mal dieselbe Signatur erzeugt, was die Duplikaterkennung wesentlich einfacher macht.

Umgekehrt kann das Fehlen von Randomisierung in einigen fortgeschrittenen Protokollen nachteilige Auswirkungen haben, z.B. in Bezug auf Anonymität in einigen Wahlsystemen. Als Faustregel gilt, dass deterministisches DSA oder ECDSA anstelle des echten DSA oder ECDSA verwendet werden kann, ohne zusätzliche Sicherheitsprobleme, wenn das Gesamtprotokoll ein anderes deterministisches Signaturverfahren tolerieren würde, insbesondere RSA, wie in PKCS #1 [RFC3447] spezifiziert (mit "type 1" Padding, nicht PSS) oder ISO 9796-2 [ISO-9796-2]. Die Liste der Protokolle, in denen deterministisches DSA oder ECDSA angemessen ist, umfasst Transport Layer Security (TLS) [RFC5246], das Secure SHell (SSH) Protocol [RFC4251], Cryptographic Message Syntax (CMS) [RFC5652] und Derivate, X.509-Public-Key-Infrastrukturen [RFC5280] und viele andere.

Die in diesem Dokument beschriebene Konstruktion ist als "Derandomisierung" bekannt. Dies wurde für verschiedene Signaturverfahren vorgeschlagen. Die Sicherheit hängt davon ab, ob die Erzeugung von k von der Ausgabe eines Random Oracle nicht unterscheidbar ist. Grob gesagt ist HMAC_DRBG in dieser Rolle sicher, solange HMAC sich wie eine PRF (Pseudorandom Function) verhält. Für Details zur Sicherheit von HMAC und HMAC_DRBG siehe bitte [H2008] und [B2006]. Für eine formellere Behandlung der Derandomisierung siehe [LN2009].

Ein verbleibendes Problem mit deterministischem (EC)DSA, wie in diesem Dokument dargestellt, ist die "Doppelverwendung" des privaten Schlüssels x, sowohl als privater Schlüssel im Signaturerzeugungsalgorithmus selbst als auch als Eingabe für das auf HMAC_DRBG basierende Pseudozufalls-Oracle zur Erzeugung des k-Werts. Dies erfordert, dass HMAC_DRBG weiterhin ein Random Oracle bleibt, selbst wenn der öffentliche Schlüssel (der aus x berechnet wird) ebenfalls bekannt ist. Angesichts des Mangels an gemeinsamer Struktur zwischen HMAC und diskreten Logarithmen scheint dies eine vernünftige Annahme zu sein.

Seitenkanalangriffe sind eine wichtige Überlegung, wann immer ein Angreifer Aspekte einer Implementierung genau messen kann, wie z.B. die Zeitdauer, die für die Durchführung einer Signierungsoperation benötigt wird, oder die zu jedem Zeitpunkt einer Signierungsoperation verbrauchte Leistung. Der Determinismus der in diesem Dokument beschriebenen Algorithmen kann für einen Angreifer bei einigen Formen von Seitenkanalangriffen nützlich sein, daher SOLLTEN Implementierungen defensive Maßnahmen verwenden, um zu vermeiden, dass der private Schlüssel durch einen Seitenkanal durchsickert.

5. Intellectual Property Status (Status des geistigen Eigentums)​

Nach unserem besten Wissen ist deterministisches (EC)DSA nicht durch ein aktives Patent abgedeckt. Das Papier [BDLSY2011] verweist auf zwei unabhängige Veröffentlichungen der Idee der Derandomisierung durch Barwood und Wigley, beide Anfang 1997, und auch auf eine Patentanmeldung von Naccache, M'Raihi und Levy-dit-Vehel einige Monate später [NML1997], aber die Anmeldung wurde 2003 zurückgezogen. Wir sind uns keines anderen Patents zu diesem Thema bewusst.

Appendix A. Examples (Beispiele)​

A.1. Detailed Example (Detailliertes Beispiel)​

Wir detaillieren hier die Zwischenwerte, die während der Erzeugung von k für eine Beispielnachricht und einen Beispielschlüssel erhalten werden. Wir verwenden eine binäre Kurve, da diese spezifische Kurve standardmäßig ist und eine Gruppenordnungslänge (qlen) hat, die kein Vielfaches von 8 ist. Dies veranschaulicht die feinen Details, wie Konvertierungen zwischen Ganzzahlen und Bit-Sequenzen durchgeführt werden.

A.1.1. Key Pair (Schlüsselpaar)​

Wir betrachten ECDSA auf der Kurve K-163, die in [FIPS-186-4] beschrieben ist (auch bekannt als "ansix9t163k1" in [X9.62]). Die Kurve ist über einem Körper GF(2^163) definiert: Körperelemente werden in 163-Bit-Zeichenfolgen kodiert. Die Ordnung des konventionellen Basispunkts ist der Primwert:

q = 0x4000000000000000000020108A2E0CC0D99F8A5EF

der die Länge qlen = 163 Bits hat.

Unser privater Schlüssel ist:

x = 0x09A4D6792295A7F730FC3F2B49CBC0F62E862272F

Der entsprechende öffentliche Schlüssel ist der Kurvenpunkt U = xG. Dieser Punkt hat zwei Koordinaten, die Elemente des Körpers GF(2^163) sind. Diese Elemente können unter Verwendung des in Abschnitt A.5.6 von [X9.62] beschriebenen Verfahrens in Ganzzahlen konvertiert werden, was die zwei öffentlichen Punktkoordinaten ergibt:

Ux = 0x79AEE090DB05EC252D5CB4452F356BE198A4FF96F
Uy = 0x782E29634DDC9A31EF40386E896BAA18B53AFA5A3

A.1.2. Generation of k (Erzeugung von k)​

In diesem Beispiel verwenden wir die Hash-Funktion SHA-256 [FIPS-180-4]. Die Eingabenachricht ist die UTF-8-Kodierung der Zeichenfolge "sample" (6 Oktette, d.h. 48 Bits).

Die gehashte Eingabenachricht h1 = SHA-256(m) ist:

h1
   AF 2B DB E1 AA 9B 6E C1 E2 AD E1 D6 94 F4 1F C7
   1A 83 1D 02 68 E9 89 15 62 11 3D 8A 62 AD D1 BF

(32 Oktette; jeder Oktettwert ist in hexadezimaler Notation aufgeführt).

Wir konvertieren den privaten Schlüssel x unter Verwendung der int2octets-Transformation in eine Sequenz von Oktetten:

int2octets(x)
   00 9A 4D 67 92 29 5A 7F 73 0F C3 F2 B4 9C BC 0F
   62 E8 62 27 2F

Hinweis: Obwohl der spezifische Wert von x numerisch in 160 Bits, d.h. 20 Oktette, passen würde, kodieren wir x dennoch in 21 Oktette, da die Kodierungslänge durch die Länge von q, die 163 Bits beträgt, bestimmt wird.

Wir kürzen und/oder erweitern auch die gehashte Nachricht unter Verwendung von bits2octets:

bits2octets(h1)
   01 79 5E DF 0D 54 DB 76 0F 15 6D 0D AC 04 C0 32
   2B 3A 20 42 24

Die Schritte b bis g (siehe Abschnitt 3.2) berechnen dann die Werte für die K- und V-Variablen. Diese Variablen sind Sequenzen von 256 Bits (die Ausgabelänge der Hash-Funktion, aufgerundet auf ein Vielfaches von 8). Wir reproduzieren hier die aufeinanderfolgenden Werte:

V nach Schritt b:

01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

K nach Schritt c:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

K nach Schritt d:

09 99 9A 9B FE F9 72 D3 34 69 11 88 3F AD 79 51
D2 3F 2C 8B 47 F4 20 22 2D 11 71 EE EE AC 5A B8

V nach Schritt e:

D5 F4 03 0F 75 5E E8 6A A1 0B BA 8C 09 DF 11 4F
F6 B6 11 1C 23 85 00 D1 3C 73 43 A8 C0 1B EC F7

K nach Schritt f:

0C F2 FE 96 D5 61 9C 9E F5 3C B7 41 7D 49 D3 7E
A6 8A 4F FE D0 D7 E6 23 E3 86 89 28 99 11 BD 57

V nach Schritt g:

78 34 57 C1 CF 31 48 A8 F2 A9 AE 73 ED 47 2F A9
8E D9 CD 92 5D 8E 96 4C E0 76 4D EF 3F 84 2B 9A

In Schritt h führen wir die finale Schleife durch. Da wir HMAC mit SHA-256 verwenden, das 256 Bits Ausgabe erzeugt, und wir nur 163 Bits für T benötigen, ergibt ein einzelner HMAC-Aufruf das folgende T:

T (erster Versuch):

93 05 A4 6D E7 FF 8E B1 07 19 4D EB D3 FD 48 AA
20 D5 E7 65 6C BE 0E A6 9D 2A 8D 4E 7C 67 31 4A

was, wenn mit bits2int in eine Ganzzahl konvertiert, einen ersten Kandidaten für k ergibt:

k1 = 0x4982D236F3FFC758838CA6F5E9FEA455106AF3B2B

Da dieser Wert größer als q-1 ist, müssen wir schleifen. Dies beinhaltet zuerst die Berechnung neuer Werte für K und V:

neues K:

75 CB 5C 05 B2 A7 8C 3D 81 DF 12 D7 4D 7B E0 A0
E9 4A B1 98 15 78 1D 4D 8E 29 02 A7 9D 0A 66 99

neues V:

DC B9 CA 12 61 07 A9 C2 7C E7 7B A5 8E A8 71 C8
C9 12 D8 35 EA DD C3 05 F2 44 5D 88 F6 6C 4C 43

Ein neuer Aufruf von HMAC_K(V) ergibt dann:

T (zweiter Versuch):

5C 51 E5 75 31 DA 57 0D 21 31 15 1E 44 05 1B 37
9A 2D EA 30 18 5F 7D FA FD B3 3A D1 85 8C 02 3D

was in eine Ganzzahl konvertiert wird:

k = 0x23AF4074C90A02B3FE61D286D5C87F425E6BDD81B

Dieser Wert ist im Bereich [1, q-1] und ist daher geeignet.

A.1.3. Signature (Signatur)​

Mit dem oben erzeugten k-Wert wird die Signatur wie in Abschnitt 2.4 beschrieben berechnet. Die endgültige Signatur über die Nachricht "sample" mit dem gegebenen Schlüssel ist:

r = 0x113A63990598A3828C407C0F4D2438D990DF99A7F
s = 0x1313A2E03F5412DDB296A22E2C455335545672D9F

A.2. Test Vectors (Testvektoren)​

Die folgenden Unterabschnitte enthalten Testvektoren für verschiedene Kombinationen von DSA/ECDSA und Hash-Funktionen. Für jeden Test wird ein Schlüsselpaar erzeugt, und die Signatur wird für zwei Beispielnachrichten berechnet:

  • Die Zeichenfolge "sample"
  • Die Zeichenfolge "test"

Für jeden Fall werden die resultierenden r- und s-Werte der Signatur angegeben.

Die vollständigen Testvektoren für alle aufgeführten Kurven und Hash-Funktionen sind im Original-RFC-Dokument enthalten und sollten für Implementierungstests konsultiert werden.

A.3. Sample Code (Beispielcode)​

Beispielimplementierungen des in diesem Dokument beschriebenen Algorithmus sind verfügbar. Implementierer werden ermutigt, ihre Implementierungen gegen die in diesem Anhang bereitgestellten Testvektoren zu testen, um die Korrektheit sicherzustellen.

A.1.2. Generation of k (Erzeugung von k)​

In diesem Beispiel verwenden wir die Hash-Funktion SHA-256 [FIPS-180-4]. Die Eingabenachricht ist die UTF-8-Kodierung der Zeichenkette "sample" (6 Oktette, d.h. 48 Bit).

Die gehashte Eingabenachricht h1 = SHA-256(m) ist:

h1
   AF 2B DB E1 AA 9B 6E C1 E2 AD E1 D6 94 F4 1F C7
   1A 83 1D 02 68 E9 89 15 62 11 3D 8A 62 AD D1 BF

(32 Oktette; jeder Oktett-Wert ist in Hexadezimalnotation aufgelistet).

Wir konvertieren den privaten Schlüssel x in eine Oktett-Sequenz unter Verwendung der int2octets-Transformation:

int2octets(x)
   00 9A 4D 67 92 29 5A 7F 73 0F C3 F2 B4 9C BC 0F
   62 E8 62 27 2F

Die Schritte b bis g (siehe Abschnitt 3.2) berechnen dann die Werte für die Variablen K und V. Siehe RFC 6979 Anhang A.1.2 für vollständige Details der Zwischenwerte.

Wir erhalten schließlich einen akzeptablen Wert für k:

k = 0x23AF4074C90A02B3FE61D286D5C87F425E6BDD81B

A.2. Test Vectors (Testvektoren)​

In den folgenden Unterabschnitten stellen wir Testvektoren für DSA und ECDSA mit verschiedenen Schlüsselgrößen und Hash-Funktionen bereit.

Die Testvektoren umfassen:

  • A.2.1. bis A.2.2.: DSA (1024 und 2048 Bit)
  • A.2.3. bis A.2.7.: ECDSA über Primkörper (192, 224, 256, 384, 521 Bit)
  • A.2.8. bis A.2.12.: ECDSA über binäre Körper, Koblitz-Kurven (163, 233, 283, 409, 571 Bit)
  • A.2.13. bis A.2.17.: ECDSA über binäre Körper, pseudozufällige Kurven (163, 233, 283, 409, 571 Bit)

Jeder Testvektor enthält:

  • Schlüsselparameter
  • Privaten und öffentlichen Schlüssel
  • Signaturen für verschiedene Hash-Funktionen (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) für die Beispielnachrichten "sample" und "test"

Diese Testvektoren können verwendet werden, um die Korrektheit deterministischer (EC)DSA-Implementierungen zu verifizieren.

A.3. Sample Code (Beispielcode)​

Das ursprüngliche RFC 6979-Dokument enthält Verweise auf Beispielimplementierungscode. Implementierer sollten konsultieren:

  • RFC 6979 Original für vollständige Testvektoren
  • HMAC-Implementierung: RFC 2104
  • HMAC_DRBG-Implementierung: NIST SP 800-90A

Bei der Implementierung sollte besondere Aufmerksamkeit geschenkt werden auf:

  • Korrekte Implementierung der bits2int- und bits2octets-Konvertierungen
  • Sicherstellung korrekter HMAC-Berechnungen
  • Überprüfung, dass generierte k-Werte im gültigen Bereich liegen
  • Verwendung der bereitgestellten Testvektoren zur Überprüfung der Implementierung