0 位元熵
金鑰長度
編碼
128、192、256 位元的 AES 隨機金鑰，在你的瀏覽器裡產生。
按 空白鍵 換一個，C 複製。金鑰由本機的 crypto.getRandomValues 產生。
保留 256 位元設定、選擇十六進位，再複製金鑰。得到的是 32 個隨機位元組，以 64 個十六進位字元表示。如果接收系統要求 Base64，改選 Base64 即可。
| AES 金鑰 | 隨機位元組 | 十六進位字元 | Base64 字元 |
|---|---|---|---|
| AES-128 | 16 | 32 | 24 |
| AES-192 | 24 | 48 | 32 |
| AES-256 | 32 | 64 | 44 |
AES 金鑰是一段長度固定的隨機位元組：AES-128 是 16 個，AES-192 是 24 個，AES-256 是 32 個。它和密碼不同，沒有長度上下限可以權衡 —— 演算法只接受這三種長度之一，而其中每一個位元都必須無法被猜到。
這些位元組直接取自 crypto.getRandomValues，也就是瀏覽器的密碼學安全亂數產生器，再以十六進位或 Base64 寫出。整條路徑上沒有時間戳、沒有計數器，也沒有 Math.random。兩種寫法承載的是同一串位元組，挑你的函式庫或金鑰儲存服務要的那種即可。
金鑰在你的瀏覽器內產生並保留，重新整理頁面後就會清除。
沒有特殊限制就選 AES-256 —— 不是因為 128 位元會被破解，而是因為更長的金鑰幾乎不增加成本，還能讓這個問題以後不必再吵。AES-128 對暴力破解依然完全安全，在沒有 AES 硬體加速的裝置上還明顯更快。AES-192 存在、可用，但因為用的人太少，部分函式庫與硬體路徑對它的支援反而不如另外兩種。
不是，差距是 2^128 倍而不是 2 倍。但這兩個數字都早已越過「暴力破解毫無意義」的界線：數到 2^128 所需的能量超出整個地球的預算，無論你設想什麼硬體。真實系統的破口從來不在金鑰長度，而在於 nonce 重複使用、金鑰由口令直接推導、以及金鑰和它保護的資料存在同一個地方。
不是。金鑰是長期保存的機密；IV（在 GCM 模式下稱為 nonce）是每則訊息各自一份的值，完全不是機密，通常就明文附在密文旁邊一起傳送。每則訊息都要產生新的 IV；金鑰則產生一次後長期保留。
不用。一把金鑰可以加密許多訊息，前提是每則訊息都有自己的 IV 或 nonce。絕對不能重複的是同一把金鑰下的 nonce —— 在 GCM 模式下重複使用會洩漏兩段明文的 XOR，並讓攻擊者能夠偽造訊息，那是徹底失守而不是稍微變弱。每則訊息隨機產生 96 位元 nonce 是常見做法，但仍有碰撞機率，不能保證唯一。請遵守協定或密碼學函式庫規定的每把金鑰使用上限，並在到達上限前輪替金鑰。
不能直接用。口令既短又取自很小的空間，而 AES 金鑰必須與隨機資料無法區分。如果輸入非得由人記住，就讓它經過金鑰推導函式 —— Argon2id、scrypt，或迭代次數足夠高的 PBKDF2 —— 再把輸出當金鑰。把口令用 SHA-256 雜湊一次確實會得到 32 個位元組，但那不是 32 個位元組的不可預測性。
絕大多數情況選 GCM。它在加密之外同時提供驗證，密文被竄改會被偵測到，而不是靜靜地解出一堆垃圾再被你的程式當成真的。CBC 本身完全不提供完整性保護，必須另外搭配 MAC，而且套用順序還要正確 —— 這正是最容易悄無聲息出錯的那類細節。
兩者是同一串位元組：256 位元金鑰寫成十六進位是 64 個字元，寫成 Base64 是 44 個字元，強度完全相同。用接收方預期的格式即可 —— 雲端金鑰服務和各語言的函式庫通常要 Base64，而設定檔、命令列參數，以及任何會經過 shell 的地方用十六進位比較保險，因為它只含 0-9 和 a-f。
有金鑰管理服務就放進去，沒有的話放在環境變數或不進版本控制的機密檔案裡。絕對不要和它保護的密文放在一起 —— 金鑰若和資料存在同一個資料庫、同一份備份或同一個程式庫裡，那份儲存一旦被複製，保護就等於不存在。另外要注意：更換 AES 金鑰意味著要把資料重新加密，所以輪替需要事先規劃，不是設個排程就好。