nguy hiểm như thế nào để xác minh nhãn không liên tục?
Theo như tôi có thể nói không nhiều, miễn là nhãn được công khai và việc xác minh này được thực hiện và không phụ thuộc vào việc xác minh byte 0x00 ở bên trái của kết quả giải mã RSA thô/sách giáo khoa $c^d\bmod n$. Điều đó áp dụng bất kể hoạt động giải mã có hỗ trợ nhãn hay không.
Các lưu ý bảo mật trong PKCS#1v2.2 được đề cập trong câu hỏi đọc:
Ghi chú. Phải cẩn thận để đảm bảo rằng đối thủ không thể phân biệt các điều kiện lỗi khác nhau trong Bước 3.f, cho dù là do thông báo lỗi hay thời gian, hay nói chung hơn là tìm hiểu một phần thông tin về thông báo được mã hóa EM. Mặt khác, đối thủ có thể có được thông tin hữu ích về việc giải mã bản mã C, dẫn đến một cuộc tấn công vào bản mã đã chọn, chẳng hạn như cuộc tấn công được quan sát bởi Manger [35].
Ghi chú đó thực sự đề cập đến thử nghiệm (được in đậm bên dưới) ở cuối Bước 3.g của hoạt động giải mã:
Tách rời ĐB thành một chuỗi octet lHashâ chiều dài hlen, một chuỗi đệm (có thể trống) Tái bút bao gồm các octet có giá trị thập lục phân 0x00 và một thông báo M là
    ĐB = lHashâ || Tái bút || 0x01 || m .
Nếu không có octet có giá trị thập lục phân 0x01 để phân tách Tái bút từ m, nếu lBăm không bằng lHashâ, hoặc nếu Y là khác không, xuất âdecryption errorâ và dừng lại.
âxác minh nhãnâ trong câu hỏi đề cập đến sự so sánh của lBăm (hàm băm của nhãn hoặc của chuỗi trống là không có nhãn) và lHashâ. byte Y là một trong những bên trái của bytestring đại diện $c^d\bmod n$ trong ký hiệu big-endian chỉ trên nhiều byte theo yêu cầu để biểu thị mô đun công khai $n$, và $c$ về cơ bản là bản mã được trình bày cho công cụ giải mã.
Nếu chúng ta thực hiện phép so sánh lHashâ và lBăm chỉ có điều kiện nếu so sánh của Y đến 0x00 thành công (ví dụ: nếu chúng ta so sánh Y || lHashâ đến 0x00 || lBăm với memcmp của thư viện chuẩn C), thì chính xác là chúng ta đang ở trong các điều kiện được yêu cầu bởi cuộc tấn công của Manger, cho phép giải mã một tin nhắn bằng cách gửi lặp đi lặp lại các mật mã không chính xác tới thiết bị giải mã và quan sát phản ứng của nó.
Nếu chúng ta thực hiện phép so sánh lHashâ đến lBăm trong thời gian không cố định nhưng bất kể nếu Y khớp với 0x00 (và thực hiện kiểm tra đó Y và đó là tổng hợp với bài kiểm tra của lHashâ trong thời gian không đổi hoặc thực hiện thử nghiệm đó Y có điều kiện nếu so sánh của lHashâ đến lBăm thành công), tình hình gần như không tệ như vậy, bởi vì sự thay đổi thời gian của chúng tôi không tiết lộ manh mối nào về việc liệu Y khớp với 0x00, đây là điều mà kẻ thù muốn biết nhất. Mặc dù đối thủ vẫn thu được một phần thông tin về EM, Tôi không thấy rằng một cuộc tấn công có thể được thực hiện để hoạt động, ngay cả khi có nhiều truy vấn hơn tới công cụ giải mã, bởi vì mỗi byte của lHashâ tại thời điểm so sánh phụ thuộc vào từng bit của EM bên cạnh những người trong Y.
không kiểm tra lHashâ không phải là cách triển khai chính xác RSAES-OAEP mà không có hỗ trợ thẻ (trong trường hợp đó, việc so sánh phải được thực hiện với hàm băm của chuỗi trống) và có khả năng kích hoạt cuộc tấn công của Manger.
Tôi có thể nghĩ rằng nhãn bí mật được chia sẻ trước được đoán bởi một người bên ngoài với khóa công khai mã hóa là một kịch bản.
Hình ảnh tinh thần của tôi cho nhãn là nó là một công cộng hằng nhằm mục đích cho phép một cặp khóa công khai/riêng tư được sử dụng trong các ngữ cảnh độc lập khác nhau. Điều đó hữu ích để tránh các cuộc tấn công chuyển tiếp một bên ngoài bản mã được xác thực (ví dụ: được ký bởi người khởi tạo) vào ngữ cảnh không nhằm mục đích nhận nó. Tôi chưa bao giờ nhận ra rằng nhãn (hoặc đó là hàm băm) có thể là một bí mật được chia sẻ trước và được sử dụng để xác thực các mật mã được gửi tới thiết bị giải mã RSAES-OAEP. Nếu có bằng chứng bảo mật về RSAES-OAEP theo cách sử dụng đó, thì tôi đã bỏ lỡ. Và thực sự, điều cực kỳ quan trọng là sự so sánh giữa lHashâ và lBăm là hằng số thời gian.
Có những người khác?
Bên cạnh cuộc tấn công của Manger xem xét ở trên, tôi không thấy bất kỳ.
