セキュリティポリシー

Herkos は秘密鍵と暗号化されたメッセージを扱うため、セキュリティに関する報告を真剣に受け止めています。問題は遅く知るより、早く知りたいと考えています。

脆弱性の報告

セキュリティ上の問題について、公開の issue を立てないでください。

GitHub の非公開の脆弱性報告を通じて、またはメールで security@herkos.email まで非公開で報告してください。

含めていただくと役立つもの：問題の内容、再現方法、テストしたプラットフォームとバージョン、攻撃者が何を達成できるか。概念実証（PoC）があると大いに助かります。

報告に、ご自身の nsec、秘密鍵、バンカーのシークレットを決して含めないでください。

報告には数日以内に受領の返事をすることを目標としています。Herkos は小さなプロジェクトなので、公開する前に修正のための妥当な時間をいただけるようお願いします。ご希望がない限り、アドバイザリーにあなたのお名前を喜んで記載します。

対象範囲

Herkos アプリケーションそのもの：鍵の取り扱いと保存、メッセージの暗号化と復号（local_packages/nostr_mail にある NIP-59 の送信者チェックと Bcc の分離を含む）、アプリロック、リレーおよびブリッジとの通信、添付ファイルの扱い、ビルドとリリースのパイプライン。

対象範囲外

Nostr プロトコルとその NIP 自体——それらは上流に報告してください。
第三者が運営するリレー、ブリッジ、Blossom サーバー。 Herkos は既定値を同梱していますが、それらを運営してはいません。問題はその運営者に報告してください。
上流プロジェクトである Nostr Mail Client。ただし、問題が Herkos で加えた変更に固有のものである場合を除きます。
既知の制限として私たちがすでに文書化している、強化の不足（下記参照）。

既知の制限（率直に）

これらは設計上のトレードオフであり、脆弱性ではありません。誰かが痛い目に遭って発見するより、ここに書いておきたいと考えています。

