Tham gia Đăng nhập
Điểm:1
kelalaka avatar Crypto

Về tính chính xác của ví dụ đệm của RFC 5246

lá cờ in
kelalaka

Phần đệm PKCS#7 được định nghĩa trong rfc5652#phần-6.3

Một số thuật toán mã hóa nội dung giả sử độ dài đầu vào là một bội số của k octet, trong đó k lớn hơn một. Đối với như vậy các thuật toán, đầu vào sẽ được đệm ở cuối dấu với k-(lth mod k) tất cả các octet có giá trị k-(lth mod k), trong đó lth là chiều dài của đầu vào. Nói cách khác, đầu vào được đệm tại kết thúc bằng một trong các chuỗi sau:

               01 -- nếu lth mod k = k-1
            02 02 -- nếu lth mod k = k-2
                 .
                 .
                 .
       k k ... k k -- nếu lth mod k = 0

Như chúng ta có thể thấy, các byte đệm có thể chứa một loạt01,02,...,hoặc,16 cho mật mã khối có kích thước 16 byte. Trong khi đang đọc

Tôi đã thấy rằng họ đã đưa ra một ví dụ như;

Khối thứ hai chứa 9 byte HMAC còn lại và 7 byte đệm 0x06, xem Hình 1. Lưu ý rằng bộ mã hóa cũng có thể chọn phần đệm dài hơn và nối thêm 23, 39, ...hoặc 247 byte đệm (đồng thời thiết lập giá trị của các byte đệm tương ứng).

Đây không phải là phần đệm PKCS#7. Vì vậy, tôi đã xem TLS 1.2's RFC 5246 và xem gần như cùng một mô hình;

Nếu chiều dài đệm là tối thiểu cần thiết, 6, thì đệm sẽ là 6 byte, mỗi byte chứa giá trị 6. Do đó, 8 octet cuối cùng của GenericBlockCipher trước mã hóa khối sẽ là xx 06 06 06 06 06 06 06, trong đó xx là octet cuối cùng của MAC.

Để tương thích với phần đệm PKCS#7, phần trên phải là ( could not see an lỗi lầm)

Nếu chiều dài đệm là tối thiểu cần thiết, 7, thì đệm sẽ là 7 byte, mỗi byte chứa giá trị 7. Như vậy, 8 octet cuối cùng của GenericBlockCipher trước mã hóa khối sẽ là xx 07 07 07 07 07 07 07, trong đó xx là octet cuối cùng của MAC.

và bài báo cũng có lỗi ở đó.

Theo như tôi biết, hai tài nguyên này là không chính xác. Có điều gì mà tôi đã bỏ lỡ về các thiết kế/cách sử dụng khác nhau của quy tắc đệm PKCS#7 không?

41
0 + 0
kelalaka avatar
lá cờ in
kelalaka
Lưu ý rằng tôi không xem xét phần đệm SSLv3 trong đó byte cuối cùng biểu thị số lượng byte đệm và phần còn lại của phần đệm có thể nhận bất kỳ giá trị nào.
0
Hồi đáp
dave_thompson_085 avatar
lá cờ cn
dave_thompson_085
Crossdupe https://security.stackexchange.com/questions/161153/rfc-5246-tls-1-2-padding-example-mistake và https://security.stackexchange.com/questions/88839/pkcs7-vs-tls -1-2-đệm
1
Hồi đáp
Điểm:3
Gilles 'SO- stop being evil' avatar Crypto
lá cờ cn
Gilles 'SO- stop being evil'

Phần đệm được sử dụng cho bộ mật mã CBC trong SSLv3 đến TLS 1.2 không phải là phần đệm PKCS#5/PKCS#7. Đó là phần đệm được sử dụng trong SSL/TLS mà tôi chưa từng thấy ở bất kỳ nơi nào khác.

Phần đệm trong TLS 1.0, TLS 1.1 và TLS 1.2 có thể từ 1 đến 256 byte, vì vậy nó có thể lấp đầy nhiều khối. Trong giao thức tiền nhiệm SSL3.0, nó phải hoàn thành chính xác một khối.Trong tất cả các phiên bản, byte cuối cùng phải là độ dài của phần đệm, không bao gồm byte cuối cùng đó. Các byte trước đó có thể nhận bất kỳ giá trị nào trong SSL 3.0 và phải là độ dài đệm trong TLS 1.0 đến 1.2. Đối với một mật mã khối với $B$khối -byte:

Sự chỉ rõ Tổng chiều dài khối Nội dung
PKCS#7 $n \in [1, B]$ byte $1$ $(n, \ldots, n)$
SSL3.0 $n \in [1, B]$ byte $1$ $(?, \ldots, ?, (n-1))$
TLS 1.0–1.2 $n \in [1, 256]$ byte $1$ đến $\lceil 256/B \rceil$ $((n-1), \ldots, (n-1))$

Như bạn có thể thấy, PKCS#7 lấp đầy phần đệm với tổng chiều dài phần đệm, trong khi TLS 1.0–1.2 lấp đầy phần đệm với tổng chiều dài phần đệm trừ đi một. Lý do cho sự lựa chọn có vẻ kỳ lạ này là vì đó là sự thích ứng của phần đệm SSL 3.0, trong đó byte cuối cùng là byte độ dài không bao gồm cái mà đặc tả SSL gọi là âphần đệmâ và â paddingâ thích hợp có thể có nội dung tùy ý.

Các ví dụ bạn trích dẫn từ RFC 5246 và từ Merget et al. đúng. Nếu thêm 7 byte sẽ đưa bản rõ lên bội số của kích thước khối, thì 06 06 06 06 06 06 06 là một phần đệm TLS có thể có (cũng như 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16, vân vân.).

0 + 0
lá cờ VietNam
Phan Văn Trường
Câu hỏi này là trong các ngôn ngữ khác:

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