先に結論です。パスワード付き ZIP は、「クラウドがファイルを見ていない」証明になりません。言えるのは、解凍にパスフレーズが要ることまでです。ZIP のディレクトリは初期状態で読めます。従来の ZipCrypto は、短い平文が分かると内部鍵を復元される余地があります。上げる前に見るべきなのは二つです。内容がこの端末で認証付き暗号化まで終わっているか。この HTTP が原文やパスフレーズを出していないか。
検索意図に一文で答える
クラウドへ上げる前に ZIP へパスワードを付けることと、本機の AES-GCM は、守る層が違います。前者はファイルを ZIP 容器へ入れ、容器の中のファイル内容に鍵を掛けます。容器自身のディレクトリ、つまりファイル名、日付、サイズは、ZIP の設計として一覧用です。後者はブラウザの Web Crypto API でバイト列に AES-256-GCM をかけ、暗号文をダウンロードしてから上げます。復号用のパスフレーズがなければ、クラウド側に残るのは乱数に近いデータです。
この記事は開発者、運用、そしてバックアップをオンラインストレージへ置く前に、「パスワードを付けた」と「相手が中身を読めない」を分けたい人向けです。ファイル暗号化の操作説明の代わりにはならず、.lock を出すクリック順も繰り返しません。持ち帰るべきなのは、ZipCrypto と ZIP-AES がそれぞれ止める範囲、クラウド既定暗号の鍵の所在、本機暗号化のあとファイル先頭に残るもの、Network と十六進ダンプでの照合です。
「パスワードを付けた」と「クラウドが中身を見えない」は別の文
日常語の「このファイルは暗号化されている」は、三つの仕事を一つに畳みます。第一は転送時の暗号化です。ブラウザとクラウドのあいだは HTTPS なので、経路上の傍観者は原文を読みにくいです。第二は事業者の保存時暗号化です。ディスク上のブロックを事業者の鍵で包むので、媒体が持ち出されたときには直接読みにくくなります。第三は、あなたが鍵を持つクライアント側暗号化です。上げる前に内容は暗号文になっており、パスフレーズがなければ事業者は開けません。
パスワード付き ZIP は、この三層の外にある四つめの習慣です。この端末でパスフレーズ付きの容器を作り、その容器を普通のファイルとして上げます。クラウド側の扱いは、暗号化していない .zip と本質的に同じです。ファイル名で索引を作り、ハッシュで同一判定し、方針があればウイルスや機微情報を走査します。中身が ZipCrypto のまま、あるいはディレクトリが平文なら、走査プログラムは「パスワードを当てる」前にファイル名を読めます。内容へ踏み込める場合もあります。
日本では、パスワード付き ZIP をメールに付け、別メールでパスワードを送る PPAP が長く使われてきました。府省は 2020 年以降この運用をやめ、取引先も受信拒否へ移っています。置き場をメールから Google ドライブや OneDrive へ変えただけでは、鍵の所在は変わりません。「パスワードを付けた」が支えられる結論は狭いです。解凍しない人、パスフレーズを持たない人は、中身を開きにくい、までです。「社員が見えない」「開示請求で原文が取れない」「ファイル名が索引に入らない」は、ここからは言えません。後の文を観察できる事実にするには、層を替えてください。この端末で認証付き暗号化を終え、暗号文だけを上げます。
ZipCrypto が本気の相手を止められない理由
ZIP の従来暗号は、Zip 2.0 や ZipCrypto と呼ばれます。WinZip 自身の説明は率直です。この形式は相対的に弱く、専用の復元ツールを持つ人を止める前提にはできません。重要な要件があるときは AES へ切り替えてください。WinZip の暗号化説明に書いてあり、掲示板の伝聞ではありません。日本語では Corel の WinZip 解説が、Zip 2.0 を弱く、AES 128/256 を強い側として分けています。
弱いのはアルゴリズムであり、パスワードの長さではありません。1994 年、Eli Biham と Paul Kocher は PKZIP のストリーム暗号に対する既知平文攻撃を示しました。十数バイト程度の平文と、対応する暗号文が揃えば、暗号機内部の三つの状態を逆算し、ファイル全体の鍵ストリームを復元できます。この段階でパスワード長は登場しません。相手が複製するのは錠の芯であり、鍵の試し打ちではありません。公開実装（たとえば bkcrack）は、この論文を実行可能なプログラムにしています。「格納（Store）かつ ZipCrypto」の書庫では特に直接的です。
既知平文はどこから来るか。PDF は %PDF で始まります。Office 文書、多くの画像、入れ子の ZIP にも固定のマジックナンバーがあります。公開された形式の契約書を ZipCrypto へ入れ、そのままクラウドへ上げると、暗号文と、ほぼ確定した原文の見本を同時に渡すことになります。攻撃の再現手順を書く必要はありません。右クリックの「送る」→「圧縮（zip 形式）」にパスワードを足したものを、AES-256-GCM と同一視するのをやめてください。
Windows 標準の圧縮、クラウド画面の「暗号化して圧縮」、古いバッチは、互換性のために ZipCrypto を選びがちです。ほぼすべての解凍ソフトが読めるからです。作ったあとに属性を見てください。ZipCrypto / Zip 2.0 と書いてあれば、バックアップ方案にしないでください。AES と書いてあれば次の節です。内容の層は強くなります。ディレクトリの層は、多くの場合まだ平文です。
本物の契約書、本人確認書類、未マスクの案件フォルダで試さないでください。捨ててよい小さなファイルを用意し、ファイル名も本文も一度きりのカナリアにしてください。照合するのはディレクトリ、ファイル先頭、通信です。プライバシーをもう一度上げることではありません。
AES の ZIP でも、ディレクトリは平文のまま残る
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 を開いてもファイル名が見える」説明を別に書いており、名前を一枚隠すには「暗号化しない ZIP を作り、それを二枚目の暗号化 ZIP へ入れる」二重化を勧めています。根拠は WinZip のファイル名可視性の説明です。日本語の解説でも、エクスプローラーでパスワード解除前に名前が見える、と繰り返し書かれています。
7-Zip の .7z には「ファイル名も暗号化」があります。それは別製品の選択肢であり、ZIP の既定動作と混ぜないでください。エクスプローラーで「パスワードが必要」と出ても、言えるのは解凍にパスフレーズが要ることだけです。別の解凍ソフトで同じファイルを開くと、一覧がすぐ出ます。運転免許証_裏面.jpg、給与明細-2026.xlsx、顧客名簿.csv。クラウドの同一判定、プレビュー、方針スキャンが読むのは、この層です。AES の ZIP は Windows 標準では開けないことが多く、互換のために ZipCrypto へ戻す運用も残っています。開けないことと、ディレクトリが隠れていることは、同じではありません。
クラウドの「暗号化済み」は、多くの場合事業者が鍵を持つ
ZIP でも原文でも、そのままドライブへ置くと、画面には転送時の暗号化、保存時の暗号化、AES-256 と出ます。これらの文は同時に正しくあり得ます。答えていないのは「復号鍵を誰が持つか」です。Google の Drive 説明はこう分かれます。アップロードしたファイル、Docs / Sheets / Slides で作ったファイルは、既定で転送中と保存時に AES-256 で暗号化されます。「Google が開けない」状態にするには、Workspace 管理者がクライアント側暗号化を有効にし、ユーザーが仕事または学校のアカウントで本人確認を終える必要があります。個人が「マイドライブ」へドラッグした普通のファイルは、既定経路であり、クライアント側暗号化ではありません。根拠は 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 と書いてあると、クラウドも、十六進ビューアを開いた人も、その数文字を読めます。暗号化しているのは内容の塊であり、容器が外へ出す札ではありません。
| 見える現象 | 支えられる結論 | 支えられない結論 |
|---|---|---|
| ZIP の解凍にパスワードが要る | 内容の層に鍵が掛かっている | ディレクトリは見えない。算法は AES-GCM |
| 解凍せずにファイル名が一覧できる | ZIP のディレクトリは平文（よくある既定） | 内容も必ず開ける |
| 属性が ZipCrypto / Zip 2.0 | 従来のストリーム暗号。既知平文攻撃が当てはまる | パスワードが長ければ専用ツールを止められる |
| クラウドが「暗号化して保存」と表示する | 転送時または保存時の暗号化は、多くの場合ある | 事業者は鍵を持たず、原文を見えない |
この端末で .lock / .enc をダウンロードした |
ブラウザが暗号文ファイルを作った | ファイル先頭の元の名前も隠れた |
| Network でカナリアが見つからない | この回のリクエストは、これらの欄を運んでいない | 拡張機能、クリップボード、次の版もきれい |
その場で照合する：Network、ファイル先頭、オフライン
スローガンは証拠になりません。捨ててよい小さなファイルを用意してください。本文を canary-fp-20260904-zip-vs-gcm にし、ファイル名を canary-fp-20260904.txt にします。パスフレーズは一度きりの長い文にし、本物のパスフレーズを再利用しないでください。
- 対照群を先に作ります。同じファイルをパスワード付き ZIP にし、解凍ソフトでパスワードを入れずに開きます。ファイル名が見えるか、属性が ZipCrypto か AES かを記録します。これがパスワード付き ZIP の実際の範囲です。
- 次に、ブラウザで本機暗号化をします。開発者ツールの Network を開き、Preserve log を入れ、フィルタは All にします。暗号化が終わったら、カナリアを検索欄へ貼ります。リクエスト行、本文、アクセス解析に、原文もパスフレーズも出てはいけません。
- 十六進ビューアで、ダウンロードした
.lockを開きます。先頭四バイトはCSLK（43 53 4C 4B）であるべきです。その先にソルト、塊サイズ、残した元のファイル名が読めます。内容領域に、カナリアの平文文は再登場してはいけません。 - ページの読み込みが終わったあと、Network で Offline にするか、システムのネットワークを切り、別の捨ててよい小さなファイルを暗号化します。
.lockがまだダウンロードできるなら、この回の暗号化／復号はリアルタイム API に依存していません。オフラインを通したあと、オンラインでも同じカナリアでもう一度検索してください。
パスフレーズと暗号文を、同じ経路で運ばないでください。クラウドへ上げるのは .lock、パスフレーズは ワンタイムリンク へ分けます。この端末で AES-256-GCM により暗号化し、サーバーが一時保存するのは暗号文だけ、鍵はリンクの # の後ろに付き、形は s.html?id={id}#{key} です。完全なワンタイムリンクと暗号文を、同じクラウドフォルダへ置くと、鍵を箱へ貼ったのと同じです。
上げる前に、元ファイルを意味のない名前へ変えてから暗号化してください。ファイル先頭は、その名前をそのまま書き込みます。拡張子 .lock / .enc も、クラウドの一覧に出ます。言えるのは「ファイル名自身が漏らす量を減らした」までです。ステガノグラフィにはなりません。
暗号化に見えて、実際には止まっていない三つの場合
第一は、ウェブ版の「暗号化圧縮」です。アップロードが終わったあと事業者が書庫を作る、あるいはサーバー側で「取出コード」を掛ける場合があります。取出コードが止めるのは、共有リンクをクリックしない人です。サーバーがすでに原文を持っていることは止められません。照合の仕方は、暗号化が「ファイルを選ぶ前」に起きたか、「進捗が終わったあと」に起きたかです。後者は本機の AES-GCM ではありません。
第二は、Office や PDF 自身の開くパスワードです。守るのは、対応する閲覧ソフトの開く流れです。ファイル形式の中には、構造化された欄が大量に残ります。クラウドのプレビュー、全文検索、変換サービスは、「開くときにパスワードを出す」層を迂回することがあります。ファイル全体の認証付き暗号化と、同一視しないでください。
第三は、拡張子だけを変えることです。.xlsx を .bin にして上げても、同一判定と一部の走査は内容ハッシュで動き、ファイル先頭のマジックナンバーは残ります。拡張子は暗号ではありません。本機暗号化のあと、内容領域のマジックは消えるべきです。十六進ダンプにまだ PK、%PDF、あるいは xlsx の平文特徴が見えるなら、この回は通過ではありません。
よくある質問
ZIPにAES-256のパスワードを付ければ、クラウドへ上げても安全ですか？
中身の層は ZipCrypto より強いです。ただし ZIP のディレクトリにあるファイル名、日付、サイズは、初期状態では平文のままです。クラウドも、ZIP を受け取った人も、一覧を読めます。ブラウザの AES-256-GCM でもありません。WinZip AES は別の包み方で、PBKDF2 の反復は 1000 回です。クラウド側に暗号文だけを持たせるには、この端末で内容全体を先に暗号化し、そのあと上げてください。
クラウドに「転送時の暗号化／保存時の暗号化」とあれば、十分ですか？
多くの場合、事業者が鍵を持つ既定の暗号化です。TLS は通信経路を守り、保存時の暗号化はディスクが持ち出された場面を守ります。事業者、鍵を持つ運用、法令に基づく開示では、原文を開ける余地が残ります。Google ドライブで「Google が開けない」を事実にするには、Workspace 管理者がクライアント側暗号化を有効にする必要があります。個人がファイルをドラッグする既定経路ではありません。
FastPwd の .lock を上げたあと、クラウドは元のファイル名を見られますか？
拡張子は見えます。ファイル先頭からも、元のファイル名と MIME を読めます。暗号化しているのは 1 MB ごとの内容であり、容器全体のメタデータではありません。上げる前に、元ファイルを意味のない名前へ変えてから暗号化してください。パスフレーズと暗号文を、同じ共有へ置かないでください。
FastPwd で暗号化するとき、ファイルとパスフレーズはアップロードされますか？
製品の説明では、暗号化と復号は今開いているタブの Web Crypto で完了し、ファイルとパスフレーズは業務データとして出さず、アクセス解析にも書きません。アクセス統計が記録するのは「暗号化をした」といったイベント名です。カナリアで Network を検索し、リクエスト行と本文に原文やパスフレーズが出てはいけません。localhost は既定でアクセス統計を送りません。本番ドメインでもう一度測ると、実際の利用に近づきます。
同じ捨ててよいファイルを、開いてすぐ使えるツールで一度照合する
計算の境界が書いてあるページで練習したいときは、FastPwd の ファイル暗号化 を開けば足ります。登録は不要です。上のカナリアの小さなファイルを選び、パスフレーズは一度きりの長い文にしてください。弱いと判定されたときは、ページが先に確認してから進みます。暗号化のあと .lock をダウンロードします。同時に Network を見てください。静的リソースと、場合によってはアクセス統計は見えてよいはずです。元ファイルやパスフレーズが業務欄として見えてはいけません。
パスフレーズは、先に パスワード生成 でこの端末で作れます。ランダムモードは 6〜128 文字、初期値は 16 文字。8 文字未満では安全性が低いと示します。生成もアップロードしません。同僚へパスフレーズを渡さなければならないときは、ワンタイムリンクへ分け、クラウドのメモ欄へ書かないでください。短い機密や一度きりの鍵を、.lock の輸送路にしないでください。ファイル暗号化が解くのは、ファイル全体のバックアップと受け渡しです。チャットの一行の秘密ではありません。
次に上げる前に、三つを覚えておいてください。第一に、パスワード付き ZIP が止めるのは解凍であり、ディレクトリではありません。ZipCrypto の既知平文攻撃でもありません。第二に、クラウド既定暗号の鍵は、多くの場合事業者の手元にあります。第三に、本機の AES-256-GCM が守るのは内容の塊です。ファイル先頭と拡張子は、まだ漏らすことがあります。Network と十六進ダンプで、自分の目で一度見てください。繰り返せる観察だけを、チームのバックアップ手順へ書いてください。
関連記事
「ローカル暗号化、アップロードなし」は証拠になりません。カナリアで Network を検索する方法は、ブラウザのローカル暗号化で、平文が端末を出ていないことを確認する にあります。パスフレーズだけを受け手へ渡すとき、# の後ろが既定で HTTP に入らない理由は、URLの#以降に鍵を置ける理由と、その保護が崩れる場面 にあります。チケット本文の番号を、端末を出る前にマスクする手順は、チケットとログをAIに貼る前に、どの欄が端末を出るかを確認する にあります。