Hash
RSAES-OAEP 和 SHA*WithRSAEncryption 在實踐中的實例化有何不同？
對於我一直從事的業餘項目，我正在評估 PKCS#1 填充 RSA 方案的實施。
對於 PKCS#1 v1.5，加密似乎不需要散列函式，並且簽名不需要額外的遮罩生成函式 (MGF)，而不需要用於散列消息的摘要算法。
對於 PKCS#1 v2.x，加密和簽名都使用 MGF、散列函式和可選標籤（目前沒有指定用途）進行實例化。MGF 又使用（ad hoc）MGF1 構造用另一個散列函式實例化。
在我看來，複合密碼系統應該盡可能少的實例化參數，以減輕實現負擔，促進互操作性；只有加密敏捷性所需的參數才應插入設計中。
這就是為什麼讓我感到驚訝的是，實例化 MGF 的散列可能與用於散列輸入的散列不同。
我的問題是：
- 是否有關於 PKCS#1 v2.x RSAES-OAEP 和 RSASSA-PSS 的使用和實例化的現有建議（例如 CMS、PKIX），其中指定了散列函式的選擇？
- 是否有分配的 ID（來自 IANA 或類似組織）？
- 其他要點涉及 NIST FIPS 186-5 草案的處理，其中 SHAKE-{128,256} 將被批准用作 MGF。
- 是否有關於 PKCS#1 v2.x RSAES-OAEP 和 RSASSA-PSS 的使用和實例化的現有建議（例如 CMS、PKIX），其中指定了散列函式的選擇？
CMS 和 PKIX 都對此有建議。CMS 的RFC-4056和 PKIX 的RFC-4055都建議對消息和 MGF 使用相同的散列。
旁注：S/MIME 和 PKIX 是 IETF 結束的工作組，它們的繼任者LAMPS正在做維護工作。
- 是否有分配的 ID（來自 IANA 或類似組織）？
ASN.1 OID 通常不需要通過 IANA。
RFC-3560甚至逐字列出算法參數 ASN.1 DER 編碼的八位字節值。
- 其他要點涉及 NIST FIPS 186-5 草案的處理，其中 SHAKE-{128,256} 將被批准用作 MGF。
NIST 與任何其他官方政府機構一樣，始終保持供應商中立立場，並否認對其官方出版物中提到的商業產品的任何認可。
IETF RFC-{ 8692 , 8702 } 指定 SHAKE 用於 RSA（以及一般的 CMS 和 PKIX），已將 Cisco Systems 列為共同編輯。所以這只是一個猜測，也許思科推出的產品在 RSA 算法中用作隨機預言機時，可能會從 Keccak 置換和 SHAKE 海綿參數的硬體效率中獲益。