Până acum nu am găsit o specificație (RFC sau similar) pentru formatul de fișier care utilizează prefixul BEGIN RSA PRIVATE KEY și END RSA PRIVATE KEY sufix . Unde este definit? Există un nume oficial pentru acesta? Se pare că este cel puțin legat de seria RFC-urilor PEM.
Caut informații de referință despre detaliile despre manipularea spațiului alb, detalii baz64 , alăturarea diferitelor chei într-un singur fișier etc.
Această întrebare NU se referă la codificarea ASN a sarcinii utile.
Comentarii
- Specificația OpenPGP descrie formate similare ASCII-Armor.
- tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
- Cele mai multe formate PEM (de asemenea, altele decât RSA Private Key) sunt documentate în RFC 7468: Codificări textuale ale Structurile PKIX, PKCS și CMS . Există, de exemplu, câteva îndrumări cu privire la subiectul gestionării spațiului alb. că detaliile variază în funcție de analizor.
- Mulțumesc user4982: Acesta este tipul de sursă pe care o caut. Cu toate acestea, RFC 7468 conține informații referitoare la eticheta ” CHEIE PRIVATĂ Criptată „, dar nu ‘ t pentru ” RSA PRIVATE KEY „.
- PEM este definit în RFC 1421 care descrie formatul general al antetului etc. Dar nu am putut ‘ să aflu despre ” RSA PRIVATE KEY „. Acest articol din 1997 menționează deja OpenSSL care îl utilizează.
Răspuns
Eu sunt aici, pentru că îmi pun aceeași întrebare ca OP.
PKCS # 1 (RFC 3447) definește structura ASN.1: RSAPrivateKey, permițând expresia unei chei private RSA numai.
PKCS # 8 (RFC 5208) definește structura ASN.1: PrivateKeyInfo, permițând expresia oricărei chei private. (Pentru o cheie privată RSA, PrivateKeyInfo este o informație de ambalare și o reutilizare a RSAPrivateKey din PKCS # 1).
PEM (Privacy Enhanced Mail), este o metodă defunctă pentru e-mail securizat. Dar, formatul său de container a fost împrumutat pentru ambalarea articolelor criptografice.
RFC 7468 (Introducere): „ Din motive care se rezumă practic la necoordonare sau neatenție, multe biblioteci PKIX, PKCS și CMS implementați o codificare bazată pe text care este similară – dar nu identică cu – codificarea PEM . „
Care citește: Um, oamenii au decis să folosească biți de PEM pentru a împacheta fișierele lor cripto . Aici avem un efort vesel de bun pentru a încerca să formalizăm asta …
Din păcate, RFC 7468 clarifică ambalajul PKCS # 8 / PrivateKeyInfo ca „BEGIN PRIVATE KEY”. Dar nu ambalarea PKCS # 1 / RSAPrivateKey ca „BEGIN RSA PRIVATE KEY”.
Ambalajul „BEGIN RSA PRIVATE KEY” se numește uneori: „SSLeay format” sau „format tradițional” pentru cheia privată. Ceea ce, cel puțin, ne dă un nume pentru acest format, dar, ca și tine, nu pot găsi și aș dori să primesc ceva care abordează o descriere formală a acestui format. Bănuiesc că acest lucru nu există.
Comentarii
-
I'm here, because, I'm asking myself the same question as the OP.– – Pentru a clarifica: acesta este răspunsul dvs. la întrebarea pusă mai sus sau chiar vă puneți aceeași întrebare?
Răspuns
Formatul conținutului base64 din interior:
-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY----- este documentat în RFC3447 – Anexa A.1.2 – Sintaxa cheii private RSA :
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 } Știți deja cum să codificați acest lucru folosind DER aroma ASN.1; iar întrebarea este despre cum să scriem datele binare DER într-un fișier.
Următorul pas este documentat în RFC 1421 – 4.3.2.4 Pasul 4 : Codificare imprimabilă
- documentează codificarea datelor binare din baza64
- codificarea ieșirii ca linii de text
- cu fiecare linie ( cu excepția ultimei) care conține exact 64 de caractere imprimabile
- și linia finală conținând 64 sau mai puține caractere imprimabile
Există apoi „Limita de încapsulare” (EB), utilizată pentru a delimita mesajele PEM încapsulate.
- șirul pre-EB este:
-----BEGIN PRIVACY-ENHANCED MESSAGE----- - șirul post-EB este:
-----END PRIVACY-ENHANCED MESSAGE-----
Defectul Mail îmbunătățit de confidențialitate a folosit:
- cinci cratime (
-----) -
BEGINsomething - cinci cratime (
-----)
urmată de
- cinci cratime (
-----) -
ENDsomething - cinci cratime (
-----)
Acele convenții PEM au fost reportate pentru cheia publică, cheia privată și certificatele, dar cu text modificat:
-----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----- Răspuns
Da. RFC7468 – Codificări textuale ale structurilor PKIX, PKCS și CMS
Acest document articulează regulile de facto prin care funcționează implementările existente și le definește astfel încât implementările viitoare să poată interopera.
Aici este un extract relevant:
10. O cheie asimetrică și codificarea textuală a PKCS # 8 Informații despre cheia privată
Structurile de sintaxă a informațiilor despre cheia privată PKCS # 8 necriptată (PrivateKeyInfo), redenumite pachete de chei asimetrice (OneAsymmetricKey), sunt codificate folosind eticheta „CHEIE PRIVATĂ”. DER preferat; vezi Anexa B) codificată ASN.1 PrivateKeyInfo structura descrisă în PKCS # 8 [RFC5208], sau o structură OneAsymmetricKey descrisă în [RFC5958]. Cele două sunt semantic identice și se pot distinge prin numărul versiunii.
-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY----- Comentarii
- Întreb despre ” CHEIE PRIVATĂ RSA „, nu despre ” CERERE CERTIFICAT „. Apropo, m-aș aștepta la PKCS # 8 sau PKCS # 1, nu la PKCS # 10. Capitolul 10 ar fi mai aproape. Dar ‘ nu specifică RSA în etichetă, deci are sens să folosiți PKCS # 8 aici. Deoarece algoritmul cheie ar fi specificat redundant, ar putea fi OK (și am văzut exemple) să pun PKCS # 1 într-un ” RSA PRIVATE KEY ” fișier.
- @Așa cum am spus deja, caut ” TASTĂ PRIVATĂ RSA „, nu pentru ” CHEIE PRIVATĂ „. Deci, nici capitolul 10 nu se aplică, iar RFC7468 este un răspuns greșit.
- @Gustave
știu că ați scris ” TASTĂ PRIVATĂ RSA „, cu toate acestea, nu este necesară specificarea formatului cheii private în antet și specificația este relevantă.
-----BEGIN RSA PRIVATE KEY----- antet. PKCS # 8 nu ‘ nu specifică nici o codificare ASCII base64. Capitolul 10 specifică într-adevăr -----BEGIN PRIVATE KEY-----. Aveți un link către un standard care specifică antetul -----BEGIN RSA PRIVATE KEY-----?