Điểm:3

Việc khởi tạo RSAES-OAEP và SHA*WithRSAEncryption khác nhau như thế nào trong thực tế?

lá cờ vu

Đối với dự án thời gian rảnh rỗi mà tôi đang thực hiện, tôi đang đánh giá các lược đồ RSA đệm PKCS#1 để triển khai.

Đối với PKCS#1 v1.5, mã hóa dường như không yêu cầu hàm băm và chữ ký không cần hàm tạo mặt nạ bổ sung (MGF) ngoài thuật toán thông báo để băm thư.

Đối với PKCS#1 v2.x, cả mã hóa và chữ ký đều được khởi tạo bằng MGF, hàm băm và nhãn tùy chọn (hiện không có mục đích sử dụng cụ thể). Đến lượt mình, MGF được khởi tạo bằng một hàm băm khác bằng cách sử dụng cấu trúc MGF1 (ad hoc) MGF1.

Theo tôi, một hệ thống mật mã tổng hợp nên có càng ít tham số khởi tạo càng tốt, để giảm bớt gánh nặng triển khai và thúc đẩy khả năng tương tác; chỉ các tham số cần thiết cho tính linh hoạt của mật mã mới được đưa vào thiết kế.

Đó là lý do tại sao, tôi ngạc nhiên rằng hàm băm khởi tạo MGF có thể khác với hàm băm được sử dụng để băm đầu vào.

Câu hỏi của tôi ở đây là:

  • có các đề xuất hiện có (ví dụ: CMS, PKIX) về việc sử dụng và khởi tạo PKCS#1 v2.x RSAES-OAEP và RSASSA-PSS, trong đó lựa chọn hàm băm được chỉ định không?
  • Có ID được chỉ định (từ IANA hoặc các tổ chức tương tự) không?
  • Các điểm bổ sung dành cho việc xử lý FIPS Dự thảo NIST 186-5, trong đó SHAKE-{128,256} sẽ được phê duyệt để sử dụng làm MGF.
Gilles 'SO- stop being evil' avatar
lá cờ cn
PKCS#1 khuyến nghị sử dụng các hàm băm giống nhau (và bắt buộc sử dụng cùng một hàm băm để băm thông báo và băm hàm băm, chỉ có MGF được phép khác biệt) và theo kinh nghiệm của tôi, điều này chủ yếu được tuân theo trong thực tế, nhưng tôi đã thấy các hệ thống bị kẹt trên SHA-1 đối với MGF mặc dù đã chuyển sang SHA-2 để băm thư. Tôi chưa bao giờ thấy bất cứ thứ gì khác ngoài MGF1 cho MGF (ngoài SHAKE, nhưng nếu có những người dùng sớm thì tôi vẫn chưa thấy chúng: mọi thứ tôi đã thấy khi sử dụng SHAKE đều ghép nối nó với ECC).
Điểm:1
lá cờ ng

Tôi sẽ bắt đầu với một so sánh chức năng của RSAES-PKCS1-v1_5 với RSAES-OAEP.

Cái sau là sự thay thế gần như hiện đại của cái trước.

Trước hết, về cơ bản, không thể tạo một thư viện triển khai giải mã RSAES-PKCS1-v1_5 để đảm bảo an ninh trước các cuộc tấn công kênh bên. Nhiều nỗ lực để có được bảo mật cấp ứng dụng đã thất bại: kẻ thù có thể thực hiện một số lượng truy vấn khiêm tốn đối với thiết bị đang thực hiện giải mã và quan sát hành vi của thiết bị đó (mã lỗi, kích thước gói, thời gian, truy cập đĩa, bộ đệm, âm thanh nguồn cung cấp...) thường thành công [nghĩa là quản lý để giải mã một tin nhắn mà họ đã chặn hoặc ký một tin nhắn nếu khóa được sử dụng kép]. Cuộc tấn công CCA của Bleichenbacher có rất nhiều biến thể mà thật khó để theo dõi. Ngược lại với RSAES-OAEP: một số lượng hạn chế trong quá trình triển khai thư viện sẽ ngăn chặn cuộc tấn công tương đương.

Ngoài ra, RSAES-PKCS1-v1_5 được xác định để cho phép tính ngẫu nhiên xuống tới 64 bit, điều này không đủ theo tiêu chuẩn hiện đại để ngăn chặn mạnh mẽ việc kiểm tra dự đoán chính xác của văn bản gốc. Cách duy nhất để khắc phục điều này là ngăn mã hóa thư quá gần với kích thước tối đa cho phép.

RSAES-OAEP có bằng chứng về bảo mật (với giả định rằng vấn đề RSA là khó và hàm băm có thể được mô hình hóa dưới dạng hàm giả ngẫu nhiên và việc triển khai không có kênh phụ). RSAES-PKCS1-v1_5 thì không.

