証明書の束、書き出した社員名簿、秘密鍵の入った設定。最後は個人の Google ドライブ、iCloud、社内の共有フォルダに落ちることが多い。アップロード画面には「転送の暗号化」「保管時の暗号化」「セーフフォルダ」と並ぶ。これらの語が指すのは事業者自身の回線とディスクだ。「あなた以外は誰も開けない」ではない。別稿ではNetwork で平文が上がっていないことを確かめる手順を書いた。スローガンは証拠にならない。本稿は場面を一つに絞る。ファイルがこの端末を離れ、他人の保管領域へ入るとき、平文を誰が見られるか、パスフレーズはどの経路で送るかを先に分ける。
オンラインのファイル暗号化の機能一覧ではない。どのクラウドを選ぶかの比較でもない。問いは三つだけだ。出る前に平文は暗号文へ変わったか。上げたあと、事業者や次に落とす人は、そのまま開けるか。パスフレーズを .lock / .enc と同じメールに束ねていないか。MyPassGen のファイル暗号はこの境界で動く。ブラウザ内の AES-256-GCM で計算し、結果をダウンロードする。ファイルとパスフレーズは業務データとして上がらない。登録は不要。下の対照表と、その場で繰り返せる手順で境界を見る。
「暗号化済み」が指す層は、たいてい別物
HTTPS が守るのは、経路上の傍受者だ。ファイルがクラウドのサーバーに着いたあと、事業者は平文のまま、あるいは自分で解ける暗号文としてディスクへ置く。多くの製品は、この事業者預かりの鍵による保管時の暗号化を、「ファイルは暗号化されています」と書く。運用者にとっては、ディスクの持ち出し対策になる。クラウド側に免許証の写しを見せたくない、という要求には足りない。
クライアントが先に暗号化してから上げるのは、別の層だ。ブラウザや手元のプログラムが、あなたが持つパスフレーズから鍵を導き、クラウドに残るのは暗号文だけになる。rclone の Crypt、一部の同期ツール、ブラウザの Web Crypto は、この層に属する。解けるのは「保管側が使える平文を持たない」ことだ。パスフレーズが弱い、パスとファイルを同じ経路で送る、ファイル名そのものが中身を言い当てる、は別問題として残る。
個人情報保護委員会の通則ガイドラインは、運転免許証番号やマイナンバーを個人識別符号とし、含まれる情報を個人情報とする。券面の写しは氏名と符号が同時に載ることが多い。暗号化せず個人ドライブへ上げ、グループへ回すと、識別できる状態のまま第三者の保管領域へ出る。先に暗号化しても匿名加工にはならない。「このファイルを端末から出していいか」は、別の判断だ。
先に「誰が開けるか」を見る。アルゴリズム名は後回し
事業者代行の暗号化：事業者もあなたも開ける。端末で先に暗号化：パスを持たない人——クラウド側を含む——は本文を開けない。パスと暗号文を同じメッセージに束ねる：そのメッセージを見た人は、最初の状態に戻る。AES と書いてあっても、三番目は二番目にならない。
平文を手にできるのは誰か：置き方は三つ
同じ certs.zip をクラウドへ置くとき、少なくとも三通りに分かれる。差は画面の文言ではない。鍵が誰の手にあるか、平文がブラウザを先に出たかだ。
| やり方 | クラウド側が手にするもの | パスを持たないダウンロード者 |
|---|---|---|
| 元ファイルをそのまま上げる | 完全な平文（外側に TLS） | そのまま開ける |
| クラウドの「セーフフォルダ / 保管時の暗号化」 | 事業者が解ける暗号文、または平文 | 同じアカウントでログインすれば、大抵開ける |
端末で先に暗号化して .lock / .enc を上げる |
暗号文。先頭に元の名前が残ることがある | パスが無ければ本文は解けない |
「保管側に本文を見せたくない」に答えるのは、三番目だけだ。暗号化がアップロードより先に起き、鍵をその保管サーバーへ渡さないことが条件になる。前稿でも書いた。ウェブ暗号化 API が保証するのは、計算がこの端末で走れることだ。先に上げてから暗号化する作者は止めない。だから「端末で先に暗号化した」は、宣伝文ではなく通信で確かめる。
この段階で AES-256-GCM が担うこと
MyPassGen の初版は AES-256-GCM だけを使う。NIST SP 800-38D は GCM を認証付き暗号とする。暗号文が改ざんされれば復号は失敗する。文字化けした本文を「たぶんこれだろう」と読む余地は出さない。RFC 5116 の AEAD_AES_256_GCM は、鍵 32 バイト、nonce 12 バイト、認証タグ 16 バイト。MDN の AesGcmParams も IV を 96 ビットとし、同じ鍵では暗号化のたびに新しい IV が要るとする。IV 自体は秘密ではない。暗号文と一緒に置いてよい。
パスフレーズを AES 鍵にそのままは使わない。このサイトのファイル暗号は PBKDF2、反復 100,000 回、SHA-256、塩 16 バイトから 256 ビット鍵を得る。塩はファイル先頭に書き、復号時に同じ計算を再現する。RFC 8018 は NIST SP 800-132 を引き、反復回数は待てる範囲で大きく取るよう書く。OWASP が「サーバーに残すパスワードハッシュ」へ勧める PBKDF2-HMAC-SHA256 は、現状少なくとも 600,000 回だ。ファイルのパスの第一防衛線は、十分長い乱数パスだ。反復が防ぐのはオフライン総当たりであり、クラウドのメモ欄に書いた 123456 ではない。
パスフレーズは暗号文と別の経路へ
いちばん多い失敗は、アルゴリズムの取り違えではない。backup.lock と「パスは部署名に誕生日」を、同じチャット、同じメール、同じフォルダの readme.txt に置くことだ。クラウド側もグループの一員も、半分を同時に手にする。端末で暗号化した意味が消える。
分け方は単純だ。暗号文はドライブかメール添付。パスは別の経路——対面、電話、または一回限りのワンタイムリンク（鍵は URL の # の後ろ。閲覧ページに登録は要らない）。ファイル名、圧縮コメント、「自分だけ」と書いて同じアカウントのメモ、には書かない。
パスそのものはパスワード生成で端末内に作る。乱数モードは 6–128 文字、既定は 16。8 未満は弱いと見てよい。忘れたパスは戻せない。サーバーに平文の控えは無く、「秘密の質問」も無い。ゼロ知識で置く代償であり、機能の欠落ではない。
来歴の分からない「オンライン暗号化」へ、元ファイルを渡さない
証明書の束を、代行するサイトへ POST するのは、平文を相手のログへ書くことと同じだ。暗号化はこのタブで終え、Network で次を見る。業務リクエストにファイル本体もパス欄も無い。落ちてくるのは .lock か .enc であり、相手サーバーが返す「暗号化済みコピー」のリンクではない。
.lock を開いてもまだ見えるもの
暗号文は「ファイル全体が識別不能なノイズになる」ではない。公開してよいコンテナ先頭には、メタデータが残ることが多い。MyPassGen の既定出力は .lock。.enc も選べる。中身の形式は同じで、拡張子だけが違う。他ツールの習慣に合わせるためだ。先頭 4 バイトは CSLK。続いて版番号、16 バイトの塩、ブロックサイズ、元のファイル名と MIME の平文。本文は約 1 MB ごとに AES-GCM し、各ブロックが 12 バイトの IV と 16 バイトのタグを持つ。
だから 運転免許証スキャン.pdf を 運転免許証スキャン.pdf.lock にして上げると、ドライブの一覧もファイル先頭も「これは免許の写しだ」と読める。暗号化が守るのはバイトの中身であり、名前ではない。名前が敏感なら、意味の無い名前へ変えてから暗号化する。上げたあとの .lock にも、読める見出しを付けない。
1 ファイルの上限は 5 GB。暗号化時は Blob.slice で約 1 MB に切り、crypto.subtle.encrypt へ渡す。Web Crypto の encrypt() は一度に一つの BufferSource しか受けない。巨大ファイルを一括で渡すと、タブのメモリが先に尽きる。切片は「平文全体を一度に API へ渡さない」ための処置だ。結果は端末内で結合してダウンロードする。復号の現行実装は .lock 全体を先に読む。大きいファイルほどメモリを食う。タスクマネージャーで見える事実であり、スローガンではない。
その場で確かめる：Network、ファイル先頭、解けないこと
次の手順は、どのブランドの約束にも依らない。捨ててよい小さいテキストで行う。本物の免許やマイナンバーカードは使わない。
- 数十バイトの
probe.txtを作り、自分だけが知る試験文、たとえばorange-lake-7を書く。本物のパスや券面は書かない。 - 開発者ツールのネットワークを開き、「ログを保持」を入れる。ファイル暗号のページでそのファイルを選び、パスを付け、暗号化を始める。
- Fetch / XHR を一行ずつ見る。リクエスト行と本文に
orange-lake-7も、いま入れたパスも出てこないはずだ。解析送信も原文を持っていかない。出てよいのはスクリプト、スタイル、ファイル本体と無関係な計測だ。 - 落ちた
.lockか.encを十六進ビューアで見る。先頭 4 バイトは43 53 4C 4B（ASCII のCSLK）。その先に元の名前probe.txtの平文は見える。試験文そのものは見えない。 - 同じページへ暗号文を戻し、正しいパスで復号する。試験文が戻る。パスを一字変えると、復号は失敗する。文字化けした本文は出ない。
- ここまで終えてから、
.lockをクラウドへ上げる。パスは別のメッセージへ。プレビューに戻る。パスを入れなければ原文は開かない。
MyPassGen のファイル暗号はこの境界で動く。AES-256-GCM、PBKDF2 100,000 回、1 ファイル 5 GB まで、出力は .lock / .enc。計算はこのタブで終わる。登録は不要。信じる対象は、いまも Network とファイル先頭であり、画面の「アップロードしません」の五文字ではない。
短い秘密はファイルにしない
API キー一行、復旧コード、データベースのパスを、先にファイルへ固めて暗号化する必要は無い。ファイル全体の流れは、証明書の束、書き出した表、ディスクイメージの切片向きだ。短いテキストはワンタイムの方が合う。平文の上限は 32 KB。サーバーが一時保管するのは暗号文だけ。鍵は # の後ろ。閲覧回数と TTL を付けられる。作成も閲覧も、ログインは要らない。
説明文書を外へ出すときは、リンクと本文が別工程になる。utm_source 付きのアドレスは消してよいパラメータで処理する。問い合わせ票の電話番号やマイナンバーは伏せるべき項目で処理する。暗号化ファイルが解くのは「保管側が本文を開けない」ことだ。「議論のときに番号を丸ごと載せない」ではない。
よくある誤解
「クラウドが暗号化と書いたから、見られるのは自分だけだ。」事業者が鍵を預かる設計では、運用、法令に基づく開示、アカウント乗っ取りのあとでも、手元には使えるファイルが残る。端末で先に暗号化して初めて、「解ける人」はパスを持つ人に縮む。
「HTTPS が最初から最後まで守っている。」HTTPS は事業者の入口で終わる。ディスクへ落ちたあとの保護範囲は、相手が決める。減らしたいのは、落ちたそのファイルの中の平文だ。
「拡張子を .lock に変えれば暗号化だ。」認証付き暗号を通していない改名は、メモ帳で原文を検索できる。先頭には決めたマジックがあり、本文は解けない。接尾辞だけ変えるのは、何もしていないのと同じだ。
「パスを忘れたらサポートに戻せばよい。」ゼロ知識の置き方に、サーバー側のパスコピーは無い。フッターにも「暗号化パスを再発行する」メールは置かない。パスは、自分のパスワードマネージャーか、自分で制御する別経路にだけ置く。
どこから始めるか
今日上げるそのファイルから手を付ける。捨ててよい小さいファイルで、前節の六つの手順を通す。Network に原文が無い、先頭が CSLK、誤ったパスでは解けない。それから本物を暗号化する。名前が敏感なら、先に変える。
暗号文はドライブかメール添付。パスは対面、電話、またはワンタイムを一本作る。同じフォルダのテキストへパスを書かない。ここまでで、本稿の問いに答えられる。クラウド側は平文を手にしないはずだ。パスは暗号文と同じ経路を通らない。ファイル先頭には元の名前が残ることがあり、それは別途扱う。
よくある質問
クラウドの「セーフフォルダ」と、端末で先に暗号化する差は何か。
セーフフォルダは、事業者が鍵を持つか預かることが多い。同じアカウントでログインすれば開ける。端末で先に暗号化すれば、クラウド側はパス無しでは本文を解けない。アカウントが盗まれても、パスを持たない人は暗号文を落とせるだけだ。
パスを忘れたら、まだ復号できるか。
できない。サーバーに平文もパスの控えも無い。十分長い乱数パスを使い、自分のパスワードマネージャーへ別に置く。「保管側が本文を見ない」ことの、対称の代償だ。
.lock と .enc はどう違うか。
このサイトでは同じコンテナで、拡張子だけが違う。復号するときは、どちらもページへ戻せばよい。他ソフトの .enc が、同じ先頭で読めるとは限らない。
暗号化に登録は要るか。ファイルは上がるか。
登録は要らない。代行するサイトへ元ファイルを渡すと、ログのリスクが出る。端末内で処理するとき、ファイルとパスはこのタブに残る。確かめる対象は、Network にファイル本体やパスが無いか、.lock から試験文の原文が検索できないか、だ。