OneTimeSecretとPrivateNote：暗号化する場所が重要な理由

同じリンクを作る二つの方法

サーバー側の暗号化では、送信者がTLS経由で秘密情報をサービスに送ります。サービスは平文を受け取り、暗号化し、暗号文を保存します。その後、ペイロードを保存し、届け、期限切れにし、削除できます。平文が暗号文になる前にサービスの中へ入るため、アプリケーションサーバーは暗号化の過程の一部です。

クライアント側の暗号化では、送信者の端末が先に暗号化します。サービスが受け取り、保存するのは暗号文です。そのアップロードはTLSで運ばれます。サービスは、標準的なペイロードを復号するために必要な鍵を受け取りません。受信者の端末がローカルで復号します。サービスは、平文へのアクセスを必要とせずに、ペイロードの保存、配送、期限切れ、削除を引き続き行えます。

どちらの設計も、一時的なリンク、制限されたアクセス、有効期限を提供できます。どちらも、暗号化されていると正確に説明できます。OneTimeSecretは第一のアーキテクチャを使い、PrivateNoteは第二を使います。したがって、関係する問いは、ワンタイムリンクが暗号化されているかどうかだけではなく、そのリンクが機能するために、どのシステムが平文へアクセスできなければならないかです。

OneTimeSecret：サーバー側の暗号化

通常のOneTimeSecretの流れでは、送信者がTLS経由で秘密情報を送ります。アプリケーションは平文を受け取り、サーバー上で暗号化し、暗号化されたペイロードを保存します。

これは、保存されたデータに意味のある保護を与えます。暗号化されたストレージを入手しただけでは、復号に必要な材料が攻撃者に利用できないとき、その内容が必ずしも明らかになるわけではありません。

アーキテクチャ上のトレードオフは、保存の前に起きます。TLSは、ブラウザとOneTimeSecretの間を移動する間、秘密情報を保護しますが、アプリケーションは暗号化するために平文を処理しなければなりません。したがって、アプリケーションサーバーは暗号上の信頼境界の内側にあります。

その時点で悪意のある、または侵害されたアプリケーションプロセスは、保存のために暗号化される前に秘密情報へアクセスでき得ます。クライアント側の暗号化は、秘密情報がサービスに届く前に暗号化することで、この特定の依存を取り除きます。

OneTimeSecretのパスフレーズは、暗号化の境界を変えません

OneTimeSecretの文書は、任意のパスフレーズを説明しています。パスフレーズを使うとき、OneTimeSecretは、送信者が提供したパスフレーズを使って、秘密情報を自らのサーバー上で暗号化すると述べています。パスフレーズそのものは保存しないと述べています。代わりに、取得時にパスフレーズを検証するために使うbcryptハッシュを保持します。その文書によれば、そのハッシュ自体は秘密情報を復号できず、保存されたパスフレーズ保護の秘密情報は、元のパスフレーズなしには復号できません。

取得も、同じサーバー側の境界を使います。受信者はTLS経由でパスフレーズをOneTimeSecretに提供します。サービスはそれを検証し、平文を返す前にサーバー上で復号を行います。

これは、暗号化が行われるときにアプリケーションプロセスが秘密情報とパスフレーズへアクセスでき、取得時にもパスフレーズと、その結果の平文を再び処理することを意味します。どちらかの時点で動作する、悪意のある、または侵害されたアプリケーションプロセスは、その情報を捕捉でき得ます。これは、暗号化と復号がどこで実行されるかの帰結であり、OneTimeSecretがそれらの値を記録したり悪用したりするという主張ではありません。

OneTimeSecretの公開文書は、それだけでは、内部の鍵階層のすべての詳細を確立しません。たとえば、サーバー側の鍵材料、秘密情報ごとの鍵、鍵導出、提供されたパスフレーズが、正確にどのように組み合わされるかです。この比較のために、それらの実装の詳細を推測する必要はありません。文書化された、関係する性質は、暗号化と復号がサービス側で行われることです。

