Zum Hauptinhalt springen

RFC 8017 - PKCS #1: RSA-Kryptographie-Spezifikationen Version 2.2

  • Status: Informational
  • Veröffentlicht: November 2016
  • Stream: IETF
  • Ersetzt: RFC3447
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

Dieses Dokument bietet Empfehlungen für die Implementierung von Public-Key-Kryptographie basierend auf dem RSA-Algorithmus und behandelt kryptographische Primitive, Verschlüsselungsschemata, Signaturschemata mit Anhang sowie ASN.1-Syntax zur Darstellung von Schlüsseln und zur Identifizierung der Schemata.

Dieses Dokument stellt eine Neuveröffentlichung von PKCS #1 v2.2 aus der Public-Key Cryptography Standards (PKCS)-Reihe von RSA Laboratories dar. Durch die Veröffentlichung dieses RFC wird die Änderungskontrolle an die IETF übertragen.

Dieses Dokument macht auch RFC 3447 obsolet.

Status dieses Memorandums​

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

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es repräsentiert den Konsens der IETF-Community. Es hat eine öffentliche Überprüfung erhalten und wurde von der Internet Engineering Steering Group (IESG) zur Veröffentlichung genehmigt. Nicht alle von der IESG genehmigten Dokumente sind Kandidaten für irgendein Niveau eines Internet-Standards; siehe Abschnitt 2 von RFC 7841.

Informationen über den aktuellen Status dieses Dokuments, eventuelle Errata und wie man Feedback geben kann, sind unter http://www.rfc-editor.org/info/rfc8017 erhältlich.

Inhaltsverzeichnis​

Anhänge​

Verwandte Ressourcen​

1. Einführung (Introduction)​

Dieses Dokument bietet Empfehlungen für die Implementierung von Public-Key-Kryptographie (Public-Key Cryptography) basierend auf dem RSA-Algorithmus [RSA] und behandelt die folgenden Aspekte:

  • Kryptographische Primitive (Cryptographic Primitives)
  • Verschlüsselungsschemata (Encryption Schemes)
  • Signaturschemata mit Anhang (Signature Schemes with Appendix)
  • ASN.1-Syntax zur Darstellung von Schlüsseln und zur Identifizierung der Schemata

Diese Empfehlungen sind für die allgemeine Anwendung in Computer- und Kommunikationssystemen vorgesehen und beinhalten daher ein erhebliches Maß an Flexibilität. Es wird erwartet, dass Anwendungsstandards, die auf diesen Spezifikationen basieren, zusätzliche Einschränkungen enthalten können. Diese Empfehlungen sollen mit den Standards IEEE 1363 [IEEE1363], IEEE 1363a [IEEE1363A] und ANSI X9.44 [ANSIX944] kompatibel sein.

Dieses Dokument ersetzt PKCS #1 Version 2.1 [RFC3447], enthält aber kompatible Techniken.

Die Organisation dieses Dokuments ist wie folgt:

  • Abschnitt 1 ist eine Einführung.

  • Abschnitt 2 definiert einige in diesem Dokument verwendete Notationen.

  • Abschnitt 3 definiert die RSA-Schlüsseltypen für öffentliche und private Schlüssel.

  • Die Abschnitte 4 und 5 definieren mehrere Primitive, oder grundlegende mathematische Operationen. Datenkonvertierungsprimitive befinden sich in Abschnitt 4, und kryptographische Primitive (Verschlüsselung-Entschlüsselung und Signatur-Verifikation) befinden sich in Abschnitt 5.

  • Die Abschnitte 6, 7 und 8 behandeln die Verschlüsselungs- und Signaturschemata in diesem Dokument. Abschnitt 6 gibt einen Überblick. Zusätzlich zu den in PKCS #1 v1.5 gefundenen Methoden definiert Abschnitt 7 ein Verschlüsselungsschema basierend auf Optimal Asymmetric Encryption Padding (OAEP) [OAEP], und Abschnitt 8 definiert ein Signaturschema mit Anhang basierend auf dem Probabilistic Signature Scheme (PSS) [RSARABIN] [PSS].

  • Abschnitt 9 definiert die Kodierungsmethoden für die Signaturschemata in Abschnitt 8.

  • Anhang A definiert die ASN.1-Syntax für die in Abschnitt 3 definierten Schlüssel und die Schemata in den Abschnitten 7 und 8.

  • Anhang B definiert die in diesem Dokument verwendeten Hash-Funktionen (Hash Functions) und die Maskengenerierungsfunktion (Mask Generation Function, MGF), einschließlich der ASN.1-Syntax für diese Techniken.

  • Anhang C gibt ein ASN.1-Modul an.

  • Die Anhänge D und E umreißen die Revisionsgeschichte von PKCS #1 und bieten allgemeine Informationen über die Public-Key Cryptography Standards.

Dieses Dokument stellt eine Neuveröffentlichung von PKCS #1 v2.2 [PKCS1_22] aus der Public-Key Cryptography Standards (PKCS)-Reihe von RSA Laboratories dar.

1.1. Anforderungssprache (Requirements Language)​

Die Schlüsselwörter „MUST" (muss), „MUST NOT" (darf nicht), „REQUIRED" (erforderlich), „SHALL" (muss), „SHALL NOT" (darf nicht), „SHOULD" (sollte), „SHOULD NOT" (sollte nicht), „RECOMMENDED" (empfohlen), „MAY" (kann) und „OPTIONAL" (optional) in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.

2. Notation​

Die Notation in diesem Dokument umfasst:

