雲端硬碟上傳前，壓縮檔密碼能擋住什麼，為什麼它不是本機 AES-GCM

一句話先回答搜尋意圖

上傳雲端前給壓縮檔設密碼，和本機 AES-GCM 不是同一層保護。前者把檔案放進 ZIP 容器，再對容器內的檔案內容加鎖；容器自己的目錄——檔名、日期、大小——依 ZIP 設計就是給人看的。後者在瀏覽器裡用 Web Crypto API 對位元組做 AES-256-GCM，下載密文後再上傳，雲端沒有解密口令就只剩亂碼。

這篇文章給開發者、維運，以及要把備份丟進雲端硬碟之前想分清「設了密碼」和「對端看不見內容」的人。它不代替 檔案加密盒 的操作說明，也不重複「怎麼點按鈕得到 .lock」。你要帶走的是：ZipCrypto 和 ZIP-AES 各擋什麼、雲端預設加密的鑰匙在誰手裡、本機加密完檔案頭還剩什麼、用 Network 和十六進位怎麼當場對照。

「設了密碼」和「雲端看不見內容」不是一回事

日常說法把三件不同的事揉成一句「這個檔案加密了」。第一件是傳輸加密：瀏覽器和雲端硬碟之間走 HTTPS，路徑上的人難讀原文。第二件是業者靜態加密：磁碟上的區塊被業者的金鑰包起來，硬碟被偷走時更難直接讀。第三件是你自己持有金鑰的用戶端加密：上傳之前內容已經在本機變成密文，業者沒有你的口令就解不開。

壓縮檔密碼落在這三層之外的第四種習慣：你在本機做了一個帶口令的容器，再把容器當普通檔案上傳。雲端硬碟對它的處理和一份未加密的 .zip 沒有本質差別——依檔名建索引、依雜湊做重複檔案偵測、依政策掃惡意軟體或掃敏感內容。容器裡如果還是 ZipCrypto，或者目錄是明文，掃描程式不必先「猜你的密碼」就能讀到檔名，有時還能對內容做更多事。

所以「我設了密碼」只能支持很窄的結論：不會解壓縮、或沒有口令的人，不容易直接打開內容。它不能支持「雲端員工看不見」「依法調取拿不到原文」「檔名不會進對方的索引」。要把後幾句寫成可核對的事實，必須換一層：先在本機做驗證加密，再上傳密文。

ZipCrypto 為什麼擋不住認真的對手

ZIP 傳統加密常被叫做 Zip 2.0 或 ZipCrypto。WinZip 自己的說明寫得很直：這種格式「相對較弱」，不能指望它擋住拿得到專用還原工具的人；有重要安全要求時，應改用 AES。WinZip 加密說明把這一點寫在產品文件裡，不是論壇傳聞。

弱在演算法，不在你設的密碼夠不夠長。1994 年，Eli Biham 和 Paul Kocher 發表了對 PKZIP 串流密碼的已知明文攻擊：只要能對上大約十幾位元組的明文和對應密文，就可以反推密碼機內部的三組狀態，進而還原整份檔案的金鑰流。口令長度在這一步裡不再出場——對手複製的是鎖芯，不是在試鑰匙。公開實作（例如 bkcrack）把這篇論文收成可執行的程式，針對「儲存（Store）且使用 ZipCrypto」的壓縮檔尤其直接。

已知明文從哪來？PDF 以 %PDF 開頭，Office 文件、許多圖片和巢狀 ZIP 都有固定魔術數字。你把一份格式公開的合約打進 ZipCrypto 包，再上傳，等於同時交出了密文和一段幾乎確定的原文樣本。這不是要你去重現攻擊，而是要你停止把「右鍵壓縮並設密碼」當成 AES-256-GCM。

系統內建的壓縮、雲端網頁上的「加密壓縮」、舊版打包指令稿，都可能默默選中 ZipCrypto，因為它相容幾乎所有解壓縮軟體。7-Zip 若格式選 ZIP，加密方法也常預設落在 ZipCrypto，要自己改成 AES-256。打包之後先看內容資訊：寫的是 ZipCrypto / Zip 2.0，就不要把它當備份方案。寫的是 AES，進入下一節——內容層強了，目錄層往往還是明文。

