nsec vs npub: それぞれが何であり、混同しない方法

すべてのNostrユーザーは、アカウント作成後1分以内にnpub1とnsec1で始まる2つの文字列を見ます。ほぼ同じに見え、同じ長さで、どちらもランダムな文字のように見えます。それらを混同することはネットワーク上で最も一般的で最も深刻な誤りの1つです。

このガイドは、視覚的および概念的に区別を明確にするので、二度と混同することはありません。

TL;DR。 npub1...はあなたの公開鍵です：共有しても安全で、これはあなたが渡すものです。nsec1...はあなたの秘密鍵です：決して共有しないでください。Webサイトに貼り付けないでください。クラウドノートに保存しないでください。どちらも63文字の長さです。最初の3文字だけが重要です。

準備ができたら、 @nostr.blog アドレスを取得 →

1行での区別

あなたのキーペアには2つの半分があります。

• npub = nostr public。投稿し、共有し、「アカウント名」として使用するアイデンティファイアです。
• nsec = nostr secret。アカウントを所有していることを証明する暗号秘密です。

「npub」には「pub」という単語が含まれています（公開）。「nsec」には「sec」という単語が含まれています（秘密）。このニーモニックは偶然ではありません。設計者は自己説明的なプリフィックスを選択しました。

実際に見えるもの

どちらの文字列も63文字です。どちらもnで始まり、その後に3文字のプリフィックスが続きます。どちらも制限されたBech32アルファベットから小文字のa-zと数字の0-9を使用しています。

npubの例：

npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

nsecの例（これは作成されたもので、実際のnsecは決して共有しません）：

nsec1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

それらはnの後のプリフィックスでのみ異なります。pub vs sec。他のすべての文字は何でもよく、そのプリフィックスが区別できる唯一の場所です。

それぞれがどこから来るか

Nostrクライアントを初めて起動すると、32ランダムバイトが生成され、それが秘密鍵と呼ばれます。これはBech32エンコード後のnsecになります。その後、クライアントは1つの数学演算（secp256k1上の楕円曲線乗算）を実行して、一致する公開鍵を派生させ、それをBech32エンコードしてnpubにします。

この関係は一方向です。nsecが与えられた場合、npubの派生は高速です。npubが与えられた場合、nsecを逆に派生させることは、存在する、または存在する可能性のあるコンピュータでは不可能と考えられています。

これがなぜあなたは安全保障上の問題なくあなたのウェブサイト、Twitter、ビジネスカード、メール署名にnpubを公開できるのかです。これはまたなぜnsecを失うことが回復不可能な大惨事なのかです：誰も、あなた自身さえも、npubから再構築することはできません。

各キーが何に使用されるか

nsecは1つの仕事があります：イベントに署名します。投稿、反応、誰かをフォロー、プロフィール更新、またはダイレクトメッセージを送信するたびに、クライアントはイベントを作成し、nsecを使用してそれに署名します。署名は、リレーに公開される前にイベントに入ります。

npubはいくつかの仕事があります：

• アイデンティティ。 誰かがあなたをフォローすると、あなたのnpubを参照します。
• 検証。 イベントを受け取るすべてのクライアントは、イベントに添付されたnpubに対して署名をチェックします。有効な署名は、イベントが一致するnsecの所有者から来たことを意味します。
• ルーティング。 リレーはフィルター内のnpubを使用します。「npub Xからのイベント」をサブスクライブするのは、フォロワーがあなたの投稿を取得する方法です。
• メンション。 誰かが投稿であなたをタグ付けするときに、イベントタグにあなたのnpubを埋め込みます。

nsecはネットワークには決して表示されません。デバイス上、またはNIP-07拡張機能やリモート署名者アプリなどの信頼できる署名者に留まります。npubはネットワークに常に存在し、署名したすべてのイベントに添付されます。

一般的な混同とその結果

混同1：npubが求められている場所にnsecを貼り付ける。

シナリオ：プロフィール編集フォームが「あなたの公開鍵」と言い、あなたが誤ってnsecを貼り付けます。結果：クライアントによっては、フォームが警告を発する場合があります（良いクライアントはプリフィックスをチェックし、公開フィールドでnsecを拒否します）。悪いクライアントはnsecをそれが行くべきでない場所に公開するかもしれません。貼り付ける前に常に3文字のプリフィックスをチェックしてください。

