是否可以使用固定的 RSA 加密代替鹽來防止彩虹表攻擊？
為了防止彩虹表的攻擊，通常在對密碼進行雜湊處理之前使用鹽。
在散列之前通過 RSA 加密（通過儲存在伺服器上的永久 RSA 私鑰）來加密密碼是否也有效？
換句話說： $ hash = SHA(RSA(password)) $
對我來說，這看起來很安全，因為彩虹表不適用於加密密碼 $ RSA(password) $ ，他們會嗎？
（旁注：由於 RSA 私鑰根本不用於加密，因此永遠不必替換它……在這種情況下，它只會作為一個完全確定性的偽隨機函式工作！）
我沒有看到使用 RSA 進行密碼散列的意義。使用 SHA 和 RSA 不會使蠻力攻擊變慢。如果我們假設公鑰，大規模的 GPU/ASIC 攻擊仍然有效 $ (e,n) $ 是已知的。這就是為什麼我們需要記憶硬函式來使攻擊變慢。堅持標準仍然比使用 Argon2id 更好（Argon2 是2015 年密碼雜湊競賽的獲勝者）。獨特的鹽也有助於消除彩虹表。對於部署獨特鹽的密碼系統，彩虹表已經死了！
一個小問題是不需要儲存 RSA 私鑰 $ (d,n) $ 因為無法反轉 SHAx。所以沒用。
回到彩虹
在防止彩虹表的情況下，需要確保每個密碼都需要一個域分隔符。這是通過為所有人提供獨特的鹽來實現的。如果要使用 RSA，則需要使用OAEP填充或 PKCS#1 v1.5。填充。兩者都是機率加密方案，只要你有一個好的隨機數源，
/dev/urandom那麼如果你一次又一次地加密相同的消息，你會得到不同的結果，當然有一個巨大的限制（ $ r $ 在 OAEP 中）。可以將鹽視為這種隨機化。**附註：**胡椒是每個應用程序伺服器唯一的鹽，用於在為同一使用者命中相同鹽的情況下分隔應用程序的域。此外，如果攻擊者僅通過 SQL 注入下載使用者表，那麼如果沒有伺服器的胡椒，他們甚至無法應用暴力破解。
注2： 根據Hashcat list，只有OpenSSH以組合方式使用RSA
RSA/DSA/EC/OpenSSH附錄
這部分基於@fgrieu在@marcus考慮這些的情況下的評論；
- $ (\text{salt},hash = \text{PasswordHash}(\text{salt},\text{DeterministicPadding}(\text{password})^d\bmod n)) $
- $ (\text{salt}, hash = \text{Hash}(\text{DeterministicPadding}(\text{salt}\mathbin|\text{password})^d\bmod n)) $
此處確定性填充代表為 RSA 加密填充消息，但具有確定性，如 RSASSA-PKCS1-v1_5。
很明顯，如果鹽對每個使用者都是唯一的，那麼它就已經可以安全地抵禦彩虹表了。如果訪問密碼的雜湊值，密碼破解者無法在不知道私鑰的情況下對其進行測試。
最大的問題是RSA私鑰的保護。通常的方法是使用 HSM 來處理儲存 RSA 密鑰的那些加密，但是，對於重型系統，它可能是速度的瓶頸。這不是一個真正的比較，密碼雜湊算法的通常建議是調整迭代，使每個使用者大約需要 1 秒。這是為了使用者友好。即一般使用者可能不想在登錄過程中等待太多。
知道公鑰 $ (n,e) $ 不會幫助攻擊者，因為據公眾所知，他們無法破解 RSA > 829 位。請參閱有關當今認為多大的 RSA 密鑰是安全的？
我們也可以將此 RSA 操作視為應用程序伺服器的一個小辣椒。此外，可以使用 HMAC-SHA256 代替 RSA，以實現相同的用途，它具有較小的密鑰大小。
**簡而言之，**如果密鑰能夠得到保護，它對通常的做法有更多的保護。