把未加密文件直接丢进网盘，服务商、同步客户端和秒传还可能看到什么

拖进网盘不是「锁进保险箱」，是把明文交给下一个系统

很多人把消费级网盘当成家里的保险柜：文件还在自己的账号里，别人打不开。拖进去之后，这份字节已经离开当前磁盘上的那一个文件夹，成为服务商要存储、同步、去重和（经常）生成预览的对象。财务报表、身份证扫描件、SSH 私钥、数据库转储、未脱敏的客户表，都属于不该以明文落入第三方存储和检索系统的内容。

HTTPS 只保护传输过程中的窃听。它不决定对方系统把文件存成什么形态、钥匙在谁手里、同步客户端在本机缓存什么、分享链接点开后对方拿到的是密文还是解开的原文。上一篇写过：密钥贴进模型会话会进历史和留存。文件丢进网盘是同一类暴露，只是接收方从「模型服务商」换成了「存储服务商及其同步、预览和去重通道」。上传前要处理的，不是「这个网盘聪不聪明」，而是「这一份里有没有不该以明文离开当前设备的内容」。

本文以 AWS S3、Google Drive / Google Cloud 和 iCloud 的公开说明为主，因为分层写得清楚，也好核对。消费级网盘很少把「钥匙在谁手里」写成同样直白的句子，但工程模型通常仍是：传输用 TLS，落盘用服务商保管钥匙的静态加密，再叠加缩略图、全文检索或秒传。换产品时应对着那一家的安全页再走一遍，不要把下面的 SSE-S3 或「标准数据保护」直接套到别的品牌上。

HTTPS、静态加密、零知识：三把锁不是同一把

把「网盘加没加密」听成一个是或否，会漏掉至少三层。第一层是传输加密。浏览器或同步客户端用 TLS 把字节送到服务端，中间网络上看不到明文。这一层几乎是标配，也是地址栏小锁真正保证的范围。

第二层是静态加密，也就是服务端加密。AWS 对 S3 服务端加密 的定义很直白：数据在目的地由接收它的服务加密；写入数据中心磁盘时加密，你访问时再解密。自 2023 年 1 月 5 日起，所有新上传对象默认使用 SSE-S3（Amazon S3 托管密钥），算法是 AES-256，每个对象一把独立密钥，根密钥由 AWS 轮换。只要请求通过身份验证且有权限，「访问加密对象和未加密对象没有差别」。预签名 URL 对两者同样有效。列出对象时，接口也不区分加没加密。换句话说：这层保护的是磁盘被偷走之后的物理介质，不是「AWS 解不开你的文件」。

Google 对 Drive 的公开口径类似：上传或在 Docs / Sheets / Slides 里创建的文件，「传输中和静态都用 AES-256 加密」。额外的保密要靠 Workspace 客户端加密，而且必须是工作或学校账号、由管理员打开。打开之后，Google 才写成「无法解密你的文件」。默认那一层并没有这句话。Google Cloud 默认静态加密 更直接：钥匙由 Google 拥有并管理；你若只用默认加密，接触不到这些钥匙，也无法控制轮换。

Apple 把默认和可选拆开写。iCloud 数据安全概述 写明：标准数据保护是账户默认设置；数据会加密，钥匙放在 Apple 数据中心，以便帮你恢复；只有部分类别默认端到端加密。安全指南给出数量：默认约 14 个类别端到端加密；打开可选的高级数据保护后升到约 23 个，包括 iCloud 备份、照片和备忘录。关掉高级数据保护时，设备会把所需钥匙重新上传到 Apple 服务器。默认并不是「Apple 也解不开网盘里的文件」。

服务商握着钥匙时，还能为你做什么、对谁可见

服务商能解密，并不是一句恐吓，而是默认产品功能成立的前提。在线预览 PDF、给照片出缩略图、对文档做 OCR 或全文搜索、按文件类型归类，都要在某台服务器上看到内容，或至少看到从内容派生出来的明文索引。Google 自己把客户端加密的代价写进了帮助页：加密后的 Docs / Sheets / Slides 不能用移动应用编辑，不能评论 Drive 文件，没有语音输入和若干附加功能；加密文档上限 100 MB，版本历史最多保留 100 个版本。这些限制出现的原因很具体：服务端不再拿得到能解出原文的钥匙。

AWS 把另一面写得同样清楚：你用预签名 URL 分享对象时，对方拿到的访问方式和未加密对象相同。SSE-S3 不会把「点开链接的人」挡在明文之外。它挡的是「谁拿走了硬盘」。账户被盗、分享链接泄露、企业管理员调取、执法调证，走的都是「有权限的访问」这条路，静态加密默认放行。

