Dezember 26, 2020
Articles
Keine Kommentare

Gibt es eine Spezifikation für das Format “ RSA PRIVATE KEY ”?

Bis jetzt habe ich keine Spezifikation (RFC oder ähnliches) für das Dateiformat gefunden, das das Präfix BEGIN RSA PRIVATE KEY und das Suffix END RSA PRIVATE KEY verwendet Wo ist es definiert? Gibt es einen offiziellen Namen dafür? Es scheint zumindest mit der Reihe von PEM-RFCs verwandt zu sein.

Ich suche nach Referenzinformationen zu den Details der Whitespace-Behandlung, base64-Details , Zusammenfügen verschiedener Schlüssel in einer Datei usw.

Bei dieser Frage geht es NICHT um die ASN-Codierung der Nutzdaten.

Kommentare

  • Die OpenPGP-Spezifikation beschreibt ähnliche ASCII-Armor-Formate.
  • tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
  • Die meisten PEM-Formate (auch außer RSA Private Key) sind in RFC 7468: Textcodierungen von dokumentiert PKIX-, PKCS- und CMS-Strukturen . Es gibt z. B. einige Anleitungen zum Thema Whitespace-Behandlung. Dieser RFC stellt dies grundsätzlich fest Diese Details variieren je nach Parser.
  • Dank an user4982: Dies ist die Art von Quelle, nach der ich suche. RFC 7468 enthält jedoch Informationen zum Label “ ENCRYPTED PRIVATE KEY „, jedoch nicht ‚ t für “ RSA PRIVATE KEY „.
  • PEM ist in RFC 1421 , der das Gesamtformat des Headers usw. beschreibt. Aber ‚ konnte “ RSA PRIVATE KEY „. In diesem Artikel aus dem Jahr 1997 wird OpenSSL bereits erwähnt.

Antwort

Ich bin hier, weil ich mir die gleiche Frage wie das OP stelle.

PKCS # 1 (RFC 3447) definiert die ASN.1-Struktur: RSAPrivateKey, sofern zulässig Nur der Ausdruck eines privaten RSA-Schlüssels.

PKCS # 8 (RFC 5208) definiert die ASN.1-Struktur: PrivateKeyInfo und ermöglicht den Ausdruck eines beliebigen privaten Schlüssels. (Bei einem privaten RSA-Schlüssel handelt es sich bei PrivateKeyInfo um einige Verpackungsinformationen und eine Wiederverwendung von RSAPrivateKey aus PKCS # 1.)

PEM (Privacy Enhanced Mail) ist eine nicht mehr verfügbare Methode für sichere E-Mails. Das Containerformat wurde jedoch zum Verpacken kryptografischer Elemente ausgeliehen.

RFC 7468 (Einführung): „ Aus Gründen, die im Wesentlichen auf Nichtkoordination oder Unaufmerksamkeit zurückzuführen sind, sind viele PKIX-, PKCS- und CMS-Bibliotheken vorhanden Implementieren Sie eine textbasierte Codierung, die der PEM-Codierung ähnlich, aber nicht identisch ist. „

Sie lautet wie folgt: Ähm, die Leute haben beschlossen, PEM-Bits zum Packen ihrer Kryptodateien zu verwenden . Hier haben wir eine gute Anstrengung, um zu versuchen, das zu formalisieren …

Leider verdeutlicht RFC 7468 die PKCS # 8 / PrivateKeyInfo-Verpackung als „BEGIN PRIVATE KEY“. Aber nicht die Verpackung von PKCS # 1 / RSAPrivateKey als „BEGIN RSA PRIVATE KEY“.

Die Verpackung „BEGIN RSA PRIVATE KEY“ wird manchmal als „SSLeay-Format“ oder „traditionelles Format“ für privaten Schlüssel bezeichnet. Was uns zumindest einen Namen für dieses Format gibt, aber wie Sie kann ich etwas nicht finden und würde es begrüßen, das sich einer formalen Beschreibung dieses Formats nähert. Ich vermute, dass dies nicht existiert.

Kommentare

  • I'm here, because, I'm asking myself the same question as the OP. – – Zur Verdeutlichung: Ist dies Ihre Antwort auf die oben gestellte Frage, oder stellen Sie sich tatsächlich dieselbe Frage?

Antwort

Das Format des base64-Inhalts in: 

-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY-----

ist in RFC3447 – Anhang A.1.2 – Syntax des privaten RSA-Schlüssels : 

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 }

Sie wissen bereits, wie Sie dies mit dem DER codieren Geschmack von ASN.1; und die Frage ist, wie diese DER-Binärdaten tatsächlich in eine Datei geschrieben werden.

