Como construímos o QuickUse Generator

Cada gerador implementa um padrão publicado ou um algoritmo bem compreendido. Não inventamos esquemas criptográficos novos ou heurísticas indocumentadas. Quando desviamos de uma leitura estrita da spec (ex: porque a spec é ambígua sobre um edge case), documentamos o desvio explicitamente.

Vetores de teste vêm do autor da spec (exemplos RFC, erratas IETF, amostras de validação da Receita Federal) quando disponíveis. Testes unitários no codebase fixam o output byte-equal contra esses vetores de referência, pra que uma mudança futura de código não quebre compliance silenciosamente.

Pra geradores client-side (90%+ do catálogo), usamos a Web Crypto API (crypto.getRandomValues, crypto.subtle) pra qualquer operação que precise de aleatoriedade criptográfica ou hashing. Nunca usamos Math.random() pra output security-sensitive. A fonte é documentada por gerador na própria página.

Pra geradores de dados em formato (CPF, CNPJ, números de cartão fake, etc.) o output é sempre format-válido mas não corresponde a nenhuma emissão real. Geradores de dados de teste têm badge visível "apenas para testes" e lembrete dos Termos.

Geradores que precisam de output imprevisível (senhas, segredos, tokens de sessão, UUIDs aleatórios) leem de window.crypto.getRandomValues(), que o navegador respalda em um CSPRNG do sistema operacional (Chrome: BoringSSL, Firefox: NSS, Safari: corecrypto). É a mesma fonte que o NIST SP 800-90A recomenda pra uso geral.

Pra senhas especificamente, usamos rejection sampling contra o conjunto de caracteres escolhido (sem bias de módulo). Os parâmetros configuráveis (tamanho, classes de caractere, excluir-caracteres-similares) afetam apenas o filtro pós-amostragem, nunca a fonte subjacente.

Geradores de passphrase usam a wordlist EFF large (7.776 palavras selecionadas pra memorabilidade) e indexação estilo Diceware via inteiros aleatórios criptográficos. Entropia por palavra é log2(7776) ≈ 12,92 bits, então uma passphrase de 6 palavras tem ~77,5 bits — confortavelmente acima da recomendação NIST SP 800-63B de 80+ bits pra contas de alto valor.

Não armazenamos, transmitimos ou logamos qualquer valor gerado. A string que você vê na caixa existe apenas no heap JavaScript da sua aba do navegador até você copiar ou fechar.

CPF (Cadastro de Pessoas Físicas) — 11 dígitos com dois dígitos verificadores calculados via módulo-11 sobre os 9 primeiros dígitos. Algoritmo publicado pela Receita Federal na Instrução Normativa RFB 1.548/2015. Nosso validador implementa o algoritmo exato; nosso gerador de dados de teste produz CPFs format-válidos que não estão registrados a nenhuma pessoa real.

CNPJ (Cadastro Nacional da Pessoa Jurídica) — 14 dígitos com dois dígitos verificadores via módulo-11 modificado com posições ponderadas. Mesma fonte.

PIS/PASEP/NIT (Programa de Integração Social) — 11 dígitos com um dígito verificador, módulo-11. Algoritmo publicado pela Caixa Econômica Federal.

Pros três, removemos e re-adicionamos a formatação convencional (XXX.XXX.XXX-XX pra CPF, XX.XXX.XXX/XXXX-XX pra CNPJ, XXX.XXXXX.XX-X pra PIS) pra que o output esteja pronto pra copy-paste em formulários que esperam input formatado ou cru.

UUID — RFC 4122. Geramos v4 (aleatório) por padrão e oferecemos v1 (timestamp+MAC) e v7 (Unix epoch + aleatório) como opções. O MAC pra v1 é randomizado por geração (a spec permite e evita vazar seu endereço de hardware). v7 é a escolha moderna pra chaves de banco porque ordena lexicograficamente por tempo de criação.

QR Code — ISO/IEC 18004:2015 com correção de erro Reed-Solomon. Suportamos os quatro níveis de correção de erro (L, M, Q, H) e deixamos você escolher. A matriz é computada no seu navegador usando uma implementação JS vendored que testamos contra os padrões oficiais de bit da amostra ISO.

Base64 — RFC 4648. Variantes standard e URL-safe. Encoding e decoding são funções puras; sem truques de padding, sem peculiaridades de whitespace.

Funções hash (SHA-1, SHA-256, SHA-384, SHA-512) — FIPS 180-4 via Web Crypto API (crypto.subtle.digest). MD5 não é exposto porque é criptograficamente quebrado; linkamos pra página da spec explicando o porquê.

Bugs acontecem. Quando encontramos um (ou você reporta um), corrigimos o gerador, adicionamos um vetor de teste que pega o bug, e atualizamos a página afetada com data de "Última atualização". Pra bugs que possam ter afetado output visível pro usuário (ex: gerador que emitia dígito verificador de CPF inválido), adicionamos um banner no topo da página explicando o problema e a data em que foi corrigido.

O histórico git do projeto é aberto em github.com/thiagojb1975/quickusegenerator — você pode auditar cada mudança contra esta metodologia.