Além do armazenamento seguro, parte 2: implementando a criptografia de carteiras com segurança

A parte 1 de Além do armazenamento seguro examinou o uso indevido da capacidade de assinatura de um sistema de pagamentos. Esta segunda parte examina um caminho diferente para obter assinaturas não autorizadas: falhas na implementação criptográfica que permitem a um atacante recuperar uma chave privada e assinar de forma independente. A pergunta é: um atacante consegue reconstruir uma chave sem ler sua cópia protegida?

A seção 1 estabelece os requisitos de segurança para a geração, o armazenamento e o uso de chaves em assinaturas. As seções 2 e 3 examinam quatro incidentes de geração de chaves e dois incidentes de assinatura, explicando os erros de implementação e suas consequências. A seção 4 extrai desses casos princípios de projeto e implementação e, em seguida, explica como verificar as propriedades exigidas.

1. Propriedades de segurança ao longo do ciclo de vida da chave

Uma chave precisa ser gerada, armazenada e usada para assinar. Cada etapa tem um requisito de segurança diferente, como mostra o diagrama.

Em uma carteira determinística hierárquica que usa frases mnemônicas BIP-39 e derivação de chaves BIP-32, dados aleatórios criptograficamente seguros são codificados em uma frase mnemônica e convertidos em uma semente. Essa semente é usada para derivar chaves privadas, chaves públicas e endereços de carteira [1, 2].

Depois de geradas, as sementes e as chaves privadas precisam ser protegidas por criptografia ou isolamento em hardware. Na assinatura, a chave privada é então usada para produzir uma assinatura verificável publicamente. Dependendo do esquema, a assinatura também pode exigir um nonce aleatório gerado de forma segura ou derivado deterministicamente de material secreto.

Os requisitos de segurança variam entre essas etapas:

1. Imprevisibilidade na criação. Um atacante não pode ser capaz de prever nem de enumerar, de forma viável, o segredo que controla a carteira.
2. Confidencialidade no armazenamento. Partes não autorizadas não podem ser capazes de ler material secreto por meio de software, interfaces físicas, backups, logs ou serviços remotos.
3. Ausência de vazamento durante o uso. A assinatura não pode revelar informações suficientes para reconstruir o segredo, mesmo após muitas assinaturas publicamente observáveis.

Carteiras de hardware, elementos seguros e ambientes de execução confiáveis (TEEs) podem reforçar a confidencialidade. Sua presença, por si só, não garante as outras duas propriedades. Uma chave previsível continua previsível depois de ser colocada em armazenamento seguro; informações matemáticas expostas pelas assinaturas continuam disponíveis mesmo quando os bytes da chave privada estão isolados do sistema hospedeiro. Portanto, um atacante pode recuperar uma chave afetada e acessar os ativos que ela controla sem ler sua cópia armazenada.

As próximas duas seções examinam como as implementações violam esses requisitos: falhas na geração podem tornar as chaves previsíveis, enquanto falhas na assinatura podem permitir sua recuperação a partir de assinaturas públicas. Esses casos servem de base para os princípios de implementação e os objetivos de verificação da seção 4.

2. Geração de chaves falha: chaves privadas previsíveis

A geração de chaves precisa preservar a imprevisibilidade em todas as etapas. A fonte de entropia deve ser adequada para uso criptográfico, não deve ser viável enumerar seus estados, e as conversões de bytes aleatórios em uma semente ou chave privada devem preservar a incerteza pretendida. Uma meta de segurança de 128 bits exige um espaço de segredos que não possa ser reduzido a uma busca viável por falhas de implementação.

A tabela resume quatro maneiras pelas quais a geração pode perder essa propriedade: um gerador fraco de biblioteca, uma associação incorreta com o gerador de números aleatórios (RNG), uma conversão de entrada com perda de informação e um gerador com estado inicial limitado. Os valores de impacto vêm de relatórios que abrangem períodos diferentes; não são totais medidos na mesma data.

2,1 Ill Bloom: aleatoriedade fraca em uma dependência de carteiras

No incidente Ill Bloom, algumas carteiras de software geraram frases de recuperação BIP-39 usando versões vulneráveis de crypto-js. A função CryptoJS.lib.WordArray.random() da biblioteca usava um gerador Multiply-With-Carry (MWC) personalizado, inicializado com Math.random(), em vez de obter entropia de uma fonte criptograficamente segura. As carteiras que usavam essa função como fonte de entropia para fins de segurança herdavam as fraquezas do gerador, mesmo que as etapas posteriores de geração da frase mnemônica e derivação de chaves seguissem corretamente seus padrões [3].

