ブラウザの暗号化機能：最新ブラウザにできること

最新のブラウザは専用のセキュリティライブラリに匹敵するネイティブ暗号処理機能を持っています。 Chrome・Firefox・Safari・Edge はすべて Web Crypto API（crypto.subtle）を公開し、TLS 1.3 を HPKP の後継メカニズムによる証明書ピニングと共に実装し、フィッシング耐性認証のために WebAuthn/パスキーをサポートし、Site Isolation で各オリジンをサンドボックス化し、Windows の TPM および macOS/iOS の Secure Enclave によるハードウェアバックアップの鍵保存を提供します。暗号化ファイル転送ツールを構築する開発者にとって、これは AES-256-GCM 暗号化・PBKDF2 鍵導出・FIDO2 認証が外部ライブラリなしで無料で利用できることを意味します。各ブラウザが2026年に実際に何ができるかを紹介します。

Web Crypto API：共通ベースライン

4つの主要ブラウザすべてが W3C Web Cryptography API をほぼ同一の表面でサポートします。コアアルゴリズム：

対称：AES-GCM・AES-CBC・AES-CTR・AES-KW（128・192・256ビット）
非対称：RSA-OAEP・RSA-PSS・RSASSA-PKCS1-v1_5（最大4096ビット）・ECDSA・ECDH（P-256・P-384・P-521）
ハッシュ：SHA-1・SHA-256・SHA-384・SHA-512
鍵導出：PBKDF2・HKDF
MAC：HMAC

不足しているもの：ChaCha20-Poly1305（ブラウザサポートなし）・Argon2（ブラウザサポートなし）・Ed25519/X25519（Safari 17+ と Firefox 129+ は持っており、Chrome も追いつきつつある）。それらには libsodium.js または @noble/curves のような JavaScript または WASM ライブラリが引き続き必要です。

Chrome と Edge は同じ暗号実装（V8 経由の BoringSSL）を共有します。Firefox は NSS を使用します。Safari は Apple の FIPS 検証済みライブラリである CoreCrypto を使用します。パフォーマンスは異なります。Firefox の PBKDF2 イテレーションは同等のハードウェアで Chrome より約20%遅い。Apple Silicon での Safari の AES-GCM はハードウェアアクセラレーションにより同じ Mac の Chrome より約2倍速い。

TLS 1.3 と証明書の透明性

すべての主要ブラウザはサポートされているオリジンでデフォルトで TLS 1.3 を使用し、レガシーサーバーのみに TLS 1.2 にフォールバックします。Chrome は Chrome 84（2020年7月）で TLS 1.0 と 1.1 のサポートを削除しました。Firefox は Firefox 78 で削除しました。Safari は macOS 11 / iOS 14 で廃止しました。

証明書の透明性が適用されています。2018年4月以降に発行された証明書は少なくとも2つの CT ログに現れなければなりません。そうでなければ Chrome と Safari は拒否します。これにより CA の不正発行が公開監査可能になることで DigiNotar スタイルの攻撃を早期に捕捉しました。Mozilla の Firefox は Firefox 117（2023年）で CT の適用を開始しました。

オリジン分離とサンドボックス

Chrome の Site Isolation は2018年（デスクトップ）と2019年（Android）以降、各オリジンを独自の OS プロセスに置いています。Firefox の Fission は Firefox 94 以降同じことを実現します。Safari は WebKit のプロセスごとのモデルを使用します。暗号化への意味：悪意のあるクロスオリジンスクリプトが隣のタブのメモリから復号したファイルを読み取ることができません。隣は独自のヒープを持つ別プロセスに存在するからです。

Cross-Origin-Opener-Policy（COOP）・Cross-Origin-Embedder-Policy（COEP）・Cross-Origin-Resource-Policy（CORP）を使うと、ページはさらに厳格な分離をオプトインできます。Cross-Origin-Opener-Policy: same-origin と Cross-Origin-Embedder-Policy: require-corp を設定するとクロスオリジン分離が有効になり、SharedArrayBuffer と高解像度タイマーのロックが解除されます。攻撃者があなたのオリジンで SAB を開けない場合、AES 実装に対する Spectre スタイルのタイミング攻撃が軽減されるため、暗号化に関連します。

WebAuthn とパスキーによる認証

FIDO2 WebAuthn は Chrome 67+・Firefox 60+・Safari 14+・Edge 18+ でサポートされています。アプリケーションがハードウェアキー（YubiKey・Titan）・プラットフォーム認証器（Face ID・Windows Hello・Android 生体認証）・またはユーザーのデバイス間で iCloud Keychain・Google Password Manager・1Password を介して同期するパスキーでユーザーを認証できます。

ファイル転送アプリケーションでは、WebAuthn は保存された共有リンクへのアクセスを保護する要素としてパスワードを置き換えます。重要なのは WebAuthn がフィッシング耐性を持つこと：署名はオリジンにバインドされているため、そっくりなドメインは認証情報を取得できません。 Chrome と Safari はどちらも2023〜2024年にパスキーデフォルトのフローに移行し、ほとんどのコンシューマー向けで物理キーの要件を廃止しました。

