Ключі Nostr пояснено: ваша цифрова ідентичність у двох рядках

Ваш акаунт Nostr — це не комбінація імені користувача та пароля. Це пара криптографічних ключів, один публічний та один приватний, які ви утримуєте самі. Кожен пост, який ви робите, підписаний приватним ключем; кожен клієнт, який бачить ваш пост, перевіряє підпис щодо вашого публічного ключа.

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

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

TL;DR. Ваш npub1... — це ваш публічний ключ. Безпечно ділитися скрізь. Ваш nsec1... — це ваш приватний ключ. Зберігайте його у менеджері паролів або надрукованому папері в сейфі. Ніколи не вставляйте його у форму веб-сайту. Втратьте його — і ідентичність безповоротно втрачена.

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

Що насправді являє собою пара ключів

Пара ключів — це два числа, які математично пов'язані. Математика — це еліптична крива криптографія на кривій, що називається secp256k1 (та ж крива, яку використовує Bitcoin).

• Приватний ключ — це випадкове число з 32 байтів. Будь-яке 256-бітне випадкове число працює; у вашому немає нічого особливого.
• Публічний ключ походить від приватного ключа через специфічне обчислення на еліптичній кривій. Маючи приватний ключ, обчислення публічного ключа швидке. Маючи публічний ключ, обчислення приватного ключа назад вважається практично неможливим.

"Практично неможливо" означає: не існує відомого алгоритму, який міг би зробити це за розумний час на будь-якому комп'ютері, який існує або який, ймовірно, існуватиме. Безпека спирається на цю асиметрію. Ви публікуєте публічний ключ вільно; ви абсолютно охороняєте приватний ключ.

Що робить кожен ключ

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

Приватний ключ підписує. Кожна подія (пост, реакція, оновлення списку підписок, зміна профілю) містить Schnorr підпис, створений з хеша події та приватного ключа. Будь-який клієнт може запустити зворотну перевірку: маючи публічний ключ, хеш та підпис, перевірити, що тільки власник відповідного приватного ключа міг би створити цей підпис.

Результат: relay та клієнти не повинні нікому довіряти. Вони самі перевіряють підписи. Підроблений пост з недійсним підписом мовчазно відпадає. Справжній пост, підписаний правильним ключем, приймається незалежно від того, який relay його подав.

Як кодуються ключі

Сире 32-байтне число незручно розглядати або вводити. Nostr використовує дві конвенції кодування.

Hex. Сирі байти написані як малі шістнадцяткові: 64 символи, a-f та 0-9. Це канонічна форма, яка відображається всередині файлів JSON NIP-05 та більшості внутрішніх протоколів.

Приклад публічного ключа в hex: 0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88

Bech32. Ті ж байти, обгорнуті у зручний для людини формат із префіксом та контрольною сумою. Префікс говорить людям (та програмному забезпеченню), що вони розглядають. npub1 означає "це публічний ключ Nostr." nsec1 означає "це приватний ключ Nostr."

Приклад публічного ключа в Bech32: npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

Контрольна сума в Bech32 важлива. Якщо ви випадково змінити один символ, контрольна сума не пройде, і будь-який інструмент відкине ключ як неправильний. Це запобігає мовчазній корупції під час копіювання-вставлення. Hex не має такої безпеки; один неправильний символ у hex ключі створить іншу (але схожу на дійсну) ідентичність.

Префікси існують і для інших видів даних Nostr. note1 — це ID події. nprofile1 — це публічний ключ, об'єднаний з рекомендованими relay. nevent1 — це ID події, об'єднаний з автором та relay. 1 є частиною Bech32 роздільника, а не номером версії.

Де живуть ключі

Коли ви вперше встановлюєте будь-який клієнт Nostr, він генерує пару ключів, запитуючи в операційної системи 32 випадкові байти. Це вся церемонія. Ключі стають вашими в момент завершення генератора випадкових чисел.

Де клієнт їх зберігає, залежить від додатку:

• Власні мобільні додатки зберігають nsec в OS keychain (iOS Keychain, Android Keystore). Обидва зашифровані в стані спокою за допомогою пароля пристрою або біометричного коду.
• Веб-клієнти зазвичай просять вас встановити розширення NIP-07 (nos2x, Alby, Flamingo), яке тримає nsec у безпечному сховищі розширення. Клієнт ніколи не бачить nsec безпосередньо; він просить розширення підписати події за запитом.
• Клієнти, які пропускають NIP-07, попросять вас вставити nsec у локальне сховище браузера, що менш безпечно. Це нормально для акаунтів з низькою цінністю та погана ідея для цінних.
• Стилізовані під апаратний гаманець Nostr підписувачі (bunker додатки, віддалені підписувачі) утримують nsec на окремому пристрої та підписують віддалено через зашифрований канал. Найбільш просунуте, найменша поверхня атаки.

Як зробити резервну копію nsec

