非彙編加密庫真的可以抵禦定時攻擊嗎？
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf聲明如下：
那麼出了什麼問題呢？答案：NIST 未能認識到表查找不需要固定時間。“表查找：不易受到定時攻擊，”NIST 在
$$ 19, Section 3.6.2 $$. NIST 的聲明過去和現在都是不正確的。
該論文的第 10 - 15 節（包括）建議對事物在 CPU 的 L1/L2 記憶體中的放置方式進行更改以解決該問題。但是，您只能通過程序集真正控制 L1/L2 記憶體中的內容。
那麼，非彙編程式碼對計時攻擊的真正安全性如何？
在 AES 的情況下，上述論文說您可以通過取消 s-box 查找來接近恆定時間，但即便如此，L1/L2 記憶體中的內容似乎仍然存在問題。如果不使用 s-box，則使用明文和密文本身或密鑰調度的各種組件。
那麼，非彙編程式碼對計時攻擊的真正安全性如何？
首先，讓我聲明這是一個棘手的主題。
最簡單的方法當然是取消查找表或其他容易受到定時攻擊的組件。因此，在設計密碼時，它應該需要最少的易受攻擊的組件。並且在執行過程中，應使用最少的易受攻擊的構造以確保絕對安全。例如，AES 可以通過多種方式實現——在側通道攻擊方面，有些方式比其他方式更安全。DJB 在論文中也說明了這一點。
本地庫也很難控制記憶體時間。通常庫通常不是為特定的 CPU 建構的。幾乎不可能控制和測量記憶體處理的執行方式——甚至存在多少記憶體。因此，從這個意義上說，機器程式碼（幾乎）與非本地程式碼一樣易受攻擊。
克服這種複雜性的一種方法是讓 CPU 指令、協程或協處理器執行 AES。可以從頭開始設計這樣的指令，使其不受定時攻擊的影響。如果設計得當，它完全獨立於記憶體和記憶體，因此也不受依賴於它們的側通道攻擊的影響。
非本機程式碼無法直接控制指令和記憶體地址這一事實並不意味著它根本無法控制它。通常，您仍然可以分析在較低級別發生的情況。例如，Java 中的數組不是反向儲存的。您從規範中知道，它將是記憶體中某處的單個連續數據塊。
如果您被表格之類的東西困擾，那麼您有多種選擇。例如，您可以確保攻擊者根本沒有足夠的訪問權限來執行攻擊。例如，攻擊者可能很難將表放在記憶體中的兩個不同頁面上。
攻擊者也可能很難獲得足夠的時間資訊。幾乎任何時間資訊都可以使用統計數據來提取。但就像暴力破解一樣，實際攻擊所需的數據量可能太高了。
不幸的是，這個頁面不夠大，無法討論可以針對側通道分析採取的所有措施，然後驗證它們對於機器程式碼和高級語言是否安全。是的，有些結構對兩者都有效（RSA 致盲可能是最廣為人知的一種）。RSA 是否足以證明程式碼對計時攻擊是安全的？可能不是。
請注意，該問題的答案通常是：我們尚未針對側通道攻擊測試程式碼，並希望我們的算法和協議足夠安全。
在組織中解決這個問題的一種方法是購買一個 HSM（或 TLS 解除安裝程序或其他安全系統），它應該可以防止側通道攻擊，基本上完全繞過問題。這些東西可能非常昂貴，但如果您需要針對側通道分析的最高保護，您也可能會失去很多。