即便是 AES 壓縮檔，目錄資訊仍是明文

WinZip 從 9.0 起提供 AES-128 / AES-256（AE-1 / AE-2）。金鑰由口令經 PBKDF2 匯出，鹽值 8 或 16 位元組，疊代次數是 1000。這比 ZipCrypto 強一個數量級，但和「瀏覽器裡的 AES-256-GCM」仍不是同一套封裝：WinZip AES 對內容做加密再驗證（AES-CTR + HMAC），不是 NIST 的 GCM；1000 次疊代也遠低於現在常見的十萬級口令派生。

更常被忽略的是目錄。WinZip 寫明：加密只作用於壓縮檔內部檔案的內容；檔名、日期、大小、屬性和壓縮比存在未加密的目錄裡，任何拿到這個 ZIP 的人都能檢視，不需要密碼。官方甚至單獨寫過一篇「打開加密 ZIP 仍能看見檔名」的說明，建議用「先打一層不加密包、再把這個包放進第二個加密包」來遮一層名字。見 WinZip 對檔名可見性的說明。

7-Zip 的 .7z 可以把「加密檔名」勾上，那是另一條產品線，不要和 ZIP 預設行為混為一談。你在檔案總管裡看到「需要密碼」，只說明解壓縮要口令；用另外一個解壓縮器打開同一份檔案，檔案清單往往立刻出來：身分證正面.jpg、薪資表-2026.xlsx、客戶名單.csv。雲端硬碟的預覽、全文搜尋和重複檔案偵測，讀的就是這一層。

雲端「已加密」通常是業者持有金鑰

把壓縮檔或原文直接丟進雲端硬碟，頁面常會寫傳輸加密、靜態加密、AES-256。這些句子可以同時為真，卻回答不了「誰拿著解密金鑰」。Google 對雲端硬碟的說明是：上傳或在文件 / 試算表 / 簡報建立的檔案，預設在傳輸中和靜態時用 AES-256 加密；若還要讓 Google 解不開，需要 Workspace 管理員開啟用戶端加密，並且使用者用公司或學校帳戶、完成身分驗證。個人拖進「我的雲端硬碟」的普通檔案，走的是預設路徑，不是用戶端加密。依據是 雲端硬碟加密檔案說明。

Google Cloud 把預設靜態加密寫得更白：金鑰由 Google 擁有並管理。磁碟上的資料加密金鑰（DEK）會再用金鑰加密金鑰（KEK）包一層，解密發生在業者的金鑰服務裡。見 Google Cloud 預設靜態資料加密。Workspace 白皮書同樣區分「Google 代管金鑰」和「用戶端加密後 Google 不可讀」。Dropbox、OneDrive 一類空間的預覽、重複檔案偵測和惡意軟體掃描，也建立在「伺服器能讀到檔案位元組或至少能讀到明文雜湊」的前提上；它們不會因為你在本機給 ZIP 設了密碼，就自動變成零知識。

因此，雲端角標上的鎖，保護的是「硬碟被搬走」和「鏈路上的旁觀者」，不是「我把檔案交給了這家公司之後，對方也看不見」。要把後一句話變成可觀察的事實，必須在上傳前先失去可讀的原文。

本機 AES-256-GCM 實際保護哪一層

AES-GCM 是驗證加密：同一輪運算既保密又帶完整性。密文被改過、截斷，或口令錯了，解密應當直接失敗，而不是吐出一段「看起來像亂碼的錯誤明文」。NIST SP 800-38D 建議實作把 IV 限制在 96 位元（12 位元組），以簡化互通；標籤長度常用 128 位元（16 位元組）。同一金鑰下 IV 不得重複，否則保密性和驗證會一起垮。

瀏覽器裡的正確路徑是 crypto.subtle.encrypt，演算法名 AES-GCM。MDN 寫明 SubtleCrypto.encrypt 只在安全情境可用，正式環境就是 HTTPS。口令不能當 256 位元金鑰直接用，要先經 PBKDF2 一類函式加鹽、多次疊代再匯出。RFC 2898 定義了 PBKDF2；疊代次數決定「猜一個口令要算多久」，1000 次和 100000 次不在同一量級。

