Join Log in
Score:0
avatar Crypto

OPENSSL CMS: Enveloped data's public key, Certificate's public key; Are they same?

cn flag
poiuy925

I read the rfc5652, and I made enveloped data via openssl:

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

Then, I check the public key. First, here is the certificate's public key.

enter image description here

And, it is the enveloped data's public key.

enter image description here

So, I understand that enveloped data contain the recipient's public key(certificate's pub key). Is it right?

Then, why are above two key's different?

118
0 + 0
cms
Score:2
dave_thompson_085 avatar Crypto
cn flag
dave_thompson_085

No, CMS enveloped-data does not contain the recipient's publickey. (Enveloped-data and encrypted-data are different, even though OpenSSL confusingly uses -encrypt and -decrypt for the former and -EncryptedData_encrypt and -EncryptedData_decrypt for the latter!) There's no need to; the message is sent to the recipient, and the recipient know their own key(s).

Enveloped-data for a recipient with an ECC key uses either ES-ECDH or 1-pass ECMQV, and OpenSSL chooses the former; see RFC5753 3.1. As stated there, this means the RecipientInfo uses the KeyAgreeRecipientInfo choice (with tag 1). As implemented by OpenSSL this consists of:

  • version 3

  • originator (tag 0 explicit) choice originatorKey (tag 1 implicit SEQUENCE) containing AlgorithmIdentifier and BITSTRING which contains, as RFC5753 says "the sending agent's ephemeral EC public key". Note this is the sender's key not the recipient's, and is ephemeral so it is not in any certificate even for the sender.

  • ukm (tag 1 explicit) optional and not used

  • keyEncryptionAlgorithm AlgorithmIdentifier for dhSinglePass and a symmetric key wrap

  • recipientEncryptedKeys a SEQUENCE of SEQUENCEs each containing IssuerAndSerialNumber (a DistinguishedName and INTEGER) and encryptedKey (a BITSTRING which is the data key wrapped by the DH secret). This identifies the recipient key but does not contain it.

You appear to have omitted or suppressed at least part of the recipientEncryptedKeys data in your image, but it's hard to tell for sure. Here's an accurate display (including KARI) of a message I created:

    0:d=0  hl=4 l= 280 cons: SEQUENCE
    4:d=1  hl=2 l=   9 prim:  OBJECT            :pkcs7-envelopedData
   15:d=1  hl=4 l= 265 cons:  cont [ 0 ]
   19:d=2  hl=4 l= 261 cons:   SEQUENCE
   23:d=3  hl=2 l=   1 prim:    INTEGER           :02
   26:d=3  hl=3 l= 202 cons:    SET
   29:d=4  hl=3 l= 199 cons:     cont [ 1 ]
   32:d=5  hl=2 l=   1 prim:      INTEGER           :03
   35:d=5  hl=2 l=  65 cons:      cont [ 0 ]
   37:d=6  hl=2 l=  63 cons:       cont [ 1 ]
   39:d=7  hl=2 l=   9 cons:        SEQUENCE
   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 cons:      SEQUENCE
  104:d=6  hl=2 l=   9 prim:       OBJECT            :dhSinglePass-stdDH-sha1kdf-scheme
  115:d=6  hl=2 l=  15 cons:       SEQUENCE
  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 cons:      SEQUENCE
  134:d=6  hl=2 l=  95 cons:       SEQUENCE
  136:d=7  hl=2 l=  51 cons:        SEQUENCE
  138:d=8  hl=2 l=  45 cons:         SEQUENCE
  140:d=9  hl=2 l=  43 cons:          SET
  142:d=10 hl=2 l=  41 cons:           SEQUENCE
  144:d=11 hl=2 l=   3 prim:            OBJECT            :commonName
  149:d=11 hl=2 l=  34 prim:            PRINTABLESTRING   :(REDACTED)
  185:d=8  hl=2 l=   2 prim:         INTEGER           :(REDACTED)
  189:d=7  hl=2 l=  40 prim:        OCTET STRING      [HEX DUMP]:847B0D796D954C05AF37E1AEFE11C7F6762FB8CE2A891AD22B5646E79E95B556EDEC5A240ACCC621
  231:d=3  hl=2 l=  51 cons:    SEQUENCE
  233:d=4  hl=2 l=   9 prim:     OBJECT            :pkcs7-data
  244:d=4  hl=2 l=  20 cons:     SEQUENCE
  246:d=5  hl=2 l=   8 prim:      OBJECT            :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
cn flag
poiuy925
Oh, when the version is 3, is it working using DH? Then, the originator's public key is used for decryption? Plus, the curve is same as recipient's?
0
Reply
dave_thompson_085 avatar
cn flag
dave_thompson_085
No, when RecipientInfo tag is 1 the keyagreement algorithm is determined by keyEncryptionAlgorithm, which OpenSSL specifies as (EC)DH; KARI version is always 3 as stated in both RFC5652 and RFC5753. Yes, for DH in E-S mode the recipient uses the originator's ephemeral publickey and its own privatekey to compute the shared secret, and decrypt; see the rest of section 3.1 in RFC5753 which I pointed you to. Yes, for ECDH the two parties use the same curve (or for any kind of DH the same group).
0
Reply
cn flag
poiuy925
Thank you! :) I gonna read RFC5753 right now
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.