0
184
Views¿Por qué este cifrado cCryptoGS AES proporciona todo el texto cifrado más o menos igual?
Actualmente estoy experimentando con el cifrado AES con Google App Script y descubrí cCryptoGS.
Se siente extraño, ya que todos los textos cifrados parecen comenzar con U2FsdGVkX1 (aunque cambié la parte , esta es mi frase de contraseña en el ejemplo, a otra muy diferente). No estoy seguro de recordar correctamente, una vez probé AES en el pasado, pero en Nodejs, y se veía tan diferente, obtendré un texto completamente diferente cifrado incluso si cambio solo un carácter en cualquiera de mis mensajes , o mi llave.
Incluso en esta publicación ¿Cómo se implementa AES en CryptoJS? , el texto cifrado también comienza con U2FsdGVkX1 .
Lo que estoy preguntando es esto: ¿Este cCryptoGS realmente hace lo que dice hacer? (es decir, para aplicar el cifrado AES a un mensaje)
Aquí está el sitio web https://ramblings.mcpher.com/gassnippets2/cryptojs-libraries-for-google-apps-script/ También hay gráficos en el sitio que muestran que Google App Script no puede manejar bien los cálculos complicados, por lo que parece legítimo , pero el resultado parece ser tan... extraño... Dado que, en general, AES parecía ser una de las mejores opciones para realizar el cifrado.
Si así es como debería funcionar AES, ¿hay alguna forma de que parezca más aleatorio? Muchas gracias de antemano, :(
Muchas gracias por adelantado,
1 answers
Answer question0
CryptoJS puede procesar frases de contraseña y claves para el cifrado y descifrado. Las cadenas se interpretan como frases de contraseña, WordArray s como claves, s. La entrada de cifrado .
cCryptoGS envuelve la variante de la frase de contraseña y admite los algoritmos AES, DES, TripleDES y Rabbit; consulte Uso .
Por ejemplo, para AES, cCryptoGS/CryptoJS cifra con AES-256, por lo que se debe pasar una frase de contraseña además del texto sin formato.
Antes del cifrado, se genera una sal aleatoria de 8 bytes y, a partir de la frase de contraseña y la sal, se deriva una clave de 32 bytes y un IV de 16 bytes con la función de derivación de clave OpenSSLEVP_BytesToKey() .
El resultado se genera en formato OpenSSL para compatibilidad con OpenSSL, que consta de la codificación ASCII de Salted__ seguida de los 8 bytes salt y el texto cifrado real, con la expresión entera codificada en Base64.
La codificación Base64 de Salted__ es U2FsdGVkX18=, donde U2FsdGVkX1 es fijo (los dos últimos caracteres dependen del primer byte de Salted y, por lo tanto, pueden cambiar). Por lo tanto, cualquier encriptación comienza con U2FsdGVkX1, pero esto no revela ninguna información.
Entonces sí, está encriptado con AES-256 y el prefijo constante U2FsdGVkX1 no es crítico.
Sin embargo, la función de derivación de claves EVP_BytesToKey() se considera insegura hoy en día, especialmente con los parámetros utilizados por cCryptoGS/CryptoJS (resumen MD5 roto y un recuento de iteraciones de 1), por ejemplo aquí, 3ra parte , por lo que su uso no puede recomendarse (aparte quizás por compatibilidad).
Esto se aplica a las funcionalidades empaquetadas que utilizan frases de contraseña para el cifrado/descifrado. cCryptoGS también permite directamente el uso de las funciones de CryptoJS, consulte CryptoJS direct , cuya seguridad se evaluará individualmente.
La forma segura es pasar la clave y el IV directamente , o cuando se usa una frase de contraseña para no aplicar la función EVP_BytesToKey() , sino una función de derivación de clave confiable como PBKDF2.
Estas variantes son compatibles con CryptoJS, pero aparentemente no con cCryptoGS, al menos no con las funcionalidades envueltas.
También tenga en cuenta que al menos las fuentes de cCryptoGS vinculadas parecen estar basadas en CryptoJS versión 3.1.2 que es de 2013, s. Fuentes cCryptoGS (la versión actual de CryptoJS es 4.1.1).