des/

No, aquí solo está implementado el DES simple. Una clave 3DES tiene 16 o 24 bytes; si la pegas aquí, solo se usan los primeros 8, así que el resultado es distinto al de 3DES, y junto al campo de la clave también aparece el aviso «solo se usan los primeros 8 bytes». Para 3DES, usa una herramienta que admita DESede.

Con menos de 8 bytes aparece un error y aquí no se rellena con ceros, así que complétala tú hasta 8 bytes. Un descuido más probable es el formato: si una clave hex de 16 caracteres se introduce con el formato de la clave en string, se trata como 16 bytes de texto y solo se usan los primeros 8 caracteres. No hay error, solo el aviso «solo se usan los primeros 8 bytes» junto al campo de la clave y debajo del resultado, y la salida no coincidirá. En formato string el recuento depende del juego de caracteres elegido, así que un carácter chino ocupa 3 bytes en UTF-8.

En DES el IV debe tener exactamente 8 bytes, no los 16 de AES, en todos los modos excepto ECB. Una clave de más de 8 bytes se recorta a los primeros 8, pero el IV no: si es más largo o más corto, da error, así que un IV de 16 bytes tomado de unos ajustes de AES hay que cambiarlo a 8 bytes. Comprueba también el formato: 16 caracteres hex son 8 bytes, mientras que los mismos 16 caracteres en formato string son 16 bytes. ECB no necesita IV y oculta el campo del IV.

Si la longitud del texto cifrado no es múltiplo de 8, normalmente se copió incompleto o se confundieron hex y base64. Un relleno no válido suele indicar que la clave, el IV, el modo o el relleno no coinciden con los usados al cifrar. ZeroPadding y NoPadding no comprueban el relleno, así que nunca dan este error, pero el resultado sale ilegible si los parámetros son incorrectos.

Comprueba primero el IV. Cuando el texto cifrado ocupa más de un bloque, un IV incorrecto en los modos CBC y CFB estropea solo el primer bloque de 8 bytes; el resto sale bien y no aparece ningún error de relleno, así que ves caracteres ilegibles al principio y texto correcto después. Si el mensaje dice que el resultado no es texto válido, puede que el juego de caracteres sea distinto del usado al cifrar, por ejemplo que el otro lado usara GBK. Si pones el formato de salida en hex, puedes comprobar primero los propios bytes descifrados.

Revisa en este orden: modo y relleno, formato y número de bytes de la clave y el IV, juego de caracteres, y formatos de entrada y salida. El texto plano en formato string no se recorta, así que un salto de línea de más al final son otros datos. Aquí CTR, CFB y OFB también rellenan según el relleno elegido, por lo que con PKCS5Padding el texto cifrado es más largo que el texto plano; si tu backend usa NoPadding, elige NoPadding también aquí. CFB aquí es la variante de bloque completo de 64 bits, así que no coincidirá con un backend que use CFB8.

No. Cuando pasas un string como clave a CryptoJS.DES.encrypt(message, string), CryptoJS lo trata como una contraseña: añade una sal aleatoria y deriva la clave y el IV como hace OpenSSL, y el resultado empieza por U2FsdGVkX1. Ese formato no está soportado aquí. Para que coincida con esta herramienta, convierte la clave a bytes en CryptoJS con CryptoJS.enc.Utf8.parse y pásala, e indica iv, mode y padding de forma explícita.

Solo existe en el localStorage del navegador de este dispositivo y nunca se sube; el código de la página no hace ninguna petición de red. Se añade un registro tras cada cifrado o descifrado correcto, se conservan hasta 20, y no se guarda nada cuya entrada o resultado supere los 20 000 caracteres. Cada registro contiene los parámetros, el IV, la entrada y el resultado, además de una huella de 8 caracteres derivada de los primeros 8 bytes de la clave (los caracteres que van después de # en cada registro, que sirven para saber si es la misma clave), pero nunca la clave en sí, así que tras pulsar «Cargar» tienes que introducir la clave de nuevo. Cada registro se puede eliminar por separado, y en un equipo compartido pulsa «Borrar historial» al terminar.