檔案情境可以收成一組看得見的動作：用檔案選擇器選出本機檔案，指令碼按塊讀進記憶體，每一塊用新的隨機 IV 做 AES-256-GCM，再觸發瀏覽器下載密文。下載到的檔案是本機拼出來的，不是伺服器回條。單檔上限如果寫成 5 GB，描述的是瀏覽器裡串流處理的能力，並不表示遠端收了 5 GB 原文。

FastPwd 的檔案加密盒按這條邊界實作：AES-256-GCM，Web Crypto；口令用 PBKDF2-HMAC-SHA256、100000 次、16 位元組鹽，匯出 256 位元金鑰；預設每塊 1 MB，每塊 12 位元組 IV + 密文 + 16 位元組標籤；單檔不超過 5 GB；輸出 .lock / .enc，魔術數字為 CSLK。全部工具開啟即用，沒有帳號和密碼庫。口令遺忘後無法復原——因為口令從未上傳。承諾仍然只是承諾。下面把它收成檢查項，包括檔案頭裡沒有加密的那部分。

加密完能證明什麼，檔案頭還剩什麼

本機加密能支持的結論同樣很窄，寫清楚能少一次誤判。它能證明：在這一次操作裡，檔案內容按塊變成了帶驗證標籤的密文；沒有口令，解密應當失敗；若 Network 裡搜不到金絲雀，原文和口令沒有作為你觀察到的 HTTP 業務資料發出。

它不能證明：雲端硬碟看不見任何中繼資料，擴充功能沒讀剪貼簿，口令夠強，或者對方拿到密文後不會對你做離線猜口令。FastPwd Lock v1 的檔案頭裡，原始檔名和 MIME 以明文存放，方便解密後還原名字。上傳 身分證正面.lock，或頭裡仍寫著 身分證正面.jpg，雲端硬碟和任何打開十六進位的人都能讀到這幾個字。加密的是內容塊，不是整份容器對外的標籤。

當場對照：Network、檔案頭、斷網

口號不能當證據。準備一個可丟棄的小檔案，例如把正文寫成 canary-fp-20260904-zip-vs-gcm，檔名用 canary-fp-20260904.txt。口令用一段一次性長句，不要重用真實口令。

1. 先做對照組：把同一檔案打成帶密碼的 ZIP，用解壓縮軟體不輸入密碼打開。記下能否看見檔名、內容資訊裡寫的是 ZipCrypto 還是 AES。這是壓縮檔密碼實際擋住的範圍。
2. 再在瀏覽器裡做本機加密。開啟開發人員工具的 Network，勾選 Preserve log，過濾器用 All。加密完成後，把金絲雀貼進搜尋框。請求行、請求體和分析上報裡都不該出現原文或口令。
3. 用十六進位檢視器打開下載的 .lock。開頭四個位元組應是 CSLK（43 53 4C 4B）。往後能讀到鹽、分塊大小，以及你留下的原始檔名。內容區不應再出現金絲雀那句明文。
4. 頁面載入完成後，在 Network 裡打開 Offline 或關掉系統網路，再對另一個可丟棄的小檔案加密。若 .lock 仍能下載，說明這一次加解密不依賴即時介面。斷網要通過，連網時還要用金絲雀再搜一遍。

口令與密文不要走同一條渠道。雲端硬碟傳 .lock，口令改走 閱後即焚：本機用 AES-256-GCM 加密，伺服器只暫存密文，金鑰放在連結的 # 片段，形態是 s.html?id={id}#{key}。把完整焚鏈和密文一起丟進同一個雲端資料夾，等於把鑰匙黏在箱子上。也不要把完整連結貼進同一則 LINE。

三種看起來加密、其實沒擋住的情況

第一，網頁版「加密壓縮」或上傳後才設的分享密碼。有的空間在進度條走完後再幫你打包，或在伺服器上套一層「取得連結的人」加上選填密碼。分享密碼擋住的是不會點連結的人，擋不住伺服器已經存下的原文。對照方法：看加密發生在「選擇檔案之前」還是「上傳完成之後」。後者不是本機 AES-GCM。