セルフホスティングは、そのサーバーへの信頼を合理的にし得ます

OneTimeSecretはオープンソースです。組織は、秘密情報を公開サービスへ送るのではなく、企業のセキュリティ境界の内側で自らのインスタンスを動かせます。

その配備では、アプリケーションサーバーを信頼することは、組織がすでに運用している基盤を信頼することです。暗号化は依然としてそこで行われるため、平文はそのサーバーに依然として届きます。境界の向こう側にいるのは、組織自身のホスト、運用者、バックアップです。秘密情報が通る経路の一部として、それらのシステムをすでに受け入れているチームにとって、サーバー側の暗号化は合理的な選択であり得ます。運用者が外部のサービスではなくなるため、サーバー側とクライアント側の脅威モデルの差は狭まります。

PrivateNoteはアップロード前に暗号化します

標準的なPrivateNoteは、アップロード前に暗号化されます。送信者のブラウザ、またはローカルのCLI、Chrome拡張機能、エディタ拡張機能、MCPのプロセスが、ランダムな鍵を生成し、AES-256-GCMでペイロードを暗号化します。アップロードされるのは暗号文だけです。TLSがその暗号文を、ブラウザからPrivateNoteのCloudflareワーカーへ運びます。復号鍵はURLフラグメント、つまり#よりあとの部分に置かれます。たとえばhttps://privatenote.ai/note/abc123#…です。フラグメントはクライアント側で扱われ、HTTPS要求には含まれません（RFC 3986, §3.5、URL Standard）。ワーカーはメモ識別子を受け取り、同じTLS接続で暗号文を返します。ブラウザはフラグメントを保持し、ローカルで復号します。

パスフレーズは、リンクのチャネルが侵害されたときに鍵を保護します

PrivateNoteのパスフレーズは、OneTimeSecretのパスフレーズとは別の仕事をします。メモは、端末を離れる前にすでに暗号文です。パスフレーズを追加すると、ブラウザがArgon2idでそこからラッピング鍵を導出し、そのラッピング鍵でメモの鍵を暗号化します。URLフラグメントが保持するのは、包まれた鍵です。受信者にはリンクとパスフレーズが必要です。ブラウザがローカルで鍵のラップを解き、そのあとで初めてメモを復号します。

PrivateNoteはパスフレーズを受け取りません。作成要求が運ぶのは、暗号文、ソルト、受信者のブラウザがパスフレーズをローカルで試すために必要なパラメータです。パスフレーズを検証する仕事の、サーバー側ハッシュはありません。誤ったパスフレーズは、端末上で復号に失敗します。

パスフレーズは、リンクを運ぶチャネルが侵害された場合に、クライアント側の鍵をローカルで追加的に保護します。そのチャネルが見るのは包まれた鍵であり、それだけでメモを開ける鍵ではありません。PrivateNoteを平文の経路の外に置く仕組みは、それではありません。その分離は、パスフレーズの有無にかかわらず、標準的なメモにすでにあります。パスフレーズは、リンクとは別のチャネルで共有してください。同じメッセージは、二つの層を一つに畳みます。パスワードを安全に共有すると同じ規則です。

PrivateNoteの鍵の扱いは、仕組みで説明しています。コンテンツ鍵はArgon2idで包まれ、包まれた鍵はリンクの中を移動します。

残る、Webクライアントへの信頼の前提

ブラウザでのクライアント側暗号化は、信頼不要のWebアプリケーションではありません。暗号はローカルで実行できても、それを実装するJavaScriptはサイトから配信されます。ブラウザは、そのセッションで受け取ったコードを信頼します。

アプリケーション、CDN、配備パイプラインを通じてそのJavaScriptを改変できる人は、クライアントを変え、将来のブラウザセッションで鍵を捕捉でき得ます。これは、データベースを盗むこととは別の失敗です。ストレージの侵害が露出するのは暗号文です。悪意のあるコード配信は、鍵が実際に存在する間にエンドポイントを攻撃します。

