Relayium がファイルをエンドツーエンドで暗号化する仕組み

最終更新: 2026-08-06

「Relayium は安全なの？」というのは当然の疑問です——どのファイル転送ツールもプライバシーを守ると謳っています。このページでは、Relayium が実際にどうやってファイルを守っているのかを平易な言葉で説明します。信じるかどうかではなく、自分で判断できるように。

実は2つの異なる暗号方式が使われています。理由は状況が2つあるからです。今まさにオンラインの相手にファイルをリアルタイムで送る場合と、あとで受け取ってもらうためにダウンロードリンクを残しておく場合です。どちらもサーバーをファイルから締め出しますが、そこへの至り方は異なります——どちらがどの場面に当てはまるのか、知っておく価値があります。

リアルタイム転送：2台のデバイスがサーバーには見えない秘密を共有する

リアルタイムでファイルを送るとき——双方がオンラインで、ブラウザ同士——Relayium はまず各デバイスに X25519 で新しい鍵ペアを生成させます。これは現代の安全なメッセージングで広く使われている楕円曲線鍵交換と同じ方式です（技術的には libsodium の crypto_kx）。各デバイスは秘密鍵を自分だけに留め、公開鍵だけを相手に送ります。

この2つの公開鍵から、各デバイスはそれぞれ独立に同じ共有秘密を計算します——これは秘密がどこかへ送られたからではなく、楕円曲線鍵交換という仕組みそのものによって成り立つ処理です。その共有秘密は、両ブラウザ内にのみ存在する AES-256-GCM 鍵になります。ファイルの各チャンクは、送信側デバイスを離れる前にこの鍵と一意のノンスで封印されるため、ネットワークを通過するもの——2台のブラウザが互いを見つける手助けをしたシグナリングサーバーも含めて——は暗号文しか目にしません。

• 転送ごとに新しい鍵ペアが生成され、セッションをまたいで再利用されることはありません。
• 共有される AES-256-GCM 鍵は各デバイスで独立に導出され、Relayium 自身のサーバーを含め、どこにも送信されません。
• 暗号化は WebRTC 自体のトランスポート層セキュリティの上、アプリケーション層で行われるため、トランスポート層が侵害されても有効性を保ちます。

不正なサーバーを見破る6桁のコード

ここには正直に触れておくべき細部があります。WebRTC 標準の暗号化（DTLS）は、2台のデバイスを引き合わせるシグナリングサーバー経由で鍵のフィンガープリントを交換します。もしそのサーバーが不正であれば、理論上は中間に入って自分の鍵にすり替えることができます——典型的な中間者攻撃で、しかもどちらのブラウザもすぐには気づきません。

Relayium はこの隙を短い検証コードで塞ぎます。両方のデバイスは双方の公開鍵から同じ6桁の Short Authentication String（SAS）を導出し、画面に表示できます。表示して照合のために止まるかどうかは「高度な検証」で、既定はオフです——つまり既定の転送ではコードは表示されません。ここで説明しているそれ以外の仕組み（毎回新しい鍵、暗号化、コミット後開示ハンドシェイク、チャンクごとの認証）は、どの転送でもそのまま働きます。既定の転送に欠けているのはこの照合そのものです——鍵のすり替えや、相手が意図した人物でないことを検知するには、高度な検証をオンにしたうえで、二人が実際に別の手段でコードを読み合わせる必要があります。2つのコードが一致すれば公開鍵はすり替えられておらず、シグナリングサーバーやリレーサーバーがどちらかのエンドポイントになりすましたり、アプリケーション層のエンドツーエンド暗号化を終端したりしていないことを確認できます。これはネットワーク経路上にサーバーが存在しないという意味ではありません——ネットワークをまたぐ暗号文は設計どおり TURN を通ることがあります。しかし単純な6桁のコードは約20ビットしかなく、原理的には双方の本物の鍵を見た攻撃者が一致するコードを総当たりで作り出そうとする余地があります。それを防ぐため、Relayium はコミット後開示ハンドシェイクを使います。各側はまず自分の鍵に対するハッシュを送ってコミットし、相手のコミットメントを受け取ってから初めて本物の鍵を開示します。この順序によって、悪意あるサーバーは本物の鍵を見る前に盲目的に偽の鍵をコミットせざるを得ず、後から衝突する鍵を選ぶことはできません。だから短いコードは信頼できるままなのです。

1. 2台のあいだで転送を開始し、それぞれの画面に検証コードが出るまで待ちます。

   https://relayium.com/

2. どちらか一方を、帯域外の経路で1桁ずつ読み上げます。アプリにコピーしたり、同じチャットに流したりしないでください。

3. 6桁すべてを照合します。一部だけ一致しているのは、一致していないのと同じです。

4. 一致したときだけ受け入れます。食い違うなら拒否し、相手が実際にどの端末にいるのかを確かめてからやり直してください。

5. CLI では、この照合を任意ではなくブロッキングにできます。--verify はその時点で転送を止めて確認を待つので、誰かが実際に見るまで1バイトも動きません。

   relayium send --verify ./report.pdf

• 最も強い保証を得るには、まず高度な検証をオンにしたうえで、隣り合った2つの画面を目で見比べるだけでなく、通話でコードを読み上げるか、対面で照合してください。
• 2つのコードが一致しない場合は中止してください。誰かが接続を傍受している可能性を示すサインです。

届いたものが送ったものと寸分違わないことを確認する

