ファイル転送の暗号化方式を詳細に比較

2026年のファイル転送サービスが使う暗号化方式は主に五つあります。TLS のみ（転送中は暗号化されるがサーバー上はプレーンテキスト）、サーバー側AES-256保存時暗号化（プロバイダーが鍵を保持）、Web Crypto APIを使ったクライアント側AES-256-GCM（エンドツーエンド、鍵はURLフラグメントに格納）、XChaCha20-Poly1305ストリーム暗号（拡張ノンス、libsodiumと Tresorit が採用）、そしてOpenPGPハイブリッド暗号（Curve25519 ECC＋AES-256セッション鍵、 Proton が採用）です。適切な選択はスレットモデル、パフォーマンス要件、規制要件によって異なります。

五つの暗号化モデル

モデル1：TLS 1.3のみ。ネットワーク転送中は暗号化されますが、サーバー上ではプレーンテキストとして保存されます。基本的なFTPS、HTTPS POSTアップロードなどが該当します。受動的なネットワーク盗聴には対応しますが、それ以外の攻撃には無力です。

モデル2：TLS＋サーバー側保存時AES-256。保存ファイルをAES-256で暗号化しますが、プロバイダーがマスター鍵を保持します（通常はAWS KMS、GCP Cloud KMSなど）。 WeTransfer 、 SwissTransfer 、 Dropbox が該当。記憶媒体の盗難には対応しますが、内部者アクセス、令状、ライブサーバー侵害には対応できません。

モデル3：対称鍵によるクライアント側E2EE。ブラウザまたはクライアントが256ビット鍵を生成し、AES-256-GCMで暗号化した後、URLフラグメントまたは帯域外チャネルに鍵を格納します。 HexaTransfer 、Firefox Sendプロトコルの後継サービスが該当。サーバーは暗号文しか見えず、いかなる状況でも復号できません。

モデル4：認証済みストリーム暗号。XChaCha20-Poly1305は24バイトのノンスを使用し（ChaCha20-Poly1305の12バイトに対して）、非常に大きなファイルでも誕生日境界の衝突が現実的に不可能です。libsodium secretbox（ Internxt ）、 Tresorit Send が採用。AES-NIハードウェアアクセラレーションが普及していない古いAndroidデバイスやIoTでは、ChaCha20のソフトウェア実装が高速なため選ばれます。

モデル5：ハイブリッド公開鍵＋対称。OpenPGP（RFC 9580、2024年改訂）はECC Curve25519またはRSA-4096を使ってファイルごとのAES-256セッション鍵を暗号化します。 Proton Drive 、従来のGPGファイル暗号化が該当。受信者の公開鍵があれば共有秘密なしの非対称鍵管理が可能になります。

AES-256対ChaCha20：実際の違い

どちらも256ビット対称暗号です。AES-256はNIST標準（FIPS 197）であり、ハードウェアアクセラレーション（x86のAES-NI、モバイル向けARM Cryptography Extensions）を備えます。現代のハードウェアでは、AES-256-GCMはコアあたり2〜4GB/sで動作します。ChaCha20-Poly1305は純粋なソフトウェア実装でコアあたり1〜2GB/sですが、AES-NIのないハードウェアではAESより高速です。4GBファイルを暗号化する場合、どちらも2秒以内に完了し、ネットワークがボトルネックになります。暗号強度の面では、2026年時点でどちらも同等に安全とみなされています。

RSAはファイル転送ではほぼ時代遅れ

RSA-4096は1回の操作で512バイトのプレーンテキストを暗号化します。1GBのファイルをRSAで直接暗号化するのは無意味です。数百万の512バイトブロックに分割することになります。現実的なパターンは常にハイブリッドです。RSAがファイルごとのAES-256セッション鍵を包み、AESがコンテンツを暗号化します。ECC Curve25519はほとんどの新しい設計でRSAに取って代わっています。理由は高速、小さな鍵（256ビットECC＝3072ビットRSAと同等のセキュリティ）、タイミング攻撃への耐性です。2024年のOpenPGPはRSAよりCurve25519（鍵交換用X25519）を推奨しています。

URLフラグメント鍵が重要な理由