SymbolBeschreibung
cChiffretextrepräsentant (Ciphertext Representative), eine ganze Zahl zwischen 0 und n-1
CChiffretext (Ciphertext), eine Oktettzeichenkette (Octet String)
dprivater RSA-Exponent (RSA Private Exponent)
d_iCRT-Exponent des zusätzlichen Faktors r_i (Additional Factor r_i's CRT Exponent), eine positive ganze Zahl mit e * d_i == 1 (mod (r_i-1)), i = 3, ..., u
dPCRT-Exponent von p, eine positive ganze Zahl mit e * dP == 1 (mod (p-1))
dQCRT-Exponent von q, eine positive ganze Zahl mit e * dQ == 1 (mod (q-1))
eöffentlicher RSA-Exponent (RSA Public Exponent)
EMkodierte Nachricht (Encoded Message), eine Oktettzeichenkette
emBits(beabsichtigte) Länge in Bits einer kodierten Nachricht EM
emLen(beabsichtigte) Länge in Oktetten einer kodierten Nachricht EM
GCD(. , .)größter gemeinsamer Teiler zweier nichtnegativer ganzer Zahlen (Greatest Common Divisor)
HashHash-Funktion (Hash Function)
hLenAusgabelänge in Oktetten der Hash-Funktion Hash
kLänge in Oktetten des RSA-Modulus n
Kprivater RSA-Schlüssel (RSA Private Key)
Loptionales RSAES-OAEP-Label (Label), eine Oktettzeichenkette
LCM(., ..., .)kleinstes gemeinsames Vielfaches einer Liste nichtnegativer ganzer Zahlen (Least Common Multiple)
mNachrichtenrepräsentant (Message Representative), eine ganze Zahl zwischen 0 und n-1
MNachricht (Message), eine Oktettzeichenkette
maskMGF-Ausgabe, eine Oktettzeichenkette
maskLen(beabsichtigte) Länge der Oktettzeichenkette mask
MGFMaskengenerierungsfunktion (Mask Generation Function)
mgfSeedSeed, aus dem die Maske generiert wird, eine Oktettzeichenkette
mLenLänge in Oktetten einer Nachricht M
nRSA-Modulus (RSA Modulus), n = r_1 * r_2 * ... * r_u, u >= 2
(n, e)öffentlicher RSA-Schlüssel (RSA Public Key)
p, qerste zwei Primfaktoren des RSA-Modulus n (Prime Factors)
qInvCRT-Koeffizient (CRT Coefficient), eine positive ganze Zahl kleiner als p mit q * qInv == 1 (mod p)
r_iPrimfaktoren des RSA-Modulus n, einschließlich r_1 = p, r_2 = q und zusätzliche Faktoren, falls vorhanden
sSignaturrepräsentant (Signature Representative), eine ganze Zahl zwischen 0 und n-1
SSignatur (Signature), eine Oktettzeichenkette
sLenLänge in Oktetten des EMSA-PSS-Salzes (Salt)
t_iCRT-Koeffizient des zusätzlichen Primfaktors r_i, eine positive ganze Zahl kleiner als r_i mit r_1 * r_2 * ... * r_(i-1) * t_i == 1 (mod r_i), i = 3, ..., u
uAnzahl der Primfaktoren des RSA-Modulus, u >= 2
xeine nichtnegative ganze Zahl
Xeine Oktettzeichenkette, die x entspricht
xLen(beabsichtigte) Länge der Oktettzeichenkette X
0xIndikator für hexadezimale Darstellung eines Oktetts oder einer Oktettzeichenkette: „0x48" bezeichnet das Oktett mit dem Hexadezimalwert 48; „(0x)48 09 0e" bezeichnet die Zeichenkette aus drei aufeinanderfolgenden Oktetten mit den Hexadezimalwerten 48, 09 und 0e
λ(n)LCM(r_1-1, r_2-1, ..., r_u-1)
⊕bitweises exklusives ODER zweier Oktettzeichenketten (Bit-wise Exclusive-OR)
⌈.⌉Aufrundungsfunktion (Ceiling Function); ⌈x⌉ ist die kleinste ganze Zahl größer oder gleich der reellen Zahl x
||Verkettungsoperator (Concatenation Operator)
==Kongruenzsymbol (Congruence Symbol); a == b (mod n) bedeutet, dass die ganze Zahl n die ganze Zahl a - b teilt

Hinweis: Der chinesische Restsatz (Chinese Remainder Theorem, CRT) kann sowohl nicht-rekursiv als auch rekursiv angewendet werden. In diesem Dokument wird ein rekursiver Ansatz nach Garners Algorithmus [GARNER] verwendet. Siehe auch Hinweis 1 in Abschnitt 3.2.

3. Schlüsseltypen (Key Types)​

In den in diesem Dokument definierten Primitiven und Schemata werden zwei Schlüsseltypen verwendet: RSA-öffentlicher Schlüssel (RSA Public Key) und RSA-privater Schlüssel (RSA Private Key). Zusammen bilden ein RSA-öffentlicher Schlüssel und ein RSA-privater Schlüssel ein RSA-Schlüsselpaar (RSA Key Pair).

Diese Spezifikation unterstützt das sogenannte „Multi-Prim"-RSA (Multi-prime), bei dem der Modulus mehr als zwei Primfaktoren haben kann. Der Vorteil von Multi-Prim-RSA sind geringere Rechenkosten für die Entschlüsselungs- und Signaturprimitive, vorausgesetzt, dass der chinesische Restsatz (Chinese Remainder Theorem, CRT) verwendet wird. Bessere Leistung kann auf Einzelprozessorplattformen erreicht werden, aber in größerem Maße auf Multiprozessorplattformen, wo die beteiligten modularen Exponentiationen parallel durchgeführt werden können.

Für eine Diskussion darüber, wie Multi-Prim die Sicherheit des RSA-Kryptosystems beeinflusst, wird der Leser auf [SILVERMAN] verwiesen.

3.1. Öffentlicher RSA-Schlüssel (RSA Public Key)​

Für die Zwecke dieses Dokuments besteht ein öffentlicher RSA-Schlüssel aus zwei Komponenten:

n        RSA-Modulus (RSA Modulus), eine positive ganze Zahl
e        öffentlicher RSA-Exponent (RSA Public Exponent), eine positive ganze Zahl

In einem gültigen öffentlichen RSA-Schlüssel ist der RSA-Modulus n ein Produkt von u verschiedenen ungeraden Primzahlen r_i, i = 1, 2, ..., u, wobei u >= 2, und der öffentliche RSA-Exponent e ist eine ganze Zahl zwischen 3 und n - 1, die GCD(e, λ(n)) = 1 erfüllt, wobei λ(n) = LCM(r_1 - 1, ..., r_u - 1). Per Konvention können die ersten beiden Primzahlen r_1 und r_2 auch als p bzw. q bezeichnet werden.

Eine empfohlene Syntax für den Austausch öffentlicher RSA-Schlüssel zwischen Implementierungen ist in Anhang A.1.1 angegeben; die interne Darstellung einer Implementierung kann davon abweichen.

3.2. Privater RSA-Schlüssel (RSA Private Key)​

Für die Zwecke dieses Dokuments kann ein privater RSA-Schlüssel eine von zwei Darstellungen haben.

Darstellung 1​

Die erste Darstellung besteht aus dem Paar (n, d), wobei die Komponenten folgende Bedeutungen haben:

n       RSA-Modulus (RSA Modulus), eine positive ganze Zahl
d       privater RSA-Exponent (RSA Private Exponent), eine positive ganze Zahl

Darstellung 2​

Die zweite Darstellung besteht aus einem Quintupel (p, q, dP, dQ, qInv) und einer (möglicherweise leeren) Sequenz von Tripeln (r_i, d_i, t_i), i = 3, ..., u, eines für jede Primzahl, die nicht im Quintupel enthalten ist, wobei die Komponenten folgende Bedeutungen haben:

p      der erste Faktor, eine positive ganze Zahl
q      der zweite Faktor, eine positive ganze Zahl
dP     CRT-Exponent des ersten Faktors, eine positive ganze Zahl
dQ     CRT-Exponent des zweiten Faktors, eine positive ganze Zahl
qInv   der (erste) CRT-Koeffizient, eine positive ganze Zahl
r_i    der i-te Faktor, eine positive ganze Zahl
d_i    CRT-Exponent des i-ten Faktors, eine positive ganze Zahl
t_i    CRT-Koeffizient des i-ten Faktors, eine positive ganze Zahl

Gültigkeitsbedingungen​

In einem gültigen privaten RSA-Schlüssel mit der ersten Darstellung ist der RSA-Modulus n derselbe wie im entsprechenden öffentlichen RSA-Schlüssel und ist das Produkt von u verschiedenen ungeraden Primzahlen r_i, i = 1, 2, ..., u, wobei u >= 2. Der private RSA-Exponent d ist eine positive ganze Zahl kleiner als n, die erfüllt:

e * d == 1 (mod λ(n))

wobei e der entsprechende öffentliche RSA-Exponent ist und λ(n) wie in Abschnitt 3.1 definiert ist.

In einem gültigen privaten RSA-Schlüssel mit der zweiten Darstellung sind die beiden Faktoren p und q die ersten beiden Primfaktoren des RSA-Modulus n (d.h., r_1 und r_2); die CRT-Exponenten dP und dQ sind positive ganze Zahlen kleiner als p bzw. q, die erfüllen:

e * dP == 1 (mod (p-1))
e * dQ == 1 (mod (q-1))

und der CRT-Koeffizient qInv ist eine positive ganze Zahl kleiner als p, die erfüllt:

q * qInv == 1 (mod p)

Wenn u > 2, enthält die Darstellung ein oder mehrere Tripel (r_i, d_i, t_i), i = 3, ..., u. Die Faktoren r_i sind die zusätzlichen Primfaktoren des RSA-Modulus n. Jeder CRT-Exponent d_i (i = 3, ..., u) erfüllt:

e * d_i == 1 (mod (r_i - 1))

Jeder CRT-Koeffizient t_i (i = 3, ..., u) ist eine positive ganze Zahl kleiner als r_i, die erfüllt:

R_i * t_i == 1 (mod r_i)

wobei R_i = r_1 * r_2 * ... * r_(i-1).

Eine empfohlene Syntax für den Austausch privater RSA-Schlüssel zwischen Implementierungen, die Komponenten aus beiden Darstellungen enthält, ist in Anhang A.1.2 angegeben; die interne Darstellung einer Implementierung kann davon abweichen.

Hinweise​

Hinweis 1: Die Definition der CRT-Koeffizienten hier und die Formeln, die sie in den Primitiven in Abschnitt 5 verwenden, folgen im Allgemeinen Garners Algorithmus [GARNER] (siehe auch Algorithmus 14.71 in [HANDBOOK]). Für die Kompatibilität mit den Darstellungen privater RSA-Schlüssel in PKCS #1 v2.0 und früheren Versionen sind jedoch die Rollen von p und q im Vergleich zu den übrigen Primzahlen vertauscht. Daher ist der erste CRT-Koeffizient qInv als Inverses von q mod p definiert, nicht als Inverses von R_1 mod r_2, d.h. von p mod q.

Hinweis 2: Quisquater und Couvreur [FASTDEC] beobachteten den Vorteil der Anwendung des CRT auf RSA-Operationen.

4. Datenkonvertierungsprimitive (Data Conversion Primitives)​

In den in diesem Dokument definierten Schemata werden zwei Datenkonvertierungsprimitive (Data Conversion Primitives) verwendet:

  • I2OSP - Ganzzahl-zu-Oktettzeichenkette-Primitiv (Integer-to-Octet-String Primitive)
  • OS2IP - Oktettzeichenkette-zu-Ganzzahl-Primitiv (Octet-String-to-Integer Primitive)

Für die Zwecke dieses Dokuments und in Übereinstimmung mit der ASN.1-Syntax ist eine Oktettzeichenkette (Octet String) eine geordnete Sequenz von Oktetten (8-Bit-Bytes). Diese Sequenz wird vom ersten (per Konvention, ganz links) bis zum letzten (ganz rechts) indiziert. Für Konvertierungen mit Ganzzahlen wird in den folgenden Konvertierungsprimitiven das erste Oktett als das höchstwertige behandelt.

4.1. I2OSP​

I2OSP konvertiert eine nichtnegative Ganzzahl in eine Oktettzeichenkette mit spezifizierter Länge.

I2OSP (x, xLen)

Eingabe (Input)​

x        zu konvertierende nichtnegative Ganzzahl
xLen     beabsichtigte Länge der resultierenden Oktettzeichenkette

Ausgabe (Output)​

X        entsprechende Oktettzeichenkette der Länge xLen

Fehler (Error)​

"integer too large" (Ganzzahl zu groß)

Schritte (Steps)​

Schritt 1. Wenn x >= 256^xLen, Ausgabe "integer too large" und Stopp.

Schritt 2. Schreibe die Ganzzahl x in ihrer eindeutigen xLen-stelligen Basis-256-Darstellung:

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

wobei 0 <= x_i < 256 (beachte, dass wenn x kleiner als 256^(xLen-1) ist, eine oder mehrere führende Ziffern null sein werden).

Schritt 3. Sei der ganzzahlige Wert des Oktetts X_i gleich x_(xLen-i), wobei 1 <= i <= xLen. Gebe die Oktettzeichenkette aus:

X = X_1 X_2 ... X_xLen

4.2. OS2IP​

OS2IP konvertiert eine Oktettzeichenkette in eine nichtnegative Ganzzahl.

OS2IP (X)

Eingabe (Input)​

X        zu konvertierende Oktettzeichenkette

Ausgabe (Output)​

x        entsprechende nichtnegative Ganzzahl

Schritte (Steps)​

Schritt 1. Seien X_1 X_2 ... X_xLen die Oktette von X vom ersten bis zum letzten, und sei x_(xLen-i) der ganzzahlige Wert des Oktetts X_i, wobei 1 <= i <= xLen.

Schritt 2. Sei:

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

Schritt 3. Gebe x aus.

5. Kryptographische Primitive (Cryptographic Primitives)​

Kryptographische Primitive (Cryptographic Primitives) sind grundlegende mathematische Operationen, aus denen kryptographische Schemata aufgebaut werden können. Sie sind für den Einsatz in Hardwareimplementierungen oder als Softwaremodule vorgesehen und sollen nicht unabhängig von Schemata Sicherheit bieten.

Dieses Dokument spezifiziert vier Typen von Primitiven, die paarweise organisiert sind: Verschlüsselung und Entschlüsselung (Encryption and Decryption); Signatur und Verifikation (Signature and Verification).

Die Spezifikation der Primitive geht davon aus, dass die Eingaben bestimmte Bedingungen erfüllen, insbesondere dass die öffentlichen und privaten RSA-Schlüssel gültig sind.

5.1. Verschlüsselungs- und Entschlüsselungsprimitive (Encryption and Decryption Primitives)​

Ein Verschlüsselungsprimitiv (Encryption Primitive) erzeugt einen Chiffretextrepräsentanten aus einem Nachrichtenrepräsentanten unter der Kontrolle eines öffentlichen Schlüssels, und ein Entschlüsselungsprimitiv (Decryption Primitive) stellt einen Nachrichtenrepräsentanten aus einem Chiffretextrepräsentanten unter der Kontrolle des entsprechenden privaten Schlüssels wieder her.

Ein Paar von Verschlüsselungs- und Entschlüsselungsprimitiven wird in den in diesem Dokument definierten Verschlüsselungsschemata verwendet und wird hier spezifiziert: RSA-Verschlüsselungsprimitiv (RSAEP, RSA Encryption Primitive) / RSA-Entschlüsselungsprimitiv (RSADP, RSA Decryption Primitive). RSAEP und RSADP beinhalten dieselbe mathematische Operation, mit unterschiedlichen Schlüsseln als Eingabe. Die hier definierten Primitive sind identisch mit dem Ganzzahlfaktorisierungs-Verschlüsselungsprimitiv mit RSA (IFEP-RSA) / Ganzzahlfaktorisierungs-Entschlüsselungsprimitiv mit RSA (IFDP-RSA) in IEEE 1363 [IEEE1363] (außer dem Hinzufügen der Unterstützung für Multi-Prim-RSA) und sind kompatibel mit PKCS #1 v1.5.

Die Hauptoperation in jedem Primitiv ist die Exponentiation (Exponentiation).

5.1.1. RSAEP​

RSAEP ((n, e), m)

Eingabe (Input)​
(n, e)   öffentlicher RSA-Schlüssel
m        Nachrichtenrepräsentant, eine ganze Zahl zwischen 0 und n - 1
Ausgabe (Output)​
c        Chiffretextrepräsentant, eine ganze Zahl zwischen 0 und n - 1
Fehler (Error)​

"message representative out of range" (Nachrichtenrepräsentant außerhalb des Bereichs)

Annahme (Assumption)​

Der öffentliche RSA-Schlüssel (n, e) ist gültig

Schritte (Steps)​

Schritt 1. Wenn der Nachrichtenrepräsentant m nicht zwischen 0 und n - 1 liegt, Ausgabe "message representative out of range" und Stopp.

Schritt 2. Sei c = m^e mod n.

Schritt 3. Gebe c aus.

5.1.2. RSADP​

RSADP (K, c)

Eingabe (Input)​
K        privater RSA-Schlüssel, wobei K eine der folgenden Formen hat:
         - Paar (n, d)
         - Quintupel (p, q, dP, dQ, qInv) und möglicherweise leere Sequenz von Tripeln (r_i, d_i, t_i), i = 3, ..., u
c        Chiffretextrepräsentant, eine ganze Zahl zwischen 0 und n - 1
Ausgabe (Output)​
m        Nachrichtenrepräsentant, eine ganze Zahl zwischen 0 und n - 1
Fehler (Error)​

"ciphertext representative out of range" (Chiffretextrepräsentant außerhalb des Bereichs)

Annahme (Assumption)​

Der private RSA-Schlüssel K ist gültig

Schritte (Steps)​

Schritt 1. Wenn der Chiffretextrepräsentant c nicht zwischen 0 und n - 1 liegt, Ausgabe "ciphertext representative out of range" und Stopp.

Schritt 2. Der Nachrichtenrepräsentant m wird wie folgt berechnet:

a. Wenn die erste Form von K (n, d) verwendet wird, sei m = c^d mod n.

b. Wenn die zweite Form von K (p, q, dP, dQ, qInv) und (r_i, d_i, t_i) verwendet wird, gehe wie folgt vor:

i. Sei m_1 = c^dP mod p und m_2 = c^dQ mod q.

ii. Wenn u > 2, sei m_i = c^(d_i) mod r_i, i = 3, ..., u.

iii. Sei h = (m_1 - m_2) * qInv mod p.

iv. Sei m = m_2 + q * h.

v. Wenn u > 2, sei R = r_1 und für i = 3 bis u, führe aus:

  1. Sei R = R * r_(i-1).
  2. Sei h = (m_i - m) * t_i mod r_i.
  3. Sei m = m + R * h.

Schritt 3. Gebe m aus.

Hinweis: Schritt 2.b kann als einzelne Schleife umgeschrieben werden, vorausgesetzt, die Reihenfolge von p und q wird umgekehrt. Für die Konsistenz mit PKCS #1 v2.0 werden jedoch die ersten beiden Primzahlen p und q getrennt von den zusätzlichen Primzahlen behandelt.

5.2. Signatur- und Verifikationsprimitive (Signature and Verification Primitives)​

Ein Signaturprimitiv (Signature Primitive) erzeugt einen Signaturrepräsentanten aus einem Nachrichtenrepräsentanten unter der Kontrolle eines privaten Schlüssels, und ein Verifikationsprimitiv (Verification Primitive) stellt einen Nachrichtenrepräsentanten aus einem Signaturrepräsentanten unter der Kontrolle des entsprechenden öffentlichen Schlüssels wieder her. Ein Paar von Signatur- und Verifikationsprimitiven wird in den in diesem Dokument definierten Signaturschemata verwendet und wird hier spezifiziert: RSA-Signaturprimitiv Version 1 (RSASP1, RSA Signature Primitive, version 1) / RSA-Verifikationsprimitiv Version 1 (RSAVP1, RSA Verification Primitive, version 1).

Die hier definierten Primitive sind identisch mit dem Ganzzahlfaktorisierungs-Signaturprimitiv mit RSA Version 1 (IFSP-RSA1) / Ganzzahlfaktorisierungs-Verifikationsprimitiv mit RSA Version 1 (IFVP-RSA1) in IEEE 1363 [IEEE1363] (außer dem Hinzufügen der Unterstützung für Multi-Prim-RSA) und sind kompatibel mit PKCS #1 v1.5.

Die Hauptoperation in jedem Primitiv ist die Exponentiation, wie in den Verschlüsselungs- und Entschlüsselungsprimitiven in Abschnitt 5.1. RSASP1 und RSAVP1 sind identisch mit RSADP und RSAEP, außer den Namen der Eingabe- und Ausgabeparameter; sie werden unterschieden, weil sie für unterschiedliche Zwecke verwendet werden.

5.2.1. RSASP1​

RSASP1 (K, m)

Eingabe (Input)​
K        privater RSA-Schlüssel, wobei K eine der folgenden Formen hat:
         - Paar (n, d)
         - Quintupel (p, q, dP, dQ, qInv) und möglicherweise leere Sequenz von Tripeln (r_i, d_i, t_i), i = 3, ..., u
m        Nachrichtenrepräsentant, eine ganze Zahl zwischen 0 und n - 1
Ausgabe (Output)​
s        Signaturrepräsentant, eine ganze Zahl zwischen 0 und n - 1
Fehler (Error)​

"message representative out of range" (Nachrichtenrepräsentant außerhalb des Bereichs)

Annahme (Assumption)​

Der private RSA-Schlüssel K ist gültig

Schritte (Steps)​

Schritt 1. Wenn der Nachrichtenrepräsentant m nicht zwischen 0 und n - 1 liegt, Ausgabe "message representative out of range" und Stopp.

Schritt 2. Der Signaturrepräsentant s wird wie folgt berechnet:

a. Wenn die erste Form von K (n, d) verwendet wird, sei s = m^d mod n.

b. Wenn die zweite Form von K (p, q, dP, dQ, qInv) und (r_i, d_i, t_i) verwendet wird, gehe wie folgt vor:

  1. Sei s_1 = m^dP mod p und s_2 = m^dQ mod q.
  2. Wenn u > 2, sei s_i = m^(d_i) mod r_i, i = 3, ..., u.
  3. Sei h = (s_1 - s_2) * qInv mod p.
  4. Sei s = s_2 + q * h.
  5. Wenn u > 2, sei R = r_1 und für i = 3 bis u, führe aus:
    • a. Sei R = R * r_(i-1).
    • b. Sei h = (s_i - s) * t_i mod r_i.
    • c. Sei s = s + R * h.

Schritt 3. Gebe s aus.

Hinweis: Schritt 2.b kann als einzelne Schleife umgeschrieben werden, vorausgesetzt, die Reihenfolge von p und q wird umgekehrt. Für die Konsistenz mit PKCS #1 v2.0 werden jedoch die ersten beiden Primzahlen p und q getrennt von den zusätzlichen Primzahlen behandelt.

5.2.2. RSAVP1​

RSAVP1 ((n, e), s)

Eingabe (Input)​
(n, e)   öffentlicher RSA-Schlüssel
s        Signaturrepräsentant, eine ganze Zahl zwischen 0 und n - 1
Ausgabe (Output)​
m        Nachrichtenrepräsentant, eine ganze Zahl zwischen 0 und n - 1
Fehler (Error)​

"signature representative out of range" (Signaturrepräsentant außerhalb des Bereichs)

Annahme (Assumption)​

Der öffentliche RSA-Schlüssel (n, e) ist gültig

Schritte (Steps)​

Schritt 1. Wenn der Signaturrepräsentant s nicht zwischen 0 und n - 1 liegt, Ausgabe "signature representative out of range" und Stopp.

Schritt 2. Sei m = s^e mod n.

Schritt 3. Gebe m aus.

6. Überblick über Schemata (Overview of Schemes)​

Ein Schema (Scheme) kombiniert kryptographische Primitive und andere Techniken, um ein bestimmtes Sicherheitsziel zu erreichen. Dieses Dokument spezifiziert zwei Arten von Schemata: Verschlüsselungsschemata (Encryption Schemes) und Signaturschemata mit Anhang (Signature Schemes with Appendix).

Die in diesem Dokument spezifizierten Schemata sind im Umfang begrenzt, da ihre Operationen nur die Schritte zur Verarbeitung von Daten unter Verwendung eines öffentlichen oder privaten RSA-Schlüssels umfassen und nicht die Schritte zum Erhalten oder Überprüfen von Schlüsseln. Daher werden Anwendungen zusätzlich zu den Schema-Operationen in der Regel Schlüsselverwaltungsoperationen (Key Management Operations) einschließen, durch die Parteien öffentliche und private RSA-Schlüssel für die Schema-Operationen auswählen können. Spezifische zusätzliche Operationen und andere Details liegen außerhalb des Umfangs dieses Dokuments.

Wie bei den kryptographischen Primitiven (Abschnitt 5) geht die Spezifikation der Schema-Operationen davon aus, dass die Eingaben bestimmte Bedingungen erfüllen, insbesondere dass die öffentlichen und privaten RSA-Schlüssel gültig sind. Daher ist das Verhalten von Implementierungen nicht spezifiziert, wenn Schlüssel ungültig sind. Die Auswirkungen dieses nicht spezifizierten Verhaltens hängen von der Anwendung ab. Mögliche Ansätze zur Behandlung des Schlüsselvalidierungsproblems umfassen: explizite Schlüsselvalidierung durch die Anwendung; Schlüsselvalidierung innerhalb einer Public-Key-Infrastruktur; und Zuweisung der Verantwortung für die Durchführung von Operationen mit ungültigen Schlüsseln an die Partei, die die Schlüssel generiert hat.

Eine allgemein gute kryptographische Praxis besteht darin, ein gegebenes RSA-Schlüsselpaar nur in einem Schema zu verwenden. Dies vermeidet das Risiko, dass eine Schwachstelle in einem Schema die Sicherheit eines anderen kompromittieren könnte, und kann entscheidend für die Aufrechterhaltung nachweisbarer Sicherheit (Provable Security) sein. Obwohl RSAES-PKCS1-v1_5 (Abschnitt 7.2) und RSASSA-PKCS1-v1_5 (Abschnitt 8.2) traditionell zusammen ohne bekannte nachteilige Wechselwirkungen verwendet wurden (tatsächlich ist dies das mit PKCS #1 v1.5 eingeführte Modell), wird diese kombinierte Verwendung von RSA-Schlüsselpaaren für neue Anwendungen NICHT EMPFOHLEN (NOT RECOMMENDED).

Um das Risiko zu veranschaulichen, das mit der Verwendung eines RSA-Schlüsselpaars in mehreren Schemata verbunden ist, nehmen Sie an, dass ein RSA-Schlüsselpaar sowohl für RSAES-OAEP (Abschnitt 7.1) als auch für RSAES-PKCS1-v1_5 verwendet wird. Obwohl RSAES-OAEP selbst gegen Angriffe resistent ist, könnte ein Angreifer möglicherweise eine Schwäche in einer RSAES-PKCS1-v1_5-Implementierung ausnutzen, um mit einem der beiden Schemata verschlüsselte Nachrichten wiederherzustellen. Ein anderes Beispiel: Nehmen Sie an, dass ein RSA-Schlüsselpaar sowohl für RSASSA-PSS (Abschnitt 8.1) als auch für RSASSA-PKCS1-v1_5 verwendet wird. In diesem Fall wäre der Sicherheitsbeweis von RSASSA-PSS nicht mehr ausreichend, da der Beweis die Möglichkeit nicht berücksichtigt, dass Signaturen mit dem zweiten Schema generiert werden könnten. Ähnliche Überlegungen können gelten, wenn ein RSA-Schlüsselpaar für eines der hier definierten Schemata und eine anderswo definierte Variante verwendet wird.

7. Verschlüsselungsschemata (Encryption Schemes)​

Für die Zwecke dieses Dokuments besteht ein Verschlüsselungsschema (Encryption Scheme) aus einer Verschlüsselungsoperation und einer Entschlüsselungsoperation, wobei die Verschlüsselungsoperation unter Verwendung des öffentlichen RSA-Schlüssels des Empfängers einen Chiffretext aus einer Nachricht erzeugt und die Entschlüsselungsoperation unter Verwendung des entsprechenden privaten RSA-Schlüssels des Empfängers eine Nachricht aus einem Chiffretext wiederherstellt.

Verschlüsselungsschemata können auf eine Vielzahl von Anwendungsszenarien angewendet werden. Eine typische Anwendung ist das Schlüsselvereinbarungsprotokoll (Key Establishment Protocol), bei dem die Nachricht Schlüsselmaterial enthält, das vertraulich von einer Partei zu einer anderen übertragen werden muss. Beispielsweise verwendet PKCS #7 [RFC2315] solche Protokolle, um einen Inhaltsverschlüsselungsschlüssel von einem Absender zu einem Empfänger zu übertragen; die in diesem Dokument definierten Verschlüsselungsschemata eignen sich für die Verwendung als Schlüsselverschlüsselungsalgorithmen in diesem Kontext.

Dieses Dokument spezifiziert zwei Verschlüsselungsschemata: RSAES-OAEP und RSAES-PKCS1-v1_5. Neue Anwendungen MÜSSEN (REQUIRED) RSAES-OAEP unterstützen; RSAES-PKCS1-v1_5 ist nur für die Kompatibilität mit bestehenden Anwendungen enthalten.

Die hier präsentierten Verschlüsselungsschemata folgen einem allgemeinen Modell ähnlich dem in IEEE 1363 [IEEE1363] verwendeten, das Verschlüsselungs- und Entschlüsselungsprimitive mit einer Kodierungsmethode für die Verschlüsselung kombiniert. Die Verschlüsselungsoperation wendet eine Nachrichtenkodierungsoperation auf die Nachricht an, um eine kodierte Nachricht zu erzeugen, die dann in einen ganzzahligen Nachrichtenrepräsentanten umgewandelt wird. Das Verschlüsselungsprimitiv wird auf den Nachrichtenrepräsentanten angewendet, um den Chiffretext zu erzeugen. Umgekehrt wendet die Entschlüsselungsoperation das Entschlüsselungsprimitiv auf den Chiffretext an, um den Nachrichtenrepräsentanten wiederherzustellen, der dann in eine Oktettzeichenkette der kodierten Nachricht umgewandelt wird. Eine Nachrichtendekodierungsoperation wird auf die kodierte Nachricht angewendet, um die Nachricht wiederherzustellen und die Korrektheit der Entschlüsselung zu überprüfen.

Um Implementierungsschwächen im Zusammenhang mit der Art und Weise zu vermeiden, wie Fehler in der Dekodierungsoperation behandelt werden (siehe [BLEICHENBACHER] und [MANGER]), sind die Kodierungs- und Dekodierungsoperationen von RSAES-OAEP und RSAES-PKCS1-v1_5 in die Spezifikationen der jeweiligen Verschlüsselungsschemata eingebettet, anstatt in separaten Spezifikationen definiert zu werden. Beide Verschlüsselungsschemata sind mit den entsprechenden Schemata in PKCS #1 v2.1 kompatibel.

7.1. RSAES-OAEP​

RSAES-OAEP kombiniert die RSAEP- und RSADP-Primitive (Abschnitt 5.1) mit der EME-OAEP-Kodierungsmethode (in diesem Abschnitt eingebettet). Es basiert auf der von Bellare und Rogaway in [OAEP] erstmals eingeführten Methode der optimalen asymmetrischen Verschlüsselungspolsterung (Optimal Asymmetric Encryption Padding, OAEP). EME-OAEP ist eine Einweg-Variante von EME-OAEP in IEEE 1363 [IEEE1363].

Das Schema ist nicht deterministisch: Für einen gegebenen öffentlichen Schlüssel und eine gegebene Nachricht können viele mögliche Chiffretexte erzeugt werden.

RSAES-OAEP wird für neue Anwendungen empfohlen. RSAES-OAEP kann als bevorzugte Alternative zu RSAES-PKCS1-v1_5 in jeder Anwendung verwendet werden.

Die Sicherheit dieses Schemas basiert auf der Schwierigkeit von zwei Funktionen: dem RSA-Problem und dem Zufallsorakelmodell der Maskengenerierungsfunktion (Mask Generation Function, MGF). Die Sicherheitseigenschaften dieser beiden Funktionen sind in einem Theorembeweis verkörpert, der zeigt, dass die Schwierigkeit, RSAES-OAEP gegen einen Angriff mit gewähltem Chiffretext (Chosen Ciphertext Attack) zu verwenden, im Wesentlichen genauso schwierig ist wie das Lösen des RSA-Problems, vorausgesetzt, dass das MGF sich wie ein Zufallsorakel (Random Oracle) verhält.

7.1.1. Verschlüsselungsoperation (Encryption Operation)​

RSAES-OAEP-ENCRYPT ((n, e), M, L)

Eingabe (Input):

  • (n, e): öffentlicher RSA-Schlüssel des Empfängers (k bezeichnet die Länge des Modulus in Oktetten)
  • M: zu verschlüsselnde Nachricht, eine Oktettzeichenkette der Länge höchstens k - 2hLen - 2, wobei hLen die Ausgabelänge der Hash-Funktion Hash in Oktetten ist
  • L: optionales Label, das mit der Verschlüsselungsoperation verknüpft ist; Standardwert ist die leere Zeichenkette

Ausgabe (Output):

  • C: Chiffretext, eine Oktettzeichenkette der Länge k

Fehler (Errors):

  • "message too long" (Nachricht zu lang)
  • "label too long" (Label zu lang)

Annahme (Assumption): Der öffentliche RSA-Schlüssel (n, e) ist gültig

Schritte (Steps):

  1. Längenprüfung: Wenn die Länge von L die Eingabegrenze für die Maskengenerierungsfunktion überschreitet (die 2^61 - 1 Oktette beträgt), Ausgabe "label too long" und Stopp.

  2. EME-OAEP-Kodierung:

    • Wenn die Länge von M größer als k - 2hLen - 2 Oktette ist, Ausgabe "message too long" und Stopp.
    • Sei lHash = Hash(L), eine Oktettzeichenkette der Länge hLen.
    • Erzeuge eine Polsterzeichenkette PS, bestehend aus k - mLen - 2hLen - 2 Null-Oktetten und einem einzelnen Oktett mit dem Wert 0x01.
    • Konkateniere lHash, PS, das einzelne Byte 0x01 und die Nachricht M, um den Datenblock DB zu bilden: DB = lHash || PS || 0x01 || M
    • Erzeuge eine zufällige Oktettzeichenkette seed der Länge hLen.
    • Sei dbMask = MGF(seed, k - hLen - 1).
    • Sei maskedDB = DB ⊕ dbMask.
    • Sei seedMask = MGF(maskedDB, hLen).
    • Sei maskedSeed = seed ⊕ seedMask.
    • Konkateniere ein einzelnes Oktett mit dem Wert 0x00, maskedSeed und maskedDB, um die kodierte Nachricht EM zu bilden: EM = 0x00 || maskedSeed || maskedDB

  3. RSA-Verschlüsselung:

    • Konvertiere die kodierte Nachricht EM in einen ganzzahligen Nachrichtenrepräsentanten m: m = OS2IP(EM)
    • Wende das RSAEP-Verschlüsselungsprimitiv an: c = RSAEP((n, e), m)
    • Konvertiere den Chiffretextrepräsentanten c in einen Chiffretext C der Länge k: C = I2OSP(c, k)

  4. Gebe den Chiffretext C aus.

7.1.2. Entschlüsselungsoperation (Decryption Operation)​

RSAES-OAEP-DECRYPT (K, C, L)

Eingabe (Input):

  • K: privater RSA-Schlüssel des Empfängers
  • C: zu entschlüsselnder Chiffretext, eine Oktettzeichenkette der Länge k, wobei k die Länge des RSA-Modulus n in Oktetten ist
  • L: optionales Label, dessen Wert mit dem Label während der Verschlüsselungsoperation verknüpft ist, die den Chiffretext erzeugt hat; Standardwert ist die leere Zeichenkette

Ausgabe (Output):

  • M: Nachricht, eine Oktettzeichenkette der Länge höchstens k - 2hLen - 2

Fehler (Error):

  • "decryption error" (Entschlüsselungsfehler)

Schritte (Steps):

  1. Längenprüfung: Wenn die Länge von L die Eingabegrenze überschreitet, Ausgabe "decryption error" und Stopp. Wenn die Länge des Chiffretexts C nicht k Oktette beträgt (oder wenn k < 2hLen + 2), Ausgabe "decryption error" und Stopp.

  2. RSA-Entschlüsselung:

    • Konvertiere den Chiffretext C in einen ganzzahligen Chiffretextrepräsentanten c: c = OS2IP(C)
    • Wende das RSADP-Entschlüsselungsprimitiv an: m = RSADP(K, c). Wenn RSADP "ciphertext representative out of range" ausgibt, Ausgabe "decryption error" und Stopp.
    • Konvertiere den Nachrichtenrepräsentanten m in eine kodierte Nachricht EM der Länge k: EM = I2OSP(m, k)

  3. EME-OAEP-Dekodierung:

    • Sei lHash = Hash(L).
    • Trenne EM in ein einzelnes Oktett Y, eine Oktettzeichenkette maskedSeed der Länge hLen und eine Oktettzeichenkette maskedDB der Länge k - hLen - 1: EM = Y || maskedSeed || maskedDB
    • Sei seedMask = MGF(maskedDB, hLen).
    • Sei seed = maskedSeed ⊕ seedMask.
    • Sei dbMask = MGF(seed, k - hLen - 1).
    • Sei DB = maskedDB ⊕ dbMask.
    • Trenne DB in eine Oktettzeichenkette lHash' der Länge hLen, eine (möglicherweise leere) Polsterzeichenkette PS bestehend aus Oktetten mit dem Wert 0x00, ein einzelnes Oktett mit dem Wert 0x01 und eine Nachricht M: DB = lHash' || PS || 0x01 || M. Wenn es kein Oktett mit dem Wert 0x01 gibt, um PS und M zu trennen, wenn lHash nicht gleich lHash' ist oder wenn Y nicht null ist, Ausgabe "decryption error" und Stopp.

  4. Gebe die Nachricht M aus.

Hinweis: Die Implementierung muss sorgfältig durchgeführt werden, um zu vermeiden, dass die Implementierung versehentlich nützliche Informationen an einen Gegner liefert. Insbesondere dürfen Fehlermeldungen nicht offenbaren, ob ein Oktett in EM oder andere Oktette in DB nicht der erwarteten Form entsprechen.

7.2. RSAES-PKCS1-v1_5​

RSAES-PKCS1-v1_5 kombiniert die RSAEP- und RSADP-Primitive (Abschnitt 5.1) mit der EME-PKCS1-v1_5-Kodierungsmethode. Es ist nur für die Kompatibilität mit bestehenden Anwendungen enthalten; für neue Anwendungen wird die Verwendung von RSAES-OAEP empfohlen.

Die Sicherheit von RSAES-PKCS1-v1_5 hängt von der Schwierigkeit des RSA-Problems ab. Es gibt bekannte potenzielle Schwachstellen (siehe [BLEICHENBACHER]), daher sollten neue Anwendungen RSAES-OAEP verwenden.

7.2.1. Verschlüsselungsoperation (Encryption Operation)​

RSAES-PKCS1-V1_5-ENCRYPT ((n, e), M)

Eingaben, Ausgaben und Schritte sind ähnlich wie bei RSAES-OAEP, verwenden jedoch die EME-PKCS1-v1_5-Kodierung

7.2.2. Entschlüsselungsoperation (Decryption Operation)​

RSAES-PKCS1-V1_5-DECRYPT (K, C)

Eingaben, Ausgaben und Schritte sind ähnlich wie bei RSAES-OAEP, verwenden jedoch die EME-PKCS1-v1_5-Dekodierung

Wichtiger Sicherheitshinweis: Entschlüsselungsfehlermeldungen dürfen nicht zwischen verschiedenen Fehlertypen unterscheiden, um den Bleichenbacher-Angriff mit gewähltem Chiffretext zu verhindern.

8. Signaturschema mit Anhang (Signature Scheme with Appendix)​

Ein Signaturschema mit Anhang (Signature Scheme with Appendix) besteht aus einer Signaturgenerierungsoperation und einer Signaturverifikationsoperation, wobei die Signaturgenerierungsoperation unter Verwendung des privaten RSA-Schlüssels des Unterzeichners eine Signatur aus einer Nachricht erzeugt und die Signaturverifikationsoperation die Authentizität der Signatur unter Verwendung des öffentlichen RSA-Schlüssels des Unterzeichners verifiziert.

Um eine Nachricht M zu signieren, wendet der Unterzeichner eine Nachrichtenkodierungsoperation auf M an, um eine kodierte Nachricht EM zu erzeugen, und wendet dann das Signaturprimitiv an, um eine Signatur S zu erzeugen. Um eine Signatur S zu verifizieren, wendet der Verifizierer das Verifikationsprimitiv auf S an, um die kodierte Nachricht EM wiederherzustellen, und wendet dann die Verifikationsoperation an, um zu bestimmen, ob die Signatur für die Nachricht gültig ist.

Zwei Signaturschemata werden in diesem Dokument spezifiziert: RSASSA-PSS und RSASSA-PKCS1-v1_5.

Obwohl nicht obligatorisch, wird RSASSA-PSS für neue Anwendungen empfohlen. RSASSA-PKCS1-v1_5 ist für die Kompatibilität mit bestehenden Anwendungen enthalten.

8.1. RSASSA-PSS​

RSASSA-PSS kombiniert die RSASP1- und RSAVP1-Primitive (Abschnitt 5.2) mit der EMSA-PSS-Kodierungsmethode. Es basiert auf dem von Bellare und Rogaway vorgeschlagenen probabilistischen Signaturschema (Probabilistic Signature Scheme, PSS) [RSARABIN] [PSS].

Die Sicherheit von PSS basiert auf der Schwierigkeit des RSA-Problems und dem Zufallsorakelmodell des MGF. Es wurde bewiesen, dass unter dem Zufallsorakelmodell, wenn das MGF sich wie ein Zufallsorakel verhält und das RSA-Problem schwierig ist, das PSS-Signaturschema gegen Angriffe mit gewählter Nachricht (Chosen Message Attack) sicher ist.

RSASSA-PSS ist nicht deterministisch: Für eine gegebene Nachricht können mehrere mögliche Signaturen erzeugt werden. Dies liegt daran, dass während der Signaturgenerierungsoperation ein zufälliger Salzwert enthalten ist.

8.1.1. Signaturgenerierungsoperation (Signature Generation Operation)​

RSASSA-PSS-SIGN (K, M)

Eingabe (Input):

  • K: privater RSA-Schlüssel des Unterzeichners
  • M: zu signierende Nachricht, eine Oktettzeichenkette beliebiger Länge

Ausgabe (Output):

  • S: Signatur, eine Oktettzeichenkette der Länge k, wobei k die Länge des RSA-Modulus n in Oktetten ist

Fehler (Errors):

  • "message too long" (Nachricht zu lang)
  • "encoding error" (Kodierungsfehler)

Schritte (Steps):

  1. EMSA-PSS-Kodierung: Wende die EMSA-PSS-Kodierungsoperation auf die Nachricht M an, um eine kodierte Nachricht EM der Länge ⌈(modBits-1)/8⌉ Oktette zu erzeugen, wobei modBits die Länge des RSA-Modulus n in Bits ist: EM = EMSA-PSS-ENCODE(M, modBits - 1). Wenn die Kodierungsoperation "message too long" oder "encoding error" ausgibt, gebe den entsprechenden Fehler aus und stoppe.

  2. RSA-Signatur:

    • Konvertiere die kodierte Nachricht EM in einen ganzzahligen Nachrichtenrepräsentanten m: m = OS2IP(EM)
    • Wende das RSASP1-Signaturprimitiv an: s = RSASP1(K, m)
    • Konvertiere den Signaturrepräsentanten s in eine Signatur S der Länge k: S = I2OSP(s, k)

  3. Gebe die Signatur S aus.

8.1.2. Signaturverifikationsoperation (Signature Verification Operation)​

RSASSA-PSS-VERIFY ((n, e), M, S)

Eingabe (Input):

  • (n, e): öffentlicher RSA-Schlüssel des Unterzeichners
  • M: Nachricht, eine Oktettzeichenkette beliebiger Länge
  • S: zu verifizierende Signatur, eine Oktettzeichenkette der Länge k

Ausgabe (Output):

  • "valid signature" (gültige Signatur) oder "invalid signature" (ungültige Signatur)

Schritte (Steps):

  1. Längenprüfung: Wenn die Länge der Signatur S nicht k Oktette beträgt, Ausgabe "invalid signature" und Stopp.

  2. RSA-Verifikation:

    • Konvertiere die Signatur S in einen ganzzahligen Signaturrepräsentanten s: s = OS2IP(S)
    • Wende das RSAVP1-Verifikationsprimitiv an: m = RSAVP1((n, e), s). Wenn RSAVP1 "signature representative out of range" ausgibt, Ausgabe "invalid signature" und Stopp.
    • Konvertiere den Nachrichtenrepräsentanten m in eine kodierte Nachricht EM der Länge emLen = ⌈(modBits - 1)/8⌉: EM = I2OSP(m, emLen)

  3. EMSA-PSS-Verifikation: Wende die EMSA-PSS-Verifikationsoperation an: Result = EMSA-PSS-VERIFY(M, EM, modBits - 1). Wenn Result = "consistent", Ausgabe "valid signature"; andernfalls Ausgabe "invalid signature".

8.2. RSASSA-PKCS1-v1_5​

RSASSA-PKCS1-v1_5 kombiniert die RSASP1- und RSAVP1-Primitive (Abschnitt 5.2) mit der EMSA-PKCS1-v1_5-Kodierungsmethode. Es ist mit dem IFSSA-Schema in IEEE 1363 [IEEE1363] kompatibel, wobei die Hash-Funktion des DigestInfo-Werts zur Generierung des Nachrichtenrepräsentanten verwendet wird.

Die Sicherheit von RSASSA-PKCS1-v1_5 hängt von der Schwierigkeit des RSA-Problems ab. Obwohl es keinen bekannten Angriff gibt, der dieses Schema erfolgreich bricht, gibt es auch keinen Sicherheitsbeweis wie bei PSS.

8.2.1. Signaturgenerierungsoperation (Signature Generation Operation)​

RSASSA-PKCS1-V1_5-SIGN (K, M)

Die Schritte sind ähnlich wie bei RSASSA-PSS, verwenden jedoch die EMSA-PKCS1-v1_5-Kodierungsmethode

8.2.2. Signaturverifikationsoperation (Signature Verification Operation)​

RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)

Die Schritte sind ähnlich wie bei RSASSA-PSS, verwenden jedoch die EMSA-PKCS1-v1_5-Verifikationsmethode

9. Kodierungsmethoden für Signaturen mit Anhang (Encoding Methods for Signatures with Appendix)​

Kodierungsmethoden werden verwendet, um eine Nachricht in eine kodierte Nachricht umzuwandeln, die dann durch RSA-Signaturprimitive signiert werden kann. Dieser Abschnitt spezifiziert zwei Kodierungsmethoden: EMSA-PSS und EMSA-PKCS1-v1_5.

9.1. EMSA-PSS​

EMSA-PSS (Encoding Method for Signatures with Appendix - Probabilistic Signature Scheme) ist eine probabilistische Kodierungsmethode, die Zufälligkeit enthält und daher für eine gegebene Nachricht mehrere unterschiedliche kodierte Nachrichten erzeugen kann.

9.1.1. Kodierungsoperation (Encoding Operation)​

EMSA-PSS-ENCODE (M, emBits)

Eingabe (Input):

  • M: zu kodierende Nachricht, eine Oktettzeichenkette beliebiger Länge
  • emBits: maximale Bitlänge der kodierten Nachricht, mindestens 8hLen + 8sLen + 9

Ausgabe (Output):

  • EM: kodierte Nachricht, eine Oktettzeichenkette der Länge emLen = ⌈emBits/8⌉

Schritte (Steps):

  1. Wenn die Länge von M größer ist als die Eingabegrenze der Hash-Funktion Hash (2^61 - 1 Oktette für SHA-1), Ausgabe "message too long" und Stopp.

  2. Sei mHash = Hash(M), eine Oktettzeichenkette der Länge hLen.

  3. Wenn emLen < hLen + sLen + 2, Ausgabe "encoding error" und Stopp.

  4. Erzeuge eine zufällige Oktettzeichenkette salt der Länge sLen.

  5. Sei M' = (0x)00 00 00 00 00 00 00 00 || mHash || salt ; M' ist eine Oktettzeichenkette der Länge 8 + hLen + sLen.

  6. Sei H = Hash(M'), eine Oktettzeichenkette der Länge hLen.

  7. Erzeuge eine Oktettzeichenkette PS, die aus emLen - sLen - hLen - 2 Null-Oktetten besteht.

  8. Sei DB = PS || 0x01 || salt ; DB ist eine Oktettzeichenkette der Länge emLen - hLen - 1.

  9. Sei dbMask = MGF(H, emLen - hLen - 1).

  10. Sei maskedDB = DB ⊕ dbMask.

  11. Setze die linkesten 8emLen - emBits Bits von maskedDB auf Null.

  12. Sei EM = maskedDB || H || 0xbc.

  13. Gebe EM aus.

9.1.2. Verifikationsoperation (Verification Operation)​

EMSA-PSS-VERIFY (M, EM, emBits)

Eingabe (Input):

  • M: Nachricht, eine Oktettzeichenkette beliebiger Länge
  • EM: zu verifizierende kodierte Nachricht, eine Oktettzeichenkette der Länge emLen = ⌈emBits/8⌉
  • emBits: maximale Bitlänge der kodierten Nachricht

Ausgabe (Output):

  • "consistent" (konsistent) oder "inconsistent" (inkonsistent)

Schritte: (Die Verifikationsschritte sind die Umkehrung der Kodierungsschritte und überprüfen alle Einschränkungen)

9.2. EMSA-PKCS1-v1_5​

EMSA-PKCS1-v1_5 (Encoding Method for Signatures with Appendix - PKCS #1 v1.5) ist eine deterministische Kodierungsmethode, die für eine gegebene Nachricht immer die gleiche kodierte Nachricht erzeugt.

EMSA-PKCS1-v1_5-ENCODE (M, emLen)

Eingabe (Input):

  • M: zu kodierende Nachricht, eine Oktettzeichenkette beliebiger Länge
  • emLen: erwartete Länge der kodierten Nachricht (in Oktetten), mindestens tLen + 11, wobei tLen die Oktettlänge des DigestInfo-Werts ist

Ausgabe (Output):

  • EM: kodierte Nachricht, eine Oktettzeichenkette der Länge emLen

Schritte (Steps):

  1. Wende die Hash-Funktion auf die Nachricht M an, um den Hash-Wert H zu erzeugen: H = Hash(M). Wenn die Hash-Funktion "message too long" ausgibt, Ausgabe "message too long" und Stopp.

  2. Unter Verwendung der Technik aus der Anmerkung in Abschnitt 9.2, kodiere den DigestInfo-Wert als T für die Hash-Funktion.

  3. Wenn emLen < tLen + 11, Ausgabe "intended encoded message length too short" und Stopp.

  4. Erzeuge eine Oktettzeichenkette PS, die aus emLen - tLen - 3 Oktetten mit dem Wert 0xff besteht.

  5. Konkateniere PS und andere Polsterung, um die kodierte Nachricht EM zu bilden: EM = 0x00 || 0x01 || PS || 0x00 || T

  6. Gebe EM aus.

10. Sicherheitsbetrachtungen​

Sicherheitsaspekte werden in diesem Dokument an verschiedenen Stellen behandelt.

Zentrale Sicherheitsaspekte​

Schlüssellänge​

Die Sicherheit eines RSA-Schlüssels hängt stark von der Größe des Modulus ab. Empfohlene Mindestschlüssellängen sind:

  • 2048 Bit: derzeitige Mindestempfehlung
  • 3072 Bit: für Anwendungen mit hohem Schutzbedarf empfohlen
  • 4096 Bit: für langfristige Schlüssel oder besonders hohe Sicherheitsanforderungen

Auswahl des Verfahrens​

  • RSAES-OAEP: ein Verschlüsselungsverfahren, das neue Anwendungen unterstützen MÜSSEN (REQUIRED)
  • RSASSA-PSS: ein Signaturverfahren, dessen Einsatz für neue Anwendungen EMPFOHLEN wird (RECOMMENDED)
  • PKCS1-v1_5: nur aus Kompatibilitätsgründen beibehalten; bekannte Schwächen sind vorhanden

Hinweise zur Implementierung​

  1. Zufallszahlenerzeugung: Es MUSS ein kryptografisch sicherer Zufallszahlengenerator verwendet werden.
  2. Seitenkanalangriffe: Implementierungen SOLLTEN Timing-Angriffe und Leistungsanalyse verhindern.
  3. Fehlerbehandlung: Fehlermeldungen bei Entschlüsselungs- und Prüfvorgängen SOLLTEN vereinheitlicht werden, damit keine Informationen preisgegeben werden.
  4. Padding-Oracle-Angriffe: RSAES-PKCS1-v1_5 ist für Bleichenbacher-Angriffe anfällig; bei der Implementierung ist besondere Vorsicht erforderlich.

Hash-Funktionen​

  • Nicht verwenden: MD5, SHA-1 (gebrochen)
  • Empfohlen: SHA-256, SHA-384, SHA-512

Schlüsselverwendung​

  • Einzelzweck: Ein RSA-Schlüsselpaar SOLLTE nur für ein Verfahren verwendet werden, entweder Verschlüsselung oder Signatur, nicht für beides.
  • Schlüsselrotation: Schlüssel regelmäßig austauschen.
  • Schutz privater Schlüssel: Private Schlüssel SOLLTEN verschlüsselt gespeichert werden; der Einsatz eines Hardware-Sicherheitsmoduls (HSM) ist eine bewährte Vorgehensweise.

Bekannte Angriffe und Gegenmaßnahmen​

  • Chosen-Ciphertext-Angriff: RSAES-OAEP bietet Schutz.
  • Chosen-Message-Angriff: RSASSA-PSS bietet Schutz.
  • Bleichenbacher-Angriff: Betrifft RSAES-PKCS1-v1_5.
  • Timing-Angriffe: Bei Algorithmen mit konstanter Laufzeit und bei CRT-Beschleunigung ist Vorsicht geboten.

Siehe Abschnitt 6 zur Vermeidung der Verwendung desselben Schlüsselpaars in mehreren Verfahren.

Appendix A. ASN.1-Syntax (ASN.1 Syntax)​

Dieser Anhang fasst die in diesem Dokument verwendete ASN.1-Syntax zusammen. Anhang C enthält das vollständige ASN.1-Modul.

A.1. RSA Key Representation (RSA-Schlüsseldarstellung)​

Dieser Abschnitt definiert die ASN.1-Syntax für öffentliche und private RSA-Schlüssel.

A.1.1. RSA Public Key Syntax (RSA-Öffentlichschlüssel-Syntax)​

Der öffentliche RSA-Schlüssel sollte als ASN.1-Typ RSAPublicKey dargestellt werden:

RSAPublicKey ::= SEQUENCE {
    modulus           INTEGER,  -- n
    publicExponent    INTEGER   -- e
}

Feldbeschreibung:

  • modulus: RSA-Modulus n
  • publicExponent: RSA-Öffentlichschlüssel-Exponent e

In einem gültigen öffentlichen RSA-Schlüssel sollte der Wert des Modulus n das Produkt von u verschiedenen ungeraden Primzahlen r_i (i = 1, 2, ..., u) sein, wobei u >= 2, und der Öffentlichschlüssel-Exponent e sollte eine ganze Zahl zwischen 3 und n - 1 sein, die GCD(e, λ(n)) = 1 erfüllt.

A.1.2. RSA Private Key Syntax (RSA-Privatschlüssel-Syntax)​

Der private RSA-Schlüssel sollte als ASN.1-Typ RSAPrivateKey dargestellt werden:

RSAPrivateKey ::= SEQUENCE {
    version           Version,
    modulus           INTEGER,  -- n
    publicExponent    INTEGER,  -- e
    privateExponent   INTEGER,  -- d
    prime1            INTEGER,  -- p
    prime2            INTEGER,  -- q
    exponent1         INTEGER,  -- d mod (p-1)
    exponent2         INTEGER,  -- d mod (q-1)
    coefficient       INTEGER,  -- (inverse of q) mod p
    otherPrimeInfos   OtherPrimeInfos OPTIONAL
}

Version ::= INTEGER { two-prime(0), multi(1) }
    (CONSTRAINED BY {
        -- version must be multi if otherPrimeInfos present --
    })

OtherPrimeInfos ::= SEQUENCE SIZE(1..MAX) OF OtherPrimeInfo

OtherPrimeInfo ::= SEQUENCE {
    prime             INTEGER,  -- r_i
    exponent          INTEGER,  -- d_i
    coefficient       INTEGER   -- t_i
}

Feldbeschreibung:

  • version: Versionsnummer (two-prime steht für Zwei-Prim-RSA, multi steht für Multi-Prim-RSA)
  • modulus: RSA-Modulus n
  • publicExponent: RSA-Öffentlichschlüssel-Exponent e
  • privateExponent: RSA-Privatschlüssel-Exponent d
  • prime1: Erster Primfaktor p
  • prime2: Zweiter Primfaktor q
  • exponent1: d mod (p-1)
  • exponent2: d mod (q-1)
  • coefficient: CRT-Koeffizient qInv, (q^-1) mod p
  • otherPrimeInfos: Optional, verwendet für zusätzliche Primfaktor-Informationen für Multi-Prim-RSA

A.2. Scheme Identification (Schema-Identifikation)​

Dieser Abschnitt definiert die Objektidentifikatoren (Object Identifiers) für die verschiedenen in diesem Dokument definierten Schemata.

A.2.1. RSAES-OAEP​

Objektidentifikator für das RSAES-OAEP-Verschlüsselungsschema:

id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 }

Algorithmusparametertyp für RSAES-OAEP:

RSAES-OAEP-params ::= SEQUENCE {
    hashFunc          [0] AlgorithmIdentifier DEFAULT sha1,
    maskGenFunc       [1] AlgorithmIdentifier DEFAULT mgf1SHA1,
    pSourceFunc       [2] AlgorithmIdentifier DEFAULT pSpecifiedEmpty
}

A.2.2. RSAES-PKCS1-v1_5​

Objektidentifikator für das RSAES-PKCS1-v1_5-Verschlüsselungsschema:

id-RSAES-PKCS1-v1_5 OBJECT IDENTIFIER ::= { pkcs-1 1 }

Dieses Schema hat keine zugeordneten Parameter.

A.2.3. RSASSA-PSS​

Objektidentifikator für das RSASSA-PSS-Signaturschema:

id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }

Algorithmusparametertyp für RSASSA-PSS:

RSASSA-PSS-params ::= SEQUENCE {
    hashAlgorithm      [0] AlgorithmIdentifier DEFAULT sha1,
    maskGenAlgorithm   [1] AlgorithmIdentifier DEFAULT mgf1SHA1,
    saltLength         [2] INTEGER DEFAULT 20,
    trailerField       [3] INTEGER DEFAULT 1
}

A.2.4. RSASSA-PKCS1-v1_5​

Das RSASSA-PKCS1-v1_5-Signaturschema verwendet die folgenden Objektidentifikatoren für verschiedene Hash-Funktionen:

sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }

Diese Objektidentifikatoren sind mit spezifischen Hash-Funktionen verknüpft.

Appendix B. Unterstützende Techniken (Supporting Techniques)​

Dieser Anhang enthält die Spezifikationen der in diesem Dokument verwendeten unterstützenden Techniken, einschließlich Hash-Funktionen und Maskengenerierungsfunktionen.

B.1. Hash Functions (Hash-Funktionen)​

Hash-Funktionen werden verwendet, um Nachrichten beliebiger Länge auf Ausgaben fester Länge abzubilden. Die in den Schemata dieses Dokuments verwendeten Hash-Funktionen sollten die folgenden Eigenschaften erfüllen:

  1. Urbildresistenz (Preimage Resistance): Gegeben einen Hash-Wert h, ist es rechnerisch nicht durchführbar, eine Nachricht m zu finden, so dass Hash(m) = h
  2. Zweite Urbildresistenz (Second Preimage Resistance): Gegeben eine Nachricht m1, ist es rechnerisch nicht durchführbar, eine andere Nachricht m2 zu finden, so dass Hash(m1) = Hash(m2)
  3. Kollisionsresistenz (Collision Resistance): Es ist rechnerisch nicht durchführbar, zwei beliebige verschiedene Nachrichten m1 und m2 zu finden, so dass Hash(m1) = Hash(m2)

