最終更新: 2026-07-09
「Relayium は安全なの？」というのは当然の疑問です——どのファイル転送ツールもプライバシーを守ると謳っています。このページでは、Relayium が実際にどうやってファイルを守っているのかを平易な言葉で説明します。信じるかどうかではなく、自分で判断できるように。
実は2つの異なる暗号方式が使われています。理由は状況が2つあるからです。今まさにオンラインの相手にファイルをリアルタイムで送る場合と、あとで受け取ってもらうためにダウンロードリンクを残しておく場合です。どちらもサーバーをファイルから締め出しますが、そこへの至り方は異なります——どちらがどの場面に当てはまるのか、知っておく価値があります。
リアルタイムでファイルを送るとき——双方がオンラインで、ブラウザ同士——Relayium はまず各デバイスに X25519 で新しい鍵ペアを生成させます。これは現代の安全なメッセージングで広く使われている楕円曲線鍵交換と同じ方式です（技術的には libsodium の crypto_kx）。各デバイスは秘密鍵を自分だけに留め、公開鍵だけを相手に送ります。
この2つの公開鍵から、各デバイスはそれぞれ独立に同じ共有秘密を計算します——これは秘密がどこかへ送られたからではなく、楕円曲線鍵交換という仕組みそのものによって成り立つ処理です。その共有秘密は、両ブラウザ内にのみ存在する AES-256-GCM 鍵になります。ファイルの各チャンクは、送信側デバイスを離れる前にこの鍵と一意のノンスで封印されるため、ネットワークを通過するもの——2台のブラウザが互いを見つける手助けをしたシグナリングサーバーも含めて——は暗号文しか目にしません。
ここには正直に触れておくべき細部があります。WebRTC 標準の暗号化（DTLS）は、2台のデバイスを引き合わせるシグナリングサーバー経由で鍵のフィンガープリントを交換します。もしそのサーバーが不正であれば、理論上は中間に入って自分の鍵にすり替えることができます——典型的な中間者攻撃で、しかもどちらのブラウザもすぐには気づきません。
Relayium はこの隙を短い検証コードで塞ぎます。両方のデバイスは双方の公開鍵から同じ6桁の Short Authentication String（SAS）を導出し、画面に表示します。2つのコードが一致すれば鍵はすり替えられておらず、中間には誰もいません。しかし単純な6桁のコードは約20ビットしかなく、原理的には双方の本物の鍵を見た攻撃者が一致するコードを総当たりで作り出そうとする余地があります。それを防ぐため、Relayium はコミット後開示ハンドシェイクを使います。各側はまず自分の鍵に対するハッシュを送ってコミットし、相手のコミットメントを受け取ってから初めて本物の鍵を開示します。この順序によって、悪意あるサーバーは本物の鍵を見る前に盲目的に偽の鍵をコミットせざるを得ず、後から衝突する鍵を選ぶことはできません。だから短いコードは信頼できるままなのです。
暗号化は機密性を守りますが、途中で何も壊れたり改ざんされたりしていないことを自動的に証明するわけではありません。Relayium はそれを別途確認します。各チャンクには独自の AES-GCM 認証タグが付いており、改ざんされたチャンクはそもそも復号に失敗します。それに加えて、各ファイルの送信中、双方がその平文内容に対して SHA-256 ハッシュを継続的に計算します。ファイルが終わると、送信側のハッシュが受信側のものと照合されます。一致すればディスクに届いたものは送られたものとバイト単位で同一であり、一致しなければそのファイルは黙って受け入れられるのではなく、フラグが立てられます。
リアルタイム転送には双方が同時にオンラインである必要があります。それができないとき、Relayium は代わりに保存型のダウンロードリンクを提供します——これは本当に異なる仕組みを使っているので、上記のリアルタイム方式と混同しないでください。
ここには鍵交換がありません。まだ交換する相手のデバイスが存在しないからです。代わりに、あなたのブラウザは1つのランダムな AES-256-GCM 鍵を生成し、何かがアップロードされる前にそれでファイルを暗号化します。この鍵はサーバーには一切送られません——ダウンロードリンクの # という文字の後ろに付加される、いわゆる URL フラグメントに置かれます。この部分のアドレスはブラウザが意図的にサーバーへ送信しないものです。結果としてサーバーが保存するのは、復号する術のない暗号文と、暗号文のサイズや有効期限のタイムスタンプといった管理情報だけです。フラグメントを含む完全なリンクを開いた人は誰でも、自分のブラウザ内でローカルにファイルを復号できます。それを持たない人には、サーバー上の中身の分からない塊が見えるだけです。これがゼロ知識という部分です。サーバーは暗号化されたファイルを保持していても、それを読む手段を一度も持たないのです。
サーバーがこの仕組みのどこに位置しているのかを正確に説明しておく価値があります。「エンドツーエンドで暗号化されている」という主張は口にするのは簡単でも、正確に言うのは意外と難しいからです。リアルタイムモードでは、ファイル自体は Relayium のサーバーに一切触れません——2台のブラウザ間を直接ストリーミングされます。シグナリングサーバーの役割は、接続確立のためのメッセージ（WebRTC が直接リンクを確立するのに必要な SDP/ICE の技術情報)を中継し、2台のデバイスが互いを見つけられるようにすることに限られます。ファイルの内容やファイル名、鍵を目にすることは一切ありません。
直接接続ができない場合——双方が制限の厳しい NAT やファイアウォールの内側にある場合——暗号化ストリームは失敗する代わりに TURN 中継サーバーにフォールバックします。中継が転送するのは暗号文だけです。鍵を持たないため、そこを通過する内容を復号することはできません。中継が行うのは、送信側アカウントの月間中継割り当てに対して中継したバイト数を数えることだけで、それは純粋に計量と不正利用防止のためであり、中身を検査することは決してありません。
いいえ。リアルタイムモードでは、暗号鍵は両方のデバイスで独立に導出され、デバイスの外に出ることはありません——Relayium のサーバーがその鍵やファイルの中身を目にすることは一切ありません。保存リンクの場合、鍵は URL フラグメントにのみ存在し、ブラウザはそれをどのサーバーにも送信しないため、サーバーは復号できない暗号文しか持ちません。
リアルタイムモードでは、2台のデバイスを引き合わせるために必要な接続確立情報だけを見ます——ファイルのバイトは一切見ません。保存リンクの場合、暗号文とサイズ・有効期限といった管理情報を見ます——平文やファイル名、復号鍵を見ることは一切ありません。
それは直接接続ができない場合にのみ使われるフォールバックであり、常に暗号文しか扱いません——鍵を持たないため、中継している内容を読むことはできません。Relayium は中継したバイト数をあなたのアカウントの月間割り当てに対して数えますが、中身を検査することはありません。
はい。プロトコル設計とクライアント・サーバーの全コードは MIT ライセンスのもと GitHub で公開されているため、ここで説明した暗号方式は信じるしかないものではなく、独自に監査できます。
転送を中止してください。コードが一致しないということは、コミット後開示の検証が失敗したことを意味し、単なる不具合ではなく中間者の存在を示している可能性があります——理由が分かるまで先に進まないでください。
実際にどう見えるか気になりますか？転送を開始して、検証コードが表示される様子を自分の目で確かめてください。
Relayium を今すぐ試す