înregistrare Logare
Puncte:0
avatar Crypto

OPENSSL CMS: cheia publică a datelor încapsulate, cheia publică a certificatului; Sunt la fel?

drapel cn
poiuy925

Am citit rfc5652 și am făcut date încapsulate prin openssl:

openssl cms -encrypt -in plain -aes256 -recip certificate.pem -outform DER -out enveloped-data.ber

Apoi, verific cheia publică. În primul rând, aici este cheia publică a certificatului.

introduceți descrierea imaginii aici

Și, este cheia publică a datelor încapsulate.

introduceți descrierea imaginii aici

Deci, înțeleg că datele în plic conțin cheia publică a destinatarului (cheia pub a certificatului). Este corect?

Atunci, de ce sunt diferite cele două chei de deasupra?

118
0 + 0
Puncte:2
dave_thompson_085 avatar Crypto
drapel cn
dave_thompson_085

Nu, datele în plic CMS nu conțin cheia publică a destinatarului. (Datele încapsulate și datele criptate sunt diferite, chiar dacă OpenSSL utilizează în mod confuz -criptare și -decriptează pentru prima şi -EncryptedData_encrypt și -EncryptedData_decrypt pentru cel din urmă!) Nu e nevoie; mesajul este trimis destinatarului, iar destinatarul își cunoaște propria cheie.

Datele plic pentru un destinatar cu o cheie ECC utilizează fie ES-ECDH, fie ECMQV cu 1 trecere, iar OpenSSL îl alege pe primul; vedea RFC5753 3.1. După cum sa menționat acolo, aceasta înseamnă că RecipientInfo utilizează KeyAgreeRecipientInfo alegere (cu eticheta 1). După cum este implementat de OpenSSL, acesta constă în:

  • versiune 3

  • originator (etichetă 0 explicit) alegere originatorKey (tag 1 SEQUENCE implicită) care conține AlgorithmIdentifier și BITSTRING care conține, după cum spune RFC5753, „cheia publică efemeră a agentului expeditor”. Rețineți că aceasta este cheia expeditorului, nu a destinatarului și este efemeră, așa că nu este în niciun certificat nici măcar pentru expeditor.

  • ukm (eticheta 1 explicită) opțională și neutilizată

  • keyEncryptionAlgorithm AlgorithmIdentifier pentru dhSinglePass și o cheie simetrică

  • recipientEncryptedKeys o SECVENȚĂ de SECVENȚE care conține fiecare IssuerAndSerialNumber (un DistinguishedName și INTEGER) și cheie criptată (un BITSTRING care este cheia de date ambalată de secretul DH). Acest identifică cheia destinatarului, dar nu o conține.

Se pare că ați omis sau suprimat cel puțin o parte din recipientEncryptedKeys date din imaginea dvs., dar este greu de spus cu siguranță. Iată un exacte afișarea (inclusiv KARI) a unui mesaj pe care l-am creat:

    0:d=0 hl=4 l= 280 contra: SECVENȚA
    4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-envelopedData
   15:d=1 hl=4 l= 265 contra: cont [ 0 ]
   19:d=2 hl=4 l= 261 contra: SECVENȚA
   23:d=3 hl=2 l= 1 prim: INTEGER :02
   26:d=3 hl=3 l= 202 contra: SET
   29:d=4 hl=3 l= 199 contra: cont [ 1 ]
   32:d=5 hl=2 l= 1 prim: INTEGER :03
   35:d=5 hl=2 l= 65 contra: cont [ 0 ]
   37:d=6 hl=2 l= 63 contra: cont [ 1 ]
   39:d=7 hl=2 l= 9 contra: SECVENȚA
   41:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
   50:d=7 hl=2 l= 50 prim: BIT STRING
  102:d=5 hl=2 l= 28 contra: SECVENȚA
  104:d=6 hl=2 l= 9 prim: OBJECT :dhSinglePass-stdDH-sha1kdf-scheme
  115:d=6 hl=2 l= 15 contra: SECVENȚA
  117:d=7 hl=2 l= 11 prim: OBJECT :id-smime-alg-CMS3DESwrap
  130:d=7 hl=2 l= 0 prim: NULL
  132:d=5 hl=2 l= 97 contra: SECVENȚA
  134:d=6 hl=2 l= 95 contra: SECVENȚA
  136:d=7 hl=2 l= 51 contra: SECVENȚA
  138:d=8 hl=2 l= 45 contra: SECVENȚA
  140:d=9 hl=2 l= 43 contra: SET
  142:d=10 hl=2 l= 41 contra: SECVENȚA
  144:d=11 hl=2 l= 3 prim: OBJECT :commonName
  149:d=11 hl=2 l= 34 prim: PRINTABLESTRING :(REDACTATE)
  185:d=8 hl=2 l= 2 prim: INTEGER :(REDACTAT)
  189:d=7 hl=2 l= 40 prim: OCTET STRING [HEX DUMP]:847B0D796D954C05AF37E1AEFE11C7F6762FB8CE2A891AD22B5646E79E95B556EDEC5A2140
  231:d=3 hl=2 l= 51 contra: SECVENȚA
  233:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
  244:d=4 hl=2 l= 20 contra: SECVENȚA
  246:d=5 hl=2 l= 8 prim: OBIECTUL :des-ede3-cbc
  256:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:9780611D4883D5B1
  266:d=4 hl=2 l= 16 prim: cont [ 0 ]
0 + 0
drapel cn
poiuy925
Oh, când versiunea este 3, funcționează folosind DH? Apoi, cheia publică a inițiatorului este folosită pentru decriptare? În plus, curba este aceeași cu cea a destinatarului?
0
Răspunde
dave_thompson_085 avatar
drapel cn
dave_thompson_085
Nu, când eticheta RecipientInfo este 1, algoritmul de acord de cheie este determinat de keyEncryptionAlgorithm, pe care OpenSSL îl specifică ca (EC)DH; Versiunea KARI este întotdeauna 3 așa cum se menționează atât în ​​RFC5652, cât și în RFC5753. Da, pentru DH în modul E-S, destinatarul folosește cheia publică efemeră a inițiatorului și propria sa cheie privată pentru a calcula secretul partajat și a decripta; vezi restul secțiunii 3.1 din RFC5753 la care v-am indicat. Da, pentru ECDH cele două părți folosesc aceeași curbă (sau pentru orice fel de DH același grup).
0
Răspunde
drapel cn
poiuy925
Mulțumesc! :) Voi citi RFC5753 chiar acum
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.