我們是否希望/是否允許並行化（例如 GPU 程式）進入加密領域？後果是什麼？
使用術語 GPU 程式，我指的是一般高度可並行化的計算。
最後，我已經建立了一些密碼學背景。所以我開始懷疑 GPU 程式是否/在哪裡適用於加密使用。我認為在大多數案例中它幾乎沒有優勢，因為它們的加密算法是圍繞在並行化上幾乎沒有優勢的概念建構的，因為這可能需要考慮替代安全模型，而且在某些情況下我們想數據依賴存在。例如，在分組密碼或流密碼（例如 AES 或 Salsa）中，但是並行化可能在密碼分組連結中提供小的優勢。但另一方面，大多數現代處理器架構（例如 x64 或 ARMv8）已經內置了用於一輪 AES 或一些雜湊函式的指令，並且它們還具有在某些情況下可以提供幫助的 SIMD 指令。但是我們不要限制我們的範圍，密碼學不僅僅是關於這些方案和這些原語。非對稱密碼學原語呢？還有像 FHE、MPC、ZKP 或基於格的密碼學這樣的“新生”領域呢？
總結一下：
- 我們是否要允許/是否允許並行化進入加密領域？如果是，這是否需要我們重新考慮安全模型？
- 哪些是最常見的設計可並行化的密碼原語？
- FHE、MPC、ZKP 或基於格的密碼學等“新生”領域呢？
他們的加密算法是圍繞在並行化方面幾乎沒有優勢的概念建構的，因為這可能需要考慮替代安全模型
這不是真的。有您描述的那種算法（通常以固有順序算法、時間鎖謎題或可驗證延遲函式等名稱命名），但它絕不是該領域的主要部分。
在大多數情況下，誠實方計算的算法非常有效，並且提高它們的效率（例如通過並行化）並不會真正影響安全性。
重要的是密碼分析在並行化方面的表現。儘管如此，即使這往往也能很好地並行化。許多密碼分析算法（比如數域篩的變體，或格算法）通常被稱為“令人尷尬的並行”，因為大多數算法通常可以很容易地並行化。有時這裡的估計是錯誤的，從而導致攻擊（LogJam 是一個著名的例子），但在大多數情況下，參數設置是假設已經完成了某種程度的並行化。
所以，答案是
- 是的。忽略特殊情況（我在上面描述的），這不會對安全定義產生太大影響。
- 我不能聲稱在這裡給出一個全面的答案，但是基於格的基元通常至少是高度可並行化的，並且現在很常見。
- 如前所述，基於格的圖元（以及因此的 FHE）是高度可並行化的。不過我無法評論其他領域。
我們有並行雜湊
- NIST SP 800-185 – 並行雜湊：
ParallelHash 的目的是通過利用現代處理器中可用的並行性來支持超長字元串的高效散列。
- Blake3 是另一個並行雜湊。
加密模式；CTR 本質上是高度並行的，由於需要磁碟加密模式。
建構彩虹表。
FHE 實施；FHE 已經是資源和耗時的。必須並行實施它們；
- 由於 FHE 的語義安全性， FHE 排序已經基於並行排序。
- FHE 私人資訊檢索
- FHE AES 評估
- 而且，其他（已經有 FPGA/GPU 實現）
因式分解算法包括許多並行子程序，例如高斯消元法。例如，CADA-NFS 性能取決於核心數量；
對 RSA 模組的 GCD 攻擊可以癱瘓。
Pollard 的離散對數袋鼠算法在GPU 支持下癱瘓。
格算法和攻擊本質上是可並行的。
量子計算模擬。這是必須的，而且是天生的。
暴力破解：雖然像 AES 這樣的現代算法不能被暴力破解，但已經在 DES 上執行了並行密鑰搜尋。此答案中列出的所有破解程序都是並行化的。
ZKP 的某些部分可以並行化。
密碼雜湊；2015 年的比賽需要並行化。這為並行搜尋提供了一些緩解，請參閱hashcat。
我們是否要允許/是否允許並行化進入加密領域？如果是，這是否需要我們重新考慮安全模型？
如我們所見，它已經存在。安全模型實際上取決於具體情況。
哪些是最常見的設計可並行化的密碼原語？
- 天生的蠻力
- FHE本質上
請注意，在 ASIC/FGGA 中實現算法的密碼學非常豐富。CHES 和快速軟體加密會議是該主題的先驅。