Tôi có câu hỏi về cách xác định RSADP/RSAEP (trong RFC2437 https://datatracker.ietf.org/doc/html/rfc2437#section-5.1.2):
RSADP (và RSAEP) được mô tả với cùng giới hạn cho thông báo (m) và bản mã (c), cụ thể là 0 <= m < n. Trong trường hợp này, nguyên thủy lũy thừa mô-đun giả định rằng phần đệm đã xảy ra, do đó, hãy loại bỏ điều đó ra khỏi bức tranh.
5.1.2 RSADP
RSADP (K, c)
Đầu vào:
Khóa riêng K RSA, trong đó K có một trong các dạng sau
-một cặp (n, d)
-một nhóm (p, q, dP, dQ, qInv)
c đại diện bản mã, một số nguyên từ 0 đến n-1
Đầu ra:
m đại diện thông báo, một số nguyên từ 0 đến n-1; hoặc
"đại diện bản mã nằm ngoài phạm vi"
Tôi có câu hỏi sau: việc triển khai có thực sự chấp nhận 0 & 1 làm giá trị c & m hợp lệ không? Không phải cả 0 và 1 đều không đổi theo phép lũy thừa sao cho văn bản mật mã và văn bản thuần túy sẽ không thay đổi? Điều đó không tệ sao? Việc triển khai từ chối các giá trị này có đúng không - mặc dù thông số kỹ thuật dường như cho phép chúng?
CẬP NHẬT: Tôi không hỏi về phần đệm per-se, vì phép lũy thừa xảy ra sau phần đệm (trong trường hợp mã hóa), mà là tại sao thông số kỹ thuật dường như hoàn toàn cho phép các giá trị không an toàn này. Tại sao thông số kỹ thuật không cho phép 0 & 1 một cách rõ ràng? Phải thừa nhận rằng rất hiếm về mặt thống kê nếu kết quả của phần đệm là một giá trị như vậy, nhưng câu hỏi của tôi là không nên để các hàm RSADP/EP không cho phép các giá trị này và sơ đồ OAEP tổng thể được xây dựng trên các hàm này được chỉ định để chọn một đầu vào phần đệm khác trong trường hợp?
Có thể có điều gì đó tôi đang thiếu ở đây, vì vậy hãy đánh giá cao bất kỳ thông tin nào.
Cảm ơn!