Empfohlene Hash-Funktionen​

Dieses Dokument empfiehlt die Verwendung der folgenden Hash-Funktionen:

Hash-FunktionAusgabelänge(Bits)Ausgabelänge(Bytes)Status
SHA-116020⚠️ Veraltet(nur Abwärtskompatibilität)
SHA-25625632✅ Empfohlen
SHA-38438448✅ Empfohlen
SHA-51251264✅ Empfohlen
SHA-512/22422428✅ Verfügbar
SHA-512/25625632✅ Verfügbar

ASN.1-Identifikation der Hash-Funktionen​

Algorithmus-Identifikator für SHA-256:

id-sha256 OBJECT IDENTIFIER ::= {
    joint-iso-itu-t(2) country(16) us(840) organization(1)
    gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1
}

Algorithmus-Identifikator für SHA-384:

id-sha384 OBJECT IDENTIFIER ::= {
    joint-iso-itu-t(2) country(16) us(840) organization(1)
    gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2
}

Algorithmus-Identifikator für SHA-512:

id-sha512 OBJECT IDENTIFIER ::= {
    joint-iso-itu-t(2) country(16) us(840) organization(1)
    gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3
}

B.2. Mask Generation Functions (Maskengenerierungsfunktionen)​

Eine Maskengenerierungsfunktion (Mask Generation Function, MGF) nimmt eine Oktettkette variabler Länge und eine erforderliche Ausgabelänge als Eingabe und erzeugt eine Ausgabe-Oktettkette der angegebenen Länge. Maskengenerierungsfunktionen können auf Hash-Funktionen oder anderen Funktionen basieren.