Dieser nächste Schritt ist in RFC 1421 – 4.3.2.4 Schritt 4 dokumentiert : Druckbare Codierung

  • Sie dokumentieren die Codierung der Binärdaten in base64
  • und codieren die Ausgabe als Textzeilen
  • mit jeder Zeile ( außer dem letzten) mit genau 64 druckbaren Zeichen
  • und der letzten Zeile mit 64 oder weniger druckbaren Zeichen

Es wird dann die „Encapsulation Boundary“ (EB) verwendet eingekapselte PEM-Nachrichten abgrenzen.

  • Die Pre-EB-Zeichenfolge lautet: -----BEGIN PRIVACY-ENHANCED MESSAGE-----
  • Die Post-EB-Zeichenfolge lautet: -----END PRIVACY-ENHANCED MESSAGE-----

Es war das fehlerhafte Privacy Enhanced Mail , das Folgendes verwendete:

  • fünf Bindestriche (-----)
  • BEGIN something
  • fünf Bindestriche (-----)

gefolgt von

  • fünf Bindestrichen (-----)
  • END something
  • fünf Bindestriche (-----)

Diese PEM-Konventionen wurden für öffentliche Schlüssel, private Schlüssel und Zertifikate übertragen, jedoch mit geeigneten geänderter Wortlaut: 

-----BEGIN RSA PUBLIC KEY----- ...base64 encoded DER ASN.1 RSAPublicKey... -----END RSA PUBLIC KEY-----

  

-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY-----

  

-----BEGIN PUBLIC KEY----- ...base64 encoded DER ASN.1 SubjectPublicKeyInfo... -----END PUBLIC KEY-----

  

-----BEGIN PRIVATE KEY----- ...base64 encoded DER ASN.1 PrivateKeyInfo... -----END PUBLIC KEY-----

  

-----BEGIN CERTIFICATE----- ...base64 encoded DER ASNl.1 Certificate... -----END CERTIFICATE-----

Antwort

Ja. RFC7468 – Textcodierungen von PKIX-, PKCS- und CMS-Strukturen

Dieses Dokument wird artikuliert Die De-facto-Regeln, nach denen vorhandene Implementierungen arbeiten, und definieren sie, damit zukünftige Implementierungen zusammenarbeiten können.

Hier ist ein relevanter Auszug:

10. Ein asymmetrischer Schlüssel und die Textcodierung von PKCS # 8 Private Key Info

Unverschlüsselte PKCS # 8-Syntaxstrukturen für private Schlüsselinformationen (PrivateKeyInfo), umbenannt in Asymmetric Key Packages (OneAsymmetricKey), werden mit dem Label „PRIVATE KEY“ codiert. Die codierten Daten MÜSSEN eine BER sein ( DER bevorzugt; siehe Anhang B) codierte ASN.1 PrivateKeyInfo-Struktur wie in PKCS # 8 [RFC5208] beschrieben oder eine OneAsymmetricKey-Struktur wie in [RFC5958] beschrieben. Die beiden sind semantisch identisch und können durch die Versionsnummer unterschieden werden. P. > 

-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY-----

Kommentare

  • Ich frage nach “ RSA PRIVATE KEY „, nicht über “ ZERTIFIKATSANFRAGE „. Übrigens würde ich PKCS # 8 oder PKCS # 1 erwarten, nicht PKCS # 10. Kapitel 10 wäre näher. ‚ gibt jedoch keine RSA in der Bezeichnung an, daher ist es sinnvoll, hier PKCS # 8 zu verwenden. Da der Schlüsselalgorithmus redundant angegeben würde, könnte es in Ordnung sein (und ich habe Beispiele gesehen), PKCS # 1 in einen “ RSA PRIVATE KEY “ Datei.
  • @ Wie ich bereits sagte, suche ich nach “ RSA PRIVATE KEY „, nicht für “ PRIVATE KEY „. Selbst Kapitel 10 ist nicht anwendbar, und RFC7468 ist eine falsche Antwort.
  • @Gustave Ich ‚ weiß, dass Sie “ RSA PRIVATE KEY “ Die Angabe des Formats des privaten Schlüssels im Header ist jedoch nicht erforderlich und die Spezifikation ist relevant.
  • Der ABNF lautet < < textualmsg = preeb * WSP (…) > > und < < preeb = “ —- -BEGIN “ label “ —– “ (…) > >. Warum ist der Header Ihrer Meinung nach nicht erforderlich?
  • PKCS # 1 ( tools.ietf.org/html/rfc8017#appendix-A.1.2 ) gibt ‚ keine ASCII-Base64-Codierung an, und ‚ gibt nicht die Header. PKCS # 8 ‚ gibt auch keine ASCII-Base64-Codierung an. Kapitel 10 gibt tatsächlich -----BEGIN PRIVATE KEY----- an. Haben Sie einen Link zu einem Standard, der den -----BEGIN RSA PRIVATE KEY----- -Header angibt?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.