HexaTransfer とFirefox Sendプロトコルの系譜は、暗号化鍵をURLフラグメント（#以降の部分）に格納します。ブラウザはRFC 3986の仕様に従い、HTTPリクエストにフラグメントを含めないことが定められています。サーバーは「GET /file/abc123」というリクエストを受け取りますが、鍵を含むフラグメントは決して見えません。ユーザーが完全なURLを貼り付けるかクリックすると、フラグメントはブラウザのメモリ内に留まり、クライアント側の復号を実行します。これが、サイドチャネルなしで共有可能なE2EEリンクを提供する構造的に洗練されたアプローチです。

エンドツーエンド対サーバー側：スレットモデルで判断する

サーバー側暗号化が保護するのは一点のみです。ストレージデバイスの物理的な盗難です。ディスクが盗まれた場合、KMSが侵害されるまでAES-256保存時暗号化はデータを不透明に保ちます。エンドツーエンド暗号化はサーバーが行い得るすべてから保護します。令状、内部者アクセス、ライブデータへのランサムウェア、国家レベルの強制です。スレットモデルが「データセンターからドライブが盗まれる」であれば、サーバー側で十分です。「政府、敵対者、競合他社がサービスにデータの提出を強制する」であれば、E2EEだけが保護します。

認証付き暗号化は必須

MACなしの平文AES-CBCは、パディングオラクル攻撃（BEAST、Lucky13）に対して脆弱であり、選択暗号文クエリで暗号文を復号できます。現代のファイル転送はAEADを使用しなければなりません。AES-256-GCM（NIST SP 800-38D）またはChaCha20-Poly1305（RFC 8439）です。Poly1305タグまたはGCMタグが暗号文と関連データ（ファイルサイズ、ノンス、ファイル名ヘッダー）を認証します。転送中に1ビットが反転すれば、復号は明示的に失敗します。2026年にHMACラッパーなしのAES-CBCを使用しているサービスは、2010年の技術水準から進化していません。

パスワード保護転送の鍵導出

ユーザーが転送を保護するためのパスワードを入力する場合、そのパスワードをAES鍵として直接使用することはできません。エントロピーが低く、ブルートフォース攻撃に脆弱です。現代の鍵導出方式：PBKDF2-SHA-256（OWASP 2023推奨の60万回イテレーション）、scrypt（N=2^17）、Argon2id（メモリ19MiB、2回イテレーション）。 HexaTransfer はPBKDF2（60万回）を使用。 Tresorit はArgon2idを使用。どちらもGPUを使ったパスワードクラッキングに耐えます。

暗号化方式比較表

| 方式 | 機密性 | 認証 | サーバーがプレーンテキストを見るか | 耐量子性 | |---|---|---|---|---| | TLS 1.3のみ | 転送中のみ | あり（暗号スイート内のMAC） | あり | 鍵交換がリスク | | サーバー側AES-256 | 保存時＋転送中 | あり | あり（鍵を保持） | 低 | | クライアント側AES-256-GCM | 完全経路 | あり（GCMタグ） | なし | 低 | | XChaCha20-Poly1305 | 完全経路 | あり（Poly1305タグ） | なし | 低 | | OpenPGP（Curve25519＋AES-256） | 完全経路 | あり（MDC/OCB） | なし | Curve25519がリスク |

耐量子性の考慮

ショアのアルゴリズムは、大型量子コンピュータが実現すればCurve25519とRSAを脅かします。対称暗号（AES-256、ChaCha20）はグローバーのアルゴリズムによって弱体化しますが破られるわけではなく、256ビット鍵は128ビットの耐量子強度を維持します。NISTは2024年に耐量子鍵カプセル化のML-KEM（Kyber）を標準化しました。 Signal は2023年にPQXDHへ移行しました。ファイル転送サービスはまだ広く採用していませんが、長期保持アーカイブは今日から256ビット対称暗号化を使用すべきです。

方式の選び方

一時的な機密転送・短期保持：クライアント側AES-256-GCM＋URLフラグメント鍵。実装は HexaTransfer 。継続的なコンプライアンス要件のあるワークフロー：Argon2idと監査ログを備えたXChaCha20-Poly1305（ Tresorit ）。複数受信者＋鍵管理：OpenPGP（ Proton Drive 、GPG）。大規模分散配信：libsodium secretbox＋イレイジャーコーディング（Storj上の Internxt ）。機密性の低い大量転送：TLS＋保存時暗号化で十分です。

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