Die Hauptverwendung von Maskengenerierungsfunktionen besteht darin, zufällig aussehende Daten in Padding-Schemata zu generieren.

B.2.1. MGF1​

MGF1 ist eine Maskengenerierungsfunktion, die auf einer Hash-Funktion basiert. MGF1 (mgfSeed, maskLen) nimmt einen Seed variabler Länge und eine erforderliche Maskenlänge als Eingabe und gibt eine Maske der angegebenen Länge aus.

MGF1 (mgfSeed, maskLen)

Eingabe (Input)​
mgfSeed     Maskengenerierungs-Seed, Oktettkette beliebiger Länge
maskLen     Erwartete Länge der Maske(in Oktetten)
Ausgabe (Output)​
mask        Maske der Länge maskLen, Oktettkette
Fehler (Error)​

"mask too long" (Maske zu lang)

Schritte (Steps)​

  1. Wenn maskLen > 2^32 * hLen, geben Sie "mask too long" aus und stoppen Sie.

  2. Sei T eine leere Oktettkette.

  3. Für Zähler C von 0 bis ⌈maskLen / hLen⌉ - 1:

    • Konvertieren Sie Zähler C in eine Oktettkette C der Länge 4: C = I2OSP(C, 4)
    • Konkatenieren Sie den Hash von mgfSeed und C zu T: T = T || Hash(mgfSeed || C)

  4. Geben Sie die ersten maskLen Oktette von T als Maske aus.

