Chaves Nostr explicadas: sua identidade digital em duas strings

Sua conta Nostr não é uma combinação de nome de usuário e senha. É um par de chaves criptográficas, uma pública e uma privada, que você mantém você mesmo. Cada post que você faz é assinado com a chave privada; cada cliente que vê seu post verifica a assinatura contra sua chave pública.

Esta é a coisa mais importante a entender sobre Nostr, porque molda tudo o mais. Sua identidade não pode ser recuperada se você a perder, porque nenhuma empresa jamais teve uma cópia. Sua conta não pode ser banida por uma plataforma, porque não existe um banco de dados de plataforma para removê-la. Estas são a mesma propriedade vista de ângulos diferentes.

Este guia explica o que são as chaves, o que cada uma faz, como são codificadas e os erros específicos que as perdem.

TL;DR. Seu npub1... é sua chave pública. Seguro compartilhar em qualquer lugar. Seu nsec1... é sua chave privada. Mantenha-a em um gerenciador de senhas ou em um pedaço de papel impresso em um cofre. Nunca a cole em um formulário de website. Perca-a e a identidade desaparece permanentemente.

Quando estiver pronto, pegue seu endereço @nostr.blog →

O que um par de chaves realmente é

Um par de chaves é dois números que são matematicamente vinculados. A matemática é criptografia de curva elíptica em uma curva chamada secp256k1 (a mesma curva que Bitcoin usa).

• A chave privada é um número aleatório de 32 bytes. Qualquer número aleatório de 256 bits funciona; nada especial sobre a sua.
• A chave pública é derivada da chave privada por um cálculo específico na curva elíptica. Dada a chave privada, calcular a chave pública é rápido. Dada a chave pública, calcular a chave privada de volta é acreditado ser praticamente impossível.

"Praticamente impossível" aqui significa: não há algoritmo conhecido que possa fazer isso em um tempo razoável em qualquer computador que exista ou que plausivelmente existirá. A segurança repousa nesta assimetria. Você publica a chave pública livremente; você guarda a chave privada absolutamente.

O que cada chave faz

A chave pública é sua identidade. Quando alguém o segue, segue a chave pública. Quando alguém o menciona, marca a chave pública. Quando um relay armazena seus posts, os indexa pela chave pública. Tudo o que é visível sobre você na rede está atrelado a este valor único.

A chave privada assina. Cada evento (post, reação, atualização de lista de seguidos, mudança de perfil) carrega uma assinatura Schnorr produzida do hash do evento e da chave privada. Qualquer cliente pode executar a verificação reversa: dada a chave pública, o hash e a assinatura, verificar que apenas o detentor da chave privada correspondente poderia ter produzido essa assinatura.

O resultado: relays e clientes não têm que confiar em ninguém. Eles verificam assinaturas a si mesmos. Um post falsificado com uma assinatura inválida é descartado silenciosamente. Um post real assinado pela chave certa é aceito independentemente de qual relay o serviu.

Como as chaves são codificadas

Um número de 32 bytes bruto é inconveniente de olhar ou digitar. Nostr usa duas convenções de codificação.

Hex. Os bytes brutos escritos como hexadecimal minúsculo: 64 caracteres, a-f e 0-9. Esta é a forma canônica que aparece dentro de arquivos JSON NIP-05 e a maioria dos internals do protocolo.

Exemplo de chave pública em hex: 0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88

Bech32. Os mesmos bytes envolvidos em um formato orientado ao humano com um prefixo e uma soma de verificação. O prefixo diz aos humanos (e ao software) que tipo de coisa eles estão olhando. npub1 significa "isto é uma chave pública Nostr." nsec1 significa "isto é uma chave privada Nostr."

Exemplo de chave pública em Bech32: npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

A soma de verificação em Bech32 é importante. Se você acidentalmente mudar um caractere, a soma de verificação falha e qualquer ferramenta rejeita a chave como inválida. Isso evita corrupção silenciosa durante cópia-cola. Hex não tem tal segurança; um único caractere errado em uma chave hex produzirá uma identidade diferente (mas aparentemente válida).

Prefixos existem para outros tipos de dados Nostr também. note1 é um ID de evento. nprofile1 é uma chave pública agrupada com relays recomendados. nevent1 é um ID de evento agrupado com autor e relays. O 1 é parte do separador Bech32, não um número de versão.

Onde as chaves vivem

Quando você instala qualquer cliente Nostr pela primeira vez, ele gera um par de chaves pedindo ao sistema operacional 32 bytes aleatórios. Essa é toda a cerimônia. As chaves são suas no momento em que o gerador de números aleatórios termina.

Onde o cliente as armazena depende do app:

• Aplicativos nativos móveis armazenam o nsec no chaveiro do SO (iOS Keychain, Android Keystore). Ambos são criptografados em repouso com a senha ou biometria do dispositivo.
• Clientes baseados em navegador geralmente pedem que você instale uma extensão NIP-07 (nos2x, Alby, Flamingo) que mantém o nsec no armazenamento seguro da extensão. O cliente nunca vê o nsec diretamente; pede à extensão para assinar eventos sob demanda.
• Clientes que pulam NIP-07 pedirão que você cole o nsec no armazenamento local do navegador, que é menos seguro. Isto é tudo bem para contas baixas e uma má ideia para as valiosas.
• Signers Nostr de estilo carteira de hardware (bunker apps, signers remotos) mantêm o nsec em um dispositivo separado e assinam remotamente sobre um canal criptografado. Mais avançado, menor superfície de ataque.

