Random byte generator

Na criptografia moderna, bytes aleatórios são o elemento mais primitivo e mais crítico. Tudo começa com eles: uma chave AES-256 são 32 bytes aleatórios. Um nonce de autenticação GCM são 12 bytes aleatórios. Um salt de bcrypt são 16 bytes aleatórios. Um segredo de JWT são tipicamente 32 ou 64 bytes aleatórios. A qualidade da aleatoriedade desses bytes determina diretamente a segurança do sistema inteiro — bytes previsíveis transformam criptografia teoricamente inquebrável em trivialmente quebrável.

A fonte dessa aleatoriedade é o kernel do sistema operacional. Linux e macOS expõem bytes aleatórios através de `/dev/urandom` e da chamada de sistema `getrandom()`. Windows usa `CryptGenRandom`. Todos coletam entropia de fontes de hardware — timing de interrupções, movimentos de periféricos, ruído elétrico de sensores — e alimentam um pool de entropia que é continuamente misturado com algoritmos criptográficos. No navegador, `crypto.getRandomValues` é a ponte entre JavaScript e esse pool do kernel, padronizada pelo W3C. É a mesma fonte que o TLS usa ao negociar a chave de sessão que protege a página atual.

Esta ferramenta é adequada para cenários de desenvolvimento e aprendizado: gerar exemplos de payloads binários para documentação, criar dados de teste para funções de processamento binário, entender como IVs e salts parecem na prática. Não é um substituto para gestão de chaves em produção — chaves reais precisam ser geradas, armazenadas e rotacionadas por sistemas dedicados como AWS KMS, HashiCorp Vault ou HSMs. A diferença entre usar esta ferramenta para gerar uma chave de produção e usar um HSM é a diferença entre anotar uma senha num post-it e guardá-la em um gerenciador de senhas: a chave pode ser igualmente aleatória, mas a proteção ao redor dela é completamente diferente.

In modern cryptography, random bytes are the most primitive and most critical element. Everything starts with them: an AES-256 key is 32 random bytes. A GCM authentication nonce is 12 random bytes. A bcrypt salt is 16 random bytes. A JWT secret is typically 32 or 64 random bytes. The quality of randomness in those bytes directly determines the security of the entire system — predictable bytes turn theoretically unbreakable cryptography into trivially breakable cryptography.

The source of that randomness is the operating system kernel. Linux and macOS expose random bytes through `/dev/urandom` and the `getrandom()` system call. Windows uses `CryptGenRandom`. All of them collect entropy from hardware sources — interrupt timings, peripheral movements, electrical sensor noise — and feed an entropy pool that is continuously mixed with cryptographic algorithms. In the browser, `crypto.getRandomValues` is the bridge between JavaScript and this kernel pool, standardized by the W3C. It is the same source that TLS uses when negotiating the session key protecting the current page.

This tool is suited for development and learning scenarios: generating sample binary payloads for documentation, creating test data for binary processing functions, understanding what IVs and salts look like in practice. It is not a replacement for production key management — real keys need to be generated, stored, and rotated by dedicated systems like AWS KMS, HashiCorp Vault, or HSMs. The difference between using this tool to generate a production key and using an HSM is the difference between writing a password on a sticky note and storing it in a password manager: the key might be just as random, but the protection around it is completely different.

En la criptografía moderna, los bytes aleatorios son el elemento más primitivo y más crítico. Todo comienza con ellos: una clave AES-256 son 32 bytes aleatorios. Un nonce de autenticación GCM son 12 bytes aleatorios. Un salt de bcrypt son 16 bytes aleatorios. Un secreto de JWT son típicamente 32 o 64 bytes aleatorios. La calidad de la aleatoriedad de esos bytes determina directamente la seguridad de todo el sistema — los bytes predecibles convierten una criptografía teóricamente inquebrantable en trivialmente vulnerable.

La fuente de esa aleatoriedad es el kernel del sistema operativo. Linux y macOS exponen bytes aleatorios a través de `/dev/urandom` y la llamada al sistema `getrandom()`. Windows usa `CryptGenRandom`. Todos recopilan entropía de fuentes de hardware — tiempos de interrupción, movimientos de periféricos, ruido eléctrico de sensores — y alimentan un pool de entropía que se mezcla continuamente con algoritmos criptográficos. En el navegador, `crypto.getRandomValues` es el puente entre JavaScript y ese pool del kernel, estandarizado por el W3C. Es la misma fuente que usa TLS al negociar la clave de sesión que protege la página actual.

Esta herramienta es adecuada para escenarios de desarrollo y aprendizaje: generar ejemplos de payloads binarios para documentación, crear datos de prueba para funciones de procesamiento binario, entender cómo son los IVs y salts en la práctica. No sustituye la gestión de claves en producción — las claves reales necesitan ser generadas, almacenadas y rotadas por sistemas dedicados como AWS KMS, HashiCorp Vault o HSMs. La diferencia entre usar esta herramienta para generar una clave de producción y usar un HSM es la diferencia entre anotar una contraseña en un post-it y guardarla en un gestor de contraseñas: la clave puede ser igual de aleatoria, pero la protección a su alrededor es completamente diferente.