KeyGenerator.io

AES 金鑰產生器

128、192、256 位元的 AES 隨機金鑰,在你的瀏覽器裡產生。不連網,不記錄,不上傳。

0 位元熵

金鑰長度
編碼

空白鍵 換一個,C 複製。金鑰由本機的 crypto.getRandomValues 產生,頁面不載入任何外部資源。

這把金鑰是怎麼產生的

AES 金鑰是一段長度固定的隨機位元組:AES-128 是 16 個,AES-192 是 24 個,AES-256 是 32 個。它和密碼不同,沒有長度上下限可以權衡 —— 演算法只接受這三種長度之一,而其中每一個位元都必須無法被猜到。

這些位元組直接取自 crypto.getRandomValues,也就是瀏覽器的密碼學安全亂數產生器,再以十六進位或 Base64 寫出。整條路徑上沒有時間戳、沒有計數器,也沒有 Math.random。兩種寫法承載的是同一串位元組,挑你的函式庫或金鑰儲存服務要的那種即可。

全部在你自己的裝置上完成。頁面載入後不發出任何網路請求,所以這把金鑰從未在別處存在過,也不會傳到任何地方。重新整理就消失。

常見問題

該選哪個長度?

沒有特殊限制就選 AES-256 —— 不是因為 128 位元會被破解,而是因為更長的金鑰幾乎不增加成本,還能讓這個問題以後不必再吵。AES-128 對暴力破解依然完全安全,在沒有 AES 硬體加速的裝置上還明顯更快。AES-192 存在、可用,但因為用的人太少,部分函式庫與硬體路徑對它的支援反而不如另外兩種。

AES-256 的強度是 AES-128 的兩倍嗎?

不是,差距是 2^128 倍而不是 2 倍。但這兩個數字都早已越過「暴力破解毫無意義」的界線:數到 2^128 所需的能量超出整個地球的預算,無論你設想什麼硬體。真實系統的破口從來不在金鑰長度,而在於 nonce 重複使用、金鑰由口令直接推導、以及金鑰和它保護的資料存在同一個地方。

IV 就是金鑰嗎?

不是,而混淆這兩者是 AES 最常見的錯誤。金鑰是長期保存的機密;IV(在 GCM 模式下稱為 nonce)是每則訊息各自一份的值,完全不是機密,通常就明文附在密文旁邊一起傳送。每則訊息都要產生新的 IV;金鑰則產生一次後長期保留。

每則訊息都要換一把金鑰嗎?

不用。一把金鑰可以加密許多訊息,前提是每則訊息都有自己的 IV 或 nonce。絕對不能重複的是同一把金鑰下的 nonce —— 在 GCM 模式下重複使用會洩漏兩段明文的 XOR,並讓攻擊者能夠偽造訊息,那是徹底失守而不是稍微變弱。慣例做法是每則訊息隨機產生一個 96 位元的 nonce。

可以直接拿口令當 AES 金鑰嗎?

不能直接用。口令既短又取自很小的空間,而 AES 金鑰必須與隨機資料無法區分。如果輸入非得由人記住,就讓它經過金鑰推導函式 —— Argon2id、scrypt,或迭代次數足夠高的 PBKDF2 —— 再把輸出當金鑰。把口令用 SHA-256 雜湊一次確實會得到 32 個位元組,但那不是 32 個位元組的不可預測性。

該用 GCM 還是 CBC?

絕大多數情況選 GCM。它在加密之外同時提供驗證,密文被竄改會被偵測到,而不是靜靜地解出一堆垃圾再被你的程式當成真的。CBC 本身完全不提供完整性保護,必須另外搭配 MAC,而且套用順序還要正確 —— 這正是最容易悄無聲息出錯的那類細節。

十六進位還是 Base64?

兩者是同一串位元組:256 位元金鑰寫成十六進位是 64 個字元,寫成 Base64 是 44 個字元,強度完全相同。用接收方預期的格式即可 —— 雲端金鑰服務和各語言的函式庫通常要 Base64,而設定檔、命令列參數,以及任何會經過 shell 的地方用十六進位比較保險,因為它只含 0-9 和 a-f。

金鑰該放在哪裡?

有金鑰管理服務就放進去,沒有的話放在環境變數或不進版本控制的機密檔案裡。絕對不要和它保護的密文放在一起 —— 金鑰若和資料存在同一個資料庫、同一份備份或同一個程式庫裡,那份儲存一旦被複製,保護就等於不存在。另外要注意:更換 AES 金鑰意味著要把資料重新加密,所以輪替需要事先規劃,不是設個排程就好。

在瀏覽器裡產生加密金鑰安全嗎?

只有在這個頁面無法把它送出去的前提下才安全,而這件事你可以查證,不必只是相信。打開開發者工具停在「網路」分頁,然後隨便產生幾次:頁面載入之後不發出任何請求。它背後沒有伺服器可以接收任何東西,也沒有分析工具或第三方腳本可以外洩。