Generador de par de claves RSA

¿Qué tamaño de clave debería elegir, 2048, 3072 o 4096 bits?

2048 bits sigue siendo el mínimo aceptado para RSA y es lo que usan por defecto la mayoría de los servicios: el NIST considera hoy que RSA de 2048 bits es adecuado al menos hasta 2030. Si tu clave necesita seguir siendo confiable mucho después de esa fecha, o si vas a firmar algo que debe conservar validez legal durante años, 3072 bits es la opción más prudente sin un coste desproporcionado. 4096 bits tiene sentido sobre todo para claves raíz de tipo CA o claves de vida muy larga; para TLS o SSH del día a día suele ser excesivo, porque una clave más grande hace las firmas y verificaciones más lentas sin un beneficio real proporcional para la mayoría de los usos personales. La herramienta pasa directamente el tamaño elegido al parámetro modulusLength de crypto.subtle.generateKey, sin ninguna restricción adicional propia.

¿Por qué generar una clave de 4096 bits tarda tanto más que una de 2048?

Generar una clave RSA consiste en buscar dos números primos grandes al azar y comprobar rigurosamente que en efecto son primos, y esa búsqueda se encarece más rápido de lo que crece el tamaño de la clave: al pasar de 2048 a 4096 bits, el tiempo de espera puede multiplicarse por tres o cuatro, no solo duplicarse. Por eso la interfaz muestra el mensaje "Generando… las claves RSA grandes pueden tardar unos segundos": crypto.subtle.generateKey es asíncrona, así que la pestaña no se congela mientras espera, pero quien elige 4096 bits debe contar con unos segundos de espera en vez de la respuesta casi instantánea de una clave de 2048 bits.

¿En qué se diferencian realmente RSA para firmar y RSA para cifrar?

Es la misma aritmética RSA de base, pero con un esquema de relleno (padding) distinto, y WebCrypto se niega deliberadamente a mezclarlos. RSASSA-PKCS1-v1_5 sirve para firmar: demostrar que un mensaje viene de verdad de quien tiene la clave privada, útil para firmar un JWT tipo RS256 o firmar documentos. RSA-OAEP sirve para cifrar: cualquiera con la clave pública puede enviar algo que solo la clave privada pueda leer. En el código esto se ve en los KeyUsage que se asignan al llamar a generateKey: ['sign', 'verify'] para el modo de firma, ['encrypt', 'decrypt'] para el de cifrado, y una clave generada para un uso no sirve para el otro. Conviene recordar que RSA nunca se usa para cifrar directamente datos voluminosos: TLS y PGP solo usan RSA para cifrar una clave simétrica corta, y el contenido real lo cifra AES.

¿Qué es Ed25519 y por qué a veces no aparece como opción?

Ed25519 es un esquema de firma moderno basado en curvas elípticas (EdDSA sobre Curve25519). Para el mismo nivel de seguridad, sus claves y firmas son mucho más pequeñas que las de RSA y firmar/verificar es más rápido, pero solo sirve para firmar y verificar — no tiene ningún modo de cifrado equivalente a RSA-OAEP. Esta opción solo aparece cuando el navegador la soporta de verdad, y la herramienta no confía en ninguna bandera de compatibilidad declarada: hay navegadores que aceptan el nombre del algoritmo 'Ed25519' sin protestar, pero lanzan un NotSupportedError en cuanto generateKey se ejecuta de verdad. Por eso isEd25519Supported intenta generar un par de claves Ed25519 real (barato, de usar y tirar) para comprobarlo, y guarda el resultado tras la primera comprobación, así la interfaz solo pregunta una vez al montarse en vez de generar una clave desechable en cada render.

¿Por qué exportar en PEM y no en otro formato?

PEM — texto en Base64 envuelto entre -----BEGIN ... -----END-----, con 64 caracteres por línea — es el estándar de facto para intercambiar claves con OpenSSL, la mayoría de las bibliotecas TLS y archivos de configuración versionados en Git. WebCrypto no tiene exportación nativa a PEM: crypto.subtle.exportKey solo devuelve bytes DER en bruto, en SPKI para la clave pública y PKCS8 para la privada. La propia herramienta arma el PEM: convierte ese DER a Base64 con btoa, lo corta en líneas de exactamente 64 caracteres y añade la cabecera y el pie correspondientes — el resultado coincide exactamente con el formato que produce openssl para las mismas estructuras SPKI/PKCS8, así que se puede pegar directamente en un archivo .pem y funciona.

¿Es seguro usar una clave generada en una pestaña del navegador?

Matemáticamente sí: crypto.subtle.generateKey toma su aleatoriedad del generador criptográfico (CSPRNG) del propio sistema operativo, la misma fuente que usa el navegador en todo lo demás. Lo que cambia es el contexto operativo: una pestaña del navegador no tiene almacenamiento de claves en hardware, no lleva un registro de auditoría, y basta una extensión maliciosa o un equipo comprometido para que la clave privada se filtre justo al generarse. Para aprender, hacer pruebas locales, claves desechables o fixtures de CI, esto es perfectamente válido. Pero para proteger tráfico de producción real o firmar algo de valor, no uses una clave generada en este sitio: genérala en (o pásala de inmediato a) un módulo de seguridad de hardware (HSM), una máquina offline aislada de la red, o una herramienta de línea de comandos auditada como openssl genrsa o ssh-keygen, ejecutada en una máquina que controles de principio a fin. La clave privada no sale de la pestaña durante la generación — no hay ninguna petición de red al crear ni mostrar el par de claves — pero que "no salga de la pestaña" y que sea "segura para producción" son dos afirmaciones distintas; no confundas una con la otra.