A implementação vulnerável de crypto-js v3.1.9-1 [4] contém esta lógica característica:

  random: function (nBytes) {
      var words = [];

      var r = (function (m_w) {
          var m_w = m_w;
          var m_z = 0x3ade68b1;
          var mask = 0xffffffff;

          return function () {
              m_z = (0x9069 * (m_z & 0xFFFF) + (m_z >> 0x10)) & mask;
              m_w = (0x4650 * (m_w & 0xFFFF) + (m_w >> 0x10)) & mask;
              var result = ((m_z << 0x10) + m_w) & mask;
              result /= 0x100000000;
              result += 0.5;
              return result * (Math.random() > .5 ? 1 : -1);
          }
      });

      for (var i = 0, rcache; i < nBytes; i += 4) {
          var _r = r((rcache || Math.random()) * 0x100000000);

          rcache = _r() * 0x3ade67b7;
          words.push((_r() * 0x100000000) | 0);
      }

      return new WordArray.init(words, nBytes);
  }

Aqui, r() é o gerador personalizado baseado em MWC, enquanto Math.random() ajuda a inicializar ou influenciar seu estado. Esse gerador de números pseudoaleatórios (PRNG) produz bytes que parecem ter entropia comum, mas a implementação não oferecia imprevisibilidade criptográfica. Os espaços efetivos de candidatos eram de aproximadamente 2 USD^{39}$ para uma saída nominal de 128 bits e 2 USD^{47}$ para uma saída nominal de 256 bits [3].

Esses espaços menores tornaram viável reconstruir possíveis frases de recuperação, derivar os endereços de carteira correspondentes e compará-los com a atividade pública na blockchain. Assim, um segredo podia ser recuperado sem extrair nada do dispositivo de uma vítima. Seguir o padrão de frases mnemônicas não corrigia a aleatoriedade fraca herdada da dependência mais antiga.

2,2 Coldcard: um gerador de números aleatórios por hardware que o código não usava

A Coldcard mostra por que ter uma fonte segura de aleatoriedade não basta se a aplicação chama outro gerador. Embora o dispositivo tivesse um gerador de números aleatórios por hardware, um erro de integração durante a compilação fez com que rng_get(), no fluxo de geração de sementes, passasse a usar o gerador de números pseudoaleatórios (PRNG) de software do MicroPython, o Yasmarang. Esse PRNG não criptográfico era inicializado com o ID exclusivo e fixo do dispositivo e com informações limitadas de temporização, o que tornava seu estado inicial previsível o suficiente para reduzir drasticamente a entropia efetiva das sementes de carteira geradas [5].

A rotina de geração de sementes também incorporava a saída de um segundo gerador Yasmarang. Nos dispositivos Mk2/Mk3 mais antigos, esse segundo gerador partia de constantes públicas e não acrescentava entropia. Nos modelos mais novos, embora tenha sido introduzida aleatoriedade proveniente de elementos seguros, apenas 32 bits eram preservados durante a reinicialização do gerador. Consequentemente, apesar de produzir sementes de carteira de 256 bits, o espaço efetivo de busca era drasticamente reduzido. A Coinkite estimou preliminarmente cerca de 2 USD^{40}$ candidatos nos modelos Mk2/Mk3 e 2 USD^{72}$ nos modelos Mk4/Q/Mk5, segundo as premissas de ataque que apresentou [6, 7].

A falha transformou a recuperação de sementes em uma busca offline: um atacante poderia derivar endereços de sementes candidatas e compará-los com dados públicos da blockchain. O custo prático depende do modelo e das premissas de ataque; a estimativa de 2 USD^{72}$ não implica a mesma viabilidade que a do caso de 2 USD^{40}$. Uma correspondência bem-sucedida expõe as chaves privadas correspondentes.

2.3 XRPH Wallet: um erro no formato da entrada que reduziu o espaço de chaves

O fluxo de geração também inclui a conversão da saída aleatória para a entrada esperada por uma API de carteira. Na XRPH Wallet, essa conversão descartava a maior parte da entrada gerada. O aplicativo Android gerava blocos de dígitos decimais com o Math.random() do JavaScript, concatenava-os em uma string de texto e passava essa string para Wallet.fromEntropy(). O código que recebia a string interpretava os caracteres como valores inteiros pequenos de bytes e preservava apenas as primeiras 16 posições. Como duas posições continham separadores de espaço fixos, apenas 14 dígitos decimais variáveis contribuíam para a entropia da carteira resultante [8].