MGF1-Optionen (MGF1 Options)

Die Standard-Hash-Funktion von MGF1 ist SHA-1. Für neue Anwendungen wird die Verwendung von SHA-256 oder einer höheren Hash-Funktion empfohlen.

ASN.1-Identifikation von MGF1 mit SHA-256:

id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }

-- Der Parameter von MGF1 ist die verwendete Hash-Funktion
AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE {
    algorithm   ALGORITHM.&id({IOSet}),
    parameters  ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
}

Sicherheitsüberlegungen für MGF​

Im Random-Oracle-Modell, wenn die zugrunde liegende Hash-Funktion gut funktioniert, ist die Ausgabe von MGF1 rechnerisch von einer wirklich zufälligen Zeichenkette nicht zu unterscheiden. Dies macht MGF1 für die Verwendung in Schemata wie OAEP und PSS geeignet.

Appendix D. Revisionsgeschichte von PKCS #1 (Revision History of PKCS #1)​

Versionsentwicklung​

PKCS #1 v1.5 (November 1993)​

  • Inhalt: Definition grundlegender Schemata für RSA-Verschlüsselung und -Signatur
  • Verschlüsselung: RSAES-PKCS1-v1_5
  • Signatur: RSASSA-PKCS1-v1_5
  • Status: Weit verbreitet, aber mit bekannten Sicherheitsschwachstellen

