AES 在同一個地方暴露明文和密文是否安全，
在 Web 應用程序中，我需要在網頁表單中發送一個 id（我的純文字），然後在使用者送出表單時將其取回。但我需要保護 id，因此惡意使用者無法向伺服器發送不正確的 id。
我正在考慮將 id 和密碼文本發送到客戶端，當我在伺服器端檢索它們時，我解密密碼文本，如果 id 與解密的值不匹配，我拒絕呼叫。我正在使用帶有 256 位密鑰的 AES。
所以問題是：這樣做安全嗎？有沒有更好的辦法？謝謝您的幫助
PS：有業務需要將 id 作為純文字（未加密）發送給客戶端。
如果要確保 id 不被客戶端修改，請使用消息驗證碼。如果要防止竊聽者的重放等網路層攻擊，請在伺服器和客戶端之間使用 SSL。
但是惡意客戶端仍然可以重用之前收到的 ID。如果這是一個問題，您需要做更多的事情（例如，使用並保留一個隨機數進行驗證）。
使用任何現代¹加密機制，將明文和密文一起發送是安全的，但這對您沒有幫助。加密機制的特性是，如果某人擁有一系列明文及其對應的密文，而他又擁有一個密文但又沒有對應的明文，又沒有密鑰，那麼就知道所有這些明文- 密文對並不能幫助他們解密那個神秘的密文。這並沒有說明能夠從明文建構密文。根據加密機制的不同，這可能完全是微不足道的，或者只有在某些特定的數據安排下才有可能，但這不是加密機制的目標。
您需要的是一種*身份驗證機制。客戶端有一些明文數據，以及他們不需要能夠解碼的額外 blob。給定明文和額外的 blob，您希望保證額外的 blob 是由您的伺服器為該特定的明文生成的。如果使用非對稱加密，則該 blob 稱為簽名，如果使用對稱加密，則稱為MAC*。身份驗證機制具有沒有密鑰的特性，就不可能生成一條數據的簽名/MAC。這個屬性正是你所需要的。
簡而言之：加密可讓您對數據保密。您對保密數據沒有興趣，因此加密在這裡沒有用處。身份驗證可讓您檢查數據是否未被修改，這是您想要的。
由於您的伺服器既要創建身份驗證 blob 又要稍後對其進行驗證，因此您可以使用對稱加密，即使用 MAC。最受歡迎的 MAC 系列是HMAC，它內部不使用 AES。HMAC 幾乎在每個加密庫中都可用。
請注意，MAC（或簽名）僅保證數據的真實性，即它保證您的伺服器在過去的某個時間點對其進行了簽名。它沒有說明為什麼您的伺服器對其進行簽名，因此與往常一樣，僅將密鑰用於驗證 ID 的目的，不要將相同的密鑰用於不同的目的。
MAC（或簽名）也沒有說明您的伺服器何時簽署它，因此僅僅因為客戶端可以顯示具有正確 MAC 的 ID 並不意味著該 ID 有效：它僅表示該 ID 有效在過去。如何處理取決於您的 ID 如何變得無效。例如，如果 ID 在伺服器重新啟動之前仍然有效，那麼您可以在啟動時生成一個新密鑰；重新啟動前的 ID 不會使用新密鑰簽名，因此無效。如果某些 ID 可能變為無效，而其他 ID 仍然有效，那麼您需要更複雜的機制，可能需要為每個客戶端使用單獨的密鑰。
¹ “現代”是指電腦時代的任何事物。顯然，這僅適用於密碼學家社區廣泛認可的機制，不適用於自製或信譽不佳的機制。