### **Às vezes a desatualização é preferível**
Lembro de uma vez que houve uma ameaça em um pacote do Linux que vinha para Ubuntu e todos os que atualizaram a última versão estavam vulneráveis, nesse caso era desejável permanecer na versão antiga e seria ideal que aqueles que haviam atualizado, desatualizassem a versão.
No contexto no qual estou escrevendo essa nota, não é este o caso.
A versão mais recente do OpenKeychain, atualmente 60400, tem um detalhe que me incomodou desde o início: substituiu o algoritmo de checagem SHA512, que existia na versão anterior, pelo SHA256, um tipo de afrouxamento da segurança, talvez pensando em consumir menos recursos computacionais. Quando descobri isso, deixei minha observação no GitHub imediatamente e fui sistematicamente ignorado.
Tentei fazer a desatualização e não consegui, porque usando compartimentalização, que dá para usar o mesmo app em outros compartimentos, desinstalar o app em um deles e deixar instalado em outro impede que uma versão diferente seja instalada, por isso não consegui e achava que era impossível fazer.
Hoje, depois de uma ajudinha de uma inteligência artificial para fazer uma pesquisa aprofundada, descobri que a versão anterior não possui vulnerabilidades relatadas e que a versão vigente só corrigiu bugs reportados que não impactavam a segurança e implementou o recurso adcional de geração de outros tipos de chaves, por exemplo as chaves NIST. Isso parece significar que a versão antiga, 58902, é tão segura quanto a recente.
Em suma, fiz a troca e estou muito satisfeito. Se você usa a versão mais recente, não está vulnerável por usar SHA256, é um algoritmo muito robusto para assinaturas, as criptomoedas e até o NOSTR usa-o, mas o SHA512 é superior, mesmo que pareça ser supérfluo, para mim significa tornar o uso da chave um pouquinho mais seguro é positivo para mim.
Lembrando que a recomendação é deixar sempre os softwares atualizados, via de regra. Principalmente aqueles que se conectam à internet e que também não é recomendável atualizar assim que sai uma versão nova, esperar 24 horas é sábio, a menos que haja uma correção de problema severo de segurança. Usar apps desatualizados pode ser perigoso, se optar por isso, faça uma pesquisa antes e procura saber sobre vulnerabilidades corrigidas em versões mais recentes.
#pgp #gpg #chaves #downdate #desatualização #privacidade #segurança #algoritmos #sha512 #sha256 #hash #checagem #checksum #brasil
?
npub1fju6jer23vcxmhjnavezr8w4mxwmrccpyd4r762682pctk606taqz82xge
npub1fju6...2xge
Notes (12)
Frustrante mexer com corretoras.
Perdi o equivalente a 7644 sats, que eu receberia pela troca de BRZs, mas acabei enviando os BRZs para a Coinbase.
Curioso é que a Coinbase é dona da blockchain usada para receber os tokens e não listou o token da sua própria rede, e não é qualquer token, é a maior stablecoin do mundo cripto não lastreada em dólar.
Acho que corretoras amam quando isso acontece e não fazem nada para ajudar as pessoas que estão passando por esses problemas nem desenvolver ferramentas para que facilitam isso, pois essa é uma das formas de lucrar!
### **Crie nsecs com SHA-256 ou SHA3-256**
Como mencionado anteriormente, alguns clients NOSTR aceitam formatos HEX (hexadecimais) de qualquer chave de criptomoedas para convertê-los em nsecs.
Também é verdadeiro que qualquer soma de checagem de 32 bytes pode ser transformado em uma nsec. Ou seja, você pode criar uma nsec personalizada com uma frase memorizável sendo somada para checagem em SHA-256.
Por exemplo, a frase padrão do aplicativo web "Cryptii" é "The quick brown fox jumps over the lazy dog.", sua soma de checagem SHA-256 é "ef537f25c895bfa782526529a9b63d97aa631564d5d789c2b765448c8635fb6c" e a nsec que ela produziu é "nsec1aafh7fwgjkl60qjjv556nd3aj74xx9ty6htcns4hv4zgep34ldkqv30r88" e a npub é "npub1rfzaedxlh9te3m7s840y0huznml4enx6u3ekzmdtm3frcjqwmrkqawnkpf".
Obviamente esse método é menos seguro que usar a HEX de uma chave privada de semente, mas pode ser uma solução para quem não deseja perder a sua nsec jamais.
Outro método, é usar a soma de checagem de um arquivo, cuidado ao usar fotos, elas podem perder metadados em algum momento e gerar uma soma diferente.
Pensando aqui: sempre que usamos SHA-256 (ou SHA3-256),pode servir para gerar um nsec, ou endereço de Bitcoin ou outra criptomoeda (EVM, Solana, etc). Isso é interessante e assustador ao mesmo tempo, embora saiba que existem decilhões de endereços, espero nunca ter copiado o hex do endereço de ninguém.
### **Derive nsecs de uma semente e só gere nsecs aleatoriamente se quiser**
Isso mesmo, se for a tua vontade, nunca mais se preocupe em guardar sua nsec, ncrypt e ter o risco de perdê-las ou esquecer a senha da ncrypt. Basta ter em mãos tua semente de doze ou vinte e quatro palavras e nem precisa ser a mesma que você holda seus satoshinhos.
Quem acompanha minhas notas, deve se lembrar da minha dica para uma brain wallet segura usando texto memorizável e as ideias de uma seed permanente e suas infinitas possibilidades. Você pode escolher um caminho de derivação próprio para tuas identidades NOSTR.
De um modo simples, você pode usar uma semente e capturar a chave privada em formato hexadecimal para usar como nsec, clients como Amber ou Amethyst transformam automaticamente em nsec. Pode ser a chave privada daquele endereço bitcoin usado que já foi substituído por outro. Ao colar no client NOSTR compatível com HEX e exportar a nsec depois.
Com ferramentas offline como "ian coleman" ou "BIP39 Flip-Coin Seed", você tem opções mais avançadas, pode editar o caminho de derivação da tua seed que, normalmente, é m/84'/0'/0'/?/? onde m é a raiz, 84 é o código do tipo de endereço (no caso BIP84 é native segwit), o primeiro 0 é referência ao tipo de moeda (0 é BTC, 60 é ETH, mas o campo aceita números de qualquer tamanho), o segundo 0 é o número de contas 0 é a conta padrão que as pessoas geram endereços para uso pessoal, a documentação sugere outro número para uso profissional, e o número pode ser pequeno ou gigantesco, não há limites), o primeiro ? é o tipo de endereço (recebimento ou troco?), o último ? é o número do endereço.
Para achar um número para o tipo de moeda, que não é Bitcoin (0), mas pode usar os números correspondentes às letras do alfabeto para NOSTR:
N: 14
O: 15
S: 19
T: 20
R: 18
m/84'/1415192018'/0'/?/?
Agora você tem uma forma diferente de derivação na mesma seed de forma personalizada e segura, especialmente se modificar a número da conta também.
Como o número de endereços com suas respectivas chaves HEX são muitíssimos, há possibilidade de criar muitas nsecs.
Por isso é bom usar clients diferentes, não sei qual é a do relé roxo, que não recebe minhas notas nem sem prova de trabalho.
Primeiramente vou desabilitar a prova de trabalho nas notas porque são inúteis e até parecem atrapalhar a propagação em alguns relés.
Afinal, todos os relés nos quais estão inscrito não tem suporte à prova de trabalho e não sei porque cargas d'águas habilitei essa joça.
Alguns relés voltam uma notificação de erro no recebimento da nota por causa da prova de trabalho, deve ser a demora característica em "minerar" zerinhos.
Tantas coisas para escrever que não sei nem por onde começar...
Mas como cantava Arnaldo Antunes: "Uma coisa de cada vez".
Tantas coisas para escrever que não sei nem por onde começar...
Mas como cantava Arnaldo Antunes: "Uma coisa de cada vez".
Engraçado é que o Samiz fez o Amethyst se conectar com a clearnet, pois o Orbot está desativado e, em tese, ele deveria se conectar exclusivamente com o Orbot ligado ou somente pelo Bluetooth.
Testando o Samiz.
Shabat shalom!
### **CARLOS SANTANA & DIDO**
**Feels like fire**
https://wim.nl.tab.digital/s/HPfj9HwpqMx6Xs9/download/Feels%20Like%20Fire%20%28feat.%20Dido%29.mp3
#music #rock #pop #carlossantana #santana #dido #música #2000s