¿Es inseguro pasar el vector de inicialización y la sal junto con el texto cifrado?

Question

Soy nuevo en la implementación del cifrado y todavía estoy aprendiendo lo básico, parece.

Necesito capacidades de encriptación simétrica en mi código fuente abierto. Hay tres componentes de este sistema:

• Un servidor que almacena algunos datos de usuario, e información acerca de si es o no está cifrado, y cómo
• cliente # AC que permite a un usuario cifrar sus datos con un simple contraseña cuando se envían al servidor, y descifrar con la misma contraseña en la recepción
cliente
• Una JavaScript que hace lo mismo y, por tanto, debe ser compatible con el método de cifrado de C# del cliente

en cuanto a diversas bibliotecas de JavaScript, vine a través de SJCL, que ha SA Página preciosa demostración aquí: http://bitwiseshiftleft.github.com/sjcl/demo/

partir de esto, parece que lo que un cliente necesita saber (además de la contraseña utilizada) con el fin de descifrar el texto cifrado es:

• El vector de inicialización
• Cualquier sal que se usa en la contraseña
• el tamaño de la clave
• fuerza de autenticación (no estoy totalmente seguro de lo que es)

¿Es relativamente seguro guardar todos estos datos con el texto cifrado? Tenga en cuenta que esta es una base de código fuente abierta, y no hay forma de que pueda ocultar razonablemente estas variables a menos que le pida al usuario que las recuerde (sí, a la derecha).

Cualquier consejo apreciado.

Answer 1

Los vectores de inicialización y las sales se llaman así, y no las claves, precisamente porque no es necesario que se mantengan en secreto. Es seguro y habitual codificar dichos datos junto con el elemento codificado/hash.

Lo que una IV o sal necesita se debe usar una sola vez con una clave o contraseña determinada. Para algunos algoritmos (por ejemplo, el cifrado de CBC) puede haber algunos requisitos adicionales, que se satisfacen al elegir el IV al azar, con una probabilidad uniforme y un generador de números aleatorios criptográficamente fuerte. Sin embargo, la confidencialidad no es una propiedad necesaria para un IV o sal.

La encriptación simétrica raramente es suficiente para proporcionar seguridad; por sí mismo, el cifrado protege contra ataques pasivos, donde el atacante observa pero no interfiere. Para protegerse contra los ataques activos , también necesita algún tipo de autenticación. SJCL utiliza modos de encriptación CCM u OCB2 que combinan cifrado y autenticación, así que está bien. La "fuerza de autenticación" es la longitud (en bits) de un campo dedicado a la autenticación dentro del texto cifrado; una fuerza de "64 bits" significa que un atacante que intenta alterar un mensaje tiene una probabilidad máxima de 2 ^-64 para lograrlo sin ser detectado por el mecanismo de autenticación (y no puede saber si lo ha logrado sin intentarlo, es decir, enviar el mensaje modificado a alguien que conoce la clave/contraseña). Eso es suficiente para la mayoría de los propósitos. Una mayor fuerza de autenticación implica un texto cifrado más grande, por (aproximadamente) la misma cantidad.

No he visto la implementación, pero a partir de la documentación parece que los autores de SJCL conocen su oficio, y han hecho las cosas correctamente. Recomiendo usarlo.

recuerdo las advertencias habituales de contraseñas y Javascript:

• Javascript es el código que se ejecuta en el lado del cliente, pero se descarga desde el servidor. Este requiere para que la descarga esté protegida contra la integridad de alguna manera; de lo contrario, un atacante podría inyectar parte de su propio código, por ejemplo, un parche simple que también registra una copia de la contraseña ingresada por el usuario en alguna parte. En la práctica, esto significa que el código SJCL se debe servir en una sesión SSL/TLS (es decir, HTTPS).

• Los usuarios son seres humanos y los seres humanos son malos para elegir las contraseñas. Es una limitación del cerebro humano. Además, las computadoras se vuelven cada vez más potentes mientras que los cerebros humanos se mantienen más o menos inalterables. Esto hace que las contraseñas sean cada vez más débiles hacia ataques de diccionario, es decir, búsquedas exhaustivas de contraseñas (el atacante intenta adivinar la contraseña del usuario probando contraseñas "probables"). Un texto cifrado producido por SJCL se puede usar en un ataque de diccionario sin conexión: el atacante puede "intentar" contraseñas en sus propias computadoras, sin tener que verificarlas contra su servidor, y solo está limitado por sus propias capacidades informáticas. SJCL incluye algunas características para hacer fuera de línea los ataques de diccionario más difícil:

  1. SJCL utiliza una sal, que evita los costos compartidos (generalmente conocido como "tablas de cálculo previo", en particular las "tablas del arco iris", que son un tipo especial de tablas precalculadas) Al menos, el atacante tendrá que pagar el precio completo de la búsqueda del diccionario para cada contraseña atacada.
  2. SJCL usa la sal varias veces, hashándolo con la contraseña una y otra vez para producir la clave. Esto es lo que SJCL llama el "factor de fortalecimiento de contraseñas". Esto hace que la transformación de contraseña a clave sea más cara para el cliente, pero también para el atacante, que es el punto. Hacer que la transformación de la clave sea 1000 veces más larga significa que el usuario tendrá que esperar, tal vez, medio segundo; pero también multiplica por 1000 el costo para el atacante.