padlock = { A, B, C, D, E, F, G, H };     // each = 6 digits from the line above
r6 =  A.join('') + ' ' + B.join('') + ' ' + C.join('') + ' ' + D.join('')
    + ' ' + E.join('') + ' ' + F.join('') + ' ' + G.join('') + ' ' + H.join('');
r5 = Wallet.fromEntropy;
r3 = r5.bind(Wallet)(r6);                 // a 55-char STRING is passed; fromEntropy wants 16 bytes

// compute entropy be like
const input = "528875 921568 528239 ...";  // decimal blocks
const entropy = Uint8Array.from(input).slice(0, 16);
// Result: [5,2,8,8,7,5,0,9,2,1,5,6,8,0,5,2]

A transformação resultante deixava aproximadamente 10 USD^{14}\approx 2^{46}$ entradas de carteira possíveis, em comparação com o espaço pretendido de cerca de 2 USD^{128}$ para 16 bytes de entropia amostrados uniformemente. Esse número descreve os candidatos possíveis sob a transformação observada, não constitui uma prova criptográfica da entropia estatística de Math.random().

Duas falhas se agravavam mutuamente: uma fonte de aleatoriedade inadequada e um erro de representação/codificação na interface da API. Ambas podem passar despercebidas em testes funcionais porque a carteira ainda gera endereços plausíveis e assina transações válidas. A investigação pública estabelece que o espaço de chaves permite a recuperação; por si só, ela não comprova qual caminho o atacante usou para obter a chave.

2,4 Qubic Wallet: aleatoriedade fraca por trás de uma semente de 55 caracteres

O estado inicial do gerador também pode limitar as sementes possíveis, por mais longa que pareça a string produzida. A Qubic ilustra esse problema: o comprometimento de carteiras relatado envolveu sementes geradas com o Math.random() não criptográfico do JavaScript. Os ambientes afetados incluíam navegadores da Apple e determinadas versões mais antigas do aplicativo para iOS baseadas em JavaScriptCore [9, 10].

A lógica de geração vulnerável e sua correção podem ser resumidas da seguinte forma [11]:

// Vulnerable seed generation (abridged)
seed += letters[Math.floor(Math.random() * 26)];

// Corrected approach (schematic excerpt of the fix)
crypto.getRandomValues(bytes);
if (byte < 234) seed += letters[byte % 26];

Chamar Math.random() 55 vezes não fornece 55 fontes independentes de entropia. Entre as reinicializações do gerador, cada chamada ao PRNG avança seu estado interno de forma determinística. Para uma posição fixa na sequência de chamadas, se a semente inicial for $SS$, toda a semente de carteira de 55 caracteres será uma função determinística $W=F(S)W=F(S)$. Conhecer $SS$ e essa posição basta para reproduzir todos os 55 caracteres, e chamar o PRNG mais vezes não cria entropia adicional.

O intervalo de estados iniciais possíveis depende da inicialização do ambiente de execução. A versão do código-fonte do JavaScriptCore obtida em 29/10/2026 inicializa seu PRNG a partir de uma semente de 32 bits, o que resulta em, no máximo, 2 USD^{32}$ sequências para uma posição fixa na sequência de chamadas. O código-fonte do V8 examinado aqui usa uma semente de 64 bits, o que resulta em, no máximo, 2 USD^{64}$ sequências desse tipo. Esses limites se aplicam aos fluxos de inicialização examinados, para uma posição fixa na sequência de chamadas. As versões do código-fonte consultadas não estabelecem as versões exatas dos navegadores usadas no incidente nem o custo de explorá-las. A correção, por sua vez, usa crypto.getRandomValues() para obter aleatoriedade criptograficamente segura, com amostragem por rejeição (byte < 234) para evitar viés ao mapear bytes para 26 letras [12, 13, 14].

3. Assinatura falha: recuperação da chave privada a partir de assinaturas públicas

Depois que uma chave é gerada com segurança, ela também deve permanecer secreta quando usada para assinar. Cada assinatura disponibiliza dados a observadores, e falhas de implementação podem transformar esses dados públicos em informações suficientes para recuperar a chave privada. ECDSA e Schnorr usam um escalar secreto por assinatura, chamado nonce, para mascarar a contribuição da chave privada para a assinatura pública.

