Điểm:1

OPENSSL: Sự khác biệt của lệnh enc và lệnh enc của cms là gì?

lá cờ cn

Tôi đã tìm thấy điều gì đó kỳ lạ khi kiểm tra dữ liệu bên trong phong bì.

Tôi có văn bản thuần túy "plaintextplant" - độ dài là $15$ (bao gồm lf(0x0A))`. Tôi đã tạo một tệp .ber được mã hóa bởi AES256 và mã hóa DER qua:

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

Sau đó, tôi đã kiểm tra dữ liệu được mã hóa thông qua berReader. Tôi nghĩ rằng dữ liệu được mã hóa dài 16 byte vì độ dài của văn bản thuần túy là $15$. Tuy nhiên, độ dài của kết quả là $32$ byte.

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

Vì vậy, tôi đã gõ:

openssl enc -aes-256-cbc -in plain -out enc -k 123 , để lấy dữ liệu được mã hóa.

Sau đó, tôi đã kiểm tra độ dài của dữ liệu được mã hóa là $16$ byte trong dữ liệu đầu ra.

Tôi cung cấp cho bạn hình ảnh của kết quả:

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

Tại sao kích thước của dữ liệu được mã hóa cms là 32 byte?

Ngoài ra, tôi đính kèm hình ảnh có độ dài của văn bản thuần túy là 13 byte. Kích thước dữ liệu được mã hóa của nó là 16byte. nhập mô tả hình ảnh ở đây

Điểm:1
lá cờ in

AES là một mật mã khối và cần một phương thức hoạt động như CBC, CTR, v.v.

Mặc dù các chế độ phát trực tuyến như CFB, OFB và CTR không yêu cầu đệm, chế độ hoạt động của CBC và ECB yêu cầu đệm.

Trong chế độ CBC, phần đệm thông thường là PKCS#7 đệm lót. Đối với mã hóa CBC, thông báo được chia thành các khối 128 bit và phần đệm được áp dụng vào khối cuối cùng. Có thể có hai trường hợp;

  1. Tin nhắn đã bỏ lỡ một số byte; trong trường hợp này, hãy để $n$ là số byte bị thiếu, sau đó là số $n$ được thêm vào $n$ lần dưới dạng byte.

    [Số byte tin nhắn ][01] // 1 byte bị thiếu
    [Số byte tin nhắn ][0202] // 2 byte bị thiếu 
    [Số byte tin nhắn] [030303] // 3 byte bị thiếu
    ....
    [MB][0F0F0F...0F0F0F0F] // 15 byte bị thiếu
    
  2. Thông báo là bội số của 16 byte, điều này có nghĩa là khối cuối cùng đã đầy. Trong trường hợp này, để phân biệt trường hợp này với trường hợp đầu tiên, chúng tôi thêm một khối mới chứa đầy 10S. Do đó, chúng ta có thể có mặt trái của phần đệm. Người ta có thể thấy lý do là nếu khối cuối cùng có 01 như byte cuối cùng. Nó có đệm hay không? Vì vậy, thêm 01 loại bỏ sự mơ hồ này.

Phần trên có thể giải thích tại sao một tin nhắn trở thành bội số của 16 byte sau khi mã hóa CBC thích hợp.

Trong trường hợp của câu hỏi, 15 byte có thể trở thành 16 byte bằng cách thêm 01 như byte cuối cùng. Còn 16 byte còn lại thì sao?

Chế độ hoạt động của CBC cần 16 byte ngẫu nhiênkhông thể đoán trước Vectơ khởi tạo (IV) để đạt được bảo mật Ind-CPA.

IV là một trong những yêu cầu để giải mã khối đầu tiên ngoài khóa ( khóa, IV và $C_0$ bắt buộc);

$$P_0 = \operatorname{AES-DEC}(key,C_0) \oplus IV$$

Do đó, IV cũng phải được thêm/chuyển. Trong thực tế thông thường, IV được thêm vào bản mã.


Nếu IV không được lưu trữ/chuyển giao thì sao? Chà, bạn sẽ chỉ mất khối đầu tiên của tin nhắn, phần còn lại có thể được giải mã đúng cách kể từ đó;

$$P_i = \operatorname{AES-DEC}(key,C_i) \oplus C_{i-1}, \quad i \geq 1$$


CMS

Các CMS yêu cầu

Trường tham số AlgorithmIdentifier PHẢI có mặt và trường tham số PHẢI chứa AES-IV:

  AES-IV ::= CHUỖI OCTET (KÍCH THƯỚC(16))

IV được lưu trữ trong Mã định danh thuật toán lĩnh vực, không phải trong nội dung được mã hóa Như dave đã viết nó là -nhị phân số báo.


  • tùy chọn OpenSSL -k

    IV và Khóa được lấy từ phương pháp dẫn xuất khóa bằng cách sử dụng mật khẩu của người dùng và muối ngẫu nhiên 8 byte. IV không được chuẩn bị trước.

    Đầu tiên OpenSSL xuất ra từ kỳ diệu muối__ sau đó muối 8 byte rồi bản mã vào tệp. Bây giờ kích thước đầu ra là kích thước ma thuật của bạn + kích thước muối + kích thước bản mã

dave_thompson_085 avatar
lá cờ cn
Tôi không nghĩ nổ súng là hợp lý, nhưng bạn đã nhầm; như đã nêu trong hai dòng đầu tiên của trích dẫn của bạn, IV nằm trong phần tham số của AlgorithmIdentifier, không được thêm vào (hoặc thêm vào trước) vào bản mã trong Nội dung được mã hóa.
kelalaka avatar
lá cờ in
Tôi hiểu rồi, tôi đã cập nhật một chút để loại bỏ phần đầu không chính xác. Cảm ơn.
kelalaka avatar
lá cờ in
Bắn tôi nếu tôi sai về CMS ..
lá cờ cn
Nhờ anh mà em biết đến lĩnh vực AES-IV trong CMS.
kelalaka avatar
lá cờ in
Xin cho biết, khi bạn nhận được 15 danh tiếng, bạn cũng có thể ủng hộ. trong SO, upvote nếu câu trả lời hữu ích cho bạn, chấp nhận nếu giải quyết được vấn đề.
Điểm:1
lá cờ cn

openssl cms -mã hóa/ký theo mặc định, áp dụng chuẩn hóa SMIME -- ngay cả khi định dạng đầu ra không phải là SMIME. Điều này thay đổi LF thành CRLF, tạo dữ liệu 16 byte, được đệm thành 32. Để xem điều này, hãy xem

 openssl cms -decrypt -in yourcmsder -inform der -recip cert -inkey privkey | od -tx1

Để ngăn chặn điều này, hãy thêm -nhị phân trên mã hóa. Xem trang hướng dẫn trên hệ thống của bạn hoặc trên mạng.

Ngoài ra, như kelalaka nói, enc -k (và cả -kfile -pass hoặc không có tùy chọn nào nhắc) thực hiện mã hóa dựa trên mật khẩu lấy khóa và IV từ mật khẩu và muối (thường là ngẫu nhiên nhưng có thể được chỉ định bằng -S hoặc đàn áp với -không muối). Bạn có thể nhận được kết quả gần hơn với dữ liệu trong cms -mã hóa, nhưng không có sự chuẩn hóa, với một cái gì đó như

openssl enc -aes-cbc-256 -in plain -K (hexupto64) -iv (hexupto32) -out được mã hóa
# lưu ý k viết hoa k viết thường
# khóa, iv được đệm nếu cần nên chỉ cần 00 cho mỗi khóa là được để kiểm tra

Điều này không thực hiện dẫn xuất khóa, do đó, nó không sử dụng muối và do đó không lưu trữ muối trong đầu ra được mã hóa.

Đă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.