Ferramentas para desenvolvedores · Gerador UUID
Math.random vs crypto.getRandomValues: Como funciona cada gerador
· Como funciona
uuid criptografia APIs do navegador
Ambos retornam números que parecem aleatórios, mas um é uma pequena máquina de estado determinística e o outro é alimentado pelo sistema operacional. Aqui está o que cada um faz nos bastidores e por que os UUIDs devem usar o segundo.
O trecho do fórum que cria um UUID a partir de Math.random — por que parece bom e passa em todos os testes casuais
Uma resposta do fórum oferece uma fábrica rápida de UUID em oito linhas: role os valores de Math.random e formate-os no layout 8-4-4-4-12. O código parece bom e passa em todos os testes casuais. Cada identificador parece diferente e uma pequena amostra não mostra nenhum padrão visual óbvio. Essa não é a propriedade que um identificador sensível à segurança precisa. JavaScript especifica Math.random como uma fonte pseudo-aleatória, mas não requer resistência criptográfica à previsão. Seus trabalhos apropriados incluem simulações, jogos e embaralhamento. Uma vez que um identificador pode influenciar o acesso, a descoberta de objetos ou outra decisão adversária, a aparência não é mais uma evidência. O contrato documentado do gerador é mais importante do que uma página de resultados aparentemente plausíveis.
Inside Math.random — um algoritmo pseudo-aleatório propagado com um estado interno fixo, projetado para velocidade e propagação estatística, não para sigilo
Como Math.random não é especificado como um gerador criptográfico, suas saídas não devem ser tratadas como evidência de que valores futuros estão ocultos de um observador. crypto.getRandomValues tem um contrato de plataforma diferente: ele preenche um array digitado inteiro com valores criptograficamente fortes. A especificação Web Crypto deixa o gerador exato para o agente do usuário, portanto, o código do aplicativo não deve reivindicar um algoritmo, tamanho de semente ou dispositivo de entropia específico. ToolAcre precisa apenas do limite suportado: o navegador fornece bytes aleatórios seguros, JavaScript recebe o Uint8Array preenchido e o código UUID define os campos de versão e variante. Essa declaração é útil e portátil em navegadores cujas implementações internas são diferentes.
Por que observar os resultados pode revelar o estado - como um estado pequeno significa que uma série de valores pode permitir que alguém preveja os próximos
O código do aplicativo recebe valores criptograficamente fortes de getRandomValues em vez de implementar ou expor um estado JavaScript PRNG. A diferença de segurança aparece em sistemas reais. Um identificador construído a partir de Math.random é inadequado onde quer que a previsão tenha consequências porque um invasor com a capacidade de ler a rede (ou qualquer sistema onde UUIDs anteriores sejam visíveis) pode prever o próximo. Um UUID v4 de crypto.getRandomValues não é por si só um token de autenticação (você ainda precisa de expiração, hash e limitação de taxa), mas o gerador foi projetado para resistir à previsão. ToolAcre se recusa a gerar um identificador se sua fonte segura estiver ausente, em vez de fazer o downgrade silenciosamente para uma fórmula previsível. Math.random foi enviado com bugs sutis de distribuição nos principais motores. Uma sequência de resultados pode parecer variada sem fornecer a imprevisibilidade adversária necessária para funções secretas.
Dentro de crypto.getRandomValues — o navegador solicita o CSPRNG do sistema operacional, que mistura entropia de hardware e sistema e é projetado para ser imprevisível
Algoritmos específicos do mecanismo e seu comportamento estatístico podem mudar; nem a inspeção visual nem um teste de distribuição casual atualizam Math.random em uma fonte criptográfica. Os cálculos de colisão também assumem saídas independentes do espaço declarado. Se um gerador repetir o estado, for propagado incorretamente ou for substituído por um acessório determinístico, essa suposição falhou e a fórmula não descreve mais a implementação. Ambas as APIs podem produzir strings que parecem igualmente irregulares. O modelo de ameaça os separa: valores que devem resistir à previsão usam crypto.getRandomValues, enquanto simulações e embaralhamentos não adversários podem usar Math.random. A escolha decorre da consequência da previsão, não da pontuação ou da variedade aparente numa amostra.
Exemplo resolvido – gerando o mesmo número de identificadores com cada método e comparando o que um observador poderia inferir
O gerador ToolAcre UUID usa crypto.getRandomValues exclusivamente; ele nunca usa Math.random porque o custo de um UUID previsível é sempre maior que o custo de um gerador um pouco mais lento. A diferença criptográfica é mensurável através de um modelo de ameaça. Um invasor que queira falsificar UUIDs deve adivinhar o identificador diretamente ou quebrar o gerador de números aleatórios. A adivinhação direta não é a comparação que este artigo quantifica; a conclusão apoiada é que o Web Crypto se destina à aleatoriedade criptográfica, enquanto Math.random não. A CSPRNG e Math.random expõem contratos diferentes: o primeiro é projetado para aleatoriedade sensível à segurança, enquanto o último não traz tal promessa. Um sistema que usa Math.random para identificadores perdeu a propriedade criptográfica; a segurança agora depende de manter em segredo a sequência de UUIDs gerados. Se pelo menos um UUID vazar, toda a geração futura estará comprometida.
Bugs históricos de distribuição — um lembrete de que os mecanismos enviaram implementações Math.random com resultados visivelmente irregulares, descritos qualitativamente
Se o aplicativo armazenar UUIDs em um log, banco de dados ou histórico de controle de versão, o vazamento será quase inevitável. A biblioteca ToolAcre impõe o uso de crypto.getRandomValues e se recusa a gerar um UUID se o contexto seguro (HTTPS ou localhost) não estiver disponível. Essa decisão de design evita o retorno silencioso para Math.random que afetou muitas implementações feitas manualmente. Em Node.js, a biblioteca usa o módulo criptográfico; nos navegadores, utiliza o Web Crypto API. Ambos os caminhos suportados solicitam aleatoriedade criptograficamente forte da plataforma. A implementação não faz nenhuma reivindicação de desempenho porque o mecanismo, o dispositivo e a carga de trabalho determinam o tempo; o contrato de segurança é a propriedade decisiva para identificadores. O motivo pelo qual o padrão da indústria se estabeleceu em crypto.getRandomValues é um breve histórico de uso indevido de UUID. Os primeiros sistemas usavam hora do sistema, interfaces de rede e relógios de hardware para gerar identificadores.
O que isto não cobre — a qualidade estatística de qualquer um dos geradores para simulações, que é uma questão diferente da imprevisibilidade
Versões UUID baseadas em tempo, baseadas em nós e aleatórias resolvem diferentes problemas de alocação; não se deve apresentar um reparo linear para todos os projetos anteriores. Para a versão 4, RFC 9562 define campos aleatórios e discute separadamente a imprevisibilidade. Uma migração para longe de Math.random, portanto, altera a qualidade dos valores recém-gerados sem alterar a forma textual de UUID. Os identificadores existentes permanecem chaves do banco de dados; regenerá-los quebraria as referências. Novos valores podem usar Web Crypto imediatamente, enquanto a autorização deve continuar a tratar cada UUID antigo ou novo como um identificador em vez de prova de permissão. Documente o ponto de corte para que os socorristas saibam qual gerador produziu cada população.
Conclusão: escolha o gerador pela ameaça, não pela aparência — o gerador ToolAcre UUID usa exclusivamente o CSPRNG, nunca Math.random()
A validação deve distinguir entre IDs legados (não adequados para sigilo) e novos (apoiados por CSPRNG). A documentação deve observar a transição. O gerador ToolAcre produz apenas UUIDs crypto.getRandomValues; ele não tenta validar ou regenerar identificadores de outras fontes. O gerador ToolAcre demonstra as melhores práticas ao recusar o downgrade para uma fonte aleatória mais fraca. Se crypto.getRandomValues não estiver disponível, a ferramenta reportará um erro em vez de usar Math.random silenciosamente. Este princípio de design se aplica a qualquer sistema crítico de segurança: falhar ruidosamente em vez de ter sucesso silenciosamente com uma garantia de segurança fraca. Um desenvolvedor que vir "falha na geração de UUID: criptografia API não disponível" deve resolver o problema subjacente (atualizar para HTTPS, corrigir o contexto seguro ou fornecer um substituto adequado). Um desenvolvedor que recebe silenciosamente UUIDs criados a partir de Math.random não tem indicação de que o sistema está comprometido. A biblioteca ToolAcre prioriza a honestidade em vez da conveniência.