消费级网盘还多一层：同步客户端。文件先出现在本机同步目录，再上传。即便云端后来写了静态加密，这台电脑、家里另一台已登录的电脑、手机里的离线缓存，仍然可能各留一份明文。关掉浏览器标签页，清不掉已经写入同步文件夹的副本。

同步、预览、秒传和分享链接是另外几份副本

把「上传成功」听成「只有云端一份」，会漏掉本地和云端两侧的副本。第一份是同步客户端的工作副本：待上传队列、失败重试缓存、版本冲突留下的副本。第二份是服务端为预览准备的派生文件：缩略图、转码后的视频、OCR 文本。它们往往和原文件分开存，删掉原文件不一定立刻带走派生文件。

第三份是内容哈希。不少网盘用整文件或分块哈希做秒传和去重：本地先算出哈希，服务端若已有相同哈希就不再传一遍字节。这对未加密文件很方便，也等于公开承认「同一份明文在系统里只存一份」。你上传一份未加密的常用安装包或公开 PDF，服务端用哈希就能确认你持有它；公司内部的同一份合同被多人上传，去重后仍是同一份明文。先在本机加密再上传，每次都会因独立的 salt 和 IV 得到不同密文，哈希对不上，秒传失效。这不是故障，而是「服务商看不到内容」的直接后果。

第四份是分享链接和团队空间。链接一旦发出，权限模型通常是「谁持有链接谁就能取回文件」。结合上一节：默认静态加密不会在下载时改成「只给密文」。对方浏览器里打开的，仍是解开后的原文。聊天群里的「网盘链接」和把文件本体贴进群，暴露面不同，明文是否离开你的账号，答案经常一样。

压缩包加密码为什么常常不够

「先打成 ZIP 再上传」听起来已经做了客户端加密，实际要先问用的是哪一种 ZIP 加密。传统 PKWARE 加密（ZipCrypto）是流密码。1994 年 Eli Biham 与 Paul Kocher 在 A Known Plaintext Attack on the PKZIP Stream Cipher 里写明：这个密码是弱的，不该用来保护有价值的数据；大约 13 到 40 字节压缩后的已知明文，或未压缩时开头约 30 到 200 字节，就能在当时的个人计算机上于数小时内找回内部密钥表示。现代实现把门槛压得更低：bkcrack 写明至少 12 字节已知明文（其中至少 8 字节连续）即可恢复内部状态，进而解开整包以及其他用同一密码加密的条目。密码长短在这场攻击里帮不上忙，因为攻击的是密钥流状态，不是穷举你的口令。

即便压缩工具改成 AES，ZIP 仍可能把文件名、目录结构和未加密的条目说明留在包头里。网盘的文件列表、搜索和「类型」筛选看的就是这些元数据。把「压缩包有密码」当成「云端只看得到乱码」，会漏掉包头和弱算法这两层。

更常见的操作失误是：加密包和写着密码的 readme.txt 放进同一个文件夹一起同步。锁和钥匙交给同一个保管方，静态加密和 ZIP 密码都救不了。

先在本机加密再上传，改变的是哪一层

客户端加密要满足的条件很窄：明文在离开设备前就变成密文；派生密钥的口令不发给存储服务商；服务商在正常运营时解不开。Google 把 Workspace 客户端加密写成「端到端、客户端之间」，并点名「Google 无法解密」。那是工作区管理员打开的附加层，不是个人免费 Drive 的默认值。自己先加密再上传，走的是同一条边界，只是钥匙完全留在你自己的口令和设备上，不依赖某一家网盘有没有客户端加密开关。

浏览器里可以核对的做法，是用 Web Crypto 的 AES-GCM，而不是自己拼一套 XOR。MDN 对 AesGcmParams 的说明与 NIST SP 800-38D 一致：同一把密钥下，IV 必须每次唯一，规范建议 IV 为 96 位（12 字节）；IV 不必保密，可以明文跟在密文旁边。NIST 把唯一性写得很重：同一密钥下重复使用 IV，实现可能遭受伪造攻击，其重要性几乎等同于密钥本身要保密。认证标签默认 128 位（16 字节），口令错误或密文被改过，解密应直接失败，而不是吐出残缺明文。

MakePwd 的文件加密盒按这条边界实现：在当前标签页用 AES-256-GCM 分块加密，口令经 PBKDF2-HMAC-SHA256、100,000 次迭代派生，每个文件独立 16 字节 salt，每块独立 12 字节 IV，输出 IV + 密文 + 16 字节标签。单文件最大 5 GB，默认 1 MB 一块，避免把整份文件一次性读进内存。输出 .lock 或 .enc，二进制格式相同。文件与口令默认不上传。全部工具打开即用，没有账号，也没有密码库替你保管口令。它回答的是「离开浏览器之前能不能先变成密文」，不是「替你把文件传到某家网盘」。

