不建議以純文本形式將數據庫中的電子郵件地址存儲在數據庫中，所以我想找出實現此目的的最佳算法。選項有：加密/解密字符串和密鑰存儲方法的最佳算法
（從文檔）
CFMX_COMPAT：在ColdFusion MX的和之前的版本中使用的算法。該算法是最不安全的選項（默認）。
AES：由美國國家標準與技術研究院（NIST）FIPS-197指定的高級加密標準。
BLOWFISH：由Bruce Schneier定義的Blowfish算法。
DES：由NIST FIPS-46-3定義的數據加密標準算法。
DESEDE：由NIST FIPS-46-3定義的「Triple DES」算法。
另一個問題是密鑰的存儲位置？在數據庫中還是在源代碼中？它會被加密嗎？如果它將被加密，那麼這個問題會引發加密密鑰的密鑰的存儲方式。
它應該存儲在源代碼中，將無源分佈是好的嗎？
我會使用AES。這是所列出的最強和最強的。
至於在哪裏存儲密鑰，那就是$ 64,000的問題。你不應該把它放在數據庫中（至少不要與它用於加密的數據在同一個數據庫中），也不要放在你的源代碼中。
密鑰管理是一個話題的怪物。 NIST有數百頁的文件說明如何做到這一點。
http://csrc.nist.gov/groups/ST/toolkit/key_management.html
密鑰管理涉及到恰當generaton，交換，存儲，旋轉，按鍵的破壞。你不應該永遠使用相同的密鑰（一個非常常見的錯誤），也不應該存儲它不正確。
您應該查看NIST指南並確定適合您的策略，並根據其敏感性充分保護您的數據。
使用AES或DESEDE - 它們很強大，根據我的經驗，如果您因某種原因需要移植此信息，則它們具有很大的兼容性。
至於關鍵，這不是真正的關鍵數據。通常情況下，您需要從該數據的獨特信息（如userId）和私鑰（salt）（如代碼庫中的常量）中創建一個compsite密鑰：
您的全局設置/常量中的某處：
<cfset myCodeBaseKey = "NateIsAwesome">
然後，當你準備好要加密：
<cfset myKey = hash(myCodeBaseKey & user.userId, "SHA")>
詩如果你使用我聽到的確切的鹽詞組，它會更好。 ：P〜
因爲我認爲這是可怕的建議，因此被拒絕投票。說鑰匙不重要不僅是錯誤的，它與事實完全相反。密鑰是密碼系統中最重要的部分（假設一個強大的算法）。而使用非隨機的，容易推斷的密鑰是一個可怕的想法。 –
密鑰是一個獨特的信息和私鑰的哈希組合 - 不容易推斷或顛倒。此外，您誤解了「這不是關鍵數據」的陳述 - 這是指被保護的數據是電子郵件地址。 – Nate
「輕鬆推理」意思是說，如果你知道如何創建一個，你就知道如何創建它們。獨特！=隨機。我很抱歉，我誤解了你的重要數據的含義，我同意電子郵件地址不是關鍵數據，但如果有人要去加密某些東西的麻煩，那麼使用弱密鑰就沒有意義一。 –
我很好奇你爲什麼認爲用明文存儲電子郵件地址是不明智的。 –
我同意，確保你不只是貨物的理由，它不適合。 –
這是爲了隱私。如果安全性被破壞，至少他們在獲得加密數據之前必須破解另一層。請閱讀以下內容：http://bit.ly/pkrOG0 http://tgr.ph/nneofZ http://bit.ly/lYdU03 http://bit.ly/nVm3EX –