我們對哪些加密庫/程序最有信心？
我最近開始研究加密貨幣。如果這是我學到的一件事，那就是我們不應該實現自己的加密。因此，我們應該考慮使用現有的軟體和庫。
- 當我去實現需要數據安全的東西時，有很多選擇——openssl、mcrypt、truecrypt、crypt、pycrypto、bouncycastle……我怎麼知道關於加密社區審查什麼是“經過驗證的和真實的”？
- 這可能取決於應用程序、您的實現語言和加密數據。對於基本的單文件加密、全盤加密和加密網路通信等常見場景，通用的答案是什麼？我可以自己對原始碼進行審計，但如果說我可以捕捉到一些明顯的漏洞，那就太天真了。
- 如果 TrueCrypt，一個備受矚目的加密軟體本身，正在廣泛呼籲進行公共審計，那麼哪些加密軟體經過充分審計？在我看來，如果任何加密軟體都應該具有高度的信心，並且有很多人仔細檢查它，那麼它應該是 truecrypt 或 openssl。
當然，還有通常的免責聲明；我了解我們無法提前了解所有漏洞和錯誤。沒有什麼是無限安全的。這給我們留下了一個簡單的高信心或低信心的價值衡量標準。 3. 是否有高可信度加密庫/軟體的列表？也許信心沒有很好的定義。是否有經過時間考驗的加密庫/軟體列表？
這個問題本質上是主觀的，這個評論也是主觀的。留下實際評論太長了，所以我將其發佈為答案，儘管它不是真正的答案，而是評論。這是為了後代，我猜——這個文章在Google搜尋中已經很高了。
NaCl可能是最受尊敬的圖書館。它的作者是某人（Daniel J. Bernstein），他在編寫安全軟體方面有著良好的記錄，並且了解許多實際和理論上的微妙安全問題。它還針對高級使用並儘可能封裝細節，而不是為許多加密原語提供開放式通用 API 的更常見的庫方法。這使得 NaCl 更難被濫用，這一點很重要，因為一些漏洞是對庫的簡單無辜濫用。很少有其他圖書館可以做出類似的聲明。
我認為很難獲得好的審計。我的總體印像是，很少有人有資格進行良好的審計，而許多有資格的人只能評估少數幾個領域。更重要的是，合格的人對其他事情的需求量很大，並且可能對主動參與審計項目的興趣很小。這並不有利可圖，因為良好的審計：
- 花費很長時間
- 不太可能支付太多（除非涉及錯誤賞金或贈款，否則可能沒有）
- 除非他們發現一些巨大的東西，否則不太可能給審計師帶來名聲
- 如果他們遺漏了後來發現的東西，這可能是對審計師的責任
所以我認為推動高質量審計的動力並不大。
流行的庫/應用程序長期以來一直沒有註意到錯誤，我認為這證明審計很少見。歷史顯示了很長一段時間都沒有註意到錯誤的例子，有時即使我們知道它們。
- Debian 弱密鑰漏洞在被發現之前已經存在了一年半多。犯錯誤的開發人員甚至在公共郵件列表上明確描述了他的更改，並詢問更改是否安全（問題沒有得到答复）。讓它沉入其中：一個流行的開源庫使用了 21 個月，在公共郵件列表中描述了一個有點明顯的致命錯誤。
- 查看OpenSSL 漏洞列表（您可以過濾更重要的漏洞）並使用發布日期將最早的修復版本與已知的最舊的易受攻擊的版本進行匹配。在被發現和修復之前存在 2 年或更長時間的百分比令人印象深刻，其中有幾個活了 4 年以上。蟲子很難找到，而且通常壽命很長。
- 這不是特定於庫的，但我認為教訓是：針對 TLS 1.0 的 BEAST 攻擊利用了9 年前發布的理論漏洞（並在實際上未使用的 TLS 1.1 中修復）。即使我們知道漏洞，如果不方便並且攻擊似乎不切實際，我們有時也不會修復它們。
我在那裡稍微選擇了 OpenSSL，因為它非常流行、開源並且有文件記錄，這讓它變得很容易。（值得注意的是，原始碼一團糟，這可能不鼓勵任何人閱讀它。）其他庫也有一些類似的模式，不太受歡迎的項目可能有誤導性的漏洞列表，因為 OpenSSL 的漏洞在出現時很受歡迎，而且很可能獲得 CVE。一個不太受歡迎的項目的貢獻者是否會報告他們修復的每個錯誤，將其評估為潛在漏洞，然後送出 CVE？我不知道。
相比之下，Truecrypt 沒有公佈的漏洞列表，誰知道在微軟的封閉原始碼庫中哪些微妙的修復未報告（或以“安全修復#XYZ”等不透明的名稱報告）。我們如何才能對他們的漏洞歷史進行高級別的評估？
我個人的感覺是好的審計是非常困難的，非常少見，而且大部分的審計都是由維護者自己完成的。對我來說，圖書館的可信度更集中於維護它的人，而不是它的受歡迎程度（並且據說更“引人注目”）。
同樣，這是我的總體印象，是一種主觀反應，不能完全回答主觀問題。
以我的經驗 bouncycastle 是最穩定的（java 和 .net 版本）。但：
- 不要在 Windows 上使用 CSP 等內置庫，因為您不知道在做什麼（因此您無法 100% 展示任何內容），並且在許多情況下它們使用作業系統設置和限制工作，因此結果可能出乎意料。使用具有可讀原始碼的庫
- 另一方面，基於虛擬機的語言在意外情況（緩衝區溢出等）上工作得更好，所以我更喜歡它們是 100% 安全的。像 OpenSSL 這樣的 C/C++ 庫具有非常好的性能，但它們的原始碼非常難以閱讀，因此需要謹慎使用它們以保護程式碼免受意外情況的影響。準備好損壞的數據
- 如果你需要選擇一個庫需要自己測試，你需要加密一個消息，然後用另一個庫解密；你需要做壓力測試；您需要對您的應用程序進行集成測試；等等。沒有完美的圖書館。
為了得出結論，您必須認為您的應用程序的弱點可能不是密碼庫。