网盘上传前，压缩包密码能挡住什么，为什么它不是本机 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，因为它兼容几乎所有解压软件。打包之后先看属性：写的是 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 对 Drive 的说明是：上传或在 Docs / Sheets / Slides 创建的文件，默认在传输中和静态时用 AES-256 加密；若还要让 Google 解不开，需要工作区管理员打开客户端加密，并且用户用工作或学校账号、完成身份校验。个人拖进「我的云端硬盘」的普通文件，走的是默认路径，不是客户端加密。依据是 Drive 加密文件说明。

Google Cloud 把默认静态加密写得更白：密钥由 Google 拥有并管理。磁盘上的数据密钥（DEK）会再用密钥加密密钥（KEK）包一层，解密发生在服务商的密钥服务里。见 Google Cloud 默认静态加密。Workspace 白皮书同样区分「Google 代管密钥」和「客户端加密后 Google 不可读」。国内网盘的合规扫描、秒传哈希、文档预览，也建立在「服务端能读到文件字节或至少能读到明文哈希」的前提上；它们不会因为你在本地给 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}。把完整焚链和密文一起丢进同一个网盘文件夹，等于把钥匙粘在箱子上。

三种看起来加密、其实没挡住的情况

第一，网页版「加密压缩」。有的网盘在上传完成后再帮你打包，或在服务器上套一层「提取码」。提取码挡住的是不会点分享链接的人，挡不住服务端已经存下的原文。对照方法：看加密发生在「选择文件之前」还是「进度条走完之后」。后者不是本机 AES-GCM。

第二，Office 或 PDF 自带的打开密码。它保护的是对应阅读器的打开流程，文件格式里仍有大量结构化字段；网盘预览、全文检索和转换服务经常能绕过「打开时弹密码」这一层。不要把它和整文件认证加密当成同一件事。

第三，只改扩展名。把 .xlsx 改成 .bin 再上传，秒传和部分扫描仍按内容哈希工作，文件头魔数还在。扩展名不是密码学。本机加密之后，内容区的魔数应消失；若十六进制里仍能看见 PK、%PDF 或 xlsx 的明文特征，这一次就不能算过关。

常见问题

给 ZIP 设了 AES-256 密码，上传网盘还不安全吗？

内容层比 ZipCrypto 强，但 ZIP 目录里的文件名、日期、大小默认仍是明文。网盘和任何拿到压缩包的人都能列目录。它也不是浏览器里的 AES-256-GCM：WinZip AES 用另一套封装，PBKDF2 迭代是 1000 次。要让云端只看见密文，先在本机加密整份内容，再上传。

网盘写「传输加密 / 静态加密」，是不是已经够了？

那通常是服务商持有密钥的默认加密。TLS 保护传输，静态加密保护磁盘被偷走的场景。服务商、持有密钥的运维和合法调取，仍可能解开你的原文。Google Drive 要把「Google 解不开」写成事实，需要工作区管理员打开客户端加密，不是个人拖文件上传的默认路径。

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 之前，怎么先核对哪些字段会离开本机。