暗号化は機密性を守りますが、途中で何も壊れたり改ざんされたりしていないことを自動的に証明するわけではありません。Relayium はそれを別途確認します。各チャンクには独自の AES-GCM 認証タグが付いており、改ざんされたチャンクはそもそも復号に失敗します。それに加えて、各ファイルの送信中、双方がその平文内容に対して SHA-256 ハッシュを継続的に計算します。ファイルが終わると、送信側のハッシュが受信側のものと照合されます。一致すればディスクに届いたものは送られたものとバイト単位で同一であり、一致しなければそのファイルは黙って受け入れられるのではなく、フラグが立てられます。

保存リンク：一度だけ生成され、リンクの中にしか存在しない別の鍵

リアルタイム転送には双方が同時にオンラインである必要があります。それができないとき、Relayium は代わりに保存型のダウンロードリンクを提供します——これは本当に異なる仕組みを使っているので、上記のリアルタイム方式と混同しないでください。

ここには鍵交換がありません。まだ交換する相手のデバイスが存在しないからです。代わりに、ブラウザは1つのランダムな AES-256-GCM 鍵を生成し、何かがアップロードされる前にそれでファイルを暗号化します。この鍵はサーバーには一切送られません——ダウンロードリンクの # という文字の後ろに付加される、いわゆる URL フラグメントに置かれます。この部分のアドレスはブラウザが意図的にサーバーへ送信しないものです。結果としてサーバーが保存するのは、復号する術のない暗号文と、暗号文のサイズや有効期限のタイムスタンプといった管理情報だけです。フラグメントを含む完全なリンクを開いた人は誰でも、自分のブラウザ内でローカルにファイルを復号できます。それを持たない人には、サーバー上の中身の分からない塊が見えるだけです。これがゼロ知識という部分です。サーバーは暗号化されたファイルを保持していても、それを読む手段を一度も持たないのです。

• 保存リンクの作成には送信者のサインインが必要ですが、ダウンロードのためにリンクを開くのに必要になることはありません。
• リンクは1時間、1日、3日、7日、最長14日（プランによる）で失効するよう設定するか、最初のダウンロード完了後に消えるよう設定できます。
• 完全なリンクはファイルそのものとして扱ってください——それを持つ人は誰でも復号できるため、ファイルを共有するのと同じ慎重さで共有してください。

サーバーが見えるもの、見えないもの

サーバーがこの仕組みのどこに位置しているのかを正確に説明しておく価値があります。「エンドツーエンドで暗号化されている」という主張は口にするのは簡単でも、正確に言うのは意外と難しいからです。同一ネットワークでのリアルタイムモードでは、ファイル自体は Relayium のサーバーに一切触れません——2台のブラウザ間を直接ストリーミングされます。シグナリングサーバーの役割は、接続確立のためのメッセージ（WebRTC が直接リンクを確立するのに必要な SDP/ICE の技術情報）を中継し、2台のデバイスが互いを見つけられるようにすることに限られます。ファイルの内容やファイル名、鍵を目にすることは一切ありません。

ネットワークをまたぐ転送では——制限の厳しい NAT やファイアウォールの内側では直接経路が成立しないことが多いため——暗号化ストリームは TURN リレーサーバーを経由します。リレーが転送するのは暗号文だけです。鍵を持たないため、そこを通過する内容を復号することはできません。リレーが行うのは、送信側アカウントの月間リレー割り当てに対してリレーしたバイト数を数えることだけで、それは純粋に計量と不正利用防止のためであり、中身を検査することは決してありません。

照合がうまくいかないとき

結果は3通りで、緊急なのは最初の1つだけです。自分がどれを見ているのかを見分けられること自体に、価値の大半があります。

よくある質問

Relayium は私のファイルを読めますか？

いいえ。リアルタイムモードでは、暗号鍵は両方のデバイスで独立に導出され、デバイスの外に出ることはありません——Relayium のサーバーがその鍵やファイルの中身を目にすることは一切ありません。保存リンクの場合、鍵は URL フラグメントにのみ存在し、ブラウザはそれをどのサーバーにも送信しないため、サーバーは復号できない暗号文しか持ちません。

サーバーは実際には何を見ているのですか？

同一ネットワークでのリアルタイムモードでは、2台のデバイスを引き合わせるために必要な接続確立情報だけを見ます——ファイルのバイトは一切見ません。ネットワークをまたぐ場合、TURN リレーは確かにファイルのバイトを運びますが、それは鍵を持たない暗号文としてだけです。保存リンクの場合、暗号文とサイズ・有効期限といった管理情報を見ます——平文やファイル名、復号鍵を見ることは一切ありません。

TURN リレーは弱点になりませんか？

ブラウザでは、直接接続に失敗したときだけの手段ではなく、設計上ネットワークをまたぐ転送すべてを担います——ただし扱うのは常に暗号文だけで、鍵を持たないため、リレーしている内容を読むことはできません。Relayium はリレーしたバイト数をアカウントの月間割り当てに対して数えますが、中身を検査することはありません。

Relayium はオープンソースですか？

はい。プロトコル設計とクライアント・サーバーの全コードは AGPL-3.0 ライセンスのもと GitHub で公開されているため、ここで説明した暗号方式は信じるしかないものではなく、独自に監査できます。

画面上の2つの検証コードが一致しない場合はどうすればいいですか？

転送を中止してください。コードが一致しないということは、2台が同じ接続を見ていないということです——鍵のすり替えや中間者がいる場合にまさに現れる結果であり、単なる不具合ではありません。（コミット後開示ハンドシェイクの失敗はこれとは別の、もっと早い段階の失敗です。接続自体が中止され、コードは表示されません。）理由が分かるまで先に進まないでください。

続けて読む

• インターネットでファイルを送るのは安全か
• P2P（ピアツーピア）ファイル転送とは？
• 期限付きの安全なダウンロードリンクでファイルを共有する
• Relayium をセルフホスト：自分専用のファイル・テキスト転送サーバーを運用
• Relayium