PKCS #1 v2.0 (September 1998, RFC 2437)​

  • Neu: RSAES-OAEP-Verschlüsselungsschema
  • Neu: RSASSA-PSS-Signaturschema
  • Verbesserung: Einführung beweisbar sicherer Schemata
  • Beibehalten: v1.5-Schemata zur Wahrung der Abwärtskompatibilität

PKCS #1 v2.1 (Juni 2002, RFC 3447)​

  • Verbesserung: Aktualisierung der RSAES-OAEP- und RSASSA-PSS-Spezifikationen
  • Neu: Unterstützung für zusätzliche Hash-Funktionen (SHA-256, SHA-384, SHA-512)
  • Neu: Vollständiges ASN.1-Modul
  • Klarstellung: Verwendung von Multi-Prim-RSA

PKCS #1 v2.2 (Oktober 2012 / November 2016, RFC 8017)​

  • Verbesserung: Technische Klärungen und Errata-Korrekturen
  • Aktualisierung: Verbesserte Beschreibung der Sicherheitsüberlegungen
  • Neu: Unterstützung für SHA-512/224 und SHA-512/256
  • Status: Aktuelle Version, veröffentlicht als RFC 8017

Zusammenfassung der Hauptänderungen​

  1. v1.5 → v2.0: Einführung beweisbar sicherer OAEP- und PSS-Schemata
  2. v2.0 → v2.1: Verbesserte Hash-Funktionsunterstützung und Multi-Prim-RSA
  3. v2.1 → v2.2: Technische Klärungen und Aktualisierung der Sicherheitsempfehlungen
  4. RFC-Transfer: Von RSA Labs PKCS-Reihe zur IETF RFC-Reihe

