FIPS 140-2，1 級驗證與編譯
我正在開發一個需要使用必須經過 FIPS 140-2、1 級驗證的加密功能的系統。具有挑戰性的部分是該系統的某些部分需要在瀏覽器中執行。出於可維護性和易用性的原因，我真的很想避免不得不求助於小程序或瀏覽器外掛或 Active-X 控制項或類似的東西，而寧願用 JavaScript 建構系統的這一部分。
所以，我一直在尋找經過驗證的 JavaScript 模組，但是這個網站：
https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Validated-Modules/Search
如果您點擊“全部顯示”，它會列出所有（？）目前已驗證的模組，這並沒有給我太多希望找到一個。
所以，這就是我的想法：
我可以使用其中一個 Java 模組（如 Bouncy Castle）並使用GWT之類的東西將它們交叉編譯為 JavaScript嗎？
或者我可以採用 C 或 C++ 模組之一併將其編譯成asm.js嗎？
或者，更一般地問這個問題：驗證程式碼的（交叉）編譯或翻譯如何影響驗證？
我不會對找到一個經過 FIPS 認證的原生 Javascript 加密實現抱太大希望。原因是歸零；FIPS 特別關注何時知道 CSP
$$ 1 $$被歸零；Javascript 會進行垃圾收集，這意味著您永遠無法確定何時將事物歸零。 而且，如果通過交叉編譯，您的意思是採用經過認證的實現，並自動將其轉換為 Javascript，那麼您將無法解決問題。
對不起，但我希望我有更好的消息給你。
$$ 1 $$：關鍵安全參數；本質上是 FIPS 的密鑰術語
- 您可以轉換/交叉編譯程式碼，但這不會移植任何驗證甚至認證。最後，交叉編譯的產品是新產品——需要重新驗證。除非發生這種（重新）驗證，否則任何交叉編譯結果都必須被視為“未經驗證的密碼學”。
NIST 認為未經驗證的密碼學不會對資訊或數據提供保護——實際上，數據將被視為未受保護的明文。如果該機構指定資訊或數據受到加密保護，則適用 FIPS 140-2。本質上，如果需要密碼學，則必須對其進行驗證。
- Javascript 本身在密碼學方面存在幾個問題，這就是Window.crypto API 誕生的原因。該 API 與通過 Web 瀏覽器客戶端程序本身提供的非 JavaScript 加密功能掛鉤。然而，據我所知，該 API尚未經過驗證。除其他原因外，由於它的地位有些不成熟。因此，從驗證的角度來看，這也必須被視為提供“沒有保護”。
- 現在，與您的
… FIPS 140-2，1 級驗證。具有挑戰性的部分是該系統的某些部分需要在瀏覽器中執行……
在撰寫本文時，還沒有“僅瀏覽器”的方式來執行此操作。但是，如果您將伺服器添加到等式中，則可以讓該伺服器處理經過驗證的加密貨幣——無論如何，這將是最值得推薦的，因為您可以控制伺服器，但無法控制客戶端。
順便說一句：我不認為美國政府很快就會因為它是敏感資訊而跳入基於 Javascript 的加密模組——這就是為什麼你不應該寄希望於在不久的將來發現一個經過驗證的 Javascript 模組……如果有的話.