Nostr 키 설명: 두 개의 문자열로 표현되는 디지털 정체성

당신의 Nostr 계정은 사용자 이름과 비밀번호 조합이 아닙니다. 당신이 직접 보유하는 암호화 키 쌍입니다. 하나는 공개이고 하나는 개인입니다. 당신이 작성하는 모든 게시물은 개인 키로 서명되며, 당신의 게시물을 보는 모든 클라이언트는 당신의 공개 키에 대한 서명을 검증합니다.

이것은 Nostr에 대해 이해해야 할 가장 중요한 것입니다. 왜냐하면 그것이 다른 모든 것을 형성하기 때문입니다. 어떤 회사도 복사본을 가지지 않았기 때문에 당신의 정체성을 잃으면 복구할 수 없습니다. 당신의 계정을 제거할 플랫폼 데이터베이스가 없기 때문에 플랫폼에서 금지할 수 없습니다. 이것들은 다른 각도에서 본 동일한 속성입니다.

이 가이드는 키가 무엇인지, 각각이 어떻게 작동하는지, 어떻게 인코딩되는지, 그리고 그들을 잃게 하는 구체적인 실수가 무엇인지 설명합니다.

TL;DR. 당신의 npub1...은 공개 키입니다. 어디서나 공유해도 안전합니다. 당신의 nsec1...은 개인 키입니다. 비밀번호 관리자 또는 안전한 장소에 있는 인쇄된 종이에 보관하세요. 절대로 웹사이트 양식에 붙여넣지 마세요. 잃어버리면 정체성은 영구적으로 사라집니다.

준비되면, @nostr.blog 주소 받기 →

키 쌍이 실제로 무엇인가

키 쌍은 수학적으로 연결된 두 숫자입니다. 수학은 secp256k1이라는 곡선에 대한 타원곡선 암호화입니다(Bitcoin이 사용하는 동일한 곡선).

• 개인 키는 무작위 32바이트 숫자입니다. 모든 256비트 무작위 숫자가 작동합니다. 당신 것에 특별한 점은 없습니다.
• 공개 키는 타원곡선에 대한 특정 계산을 통해 개인 키에서 파생됩니다. 개인 키가 주어지면 공개 키를 계산하는 것은 빠릅니다. 공개 키가 주어지면 개인 키를 다시 계산하는 것은 사실상 불가능한 것으로 믿어집니다.

여기서 "사실상 불가능"은 다음을 의미합니다. 존재하거나 합리적으로 존재할 것으로 예상되는 컴퓨터에서는 어떤 알려진 알고리즘도 합리적인 시간 내에 이를 수행할 수 없습니다. 보안은 이러한 비대칭성에 기반합니다. 공개 키는 자유롭게 게시하고, 개인 키는 절대적으로 보호합니다.

각 키의 기능

공개 키는 당신의 정체성입니다. 누군가 당신을 팔로우할 때, 그들은 공개 키를 팔로우합니다. 누군가 당신을 언급할 때, 그들은 공개 키를 태그합니다. relay가 당신의 게시물을 저장할 때, 공개 키로 인덱싱합니다. 네트워크상의 당신에 대한 보이는 모든 것은 이 하나의 값에 고정되어 있습니다.

개인 키는 서명합니다. 모든 이벤트(게시물, 반응, 팔로우 목록 업데이트, 프로필 변경)는 이벤트의 해시와 개인 키에서 생성된 Schnorr 서명을 포함합니다. 모든 클라이언트는 역 검사를 실행할 수 있습니다. 공개 키, 해시 및 서명이 주어지면, 일치하는 개인 키의 보유자만이 해당 서명을 생성할 수 있음을 검증합니다.

결과적으로: relay와 클라이언트는 누구를 믿을 필요가 없습니다. 그들은 서명을 스스로 검증합니다. 잘못된 서명이 있는 위조된 게시물은 조용히 삭제됩니다. 올바른 키로 서명된 실제 게시물은 어떤 relay가 제공했는지에 관계없이 수락됩니다.

키가 어떻게 인코딩되는가

원시 32바이트 숫자는 보거나 입력하기가 불편합니다. Nostr은 두 가지 인코딩 규칙을 사용합니다.

16진수. 원시 바이트를 소문자 16진수로 표기합니다: 64자, a-f 및 0-9. 이는 NIP-05 JSON 파일과 대부분의 프로토콜 내부에 나타나는 정규 형식입니다.

16진수 공개 키 예제: 0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88

Bech32. 접두사와 체크섬이 있는 인간 친화적인 형식으로 래핑된 동일한 바이트입니다. 접두사는 사람(및 소프트웨어)에게 그들이 무엇을 보고 있는지 알려줍니다. npub1은 "이것은 Nostr 공개 키입니다"를 의미합니다. nsec1은 "이것은 Nostr 개인 키입니다"를 의미합니다.