ハードウェアバックアップの鍵保存

Windows では、TPM 2.0 チップ（Windows 11 で必須）が Windows CNG ブリッジを介して非抽出可能として生成された Web Crypto 鍵を保存できます。macOS と iOS では、Secure Enclave が Face ID・Touch ID・パスキーに使用される鍵を保持します。Android では、StrongBox（ハードウェア）または TEE（Trusted Execution Environment）によってバックアップされた Keystore が同様の保護を提供します。

実際的な意味：最新のノートパソコンで extractable: false として生成された Web Crypto 鍵は、メインメモリではなく TPM または Secure Enclave に存在することがあります。JavaScript メモリをダンプするブラウザの完全なエクスプロイトでも生の鍵バイトは得られません。ファイル転送ツールでは、これは長期保存される受信者鍵に最も有用です。ファイルごとの一時的な AES 鍵はこの保護を必要としません。

暗号化の乗数としてのコンテンツセキュリティポリシー

暗号化は悪意のあるスクリプトが暗号化前の平文を読める場合に無意味です。Content Security Policy ヘッダーは、実行が許可されているスクリプトをサイトが宣言できます。厳格なポリシー：

Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-abc123';

これはインラインスクリプトとサードパーティコードをブロックし、注入された暗号盗取ペイロードの攻撃面を残しません。すべての主要ブラウザは CSP Level 3 をサポートします。ファイル転送アプリには、許可されたサードパーティ JS も改ざんされていないことを確認するために CSP と Subresource Integrity（SRI）を組み合わせてください。

ファイルシステムアクセスと OPFS

File System Access API（Chrome 86+・Edge 86+・Safari 15.2+ 以降の Origin Private File System 経由の部分的なサポート）を使うと、ウェブアプリがユーザーの許可を得てローカルファイルを読み書きできます。Origin Private File System は暗号化に特に関連します。これはオリジンごとのプライベートファイルシステムで、ブラウザが管理し、アップロード前に大きな暗号化ペイロードをすべてメモリに読み込まずにステージングするために使われます。

Firefox は FSA の採用が遅れていますが Firefox 111 以降 OPFS をサポートします。Safari は全体的に OPFS をサポートしていますが、より広い File System Access API ではより制限的な動作があります。

ブラウザがまだ得意でないこと

いくつかのギャップが残っています：

Argon2 鍵導出は Web Crypto にありません。PBKDF2 より上のパスワードハッシングには WASM ライブラリを使用してください。
ChaCha20-Poly1305 は公開されていません。AES-GCM がほとんどのニーズをカバーしますが、ChaCha は AES-NI のない古い ARM デバイスで役立ちます。
ハードウェアバックアップされた鍵の鍵証明は限定的です。WebAuthn は証明を提供します。より広い Web Crypto API はそうではありません。
ストリーミング AEAD はまだスペックにありません。大きなファイルの暗号化にはチャンキングロジックまたは WASM が必要です。
耐量子アルゴリズム（Kyber・Dilithium）はまだブラウザに入っていません。Google は TLS ハンドシェイクで Kyber を出荷しました（Chrome 116+）が、JavaScript で公開された耐量子暗号はまだライブラリの領域です。

ファイル転送に今日使うべきもの

2026年の信頼できるブラウザベースのファイル転送スタック：

ファイルコンテンツには crypto.subtle.encrypt 経由の AES-256-GCM
パスワード導出鍵には PBKDF2-SHA-256 で600,000回のイテレーション
ソルトとナンスには crypto.getRandomValues()（Math.random は絶対に不可）
サーバーに露出させずに鍵をクライアントサイドで渡すための URL フラグメント（#key=...）
TLS 1.3 以上の HTTPS・HSTS 有効・分離のための COOP/COEP
インラインスクリプトなしの CSP strict-dynamic
保存アカウント機能には WebAuthn パスキー
Chrome/Edge/Safari 16+ での大ファイルステージングには OPFS

HexaTransfer は基本的にこのスタックを実行します。SwissTransfer・Tresorit Send・Cryptpad・Proton Drive Share も同様です。プリミティブは成熟しており、ブラウザ間で一貫しています。

ブラウザのテスト

常に4つすべてでテストしてください。実際のバグ：Firefox は Chrome がサイレントに受け入れる PBKDF2 入力で OperationError をスローします。Safari の FileReader は2GB 以上のファイルで遅くなります。Chrome の OPFS は一部のバージョンで4 GB 以上の書き込みをチャンク分割します。WebAuthn ユーザー確認プロンプトは大きく異なります（Face ID vs Touch ID vs Windows Hello vs Android 生体認証）。事前リリーステストには BrowserStack・Sauce Labs・または物理デバイスのローカルマトリクスを使用してください。

ブラウザは静かに最も完全な暗号プラットフォームの一つになりました。バンキングアプリ・パスワードマネージャー・メッセージングクライアントを動かすのと同じ標準ベースのプリミティブが、暗号化ファイル転送ツールを構築する誰にとっても単一の JavaScript 呼び出しで利用できます。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。