Hinweise zur Veralterung​

  • RFC 3447 (PKCS #1 v2.1) wurde durch dieses Dokument (RFC 8017, PKCS #1 v2.2) veraltet
  • RSAES-PKCS1-v1_5 wird nur zur Abwärtskompatibilität beibehalten, nicht für neue Anwendungen empfohlen
  • SHA-1 wird aufgrund bekannter Kollisionsangriffe nicht mehr empfohlen

Hinweise zur Kompatibilität​

Obwohl zwischen den Versionen neue Schemata eingeführt wurden, gilt zur Wahrung der Abwärtskompatibilität:

  • v1.5-Schemata werden in allen Versionen unterstützt
  • Neu hinzugefügte Schemata (OAEP, PSS) koexistieren mit alten Implementierungen
  • ASN.1-Syntax wahrt die Abwärtskompatibilität

Appendix E. Über PKCS (About PKCS)​

Über Public-Key Cryptography Standards (öffentliche Schlüssel-Kryptographie-Standards)​

Public-Key Cryptography Standards (PKCS, öffentliche Schlüssel-Kryptographie-Standards) sind Spezifikationen, die von RSA Laboratories in Zusammenarbeit mit Entwicklern aus Industrie und Wissenschaft erstellt wurden, mit dem Ziel, die Bereitstellung von Public-Key-Kryptographie-Technologien zu beschleunigen.

Überblick über die PKCS-Reihe​

Die PKCS-Reihe wurde ursprünglich von RSA Security Inc. (ehemals RSA Data Security, Inc.) initiiert und umfasst mehrere Standards:

StandardNameStatus
PKCS #1RSA-Kryptographie-Spezifikationen✅ Dieses Dokument (RFC 8017)
PKCS #3Diffie-Hellman-Schlüsselvereinbarungsstandard-
PKCS #5Passwortbasierte Kryptographie-SpezifikationenRFC 2898, RFC 8018
PKCS #6Erweiterte ZertifikatssyntaxstandardVeraltet
PKCS #7Kryptographische NachrichtensyntaxstandardRFC 2315 (durch CMS ersetzt)
PKCS #8Private-Key-Informationssyntax-SpezifikationRFC 5208, RFC 5958
PKCS #9Ausgewählte AttributtypenRFC 2985
PKCS #10Zertifikatsanforderungssyntax-SpezifikationRFC 2986
PKCS #11Kryptographisches Token-Interface (Cryptoki)OASIS-Standard
PKCS #12Persönliche InformationsaustauschsyntaxstandardRFC 7292
PKCS #15Kryptographisches Token-InformationsformatstandardISO/IEC 7816-15

Historische Bedeutung von PKCS #1​

PKCS #1 ist einer der frühesten und wichtigsten Standards in der PKCS-Reihe und definiert die standardisierte Implementierungsmethode für RSA-Kryptographie:

  • Industrielle Akzeptanz: PKCS #1 wird in Protokollen wie SSL/TLS, SSH, S/MIME, PGP weit verbreitet eingesetzt
  • Einfluss auf Standardisierung: Hat internationale Standards wie IEEE 1363, ISO/IEC 18033 beeinflusst
  • Akademischer Beitrag: Die Einführung der OAEP- und PSS-Schemata hat die Entwicklung beweisbar sicherer Kryptographie vorangetrieben

Von RSA Labs zur IETF​

Ab Mitte der 2000er Jahre wurden PKCS-Reihenstandards schrittweise an offene Standardisierungsorganisationen übertragen:

  • IETF: PKCS #1, #5, #7, #8, #9, #10, #12 in RFCs umgewandelt
  • OASIS: PKCS #11 (Cryptoki) in OASIS-Standard umgewandelt
  • ISO/IEC: PKCS #15 in ISO/IEC 7816-Standard integriert

Dieses Dokument (RFC 8017) stellt die Übertragung der Kontrolle über PKCS #1 von RSA Labs zur IETF dar und stellt die kontinuierliche Wartung und Weiterentwicklung dieses Standards sicher.

Danksagungen (Acknowledgements)​

Die Entwicklung von PKCS #1 profitierte von zahlreichen Beiträgen aus der Kryptographie-Community, darunter:

  • Ursprüngliche Autoren: Burt Kaliski, Jake Lacy
  • Theoretische Grundlagen: Mihir Bellare, Phillip Rogaway (OAEP- und PSS-Schemata)
  • v2.0-v2.2-Mitwirkende: Jakob Jonsson, Burt Kaliski, Kathleen Moriarty, Andreas Rusch
  • Review und Feedback: Umfassendes Review von der IETF-Community, RSA Labs und der akademischen Welt

Weitere Informationen​

  • IETF PKCS-Arbeitsgruppe: https://datatracker.ietf.org/wg/pkcs/
  • RSA Labs: http://www.rsa.com/rsalabs/
  • PKCS-Archiv: https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs.htm