nsec vs npub: що це таке і як їх не переплутати

Кожен користувач Nostr бачить дві строки, що починаються з npub1 та nsec1, в течение хвилини після створення акаунту. Вони виглядають майже однаково, мають однакову довжину, і обидві виглядають як випадкові символи. Їх змішування — одна з найчастіших і найнебезпечніших помилок в мережі.

Цей посібник закріплює розрізнення візуально та концептуально, щоб ви їх ніколи не переплутали.

TL;DR. npub1... — ваш публічний ключ: безпечно ділити, це те, що ви передаєте. nsec1... — ваш приватний ключ: ніколи не ділити, ніколи не вставляти на веб-сайт, ніколи не зберігати в хмарних нотатках. Обидва мають довжину 63 символи. Значення мають лише перші три літери.

Коли будете готові, заберіть адресу @nostr.blog →

Розрізнення в один рядок

Ваша пара ключів має дві половини.

• npub = nostr public (публічний). Ідентифікатор, який ви публікуєте, діліться, та використовуєте як своє "ім'я акаунту".
• nsec = nostr secret (секрет). Криптографічний секрет, який доводить, що ви володієте акаунтом.

"npub" містить слово "pub" для публічного. "nsec" містить "sec" для секретного. Цей мнемонічний прием не випадковий; розробники вибрали префікси, щоб вони були самопояснювальними.

Що ви насправді бачите

Обидві строки мають 63 символи. Обидві починаються з n і потім трьохлітерного префіксу. Обидві використовують малі літери a-z та цифри 0-9 з обмеженого алфавіту Bech32.

Приклад npub:

npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

Приклад nsec (цей вигаданий; ніколи не ділитеся реальним nsec):

nsec1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

Вони відрізняються лише префіксом після n. pub vs sec. Кожен інший символ може бути чим завгодно; цей префікс — єдине місце, де ви можете їх розрізнити.

Звідки бере початок кожен з них

Коли ви запускаєте Nostr-клієнт вперше, він генерує 32 випадкові байти і називає їх вашим приватним ключем. Це стає вашим nsec після кодування Bech32. Потім клієнт виконує одну математичну операцію (множення еліптичної кривої на secp256k1) для виведення відповідного публічного ключа, і кодує його як Bech32 в ваш npub.

Взаємозв'язок односторонній. З nsec виведення npub швидко. З npub виведення nsec назад вважається неможливим на жодному комп'ютері, який існує або може існувати.

Ось чому ви можете публікувати свій npub на своєму веб-сайті, в Twitter, на візитних картках та в підписі електронної пошти без будь-яких наслідків для безпеки. Це також чому втрата nsec — невиправна катастрофа: ніхто, навіть ви, не зможе його реконструювати з npub.

Для чого використовується кожен ключ

nsec має рівно одну роль: підписувати події. Кожного разу, коли ви публікуєте, реагуєте, стежите за кимось, оновлюєте свій профіль або надсилаєте прямі повідомлення, ваш клієнт створює подію та підписує її за допомогою nsec. Підпис вводиться в подію перед її публікацією на relay.

npub має кілька ролей:

• Ідентичність. Коли хтось вас стежить, вони посилаються на ваш npub.
• Перевірка. Кожен клієнт, який отримує подію, перевіряє підпис проти npub, приєднаного до події. Дійсний підпис означає, що подія походить від того, хто володіє відповідним nsec.
• Маршрутизація. Relay використовують npub в фільтрах. Підписка на "події від npub X" — це те, як ваші послідовники отримують ваші пости.
• Згадки. Коли хтось вас тегує в дописі, він вбудовує ваш npub в теги події.

nsec ніколи не з'являється в мережі. Він залишається на вашому пристрої (або у надійному підписувачу, як розширення NIP-07 або додаток віддаленого підписувача). npub постійно в мережі, приєднаний до кожної події, яку ви підписуєте.

Часті помилки змішування та їх наслідки

Помилка 1: вставлення вашого nsec там, де запитується npub.

Сценарій: форма редагування профіля говорить "ваш публічний ключ" і ви випадково вставляєте nsec. Наслідок: залежно від клієнта, форма може вас попередити (хорошим клієнтам перевіряють префікс та відхиляють nsec в публічних полях). Поганих клієнтів можуть опублікувати nsec там, де його бути не повинно. Завжди перевіряйте трьохлітерний префікс перед вставленням.

