Điểm:0

OPENSSL CMS: Khóa chung của dữ liệu được bao bọc, Khóa chung của chứng chỉ; Họ có giống nhau không?

lá cờ cn

Tôi đã đọc rfc5652 và tôi đã tạo dữ liệu được bao bọc qua openssl:

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

Sau đó, tôi kiểm tra khóa công khai. Đầu tiên, đây là khóa công khai của chứng chỉ.

nhập mô tả hình ảnh ở đây

Và, nó là khóa công khai của dữ liệu được bao bọc.

nhập mô tả hình ảnh ở đây

Vì vậy, tôi hiểu rằng dữ liệu được bao bọc chứa khóa công khai của người nhận (khóa công khai của chứng chỉ). Đúng không?

Sau đó, tại sao hai phím trên lại khác nhau?

Điểm:2
lá cờ cn

Không, dữ liệu bao bọc CMS không chứa khóa công khai của người nhận. (Dữ liệu được bao bọc và dữ liệu được mã hóa là khác nhau, mặc dù OpenSSL sử dụng một cách khó hiểu -mã hóa-giải mã cho trước đây và -EncryptedData_encrypt-EncryptedData_decrypt cho cái sau!) Không cần; tin nhắn được gửi đến người nhận và người nhận biết (các) khóa của riêng họ.

Dữ liệu được bao bọc cho người nhận có khóa ECC sử dụng ES-ECDH hoặc 1-pass ECMQV và OpenSSL chọn cái trước; xem RFC5753 3.1. Như đã nêu ở đó, điều này có nghĩa là RecipientInfo sử dụng KeyAgreeRecipientInfo lựa chọn (với thẻ 1). Như được triển khai bởi OpenSSL, điều này bao gồm:

  • phiên bản 3

  • người khởi xướng (thẻ 0 rõ ràng) lựa chọn người khởi tạoKey (thẻ 1 TRÌNH TỰ ẩn) chứa AlgorithmIdentifier và BITSTRING chứa, như RFC5753 nói "khóa công khai EC tạm thời của tác nhân gửi". Lưu ý rằng đây là khóa của người gửi chứ không phải của người nhận và là khóa tạm thời nên nó không có trong bất kỳ chứng chỉ nào ngay cả đối với người gửi.

  • ukm (thẻ 1 rõ ràng) tùy chọn và không được sử dụng

  • keyEncryptionAlgorithm AlgorithmIdentifier cho dhSinglePass và gói khóa đối xứng

  • người nhậnKhóa được mã hóa một SEQUENCE của SEQUENCE mỗi chứa Tổ chức phát hànhVà số sê-ri (một Tên phân biệt và INTEGER) và khóa mã hóa (BITSTRING là khóa dữ liệu được bao bọc bởi bí mật DH). Cái này xác định khóa người nhận nhưng không chứa nó.

Bạn dường như đã bỏ qua hoặc loại bỏ ít nhất một phần của người nhậnKhóa được mã hóa dữ liệu trong hình ảnh của bạn, nhưng thật khó để nói chắc chắn. Đây là một chính xác hiển thị (bao gồm cả KARI) của tin nhắn tôi đã tạo:

    0:d=0 hl=4 l= 280 khuyết điểm: TRÌNH TỰ
    4:d=1 hl=2 l= 9 nguyên tố: ĐỐI TƯỢNG :pkcs7-envelopedData
   15:d=1 hl=4 l= 265 khuyết điểm: tiếp [ 0 ]
   19:d=2 hl=4 l= 261 khuyết điểm: TRÌNH TỰ
   23:d=3 hl=2 l= 1 nguyên tố: INTEGER :02
   26:d=3 hl=3 l= 202 khuyết điểm: SET
   29:d=4 hl=3 l= 199 khuyết điểm: tiếp [ 1 ]
   32:d=5 hl=2 l= 1 nguyên tố: INTEGER :03
   35:d=5 hl=2 l= 65 nhược điểm: tiếp [ 0 ]
   37:d=6 hl=2 l= 63 khuyết điểm: tiếp [ 1 ]
   39:d=7 hl=2 l= 9 khuyết điểm: TRÌNH TỰ
   41:d=8 hl=2 l= 7 nguyên tố: ĐỐI TƯỢNG :id-ecPublicKey
   50:d=7 hl=2 l= 50 prim: CHUỖI BIT
  102:d=5 hl=2 l= 28 khuyết điểm: TRÌNH TỰ
  104:d=6 hl=2 l= 9 nguyên tố: ĐỐI TƯỢNG :dhSinglePass-stdDH-sha1kdf-scheme
  115:d=6 hl=2 l= 15 khuyết điểm: TRÌNH TỰ
  117:d=7 hl=2 l= 11 nguyên thủy: ĐỐI TƯỢNG :id-smime-alg-CMS3DESwrap
  130:d=7 hl=2 l= 0 nguyên tố: NULL
  132:d=5 hl=2 l= 97 khuyết điểm: TRÌNH TỰ
  134:d=6 hl=2 l= 95 khuyết điểm: TRÌNH TỰ
  136:d=7 hl=2 l= 51 khuyết điểm: TRÌNH TỰ
  138:d=8 hl=2 l= 45 khuyết điểm: TRÌNH TỰ
  140:d=9 hl=2 l= 43 khuyết điểm: SET
  142:d=10 hl=2 l= 41 khuyết điểm: TRÌNH TỰ
  144:d=11 hl=2 l= 3 nguyên tố: ĐỐI TƯỢNG :commonName
  149:d=11 hl=2 l= 34 prim: PRINTABLESTRING:(REDACTED)
  185:d=8 hl=2 l= 2 nguyên tố: INTEGER(DỮ LIỆU BỊ GIẤU)
  189:d=7 hl=2 l= 40 prim: OCTET STRING [HEX DUMP]:847B0D796D954C05AF37E1AEFE11C7F6762FB8CE2A891AD22B5646E79E95B556EDEC5A240ACCC621
  231:d=3 hl=2 l= 51 khuyết điểm: TRÌNH TỰ
  233:d=4 hl=2 l= 9 nguyên tố: ĐỐI TƯỢNG :pkcs7-data
  244:d=4 hl=2 l= 20 khuyết điểm: TRÌNH TỰ
  246:d=5 hl=2 l= 8 nguyên tố: ĐỐI TƯỢNG :des-ede3-cbc
  256:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:9780611D4883D5B1
  266:d=4 hl=2 l= 16 nguyên tố: tiếp [ 0 ]
lá cờ cn
Ồ, khi phiên bản là 3, nó có hoạt động bằng DH không? Sau đó, khóa công khai của người khởi tạo được sử dụng để giải mã? Ngoài ra, đường cong giống như của người nhận?
dave_thompson_085 avatar
lá cờ cn
Không, khi thẻ RecipientInfo là 1, thuật toán thỏa thuận khóa được xác định bởi keyEncryptionAlgorithm, mà OpenSSL chỉ định là (EC)DH; Phiên bản KARI luôn là 3 như đã nêu trong cả RFC5652 và RFC5753. Có, đối với DH ở chế độ E-S, người nhận sử dụng khóa công khai tạm thời của người khởi tạo và khóa riêng của chính nó để tính toán bí mật dùng chung và giải mã; xem phần còn lại của phần 3.1 trong RFC5753 mà tôi đã chỉ cho bạn. Có, đối với ECDH, hai bên sử dụng cùng một đường cong (hoặc đối với bất kỳ loại DH nào, cùng một nhóm).
lá cờ cn
Cảm ơn bạn! :) Tôi sẽ đọc RFC5753 ngay bây giờ

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.