当场核对：金丝雀明文不进上传队列，Network 只见密文

口号写「不上传」没法证明。把核对拆成两段：先确认加密过程本身没有把明文当业务数据送走，再确认你交给网盘的是密文文件。

1. 新建文本，写一句不会出现在真实业务里的话，例如 canary-cloud-20260902-only-once。文件名也可以带金丝雀。口令用一段一次性长句，不要用常用密码。
2. 在浏览器打开文件加密页，打开开发者工具，切到 Network，勾选 Preserve log。选中该文件、输入口令、下载 .lock。过滤器里粘贴金丝雀：请求行、请求体和分析上报都不该出现原文。口令同样不该出现。
3. 把下载得到的 .lock 用十六进制查看器或编辑器打开头部：应看到固定魔数，而不是刚才那句金丝雀。用错误口令解密应失败，且不生成残缺明文文件。
4. 若你仍要把密文备份到自己的网盘，上传的是 .lock，不是原文件。上传完成后再搜网盘预览：不应出现可读正文。口令不要放进同一个同步文件夹。

第一段核对的细节——请求行、请求体、分析上报——与浏览器里做加密，怎么当场核对明文没有离开本机相同。本文多出来的是第四步：对象一旦离开浏览器，分层就从「本机 Web Crypto」换成「网盘会不会当明文处理」。金丝雀只应出现在你自己保存的原文件里；出现在网盘预览或秒传命中提示里，说明你上传的仍是未加密副本。

用打开即用的文件加密盒把边界练熟

若你要的是「先变成密文，再自己决定传到哪」，不必先注册，也不必把文件交给 MakePwd。打开文件加密盒，选一个可丢弃的小文件，用随机长口令加密，下载 .lock，按上一节搜 Network。口令需要人记住或交给同事时，用密码生成器抽 6–128 位随机串（默认 16；低于 8 位会提示较弱），再考虑用阅后即焚另发一次，不要和密文走同一条网盘目录。阅后即焚的密钥在 URL # 片段，阅读页对接收方公开。

文件加密盒不替代网盘的客户端加密开关，也不保证你上传密文之后对方产品会如何做病毒扫描或文件名审查。.lock 头里带有原文件名，网盘侧仍可能看到名字。真正不能让对方看见的名字，加密前先改成无意义文件名。忘记口令无法从密文恢复，请把口令单独记在你控制的地方。

常见问题

网盘写「已加密」，服务商还能打开我的文件吗？

默认静态加密通常可以。AWS 写明：服务端加密是在写入磁盘时加密、你访问时再解密；有权限的请求和未加密对象没有差别。Google 默认加密的钥匙由自己保管。Apple 标准数据保护把多数钥匙放在自己的数据中心，以便帮你恢复。这和「服务商解不开」不是同一层。

先打成带密码的 ZIP 再上传，够不够？

传统 ZipCrypto 不够。1994 年 Biham 与 Kocher 证明：大约十几字节已知明文就能恢复内部密钥状态，密码长短帮不上忙。即便改用 AES 压缩包，文件名等元数据仍可能明文可见。要让网盘侧只见到密文，应在本机完成认证加密后再上传。

加密后再上传，秒传和在线预览还能用吗？

通常不能按原文去重或预览。秒传比的是内容哈希；同一份明文每次用独立 salt 和 IV 加密后，哈希会变。在线预览、缩略图和 OCR 需要解开原文。这是预期代价：服务商看不到内容，也就无法替你生成预览。

口令可以和 .lock 放在同一个网盘文件夹吗？

不要。密文和口令走同一账号、同一同步目录，等于把锁和钥匙交给同一个保管方。口令放在密码管理器，或用阅后即焚另发一次。忘记口令无法从 .lock 里找回明文，这是零知识备份的边界，不是缺陷。

下次上传前记住的三件事

第一，地址栏小锁和「已加密」只覆盖传输和磁盘被偷，不覆盖服务商、管理员和持有分享链接的人。第二，同步缓存、预览派生文件、内容哈希和分享链接可能各留一份；未加密上传等于明文进入这几条通道。第三，要让网盘侧只见到不透明字节，先在本机用 AES-256-GCM 打成 .lock / .enc，口令走另一条通道，再用 Network 和网盘预览搜金丝雀核对。

若你还要继续追问「加密过程有没有把明文当业务数据送走」，请读浏览器里做加密，怎么当场核对明文没有离开本机。必须把打开密文的口令交给人时，可读URL 的井号后面为什么适合放密钥，以及阅后即焚链接读完一次后，服务端还剩什么。本文只把「未加密文件进了网盘之后还可能剩什么」收成可以写进结论的范围。