公司是否應該實施（最近）發布的加密協議
我知道你永遠不應該實現你自己的未發布的加密協議。這個話題在很多地方都得到了很好的討論，例如這裡。
但是，一旦一個協議已經發布、經過同行評審並已經存在了幾年，那麼為自己實施該協議的一般準則是什麼？
我聽到的一般建議是不要。（例如 SEJPM 對此問題的評論）。相反，請使用經過充分審查的預先存在的開源實現，例如 SSL。但這有幾個問題：
- 對此類實現的使用可能存在限制。
- 有時不存在實現。該協議可能僅在 1-2 年前實施，還沒有人能夠實施。
- 您發現的實現也可能有問題。特別值得關注的是，作者可能會意識到錯誤（例如後門）。
似乎公司確實實施了加密協議而不發布實施，例如產品“Sharemind”。
那麼，公司是否應該為商業產品實施已發布的協議？如果是這樣，他們應該遵循什麼準則？
那麼，公司是否應該為商業產品實施已發布的協議？
是的，如果它真正為您的使用者增加價值的話。不，如果它是關於節省 4 個簽名字節和 112 個 CPU 週期。
如果是這樣，他們應該遵循什麼準則？
- 至少發布加密部分的原始碼，以便同行評審。
- 聘請該領域的專家作為顧問來審查實施情況。
上述兩點都將有助於為可能對安全性持保守態度的客戶提供強有力的採用理由。
那麼，公司是否應該為商業產品實施已發布的協議？如果是這樣，他們應該遵循什麼準則？
我將詳細說明最後一個問題；其他答案非常徹底地涵蓋了其他部分。
首先要注意的是，編寫將在實踐中使用的密碼學程式碼並不是應用程序程式中的標準練習。我們最近有一個關於密碼學實現實踐的問題，一些對加密編碼不太熟悉的開發人員對編寫加密程式碼時使用的一些實踐完全不相信。
所以首先要注意的是：
開發人員是否有實施加密算法的經驗？
如果答案是“否”，則應避免實施。有很多方法可以將理論上無懈可擊的密碼算法轉變為可以在實踐中以極少的努力和時間破解的東西。
常見數據類型的標準程式錯誤現在是安全問題。您需要有意識地意識到這一事實的開發人員。
某些算法容易受到旁道攻擊： 某些算法可能以某些方式實現，通過替代資訊通道洩露內部資訊；以下是可能需要積極、有意識地進行調解的問題列表：
- 記憶體攻擊——攻擊基於攻擊者監控受害者在共享物理系統（如在虛擬化環境或某種雲服務中）進行的記憶體訪問的能力。
- 定時攻擊——基於測量各種計算執行所需時間的攻擊。
- 電源監控攻擊——在計算過程中利用硬體不同功耗的攻擊。
- 電磁攻擊——基於洩露的電磁輻射的攻擊，可以直接提供明文等資訊。此類測量可用於使用與功率分析中的技術等效的技術來推斷密碼密鑰，或者可用於非密碼攻擊，例如 TEMPEST（又名 van Eck phreaking 或輻射監測）攻擊。
- 聲學密碼分析——利用計算過程中產生的聲音的攻擊（類似於功率分析）。
- 差分故障分析——通過在計算中引入故障來發現秘密。
- 數據殘留——敏感數據在被刪除後被讀取。
- 行錘 - 可以通過訪問相鄰記憶體來更改禁區記憶體。
- 光學 - 可以使用高解析度相機或其他具有此類功能的設備通過視覺記錄來讀取機密和敏感數據。
實施正確性的正式證明
如果您真的很認真地想要實現它，那麼您可以通過創建一個正式證明是正確的實現來贏得很多青睞。有專門的語言可以做到這一點。
基本上，如果您：
- 正在實施標準化算法
- 它已經看到了足夠的同行評審
- 有一個至少可以抵禦基本側通道攻擊的實現
- 有一個正式證明是正確的實現
我看不出任何人有充分的理由抱怨這樣的實施；很少有現有的庫提供這樣的功能集合，如果我們有更多滿足這些要求的軟體，世界可能會變得更好。
但…
您的普通 Web、應用程序或系統開發人員不太可能熟悉生成此類實現所需的工具/語言/技術，無論他們工作了多長時間。
許多熟悉此類事情的開發人員都在攻讀博士學位 - 正確性的正式證明和針對 DPA 攻擊的積極應對措施根本不是普通程序員關心的事情，更不用說甚至意識到了。
簡單地說…
您會知道您的開發團隊是否準備好產生可接受/成功的實現。
如果您的開發團隊不是由具有安全實施算法和/或證明其正確性的先前經驗的成員組成，那麼讓他們實施任何東西可能是個壞主意。至於原因…
失敗的代價
當您在正常軟體中出現錯誤時，最壞的情況是您的應用程序在客戶端使用時崩潰。
當您的加密軟體出現錯誤時，您的客戶資訊就會面臨風險：
- 如果您的客戶使用您的軟體是因為他們關心保護他們的資訊，那麼您未能提供此結果
- 如果他們付錢給你，他們可能會更加沮喪
- 這可能會損害您的企業聲譽
- 這可能會花費您的企業資金
底線顯然是企業最關心的。即使您不為軟體收費，其餘部分也適用。
在實施提供給客戶的加密算法/服務之前，請務必權衡風險與潛在利潤——不要過於關注潛在利潤，以至於忽略了企業遭受損失並造成實際損失的所有非常真實的可能性對使用它的人的生命造成損害。