混同2：nsecをソーシャルメディアにデモとして公開する。

毎年、新しいユーザーが両方の文字列を含む「Nostrアカウント詳細」のスクリーンショットを投稿します。結果：スクリーンショットを見た誰もが、気づいて回転するまで、そのユーザーとしてイベントに署名できます。解決策は、npubの半分のみを共有することです。

混同3：nsecを「一時的に」クラウドノートに保存する。

シナリオ：キーペアを生成し、2番目のデバイスにコピーしたいので、nsecをiCloud NotesまたはGmailドラフトに貼り付けてデバイス間で移動させます。結果：そのプロバイダーは、読める形式でnsecを保持しています。そのプロバイダーの侵害は、あなたのNostrアイデンティティの侵害です。エンドツーエンド暗号化を備えたパスワードマネージャーを使用するか、（1回限りの転送の場合）デバイス間でスキャンするが、クラウド同期位置に保存しないQRコードを使用してください。

混同4：nsecをWebサイトのログインフォームに貼り付ける。

シナリオ：新しいNostr Webアプリが「ログイン」するためにnsecを要求します。結果：そのWebサイトは、タブを閉じた後もnsecを永久に保有しています。これはしないでください。評判の良いWebクライアントは代わりにNIP-07ブラウザ拡張機能を使用します。拡張機能はnsecを保有し、要求時にのみ署名し、Webページに生の秘密を決して露出させません。

Bech32チェックサムトリック

npubとnsecはどちらもBech32エンコーディングを使用しており、組み込みエラー検出チェックサムが含まれています。npubまたはnsecの1文字を変更した場合、チェックサムが失敗し、準拠した任意のツールが文字列を無効として拒否します。

これは実際には便利です：キーをコピー貼り付けし、文字がドロップまたは置換された場合、受信側のツールはすぐに告げます。無知のうちに異なる（見た目は有効な）アイデンティティを受け入れることはありません。

16進数エンコードキーにはこの特性がありません。16進数キーの単一の間違った文字は、別の（見た目は有効な）キーを生成し、完全に異なるアイデンティティを指します。システム間でキーを貼り付けるときは常にBech32形式（npub/nsec）を好みます。

どちらを見ているかを確認する方法

最初の4文字です。それが全体のチェックです。

• npub1で始まる：共有しても安全で、それは公開半分です。
• nsec1で始まる：いかなる状況でも共有しないでください。それは秘密半分です。
• note1で始まる：これはイベントID（特定の投稿）です。鍵ではありません。
• nprofile1で始まる：これは推奨リレーでバンドルされた公開鍵です。
• nevent1で始まる：これは著者とリレーでバンドルされたイベントIDです。
• naddr1で始まる：これは長編記事のアドレスです。

有用な精神ルール：nsecで始まるBech32文字列はデバイスに留まります。他のすべて（npub、note、nprofile、nevent、naddr）は共有することを目的としています。

具体的なセキュリティ儀式

新しいNostrアイデンティティを生成した瞬間に、これを行いました：

1. パスワードマネージャーを開きます。
2. 「Nostr nsec [アカウント名]」というラベルの付いた新しいエントリを作成します。
3. nsecをパスワードフィールドに貼り付けます。
4. 保存します。
5. アプリを閉じます。

合計時間：30秒。代わりに：信頼できるプリンターを持つ紙にnsecを印刷し、その紙を失わない場所に保管します。5分です。

これで復旧パスが得られました。nsecはマスターパスワードで暗号化されているか、完全にオフラインの場所にあります。電話を失った場合、nsecを再度貼り付けることで新しい電話にログインできます。ラップトップを失った場合も同じです。

人々がこれに抵抗する場所：彼らは電話でキーを生成し、nsecはキーチェーンにあり、「後で保存します」。後は来ません。その後、電話をワイプしたり、アップグレードしたり、失ったりして、アイデンティティは消えます。バックアップはこれを防ぎ、この段落を読むより短い時間を要する単一のステップです。