従来のアドレスとのメールはエンドツーエンドで暗号化されません。 Nostr 利用者どうしのメッセージは NIP-17 の gift wrap を使い、E2E で暗号化されます。通常のメールアドレスに書く場合は、ブリッジがメッセージを変換し、内容を読めます。
アプリロック（PIN と生体認証）は利便性のための障壁であり、保存時の暗号化ではありません。ロック解除された端末を手に取った人は止めますが、端末やそのストレージに完全にアクセスできる攻撃者からは守りません。
Windows では、生体認証のみの認証を強制できません。 Windows Hello は方式の選択を許さないため、システムの PIN が常に代替手段として残ります。
鍵を失うことは、アカウントを失うことです。 設計上、復旧の手段はありません。
メタデータは完全には隠されません。 リレーは接続のパターンを観察でき、メッセージの内容を読めなくても、すべてのリレーがあなたの IP アドレスを見ます。 Herkos が（2026年9月30日以降）明かさないのは、リレーが NIP-42 認証を求めたときの、誰が誰に書いているか、です。
配送先の調査。 受信者のリレー一覧と Blossom 一覧は、あなたを一切識別しない別の接続で問い合わせます。まず認証を求めないリレー（purplepag.es、 user.kindpag.es、nos.lol、offchain.pub）に問い合わせます。
プロフィールと予約送信。 他の人について表示する名前と画像（kind 0）、およびメールを予約または取り消すときの予約送信 DVM のリレー一覧も、同じ方法で問い合わせます。まず匿名で、リレーがどうしても求める場合は下で説明する一時的な鍵で問い合わせ、あなたの鍵は決して使いません（2026年10月1日以降。それ以前は、認証を求めるリレーにはあなたの鍵が渡り、あなたが誰のプロフィールを見ているかが分かりました）。あなた自身のプロフィールだけは、今もあなたとして読み込みます。
配送。 gift wrap は受信者の DM リレーへ、同じ別の接続で送られます。そのうちのどれかが認証を求めた場合、Herkos はその目的のために作られ、メモリ内だけに保持される鍵で応答し、あなたの鍵は決して使いません。端末上のアカウントごとに別の鍵があります。リレーは、同じ端末（同じ IP、同じ一時的な鍵）がセッション中に複数の封筒を送ったことは引き続き見ることができます。
大きなメール。 32 KB を超えるメールの暗号化されたコピーは、受信者のものを含む Blossom サーバーにアップロードされます。あなたの鍵で認可してアップロードするのは、あなた自身のサーバー（あなたの Blossom 一覧）だけです。それ以外のサーバーには匿名でアップロードし、認可をどうしても求める場合は、上と同じ一時的な鍵で署名した認可を使います（2026年10月1日以降。それ以前は、すべてのサーバーにあなたの鍵が渡っていました）。既知の鍵しか受け付けないサーバーは拒否し、コピーは他のサーバーに残ります。
あなた自身のデータ。 メールボックス、ラベル、設定、下書きの同期では、リレーが求める場合、アカウントの切り替え中であっても、そのデータが属するアカウントとして認証します。あなた自身のリレーにとっては、新たに知ることは何もありません。要求にはいずれにせよあなたの鍵が書かれているからです。あなた自身のリレー一覧と Blossom 一覧は公開されており、あなたを識別せずに問い合わせます。メール内のリンクに書かれたリレーも同様です。
既読状態とフォルダーは（今のところ）公開メタデータです。 メールを既読、スター付き、アーカイブ、移動にすると、あなたの公開鍵に結び付いた、暗号化されていない NIP-32 ラベルイベントが公開され、独自フォルダーの名前も含まれます。あなたに送ったメールの id を知っている送信者は、あなたがいつそれを操作したかが分かります。これらのラベルの暗号化は予定していますが、それまではフォルダー名を公開されるものと考えてください。
プッシュ通知と予約送信は第三者のサービスを使います。 プッシュサーバー（既定は api.nmail.li）は、あなたの公開鍵、プッシュトークン、メールを受け取った時刻を知ります。予約送信 DVM は、あなたの公開鍵と、公開すべき暗号化済みのメッセージを知ります。どちらも任意で有効にするもので、PRIVACY.md に記載しています。プッシュ通知の文面はプッシュサーバーが決めるもので、Herkos は UnifiedPush が暗号化して（RFC 8291）届けた場合にのみそれを信頼します。暗号化されていないペイロードは、アプリを起こしてメール自体を取得させるだけです。
ウェブ版はあなたの鍵をブラウザーに保持します。そこは鍵にとって最も弱い場所です。 インストール版のアプリは、秘密鍵を OS の安全な保管領域（Android キーストア、Windows 資格情報マネージャー、libsecret、iOS/macOS のキーチェーン）に渡します。ブラウザーにはそのどれもありません。鍵はオリジンのストレージに置かれ、署名のたびに JavaScript を通り、ページ内で動くあらゆるコード——すべてのサイトにアクセスできるブラウザー拡張機能、アプリや依存関係の XSS の欠陥、改ざんされた配信——や、ブラウザーのプロファイルをコピーするインフォスティーラーの手が届くところにあります。また、コードを一度だけ検証する機会もありません。署名済みのバイナリはインストール時に確認されますが、ウェブページは訪問のたびに新しいコードを配信します。ウェブ版にはリモート署名（NIP-46 のバンカー、Amber）でログインして鍵がブラウザーに届かないようにするか、使い捨てのアイデンティティとして扱い、本当の鍵はインストール版のアプリに置いてください。
ブリッジ経由のメールの信頼性は、ブリッジの信頼性と同じです。 Herkos は、ブリッジ経由と表示されたメッセージが、あなたが設定したブリッジ（または既定のいずれか）によって本当に署名されたものかを検証します。ブリッジが中継する従来の From: アドレスについては、何も検証できません。
添付ファイルは OS によって開かれます。 Herkos は実行ファイルやスクリプトの種類を決して起動せず、プレビューできないその他の添付ファイルをシステムの既定アプリに渡す前には確認しますが、ファイルを開くアプリは私たちの管理外です。

サポート対象のバージョン

セキュリティ修正は、最新のリリース版に適用されます。プロジェクトの規模から、古いバージョンは保守していません——報告の前に更新してください。