2015 年的密碼混淆狀況如何？
加密混淆是一種允許人們以安全方式混淆原始碼的技術（而不是將其不安全地修改為意大利麵條程式碼。）例如，這是一種使用密碼保護一段數據的方法：
cipher_text = obfuscate("\key -> if input == SYMETRIC_KEY then return \"Launch code is 7205872\" else return \"No launch codes for you!\"")或者這裡是一個公鑰加密方案：
public_key = obfuscate( "\input -> obfuscate(\" \key -> if key == PRIVATE_KEY then return " ++ input ++ " else return \\\"You do not have the public key!\\\")" )我的問題是，這項技術的現狀如何？它是否有任何程式語言可用？（我以類似 haskell 的語言提供了我的程式碼範例，因為 haskell 與 lambda 演算非常相似。事實上，
GHC將 Haskell 編譯為 lambda 演算作為中間步驟。因此，像 Haskell 或 lisp 這樣的語言很可能會成為第一個可用的。）注意：我不是在談論加密程序的傳統混淆，而是密碼混淆技術。
這確實是密碼學界正在進行的研究領域。所以，不，我不認為任何程式語言都可以使用這種類型的東西。DARPA SAFEWARE計劃表明，該領域正在投入大量研究資金，這將使您對社區正在研究的一些主題領域有所了解。
您連結到的 Matt Green 的文章提供了很多很好的背景材料，但是一歲的年齡有點過時了。
最近的一份調查報告涵蓋了目前狀態、未解決的問題等。
以下是有關該技術狀態的一些相關引述：
範圍
可學習的程序，即可以通過在不同的輸入上執行來重構其原始碼，顯然對混淆沒有興趣，儘管大多數有趣的程序是不可學習的，並且潛在的應用範圍非常廣泛。
效率
他們（ Apon 等人，在實現加密程序混淆中）混淆的最複雜的函式是一個包含 15 和門的 16 位點函式。該過程耗時 9 小時，生成了一個大小為 31.1 GB 的混淆程序，在具有 32 個核心和 244 GB RAM 的機器上，對單個輸入的評估大約需要 3.3 小時。
Dan Bernstein、Andreas Hülsing、Tanja Lange 和 Ruben Niederhagen 在 19 分鐘內在 21 台 PC 的集群上打破了 Apon 等人的計劃。他們論文的第 3 節包含一些（部分非常明顯的）優化，以使執行混淆程序的速度提高約 50。
我正在將此作為社區 wiki 文章，以便其他人可以在新結果出現時更輕鬆地對其進行更新。這是密碼學中一個快速變化的領域。
目前沒有（我所知道的）具有此類功能的程式語言。它似乎仍然是一個研究課題。
有一些原因我相信可能永遠不會有“安全混淆”（混淆意味著程序開箱即用，不需要使用者輸入，例如密鑰）
- 該程序必須是可執行的。這意味著即使有人手頭有一個魔術來掩蓋程序的工作方式，在某些時候它也是可以分析的。在這一點上，我會說你的例子很糟糕。密鑰以明文形式存在。
- 即使使用格林先生使用的論點，不儲存密鑰，而是使用鹽和胡椒進行雜湊，我仍認為它不安全。因為安全意味著我們無法通過分析獲得任何進展，也沒有能力規避它。但我們這樣做。最簡單的例子是反編譯、分析、修改程式碼、重新編譯，密碼檢查消失了，其餘的仍然可用。這與 JavaScript 中客戶端使用者身份驗證的壞主意非常相似。現在你可能會爭辯說我實際上並沒有學習秘密密碼，對我沒有，但那個密碼不是程序，所以基本上你什麼都沒有混淆，你仍然依賴眾所周知的密碼學。
- 這個話題是理論上的。這項研究背後可能有很多非常聰明的想法和聰明的頭腦，但我敢說，格林先生提出這些想法的方式是不切實際的（關於他對模糊程序的解釋）。我強烈懷疑“不可區分性混淆”是否適合此目的，因為如果它確實按建議工作，可能會破壞任何性能，從而使其對任何公司都沒有吸引力，或者不適用於實際電腦，因為可能會有更多攻擊向量，它可能不滿足安全要求。這是我對該主題的一般概念，因為所有這些證明都需要特定的模型和某些假設，這些假設可能適用於真機，也可能不適用。
在某些情況下，您可能能夠混淆部分，但這並不意味著您可以在任何情況下保護它免受任何人的影響。
請注意，我不想說格林先生不知道他在寫什麼，而是對他的文章持懷疑態度。他可能比我更了解這個話題。