Một nhược điểm của RSAES-OAEP là nó cho phép các thông báo nhỏ hơn cho cùng một mô-đun, nhưng đó hiếm khi là vấn đề trong thực tế, vì khi kích thước thông báo tăng lên, chúng tôi sử dụng mã hóa lai.


các đề xuất hiện có (ví dụ: CMS, PKIX) về việc sử dụng và khởi tạo RSAES-OAEP và RSASSA-PSS

Như đã chỉ ra trong bình luận đối với câu hỏi, thực tiễn tốt nhất hiện tại là sử dụng MGF1 với hàm băm giống như phần còn lại của cấu trúc. SHA-256 là phổ biến, SHA-512 sẽ là tốt nhất. Sai lệch phổ biến nhất so với điều đó là việc sử dụng SHA-1 trong MGF1 cho RSAES-OAEP, vì API Java khiến nó dễ mắc lỗi (xem cái này). Điều đó vẫn an toàn theo như chúng tôi biết.

RSASSA-PSS, một cách làm phổ biến (nhưng không phải là tốt nhất) là để trống ruộng muối, đó là sử dụng $sLen=0$ Trong EMSA-PSS.

Về mặt lý thuyết, việc sử dụng SHAKE-{128,256} làm MGF sẽ hợp lý nhưng chưa được thực hiện trong các ứng dụng mà tôi biết và có thể sẽ không bao giờ thực hiện được.

Có ID được chỉ định (từ IANA hoặc các tổ chức tương tự) không?

OIDs cho RSAES-OAEP, RSASSA-PSS, MGF1, SHA-256SHA-512. Bây giờ, các OID này nên được sử dụng kết hợp như thế nào trong ví dụ: chứng chỉ X.509 và có thứ gì đó sẽ tiếp tục hoạt động nếu thử không? Tôi vượt qua.

dave_thompson_085 avatar
lá cờ cn
Đối với hầu hết mọi người, PKIX cũng tốt như X.509 và **Thông số PKIX** cho OAEP và PSS nằm trong **RFC 4055**. TLS1.3 (RFC 8446 4.2.3) sử dụng chữ ký PSS, chỉ định MGF-hash = message-hash và saltlen = digestlen và chứng chỉ phải chứa OID gốc (rsaEncryption vì lý do lịch sử mặc dù chữ ký không được mã hóa) hoặc PSS OID. TLS1.3 được triển khai khá rộng rãi, mặc dù tôi không biết có bao nhiêu trang web sử dụng RSA-PSS so với ECDSA hoặc EdDSA -- có lẽ đã đến lúc EFF thực hiện một cuộc khảo sát khác?
Điểm:1
lá cờ vu
  • có các đề xuất hiện có (ví dụ: CMS, PKIX) về việc sử dụng và khởi tạo PKCS#1 v2.x RSAES-OAEP và RSASSA-PSS, trong đó lựa chọn hàm băm được chỉ định không?

Cả CMS và PKIX đều có khuyến nghị về điều này. Cả hai CMS RFC-4056 và PKIX RFC-4055 khuyến nghị sử dụng cùng một hàm băm cho tin nhắn và MGF.

Lưu ý bên lề: S/MIME và PKIX được kết thúc bởi các nhóm làm việc tại IETF, người kế nhiệm của chúng ĐÈN đang làm công việc bảo trì.

  • Có ID được chỉ định (từ IANA hoặc các tổ chức tương tự) không?

ASN.1 OID thường không cần thông qua IANA.

RFC-3560 tiến xa hơn để liệt kê các giá trị bộ tám cho tham số thuật toán mã hóa ASN.1 DER, nguyên văn.

  • Các điểm bổ sung dành cho việc xử lý FIPS Dự thảo NIST 186-5, trong đó SHAKE-{128,256} sẽ được phê duyệt để sử dụng làm MGF.

NIST, giống như bất kỳ cơ quan chính phủ chính thức nào khác, luôn duy trì quan điểm trung lập với nhà cung cấp và từ chối mọi chứng thực đối với các sản phẩm thương mại được đề cập trong các ấn phẩm chính thức của họ.

IETF RFC-{8692,8702} chỉ định SHAKE để sử dụng với RSA (và CMS và PKIX nói chung), đã liệt kê Cisco Systems là đồng biên tập. Vì vậy, đây chỉ là dự đoán, có thể Cisco đang giới thiệu các sản phẩm có thể thu được từ hiệu quả phần cứng của hoán vị Keccak và tham số miếng bọt biển SHAKE, khi được sử dụng làm tiên tri ngẫu nhiên trong thuật toán RSA.

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