Єдине найважливіше правило резервного копіювання: nsec повинен існувати щонайменше в двох місцях, але ніколи в хмарі, яку провайдер може читати.

Хорошi місця:

• 1Password, Bitwarden, KeePassXC або будь-який менеджер паролів з наскрізним шифруванням
• iCloud Keychain (наскрізне шифрування; Apple не може його читати)
• Надрукований папір у безпечному фізичному місцезнаходженні (сейф, сейф депозит)
• Пластина для резервного копіювання у стилі Bitcoin, якщо вам потрібна фізична довговічність

Поганi місця:

• iCloud Notes, Google Keep, Evernote, OneNote (вони синхронізуються в форматах, які провайдер може розшифрувати)
• Скріншот у вашому рулоні камери (автоматично загруженно в iCloud або Google Photos у простому тексті)
• Електронна пошта собі
• Telegram "Збережені повідомлення" або будь-який інший самочат додатку
• Текстовий файл на Dropbox, Google Drive, iCloud Drive

Розрізнення: чи може провайдер, якщо захочуть, прочитати текст? Якщо так, місцезнаходження небезпечне. Якщо ні (або провайдер — це ви з принтером), місцезнаходження безпечне.

Для параноїків: sharding. Розділіть nsec на кілька частин за допомогою схеми порогу (Shamir's Secret Sharing) та зберігайте кожну частину окремо. Дві з трьох частин відновлюють ключ. Надмірно для більшості користувачів, розумно для користувачів з цінною ідентичністю.

Що трапляється, якщо ви втратите nsec

Акаунт безповоротно втрачений. Немає потоку скидання. Жодна компанія не має копії. Жодна криптографічна хитрість не може відновити ключ лише з npub.

Втрата має три практичні наслідки:

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

Ваші пости залишаються на relay, читаються будь-ким. Ваші послідовники все ще бачать старі пости у своїх клієнтах. Нова діяльність неможлива.

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

Що трапляється, якщо хтось отримає ваш nsec

Зловмисник може зробити все, що ви можете:

• Публікувати під вашою ідентичністю (назавжди)
• Читати ваші розшифровані прямі повідомлення
• Оновити ваш профіль (включаючи зміну вашого NIP-05 ідентифікатора)
• Надіслати zap з будь-якого балансу гаманця, доступного вашому клієнту
• Змінити ваш список підписок

Що вони не можуть зробити без додаткового доступу:

• Безпосередньо слити Lightning гаманець, який не спарений з клієнтом
• Украсти zap, відправлені вам (вони йдуть на вашу налаштовану Lightning адресу)
• Запобігти вам також використовувати ключ (ви його все ще маєте; це не маркер автентифікації, який стає недійсним)

Негайна відповідь на підозру на компрометацію nsec важка. На відміну від пароля, nsec nostr не можна відкликати. Реалістична пом'якшувача — це згенерувати нову пару ключів, опублікувати зі старої, щоб попередити всіх, що ви обертаєтеся, та переключитися на ідентичність. NIP-41 та подібні пропозиції спрямовані на те, щоб зробити це чистішим, але ще не універсально підтримуються.

Декілька ідентичностей

Багато користувачів Nostr керують більш ніж однією ідентичністю. Публічно звернена професійна облікова запис, приватна особистісна облікова запис, анонімна облікова запис для конкретних спільнот. Кожна — це окрема пара ключів; нічого їх криптографічно не пов'язує, якщо ви не вибираєте їх з'єднання шляхом перехресного публікування.

Більшість клієнтів підтримують переключення між ідентичностями з меню. Ключі незалежні; той же клієнт може бути залогований у всіх них та переключатися з дотиком. Це відрізняється від Twitter мультиакаунту, де ідентичності — це записи в базі даних однієї платформи; на Nostr вони криптографічно не пов'язані.

Один практичний совіт: чітко позначайте записи менеджера паролів. nostr-main-nsec, nostr-anon-nsec, nostr-work-nsec. Змішування їх під час копіювання-вставлення — це спосіб випадково публікувати з неправильної ідентичності.

Ключі — це облікова запис

Все інше в Nostr (читаєме ім'я, зображення профілю, біографія, relay, які ви використовуєте, ідентифікатор NIP-05) — це вторинні метадані. Все це можна замінити або перенести. Пара ключів — це єдине, що не може бути замінено без нового початку.

Відповідно розглядайте nsec. Резервне копіювання займає дві хвилини у момент генерування. Відновлення після втраченого nsec займає тижні перебудови та ніколи не працює цілком.

Примітка щодо генерування. Безпечний спосіб отримати нову пару ключів — дозволити клієнту генерувати її локально та ніколи не передавати приватну половину по мережі. Реєстрація nostr.blog робить це на стороні клієнта в браузері; сервер ніколи не бачить nsec. Якщо будь-який потік реєстрації відправляє приватний ключ на сервер спочатку, це червоний прапор. Відійдіть та генеруйте інде.