Normalmente, usaría PBKDF2 para generar una clave que usaría con AES. Pero viendo que el hash será tan largo como los datos que necesito cifrar, ¿hay alguna desventaja con solo XOR'ing?
Mi razonamiento es que si puedes obtener el hash, tendrías la clave AES de todos modos.
* Solo para agregar la razón por la que usaría PBKDF2 es que tiene que usar una contraseña proporcionada por el usuario. Los datos encriptados pueden considerarse aleatorios. También estoy salado.
Al usar PBKDF2 de esa manera, lo que realmente estás haciendo es convertir PBKDF2 en un cifrado de flujo . Los tres problemas principales con esta idea son:
El uso de PBKDF2 como un cifrado de flujo no se ha investigado a fondo. Puede estar bien O no. Las propiedades de seguridad de PBKDF2 se analizaron solo en su mayoría para resultados cortos, y luego, solo como KDF.
Si reutiliza la misma contraseña y sal, entonces obtiene el mismo resultado. En un modo de cifrado XOR con los datos, esto es muy malo si cifras dos elementos. En ese sentido, ahora ha fusionado la sal PBKDF2 con lo que era el IV para AES, combinando así los requisitos. Será mejor que te asegures de que tu protocolo general se ocupe de eso correctamente. (En ese sentido, esto es similar al uso de PBKDF2 para generar una clave para el cifrado RC4, porque RC4 no tiene IV).
PBKDF2 se hace lento con iteraciones. Sucede que su velocidad de procesamiento es también proporcional a la longitud de salida solicitada. Si usa PBKDF2 / SHA-1 y solicita, por ejemplo, 24 bytes, y usa 10000 iteraciones, entonces realmente pagará por 20000 iteraciones. Esto puede volverse rápidamente intolerable para mensajes más largos para cifrar. Tenga en cuenta que el atacante que ejecuta un ataque de diccionario no necesita no para calcular toda la secuencia; por lo tanto, incurres en el riesgo de ralentizar innecesariamente al defensor y dejar que el atacante corra a toda velocidad.
Sí. Debido a los ataques de texto sin formato conocidos, un adversario que puede encontrar el texto en claro puede usarlo para descubrir el hash para descifrar los textos cifrados que el adversario no tiene el texto en claro.
AES está diseñado específicamente para evitar que un atacante descubra la clave, incluso si conoce tanto el texto plano como el texto cifrado.
Si desea obtener un rendimiento y seguir utilizando XOR, sería adecuado agregar caracteres aleatorios a la contraseña y luego incluir estos caracteres con el mensaje.
Por ejemplo, para cifrar M, generas un nonce aleatorio N. Entonces usas: PBKDF2 (Contraseña + N) xor M = C
Enviar NC al destinatario
NC se descifra al seleccionar el nonce, y luego el destinatario proporciona la contraseña precompartida, por lo que
PBKDF2 (Contraseña + N) xo C = M.
Para averiguar la clave de un mensaje cifrado con XOR + PBKDF2 (Contraseña + A), y tener un texto plano y un texto cifrado pertenecientes a PBKDF2 (Contraseña + N), aún tendría que descifrar el PBKDF2 usando fuerza bruta simple.
No hay ninguna razón por la que esta construcción deba ser insegura, a excepción de los ataques estándar de texto simple y cifrado. Para prevenirlos, todavía necesitas un mecanismo de autenticación. (como AES-GCM o Poly-1305).
Como construcción práctica, te sugiero que uses un offset. Por lo tanto, usaría los primeros bits del PBKDF para derivar una clave para la autenticación y el resto como almohadilla.
Luego usaría, por ejemplo, HMAC-SHA256 para autenticar el texto cifrado y agregar la etiqueta.
Esto solo funciona en caso de que sepa el tamaño de los datos antes de realizar la derivación de la contraseña. Esta es la razón por la que no se usa ampliamente.
¿Por qué es seguro?
Estoy saltando la parte de autenticación aquí, ya que esto es estándar para los cifrados de flujo.
Básicamente, PBKDF es una llamada repetida a HMAC, que es un PRF, por lo que si su sal es aleatoria (es su IV aquí) la salida es pseudoaleatoria y debería ser tan segura como HMAC.
Lea otras preguntas en las etiquetas hash encryption