O nonce deve permanecer secreto, não pode ser reutilizado em mensagens distintas sob a mesma chave e deve atender aos requisitos de distribuição do esquema. A derivação determinística é compatível com esses requisitos: conhecer a chave pública e a mensagem assinada não deve ser suficiente para prever o nonce.

Considere, como exemplo, a relação simplificada de Schnorr:

$s=k-rd(\mathrm{m}\mathrm{o}\mathrm{d}n),s=k-rd\backslash pmod\; n,$

em que $dd$ é a chave privada, $kk$ é o nonce, $rr$ é um valor público calculado com informações públicas (por exemplo, a chave pública e a mensagem), $ss$ é o escalar público da assinatura e $nn$ é a ordem do subgrupo. Um nonce conhecido expõe imediatamente $d=(k-s)r^{-1}(\mathrm{m}\mathrm{o}\mathrm{d}n)d=(k-s)r^\{-1\}\backslash pmod\; n$ quando $rr$ é invertível.

Além disso, não é necessário conhecer o nonce por completo para que a chave seja exposta. Restrições ou vieses em múltiplos nonces podem fornecer informações suficientes para recuperar a chave por meio de métodos baseados em reticulados. A viabilidade depende das informações expostas e das assinaturas disponíveis.

A tabela distingue as duas falhas de nonce examinadas nesta seção: os nonces da Zilliqa tinham restrições parciais, enquanto os da SecondFi passaram a ser calculáveis a partir de dados públicos. Os impactos relatados se referem a períodos históricos de apuração distintos.

3,1 Zilliqa Ledger Wallet: 64 bits ausentes em cada nonce Schnorr

O incidente da Zilliqa Ledger Wallet envolveu uma falha no aplicativo usado para transações legadas de EC-Schnorr da Zilliqa [15]. O aplicativo gerava os dados do nonce, mas copiava a parte errada para o buffer final de assinatura. Ele mantinha oito bytes de preenchimento com zeros e descartava oito bytes de aleatoriedade real. Como resultado, cada nonce afetado satisfazia 0 USD \le k < 2^{192},$ em vez de abranger adequadamente a ordem do grupo secp256k1, de aproximadamente 256 bits.

As equações da assinatura mostram por que restringir o nonce importa:

Aqui, $GG$ é o gerador do grupo. Reorganizando, obtém-se

$k=s+rd(\mathrm{m}\mathrm{o}\mathrm{d}n)\mathrm{.}k=s+rd\backslash pmod\; n.$

Portanto, cada assinatura fornece uma relação modular envolvendo a incógnita $dd$, com um nonce limitado por 2 USD^{192}$. A combinação de várias relações independentes produz uma instância do Problema do Número Oculto (HNP), que pode ser abordada por redução de reticulados. O relatório oficial pós-incidente relata a recuperação da chave privada a partir de quatro ou mais assinaturas afetadas.

O elemento seguro nunca precisou revelar os bytes da chave privada. Os nonces enviesados tornaram essa chave recuperável a partir de assinaturas já publicadas na blockchain.

3,2 SecondFi: um nonce de assinatura calculável a partir de dados públicos

Na SecondFi, a derivação incorreta do nonce Ed25519 expôs mais do que uma restrição parcial: tornou o nonce calculável a partir de dados públicos. Isso permitiu recuperar chaves privadas de assinatura a partir de uma única assinatura de transação disponível publicamente [16].

Em uma assinatura no estilo Ed25519, a construção pretendida deriva um escalar secreto $aa$ e um prefixo privado de nonce a partir do material da chave secreta. Aqui, $A=aBA=aB$ é a chave pública, $BB$ é o ponto-base da Ed25519, $MM$ é a mensagem assinada, $LL$ é a ordem do subgrupo e $HH$ denota SHA-512. De forma esquemática:

A implementação falha, em vez disso, define $r=H(M)Lr=H(M)\backslash bmod\; L$. Qualquer pessoa que conheça a mensagem assinada pode derivar $rr$. Como $RR$, $AA$ e $SS$ são públicos, um observador pode então calcular

$a=(S-r)h^{-1}(\mathrm{m}\mathrm{o}\mathrm{d}L),a=(S-r)h^\{-1\}\backslash pmod\; L,$