Помилка 2: публікування вашого nsec в соціальних мережах як демонстрація.

Кожного року новий користувач публікує скріншот своїх "деталей акаунту Nostr", який включає обидві строки. Наслідок: кожен, хто побачить скріншот, тепер може підписувати події від цього користувача, поки він не зрозуміє, що сталося, і не обертається. Виправлення полягає в тому, щоб ділити лише npub половину.

Помилка 3: збереження nsec в хмарних нотатках "тимчасово".

Сценарій: ви генеруєте пару ключів, хочете скопіювати її на другий пристрій та вставляєте nsec в iCloud Notes або чернетку Gmail, щоб перенести його між пристроями. Наслідок: цей провайдер тепер володіє вашим nsec у формі, яку вони можуть читати. Порушення цього провайдера — це порушення вашої ідентичності Nostr. Використовуйте менеджер паролів з наскрізним шифруванням або (для одноразового передання) QR-код, який ви сканіруєте між пристроями, не зберігаючи в синхронізованій з хманою місцеположенні.

Помилка 4: вставлення nsec в форму логіну веб-сайту.

Сценарій: новий веб-додаток Nostr просить ваш nsec, щоб "вас увійти". Наслідок: цей веб-сайт тепер постійно має ваш nsec, навіть після того, як ви закриєте вкладку. Ніколи це не робіть. Авторитетні веб-клієнти використовують замість цього розширення браузера NIP-07; розширення утримує nsec та підписує лише за запитом, ніколи не розкриваючи сирий секрет веб-сторінці.

Трюк з контрольною сумою Bech32

Як npub, так і nsec використовують кодування Bech32, яке включає вбудовану контрольну суму для виявлення помилок. Якщо ви змінюєте один символ npub або nsec, контрольна сума не збігається, і будь-яке відповідне обладнання відхиляє строку як недійсну.

Це корисно на практиці: якщо ви копіюєте та вставляєте ключ і символ опускається або замінюється, отримане обладнання відразу вам це скаже, а не мовчки прийме іншу (схожу на дійсну) ідентичність.

Hex-кодовані ключі не мають цієї властивості. Один неправильний символ в hex-ключі створює інший, але "дійсний" ключ, який вказує на зовсім іншу ідентичність. Завжди надавайте перевагу формі Bech32 (npub/nsec) при вставленні ключів між системами.

Як перевірити, який з них ви розглядаєте

Перші чотири символи. Це вся перевірка.

• Починається з npub1: безпечно ділити, це публічна половина.
• Починається з nsec1: не ділити в жодному разі, це секретна половина.
• Починається з note1: це ID事件 (для певного допису), не ключ.
• Починається з nprofile1: це публічний ключ, розділений з рекомендованими relay.
• Починається з nevent1: це ID события, розділене з автором та relay.
• Починається з naddr1: це адреса довгої статті.

Корисне ментальне правило: будь-яка строка Bech32, що починається з nsec, залишається на вашому пристрої. Все інше (npub, note, nprofile, nevent, naddr) призначено для поділу.

Конкретний ритуал безпеки

У момент, коли ви генеруєте нову ідентичність Nostr, зробіть це:

1. Відкрийте свій менеджер паролів.
2. Створіть новий запис з написом "Nostr nsec [назва акаунту]".
3. Вставте nsec в поле пароля.
4. Збережіть.
5. Закрийте додаток.

Загальний час: 30 секунд. Альтернатива: надрукуйте nsec на аркуші паперу надійним принтером і зберігайте папір там, де ви його не втратите. П'ять хвилин.

Тепер у вас є шлях відновлення. nsec знаходиться в місці, зашифрованому за вашим головним паролем або повністю в автономному режимі. Якщо ви втратите свій телефон, ви можете увійти на новий, вставивши nsec назад. Якщо ви втратите свій ноутбук, те саме.

Єдиний місце, де люди опиняються: вони генеруються ключи на своєму телефоні, nsec знаходиться в ланцюзі ключів, "я це зберегу пізніше". Пізніше ніколи не приходить. Потім вони витирають телефон, оновлюють або втрачають його, і ідентичність зникає. Резервна копія — це єдиний крок, який це запобігає, і вона займає менше часу, ніж читання цього абзацу.