Bech32의 공개 키 예제: npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

Bech32의 체크섬은 중요합니다. 실수로 한 글자를 변경하면 체크섬이 실패하고 모든 도구가 키를 유효하지 않은 것으로 거부합니다. 이는 복사-붙여넣기 중 자동 손상을 방지합니다. 16진수는 그러한 안전 장치가 없습니다. 16진수 키에서 한 글자를 잘못 입력하면 다른(하지만 유효해 보이는) 정체성을 생성합니다.

다른 종류의 Nostr 데이터에도 접두사가 있습니다. note1은 이벤트 ID입니다. nprofile1은 권장 relay와 함께 번들된 공개 키입니다. nevent1은 작성자 및 relay와 함께 번들된 이벤트 ID입니다. 1은 버전 번호가 아니라 Bech32 구분 기호의 일부입니다.

키가 어디에 있는가

당신이 처음으로 Nostr 클라이언트를 설치할 때, 운영 체제에 32개의 무작위 바이트를 요청하여 키 쌍을 생성합니다. 그것이 전부입니다. 키는 난수 생성기가 작업을 마치는 순간 당신의 것입니다.

클라이언트가 보관하는 위치는 앱에 따라 다릅니다:

• 네이티브 모바일 앱은 OS 키체인(iOS Keychain, Android Keystore)에 nsec을 저장합니다. 둘 다 기기의 암호 또는 생체 인식으로 암호화됩니다.
• 브라우저 기반 클라이언트는 일반적으로 NIP-07 확장(nos2x, Alby, Flamingo) 설치를 요청하며, 이는 확장의 보안 저장소에 nsec을 보유합니다. 클라이언트는 nsec을 직접 보지 못합니다. 요청 시 이벤트에 서명하도록 확장을 요청합니다.
• NIP-07을 건너뛰는 클라이언트는 nsec을 로컬 브라우저 저장소에 붙여넣을 것을 요청하며, 이는 덜 안전합니다. 이것은 낮은 위험 계정에는 괜찮고 귀중한 계정에는 나쁜 생각입니다.
• 하드웨어 지갑 스타일 Nostr 서명자(bunker 앱, 원격 서명자)는 nsec을 별도 기기에 보유하고 암호화된 채널을 통해 원격으로 서명합니다. 가장 고급이고 가장 낮은 공격 표면입니다.

nsec을 백업하는 방법

가장 중요한 백업 규칙: nsec은 최소한 두 곳에 존재해야 하지만 제공자가 읽을 수 있는 클라우드에는 절대로 없어야 합니다.

좋은 위치:

• 1Password, Bitwarden, KeePassXC 또는 end-to-end 암호화가 있는 모든 비밀번호 관리자
• iCloud Keychain(end-to-end 암호화됨; Apple은 읽을 수 없음)
• 안전한 물리적 위치에 있는 인쇄된 종이 조각(금고, 안전 보증금 상자)
• 물리적 내구성을 원하는 경우 Bitcoin 스타일 스틸 백업 플레이트

나쁜 위치:

• iCloud Notes, Google Keep, Evernote, OneNote(이들은 제공자가 복호화할 수 있는 형식으로 동기화됨)
• 카메라 롤의 스크린샷(일반 텍스트로 iCloud 또는 Google Photos에 자동 백업됨)
• 자신에게 이메일 보내기
• Telegram "저장된 메시지" 또는 다른 채팅 앱 자체 DM
• Dropbox, Google Drive, iCloud Drive의 일반 텍스트 파일

구분은 다음과 같습니다: 제공자가 원한다면 텍스트를 읽을 수 있는가? 그렇다면 위치는 안전하지 않습니다. 그렇지 않다면(또는 제공자가 프린터를 가진 당신이라면) 위치는 안전합니다.

편집증 사용자를 위한 팁: 샤딩. 임계값 스킴(Shamir의 비밀 공유)을 사용하여 nsec을 여러 조각으로 분할하고 각 조각을 별도로 저장합니다. 3개 중 2개 조각이 키를 복구합니다. 대부분의 사용자에게는 과도하고, 높은 가치의 정체성을 가진 사용자에게는 합리적입니다.

nsec을 잃으면 어떻게 됩니까

계정은 영구적으로 사라집니다. 리셋 흐름이 없습니다. 어떤 회사도 복사본을 가지고 있습니다. 어떤 암호화 기법도 npub만으로 키를 복구할 수 없습니다.

손실은 세 가지 실질적인 결과를 초래합니다:

• 당신은 더 이상 해당 정체성에서 게시물을 작성할 수 없습니다.
• 당신은 더 이상 해당 정체성에 zap을 받을 수 없습니다(해당 정체성을 가리키는 Lightning 주소는 여전히 이전 프로필 이벤트에 있지만 프로필을 업데이트할 수 없으므로 기본 서비스가 변경되면 주소가 만료될 수 있습니다).
• 팔로우 목록, 프로필을 업데이트하거나 직접 메시지에 응답할 수 없습니다.

당신의 게시물은 relay에 남아 있으며 누구나 읽을 수 있습니다. 당신의 팔로워는 여전히 클라이언트에서 이전 게시물을 봅니다. 새로운 활동은 불가능합니다.

실용적인 대응: 새 키 쌍을 생성하고 이전 npub를 "마이그레이션" 설명과 함께 시청하는 모든 사람을 위해 게시한 후 재구축합니다. 당신을 따라가고 싶은 사람들은 그렇게 할 것입니다. 일부는 손실되고 다른 일부는 다시 얻을 것입니다. 아직 이것을 마찰 없이 만드는 프로토콜 수준의 방법은 없습니다.

누군가가 당신의 nsec을 얻으면 어떻게 됩니까

공격자는 당신이 할 수 있는 모든 것을 할 수 있습니다:

• 당신의 정체성으로 게시(영구적으로)
• 암호화되지 않은 직접 메시지 읽기
• 프로필 업데이트(NIP-05 식별자 변경 포함)
• 클라이언트에 접근할 수 있는 모든 지갑 잔액을 사용하여 zap 보내기
• 팔로우 목록 변경

추가 접근 없이 할 수 없는 것:

• 클라이언트와 페어링되지 않은 Lightning 지갑을 직접 비우기
• 당신에게 보낸 zap 도용(그것들은 구성된 Lightning 주소로 이동함)
• 당신이 또한 키를 사용하는 것을 방지(당신은 여전히 가지고 있습니다. 이는 무효화되는 인증 토큰이 아닙니다)

의심되는 nsec 손상에 대한 즉각적인 대응은 어렵습니다. 비밀번호와 달리 nostr nsec은 취소될 수 없습니다. 현실적인 완화는 새로운 키 쌍을 생성하고, 이전 것에서 게시하여 모든 사람에게 회전 경고를 하고, 정체성을 전환하는 것입니다. NIP-41 및 유사한 제안은 이를 더 깔끔하게 하기를 원하지만 아직 보편적으로 지원되지 않습니다.

여러 정체성

많은 Nostr 사용자가 하나 이상의 정체성을 운영합니다. 공개 전문 계정, 개인 개인 계정, 특정 커뮤니티용 익명 계정. 각각은 별도의 키 쌍입니다. 교차 게시하여 명시적으로 링크하지 않는 한 아무것도 그들을 암호화로 연결하지 않습니다.

대부분의 클라이언트는 메뉴에서 정체성 간 전환을 지원합니다. 키는 독립적입니다. 같은 클라이언트가 모두에 로그인할 수 있고 탭으로 전환합니다. 이것은 정체성이 동일한 플랫폼의 데이터베이스 항목인 Twitter 멀티 계정과 다릅니다. Nostr에서 그들은 암호화로 무관합니다.

한 가지 실질적인 팁: 비밀번호 관리자 항목을 명확하게 레이블 지정합니다. nostr-main-nsec, nostr-anon-nsec, nostr-work-nsec. 복사-붙여넣기 중에 섞이는 것은 실수로 잘못된 정체성에서 게시하는 방법입니다.

키는 계정입니다

Nostr의 다른 모든 것(읽을 수 있는 이름, 프로필 사진, 약력, 당신이 사용하는 relay, NIP-05 식별자)은 보조 메타데이터입니다. 모두 대체되거나 이동할 수 있습니다. 키 쌍은 다시 시작하지 않고 대체할 수 없는 유일한 것입니다.

따라서 nsec을 취급합니다. 백업하는 데는 2분이 걸립니다. 잃어버린 nsec으로부터 복구하려면 몇 주가 걸리며 완전히 작동하지 않습니다.

세대에 대한 참고. 새 키 쌍을 얻는 안전한 방법은 클라이언트가 로컬로 생성하고 개인 부분을 네트워크를 통해 절대로 전송하지 않도록 허용하는 것입니다. nostr.blog의 가입은 브라우저에서 클라이언트 측에서 이를 수행합니다. 서버는 nsec을 보지 않습니다. 개인 키를 먼저 서버로 보내는 가입 흐름이 있다면 그것은 위험 신호입니다. 멀리 떠나 다른 곳에서 생성합니다.