desde que $hh$ seja diferente de zero módulo $LL$.

Ao contrário do vazamento parcial do nonce na Zilliqa, uma assinatura afetada bastava para recuperar o escalar de assinatura. Isso não prova automaticamente a recuperação da frase mnemônica original nem de todas as chaves derivadas do mesmo nível em uma carteira hierárquica. A falha estava na interface entre a derivação de chaves e a assinatura: o segredo necessário estava disponível, mas nunca foi passado à rotina de derivação do nonce.

4. Princípios de implementação segura e verificação

Em conjunto, os casos mostram por que as fontes de aleatoriedade e os algoritmos de assinatura precisam ser examinados juntamente com o código que os conecta. Uma fonte imprevisível precisa produzir chaves imprevisíveis, e essas chaves precisam permanecer secretas durante a assinatura. Erros nas rotinas de conversão ou nas interfaces de bibliotecas podem comprometer qualquer um desses requisitos.

As seções 4,1 e 4,2 apresentam os princípios de projeto e implementação para geração e assinatura. A seção 4,3 explica que evidências as revisões e os testes devem fornecer para avaliar esses princípios no sistema implantado.

4,1 Preservar a segurança durante a geração de chaves

Os casos de geração apontam para três requisitos de implementação:

1. Usar aleatoriedade criptograficamente segura e interromper a geração em caso de falha. Seeds e chaves privadas exigem uma fonte criptograficamente segura adequada, como um gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG). Ill Bloom e Qubic mostram por que um gerador de uso geral não pode cumprir esse papel. Se a fonte pretendida estiver indisponível ou falhar, a geração deve ser interrompida, em vez de usar silenciosamente uma alternativa mais fraca.

2. Preservar a entropia durante a conversão de dados. A saída de uma fonte segura deve conservar a incerteza necessária ao ser codificada, amostrada ou passada entre interfaces. O caso da XRPH Wallet mostra por que uma saída aparentemente válida não é suficiente. Restrições de tipo, comprimento e codificação devem impedir que truncamentos não intencionais ou mapeamentos enviesados reduzam o espaço efetivo de chaves.

3. Garantir que o código implantado use a fonte pretendida. Coldcard mostra que a presença de uma fonte segura de aleatoriedade não estabelece qual fonte o aplicativo de fato chama. A seleção da fonte deve permanecer correta durante a integração, a compilação e a implantação, inclusive nos caminhos de erro e de fallback. Uma premissa de projeto sobre o RNG deve se confirmar no executável em execução na plataforma de destino.

4,2 Preservar o sigilo durante a assinatura

Os requisitos de geração protegem a forma como uma chave é criada. Mantê-la secreta durante o uso também exige o tratamento correto dos nonces. Os requisitos dependem do esquema; a lista inclui ECDSA ao lado dos esquemas Schnorr e Ed25519 examinados nos casos.

1. ECDSA: Preservar o sigilo e a imprevisibilidade do nonce e impedir sua reutilização com a mesma chave em mensagens diferentes. A geração determinística conforme a RFC 6979 [17] evita a dependência de nova aleatoriedade externa para cada assinatura, mas as implementações ainda precisam de proteção contra vazamentos por canais laterais e ataques por indução de falhas.

2. EdDSA: Preservar todas as entradas secretas exigidas pela derivação do nonce. SecondFi demonstra a consequência de omitir o prefixo privado e usar apenas dados públicos. Wrappers e adaptadores de chaves devem passar todas as entradas secretas exigidas pela RFC 8032 [18], em vez de tratar uma assinatura funcional como prova de que as entradas estão corretas.

3. Schnorr: Preservar a distribuição e a representação dos nonces exigidas pelo esquema. Como mostra o caso da Zilliqa, evitar a repetição e nonces totalmente previsíveis não basta se parte da aleatoriedade for perdida. O tratamento dos dados e a conversão de escalares não devem introduzir restrições ou vieses exploráveis.

Bibliotecas amplamente revisadas reduzem o risco de implementação, mas não eliminam erros de integração. Uma primitiva de assinatura correta continua insegura se o código que a chama fornecer entradas incompletas ou corrompidas.

4.3 Testar as propriedades de segurança

Para avaliar se esses requisitos são atendidos, as revisões devem acompanhar as entradas ao longo da implementação que efetivamente é executada. Uma saída válida pode ocultar um erro de integração; por isso, a verificação também precisa abranger caminhos que os testes funcionais normais não cobrem. A tabela converte os requisitos de geração e assinatura em objetivos específicos de revisão:

A avaliação desses objetivos exige a combinação de vários métodos. A revisão de código rastreia como as entradas secretas e aleatórias chegam às rotinas de geração e assinatura implantadas. Testes de caminhos de falha e injeção de falhas examinam o comportamento quando as premissas normais não se confirmam; testes com respostas conhecidas e comparações com implementações independentes podem revelar desvios do esquema. Testes estatísticos podem detectar vieses evidentes, mas a geração bem-sucedida de endereços, a verificação de assinaturas ou os testes estatísticos, isoladamente, não podem estabelecer a segurança criptográfica. Avalie o conjunto das evidências à luz dos requisitos relativos à fonte, ao tratamento das entradas e ao esquema.

Equipes ou especialistas externos em segurança podem complementar a verificação interna por meio de auditorias de código e integração, sobretudo nos pontos de encontro entre fontes de aleatoriedade, derivação de chaves e bibliotecas de assinatura. O escopo deve abranger as versões das dependências, a configuração de compilação e o caminho de código executado. As conclusões devem identificar a propriedade de segurança afetada e fornecer evidências reproduzíveis e verificações de regressão. Alterações na implementação ou em suas dependências ainda exigem verificação.

5. Conclusão

Os seis incidentes revelam duas maneiras pelas quais erros de implementação podem comprometer chaves protegidas: reduzir o conjunto de chaves possíveis durante a geração ou expor informações sobre uma chave existente por meio de assinaturas. A análise transforma essas falhas em requisitos de geração e assinatura, com objetivos de revisão e teste para o código implantado na infraestrutura de pagamentos.

Para instituições de pagamento, o armazenamento seguro protege o segredo armazenado; ele não pode corrigir uma geração previsível nem informações vazadas pela assinatura. As propriedades exigidas devem ser preservadas ao longo das dependências, dos adaptadores e da implantação. Revisões e testes precisam examinar essa implementação completa, em vez de inferir segurança a partir de endereços e assinaturas válidos.

Esses requisitos de implementação complementam os controles de fluxo de trabalho examinados na Parte 1 de Beyond Secure Storage. A Parte 1 examina riscos do fluxo de trabalho, verificações preventivas e contenção de perdas quando essas verificações não conseguem impedir operações não autorizadas. A Parte 2 aborda falhas de implementação que podem dar a um invasor capacidade independente de assinatura. A execução criptográfica correta não comprova a autorização de negócios; uma aprovação de negócios válida não estabelece que a chave de assinatura é imprevisível ou irrecuperável. Sistemas seguros de pagamento e assinatura exigem que tanto o fluxo de trabalho de autorização quanto a implementação criptográfica subjacente sejam projetados e verificados.

Referências

• [1] BIP-39, Código mnemônico para geração de chaves determinísticas.

• [2] BIP-32, Carteiras hierárquicas determinísticas.

• [3] CryptoJS, Aviso de segurança GHSA-rg76-677x-56q9.

• [4] CryptoJS, Código-fonte de core.js, versão 3.1.9-1.

• [5] Coldcard, Aviso sobre o firmware e notas de versão.

• [6] MicroPython, Análise pós-incidente da Coldcard sob a perspectiva do MicroPython.

• [7] Coinkite, Análise técnica aprofundada do problema de entropia.

• [8] XRPL.to, O ataque à XRPH Wallet: 4011 carteiras esvaziadas e todas as chaves eram adivinháveis.

• [9] Qubic, Comunicado sobre o incidente e orientações para as plataformas afetadas.

• [10] Qubicmap, Cronologia do incidente da Qubic e resumo das carteiras.

• [11] Qubic Wallet, Correção 09dd288 para a geração segura de seeds.

• [12] WebKit, JSGlobalObject.cpp, inicialização de m_weakRandom.

• [13] WebKit, WeakRandom.h, implementação da seed e do PRNG.

• [14] V8, math-random.cc, inicialização do estado do PRNG.

• [15] Zilliqa, Análise pós-incidente: viés nos nonces do Schnorr legado.

• [16] KarpelesLab, Análise e reprodução da implementação da SecondFi.

• [17] RFC 6979, Uso determinístico de DSA e ECDSA.

• [18] RFC 8032, Algoritmo de assinatura digital com curvas de Edwards (EdDSA).