第二，Office 或 PDF 自帶的開啟密碼。它保護的是對應閱讀器的開啟流程，檔案格式裡仍有大量結構化欄位；雲端硬碟預覽、全文搜尋和轉換服務經常能繞過「開啟時跳密碼」這一層。不要把它和整檔驗證加密當成同一件事。

第三，只改副檔名。把 .xlsx 改成 .bin 再上傳，重複檔案偵測和部分掃描仍按內容雜湊工作，檔案頭魔術數字還在。副檔名不是密碼學。本機加密之後，內容區的魔術數字應消失；若十六進位裡仍能看見 PK、%PDF 或 xlsx 的明文特徵，這一次就不能算過關。

常見問題

給 ZIP 設了 AES-256 密碼，上傳雲端硬碟還不安全嗎？

內容層比 ZipCrypto 強，但 ZIP 目錄裡的檔名、日期、大小預設仍是明文。雲端硬碟和任何拿到壓縮檔的人都能列出目錄。它也不是瀏覽器裡的 AES-256-GCM：WinZip AES 用另一套封裝，PBKDF2 疊代是 1000 次。要讓雲端只看見密文，先在本機加密整份內容，再上傳。

雲端硬碟寫「傳輸加密 / 靜態加密」，是不是已經夠了？

那通常是服務供應商持有金鑰的預設加密。TLS 保護傳輸，靜態加密保護硬碟被偷走的情境。業者、持有金鑰的維運和依法調取，仍可能解開你的原文。Google 雲端硬碟要把「Google 解不開」寫成事實，需要 Workspace 管理員開啟用戶端加密，不是個人拖檔上傳的預設路徑。

FastPwd 的 .lock 上傳後，雲端硬碟能看見原檔名嗎？

能看見副檔名，也能從檔案頭讀出原始檔名和 MIME。加密的是按 1 MB 分塊的檔案內容，不是整份容器的中繼資料。上傳前把來源檔改成無含義的名字，再加密。口令不要和密文放在同一個分享裡。

在 FastPwd 加密時，檔案和口令會不會被上傳？

依產品說明，加解密在目前分頁用 Web Crypto 完成，檔案與口令不作為業務資料發出，也不寫入 analytics。造訪統計只記「做了加密」這類事件名。用金絲雀搜 Network，請求行和請求體裡都不應出現原文或口令。localhost 預設不發送造訪統計，換到線上網域再複測一次更接近真實使用。

把同一份可丟棄的檔案用開啟即用的工具對照一次

若你希望用一個把計算邊界寫清楚的頁面來練習，開啟 FastPwd 的 檔案加密盒 即可，無需註冊。選上面那個金絲雀小檔案，口令用一次性長句；口令若被評為弱，頁面會先確認再繼續。加密後下載 .lock。同時盯著 Network：你應看到靜態資源和可能的造訪統計，不應看到原檔或口令作為業務欄位。

口令可以先在 密碼產生器 裡本地產生，亂數模式長度 6–128 字元、預設 16 字元；低於 8 字元會提示安全性較低。產生過程同樣不上傳。必須把口令交給同事時，改走閱後即焚，不要寫進雲端硬碟備註。短機密、一次性金鑰也不要塞進 .lock 當傳輸通道——檔案盒解決的是整份檔案的備份與交接，不是聊天紀錄裡的一行秘密。

下次上傳前記住三件事。第一，壓縮檔密碼擋住的是解壓縮，不是目錄，更不是 ZipCrypto 上的已知明文攻擊。第二，雲端預設加密的鑰匙通常在業者手裡。第三，本機 AES-256-GCM 保護的是內容塊；檔案頭和副檔名仍可能洩密，要用 Network 和十六進位自己看一遍。能重複的觀察，才值得寫進你們自己的備份說明。

延伸閱讀

「本地加密、不上傳」不能當證據，要用金絲雀搜 Network，見 瀏覽器本地加密怎麼核對明文沒有離開本機。把口令單獨交給接收方時，井號後面為什麼預設不進 HTTP，見 URL 的井號後面為什麼適合放金鑰，以及什麼時候會失效。若還要把工單正文裡的證件號在離開本機前掩碼，見 把工單和日誌貼進 AI 之前，怎麼先核對哪些欄位會離開本機。