Como fazer backup do nsec

A regra de backup mais importante: o nsec deve existir em pelo menos dois lugares, mas nunca em uma nuvem que o provedor possa ler.

Bons lugares:

• 1Password, Bitwarden, KeePassXC, ou qualquer gerenciador de senhas com criptografia ponta a ponta
• iCloud Keychain (criptografia ponta a ponta; Apple não pode ler)
• Um pedaço de papel impresso em um local seguro (um cofre, uma caixa de depósito de segurança)
• Uma placa de backup de aço ao estilo Bitcoin, se você quiser durabilidade física

Maus lugares:

• iCloud Notes, Google Keep, Evernote, OneNote (estes sincronizam em formatos que o provedor pode descriptografar)
• Uma captura de tela no rolo de câmera (backup automático para iCloud ou Google Photos em texto simples)
• Email para você mesmo
• Telegram "Mensagens Salvas" ou qualquer outro auto-DM de aplicativo de chat
• Um arquivo de texto simples no Dropbox, Google Drive, iCloud Drive

A distinção é: o provedor pode, se quisesse, ler o texto? Se sim, o local é inseguro. Se não (ou o provedor é você com uma impressora), o local é seguro.

Para os paranóicos: fragmentação. Divida o nsec em múltiplas peças usando um esquema de limite (Shamir's Secret Sharing) e armazene cada peça separadamente. Duas de três peças reconstroem a chave. Exagerado para a maioria dos usuários, sensato para usuários com uma identidade de alto valor.

O que acontece se você perder o nsec

A conta desaparece permanentemente. Não há fluxo de redefinição. Nenhuma empresa tem uma cópia. Nenhum truque criptográfico pode recuperar a chave apenas do npub.

A perda tem três consequências práticas:

• Você não pode mais postar dessa identidade.
• Você não pode mais receber zaps para essa identidade (o endereço Lightning apontado para ela ainda está em seu antigo evento de perfil, mas como você não pode atualizar seu perfil, o endereço pode se tornar obsoleto se o serviço subjacente mudar).
• Você não pode atualizar sua lista de seguidos, seu perfil ou responder a mensagens diretas.

Seus posts permanecem em relays, legíveis por qualquer um. Seus seguidores ainda veem os posts antigos em seus clientes. Nenhuma atividade nova é possível.

A resposta pragmática: gere um novo par de chaves, poste seu antigo npub com uma explicação de "migração" para qualquer um observando, e reconstrua. Pessoas que querem segui-lo através da quebra farão isso; você perderá alguns e reganhará outros. Ainda não há maneira de nível de protocolo para tornar isso sem atrito.

O que acontece se alguém conseguir seu nsec

O atacante pode fazer tudo o que você poderia fazer:

• Postar sob sua identidade (para sempre)
• Ler suas mensagens diretas descriptografadas
• Atualizar seu perfil (incluindo mudar seu identificador NIP-05)
• Enviar zaps usando qualquer saldo de carteira acessível ao seu cliente
• Mudar sua lista de seguidos

O que eles não podem fazer sem acesso adicional:

• Drenar diretamente uma carteira Lightning que não está emparelhada com o cliente
• Roubar zaps enviados para você (aqueles vão para seu endereço Lightning configurado)
• Impedi-lo de também usar a chave (você ainda a tem; este não é um token de autenticação que fica inválido)

A resposta imediata ao comprometimento suspeito de nsec é difícil. Diferentemente de uma senha, nsecs nostr não podem ser revogados. A mitigação realista é gerar um novo par de chaves, postar do antigo para avisar todos que você está rotacionando e mudar de identidades. NIP-41 e propostas semelhantes visam tornar isso mais limpo, mas ainda não são universalmente suportadas.

Múltiplas identidades

Muitos usuários Nostr executam mais de uma identidade. Uma conta profissional voltada para o público, uma conta pessoal privada, uma conta anônima para comunidades específicas. Cada uma é um par de chaves separado; nada as vincula criptograficamente a menos que você escolha vinculá-las por cross-posting.

A maioria dos clientes suporta alternar entre identidades de um menu. As chaves são independentes; o mesmo cliente pode estar conectado a todas elas e alternar com um toque. Isto é diferente de multi-conta do Twitter, onde as identidades são entradas no banco de dados da mesma plataforma; em Nostr elas são criptograficamente não relacionadas.

Uma dica prática: rotule as entradas do gerenciador de senhas claramente. nostr-main-nsec, nostr-anon-nsec, nostr-work-nsec. Misturá-los durante uma cópia-cola é uma forma de acidentalmente postar de uma identidade errada.

As chaves são a conta

Tudo mais em Nostr (o nome legível, a foto de perfil, a bio, os relays que você usa, o identificador NIP-05) é metadados secundários. Tudo pode ser substituído ou movido. O par de chaves é a única coisa que não pode ser substituída sem começar novamente.

Trate o nsec de acordo. Fazer backup dele leva dois minutos no momento em que você o gera. Recuperar-se de um nsec perdido leva semanas de reconstrução e nunca funciona bem.

Uma nota sobre geração. A forma segura de obter um novo par de chaves é deixar um cliente gerá-lo localmente e nunca transmitir a metade privada pela rede. O signup de nostr.blog faz isso do lado do cliente no navegador; o servidor nunca vê o nsec. Se algum fluxo de signup enviar a chave privada para um servidor primeiro, isso é uma bandeira vermelha. Saia e gere em outro lugar.