後からのデータベースのダンプは、そこに一度も保存されなかったクライアント側の鍵を作り出せません。積極的に侵害されたクライアントは、そのセッション中に扱われた秘密情報を攻撃できます。同じ前提は、PrivateNoteの脅威モデルにも書かれています。配信されたアプリケーションコードが悪意を持って改変されておらず、暗号化と復号の時点で送信者と受信者の端末が信頼されていることです。

インストールされたソフトウェアは、新しくダウンロードしたページへのその依存を狭めます。CLI、エディタ拡張機能、ネイティブアプリは、インストールしたコードを実行します。それらのクライアントも、オペレーティングシステム、署名、依存関係、更新チャネルに依存します。開発者ツールは、ブラウザと同じ分かれ方を使います。ローカルで暗号化し、暗号文をアップロードし、鍵はフラグメントに残します。

寿命と機密性

ワンタイムリンクは、二つの別々の問いに答えます。暗号化されたペイロードは、どのくらい存在するべきか。そして、存在している間、誰が復号できるか。取得後または期限切れのあとに破棄すると、窓は短くなります。その窓の間に誰が読めたかは決まりません。寿命と機密性は、互いを支えます。一方が他方の代わりにはなりません。

区別がいちばん鋭いのは、ペイロードが権限であるときです。APIキー、データベース認証情報、クラウドトークン、復旧コード、基盤のパスワードです。秘密情報の共有サービスが存在するのは、送信者が、その情報を託すシステムを減らしたいからです。仲介者が運ぶべきものが不透明な暗号化オブジェクトだけであり、有効期限を適用し、削除するだけでよいなら、サーバーは秘密情報や、それを開く鍵を受け取らずに、その仕事を行えます。

境界がどこにあるか

「暗号化されている」は、信頼境界がどこにあるかを教えません。使う価値のある基準は、最小の信頼境界です。誰が平文を見なければならないかに適用した、最小権限の原則です。現代の暗号工学では、目標はサーバーが正しく振る舞うと信頼することだけではなく、そもそも信頼の数学的な必要性を減らすことです。

OneTimeSecretは、サーバー側で暗号化したシステムを説明しています。パスフレーズ保護では、保存された秘密情報は、その後、パスフレーズなしには復号できないと述べ、そのパスフレーズが未知のままなら、サーバーの侵害があっても秘密情報は安全なままであると述べています。弱いパスフレーズは総当たりされ得ます。弱い場合、その侵害があっても秘密情報は復元可能なままになり得ます。暗号化はサーバー上で行われるため、平文とパスフレーズは作成時にOneTimeSecretへ届き、それらのサーバーが復号できるように、取得時にパスフレーズが再び送られます。

PrivateNoteは、別のアーキテクチャ上の選択をします。ペイロードはサービスに届く前に暗号化され、標準的なペイロード鍵はクライアント側に残ります。パスフレーズを設定した場合、それは、リンクを運ぶチャネルが侵害されたときに、そのクライアント側の鍵をローカルで追加的に保護します。PrivateNoteには送られません。

OneTimeSecretは秘密情報を暗号化します。PrivateNoteのサービスを使うクライアントは、サービスが受け取る前に暗号化します。その区別は、どちらかの提供者が悪意があると仮定することに依存しません。問いはアーキテクチャに還元されます。サービスが機能するために、平文へのアクセスを必要とするシステムはいくつあるか、です。

よくある質問

一次情報

OneTimeSecretに関するアーキテクチャ情報は、2026年9月23日に公開文書と照合して確認しました。製品の実装と文書は変わることがあります。

• OneTimeSecretの文書
• セキュリティとパスフレーズに関するOneTimeSecret
• OneTimeSecretのソースコード
• PrivateNoteの暗号化の仕組み
• CLIを含む開発者向けPrivateNote
• 参照前にフラグメントをURIから分離するRFC 3986、3.5節
• フラグメントのクライアント側の扱いについてのURL Standard、フラグメント