december 26, 2020
Articles
Inga kommentarer

Finns det en specifikation för “ Börja RSA PRIVATE KEY ” -format?

Hittills hittade jag inte en specifikation (RFC eller liknande) för filformatet som använder prefixet BEGIN RSA PRIVATE KEY och END RSA PRIVATE KEY suffix Var är det definierat? Finns det ett officiellt namn på det? Det verkar åtminstone vara relaterat till serien av PEM-RFC: er.

Jag letar efter referensinformation om detaljerna i blankstegshantering, base64-detaljer , sammanfogning av olika nycklar i en fil etc ..

Den här frågan handlar INTE om ASN-kodning av nyttolasten.

Kommentarer

  • OpenPGP-specifikationen beskriver liknande ASCII-Armor-format.
  • tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
  • De flesta PEM-format (även andra än RSA Private Key) är dokumenterade i RFC 7468: Textkodning av PKIX-, PKCS- och CMS-strukturer . Det finns t.ex. några riktlinjer för ämnet för hantering av utrymme. att detaljerna varierar beroende på parser.
  • Tack till user4982: Det här är den typ av källa jag letar efter. RFC 7468 innehåller dock information om etiketten ” Krypterad privat nyckel ”, men ’ t för ” RSA PRIVAT NYCKEL ”.
  • PEM definieras i RFC 1421 som beskriver rubrikens övergripande format etc. Men jag kunde inte ’ inte hitta om ” RSA PRIVAT NYCKEL ”. Denna artikel från 1997 nämner redan OpenSSL med den.

Svar

Jag är här, för jag frågar mig samma fråga som OP.

PKCS # 1 (RFC 3447) definierar ASN.1-strukturen: RSAPrivateKey, tillåter endast uttrycket av en RSA-privatnyckel.

PKCS # 8 (RFC 5208) definierar ASN.1-strukturen: PrivateKeyInfo, vilket tillåter uttryck för vilken som helst privat nyckel. (För en RSA-privatnyckel är PrivateKeyInfo viss förpackningsinformation och återanvändning av RSAPrivateKey från PKCS # 1).

PEM (Privacy Enhanced Mail) är en avstängd metod för säker e-post. Men behållarformatet lånades ut för förpackning av kryptografiska föremål.

RFC 7468 (Inledning): ” Av skäl som i grunden går ut på att inte samordna eller uppmärksamma många PKIX-, PKCS- och CMS-bibliotek implementera en textbaserad kodning som liknar – men inte är identisk med – PEM-kodning . ”

Vilket lyder som: Um, folk har beslutat att använda bitar av PEM för att paketera sina kryptofiler . Här har vi ett jättebra försök att försöka formalisera det …

Ack, RFC 7468 klargör förpackningen PKCS # 8 / PrivateKeyInfo som ”BEGIN PRIVATE KEY”. Men inte förpackningen av PKCS # 1 / RSAPrivateKey som ”BEGIN RSA PRIVATE KEY”.

Förpackningen ”BEGIN RSA PRIVATE KEY” kallas ibland: ”SSLeay format” eller ”traditionellt format” för privat nyckel. Som, åtminstone, ger oss ett namn för detta format, men som dig själv kan jag inte hitta, och skulle välkomna, något som närmar sig en formell beskrivning av detta format. Jag misstänker att detta inte finns.

Kommentarer

  • I'm here, because, I'm asking myself the same question as the OP. – – För att klargöra: är detta ditt svar på frågan som ställts ovan, eller frågar du dig själv samma fråga?

Svar

Formatet för base64-innehållet inuti: 

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

är dokumenterat i RFC3447 – Appendix A.1.2 – RSA private key syntax : 

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 }

Du vet redan hur du kodar det med DER smak av ASN.1; och frågan handlar om hur man faktiskt skriver DER-binära data till en fil.

Det nästa steget dokumenteras i RFC 1421 – 4.3.2.4 Steg 4 : Utskrivbar kodning

  • de dokumenterar kodning av binära data i base64
  • som kodar utdata som textrader
  • med varje rad ( utom det sista) som innehåller exakt 64 utskrivbara tecken
  • och den sista raden som innehåller 64 eller färre utskrivbara tecken

Det finns då ”Encapsulation Boundary” (EB) för att avgränsa inkapslade PEM-meddelanden.

  • strängen före EB är: -----BEGIN PRIVACY-ENHANCED MESSAGE-----
  • strängen efter EB är: -----END PRIVACY-ENHANCED MESSAGE-----

Det var defekten Privacy Enhanced Mail som använde:

  • fem bindestreck (-----)
  • BEGIN something
  • fem bindestreck (-----)

följt av

  • fem bindestreck (-----)
  • END something
  • fem bindestreck (-----)

Dessa PEM-konventioner överfördes för offentlig nyckel, privat nyckel och certifikat, men med lämpliga ändrad formulering: 

-----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-----

Svar

Ja. RFC7468 – Textkodningar av PKIX-, PKCS- och CMS-strukturer

Detta dokument artikulerar de facto-reglerna enligt vilka befintliga implementeringar fungerar och definierar dem så att framtida implementeringar kan samverka.

Här ”är ett relevant utdrag:

10. En asymmetrisk nyckel och textkodning av PKCS # 8 privat nyckelinformation

Okrypterad PKCS # 8 Private Key Information Syntaxstrukturer (PrivateKeyInfo), bytt namn till Asymmetric Key Packages (OneAsymmetricKey), kodas med etiketten ”PRIVATE KEY”. De kodade data MÅSTE vara en BER ( DER föredras; se bilaga B) kodad ASN.1 PrivateKeyInfo-struktur som beskrivs i PKCS # 8 [RFC5208], eller en OneAsymmetricKey-struktur som beskrivs i [RFC5958]. De två är semantiskt identiska och kan särskiljas genom versionsnummer. 

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

Kommentarer

  • Jag frågar om ” RSA PRIVATE KEY ”, inte om ” CERTIFIKATFÖRFRÅGAN ”. Förresten, jag förväntar mig PKCS # 8 eller PKCS # 1, inte PKCS # 10. Kapitel 10 skulle vara närmare. Men det

anger inte RSA i etiketten, så det är vettigt att använda PKCS # 8 här. Eftersom nyckelalgoritmen skulle anges överflödigt kan det vara OK (och jag såg exempel) att placera PKCS # 1 i en ” RSA PRIVATE KEY ” -fil.

  • @ Som jag redan sa letar jag efter ” RSA PRIVATE KEY ”, inte för ” PRIVAT NYCKEL ”. Så även kapitel 10 är inte tillämpligt och RFC7468 är ett felaktigt svar.
  • @Gustave Jag ’ jag är medveten om att du skrev ” RSA PRIVATE KEY ”, men att ange formatet för den privata nyckeln i rubriken är onödigt och specifikationen är relevant.
  • ABNF läser < < textualmsg = preeb * WSP (…) > > och < < preeb = ” —- -BEGIN ” label ” —– ” (…) > >. Så varför tror du att rubriken är onödig?
  • PKCS # 1 ( tools.ietf.org/html/rfc8017#appendix-A.1.2 ) anger inte ’ t någon ASCII base64-kodning, och ’ t specificerar inte -----BEGIN RSA PRIVATE KEY----- rubrik. PKCS # 8 anger inte ’ någon ASCII base64-kodning heller. I kapitel 10 anges -----BEGIN PRIVATE KEY-----. Har du en länk till en standard som anger -----BEGIN RSA PRIVATE KEY----- rubriken?

    • Lämna ett svar

    Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *