RSA-PSS 鹽大小
RSA-PSS 簽名和驗證的輸入之一是鹽大小。根據 PKCS#1，在進行驗證之前，您必須知道鹽的大小。但是，這使得互操作性變得不可能：例如，如果我希望我的程序驗證 OpenSSL 生成的簽名，那麼我無法進行驗證，因為我不知道所使用的鹽的大小。
由於其編碼，可以推斷鹽的大小*。*但是，PKCS#1 沒有提到是否應該這樣做。（OpenSSL 支持這個）
我的問題是：推斷鹽大小是否安全，或者鹽大小必須是驗證算法的輸入？
通常，鹽長度是簽名參數的一部分，即告訴您簽名確實是 RSA-PSS 類型、使用什麼散列函式以及使用什麼遮罩生成函式的東西。
許多協議使用 ASN.1 對這些參數進行編碼（例如CMS，PKCS#7 的後代以及使用 S/MIME 簽名電子郵件的基礎）。PKCS#1（在附件 A 中）為 RSA-PSS (
RSASSA-PSS-params) 定義了 ASN.1 結構。算法的辨識使用泛型：AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm }（我使用的是舊式 ASN.1 表示法，這對於人類來說更容易閱讀。）簡單來說，一個包含符號標識符的結構（這裡是 1.2.840.113549.1.1.10，意思是“帶有 PSS 的 RSA” ) 和取決於算法的參數。在 RSA-PSS 的情況下，參數應為：
RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, saltLength [2] INTEGER DEFAULT 20, trailerField [3] TrailerField DEFAULT trailerFieldBC }where
hashAlgorithm告訴應該使用哪個散列函式來初始處理數據（它實際上是一個嵌套AlgorithmIdentifier結構），maskGenAlgorithm定義了 PSS 中使用的“遮罩生成函式”（它是一種具有可擴展輸出長度的散列函式；同樣，一個嵌套AlgorithmIdentifier結構），saltLength是鹽長度，並且trailerField是一個符號值，它定義了在 PSS 中添加的“拖車字節”（通常值為 0xBC，但將來可能會更改）。只有一個標準 MGF，稱為 MGF1，它本身依賴於底層散列函式。因此該
MaskGenAlgorithm結構（AlgorithmIdentifier另一個名稱的結構）包含一個對象標識符，上面寫著“這是 MGF1”（1.2.840.113549.1.1.8）並使用另一個AlgorithmIdentifier結構（是的，第三級嵌套）作為參數，它指定雜湊函式與 MGF1 一起使用。**底線：**要實際驗證 RSA-PSS 簽名，您必須了解以下內容：
- 簽名確實是 RSA-PSS 類型；
- 用於首先處理散列數據的散列函式，並在 PSS 中產生“DB”值的右半部分；
- PSS中使用的MGF（通常是MGF1，因為這是唯一定義的MGF函式，但MGF1本身需要一些參數，即它應該依賴的雜湊函式）；
- 鹽長；
- 拖車字節（通常為 0xBC；這是人們唯一使用過的字節，幾乎沒有理由更改它）。
如果您只關心鹽長度，那麼這意味著在您定義的任何協議中，您已經負責編碼所有其他參數（或在程式碼中硬編碼它們），所以我建議您在一樣的地方。
習慣上（但不是強制性的）使用參數使得 MGF 為 MGF1，建立在與用於處理簽名消息的雜湊函式相同的雜湊函式上，並將鹽長度設置為等於輸出的長度雜湊函式。從這個意義上說，在實踐中，您可以將參數編碼減少為單個雜湊函式（PKCS#1 表示“SHA-1”，但現在您更願意使用具有更好前景的東西，例如 SHA-256）。
關於鹽長的選擇
該鹽與PSS的安全證明有關。PSS 的要點，關於較舊和更簡單的“v1.5”填充，是 PSS 受益於將其安全性綁定到核心 RSA 操作（模冪運算）的數學證明。因此表明，為了打破 RSA-PSS，你必須能夠打破取冪部分（能夠計算一些 $ e $ -th 根模 $ n $ )，在某種程度上。“程度”就是所謂的鬆緊度；證明越嚴格越好。碰巧鹽長度等於散列輸出長度會產生比鹽長度為 0（即根本沒有鹽）更嚴格的證明。請注意，我們不是在談論實際攻擊甚至實際防禦；證明並沒有說空鹽更弱，只是數學給出了非空鹽的更多保證。參見 PKCS#1，第 34 頁，注 4：這包含指向相關科學文章的指針。
在實踐中，沒有人知道如何用空鹽破解 PSS；也沒有人知道如何破解 v1.5 簽名。如果您根本不使用 PSS，那麼這一定是因為數學證明，因為 PSS 與更簡單的 v1.5 填充相比沒有其他優勢。因此，您可能需要非空鹽。
關於推斷鹽長
這是您的實際問題；以上只是序言。您可以從簽名本身推斷鹽長度，這是安全的，因為在鹽長度編碼在參數結構中的實際協議中，該結構本身不受任何保護。因此，攻擊者可以輕鬆更改他認為合適的編碼鹽長度。
但請注意細節：僅在推斷的鹽長度是您可以接受的長度的範圍內推斷鹽長度是可以的，如果它以
RSASSA-PSS-params結構編碼提供。如果您想強制執行最小鹽長度（因為對數學證明的重要性有些瘋狂的看法），那麼您也必須針對您推斷的鹽長度強制執行它。我的建議仍然是將鹽長度編碼為特定應用程序中用作“參數”的內容。它感覺“更乾淨”，並將幫助您與現有的 RSA 實現進行互動（通常期望將鹽長度作為參數給出，而不是從簽名本身推斷它）。