¿La pérdida del hash de su clave de cifrado es un riesgo de seguridad?

Si cada entidad, que quiere descifrar el archivo, solo conoce unas pocas claves posibles, la solución más sencilla es probar todas estas claves. Esto supone que su mecanismo de cifrado incluye un MAC , como debería ser de todos modos. El MAC le dirá si los datos son válidos o no, lo que atrapa las alteraciones de los datos (malintencionadas o no) y el caso más simple de usar una clave incorrecta. La combinación de MAC y el cifrado es plagado de peligros y, por lo tanto, se recomienda utilizar un modo que combine el MAC y el cifrado de forma segura ( EAX , GCM ...).

Si una entidad que desea descifrar los datos conoce muchas claves de cifrado potenciales, intentarlas todas podría ser ineficaz, en cuyo caso incluir un identificador de clave en el encabezado del archivo puede ayudar. El hash de la clave no es malo y no generará riesgos adicionales siempre que el hash sea "suficientemente distinto" del procesamiento de la clave para el cifrado. Estas son aguas peligrosas. Calificar adecuadamente esta propiedad, de manera científica, ya es lo suficientemente difícil. Una forma criptográfica de sonido es la siguiente: desde la clave compartida K , calcule SHA-256 ( K ). Esto produce 256 bits. Divida eso en dos mitades: los primeros 128 bits serán su "identificador de clave" (que se puede incluir en el encabezado del archivo), mientras que los otros 128 bits serán la clave simétrica que se usará realmente para cifrar los datos.

La búsqueda de fuerza bruta de 128 bits AES para encontrar una colisión SHA-1 no es mucho más preocupante que una búsqueda de fuerza bruta con descifrado de prueba. Si usas algo como PBKDF2 en lugar de un hash en bruto, entonces puedes hacerlo más difícil que el descifrado de prueba.

(Y, de hecho, una colisión como tal no ayudará a un atacante: si encuentran una clave diferente con el mismo hash, pueden publicar un artículo sobre la resistencia a la colisión SHA-1, porque con un espacio de búsqueda de 128 bits no debería ocurrir, pero no pueden descifrar sus datos.)

Usted tiene un problema si alguien rompe el SHA-1, por lo que fundamentalmente puede encontrar la clave del hash (truncado) mucho más fácilmente que una búsqueda de fuerza bruta (ataque de preimagen), pero en ese caso también lo hace todo el mundo que usa SHA. 1 para firmas digitales. (Y en el improbable caso de que SHA-1 esté roto, es probable que SHA-256 también tenga serios problemas).

También tiene un problema si le importa si un atacante puede decir qué mensajes se cifraron con la misma clave y cuáles con diferentes claves. Por ejemplo, si saben que una clave en particular se usa para mensajes importantes, y pueden ver más mensajes con esa clave, pueden saber que algo grande está sucediendo, incluso si no pueden decir qué (cf. enlace ). (Cambiar a claves públicas no ayudará con eso).

Hay casos en que la criptografía de clave pública no es apropiada, pero sin saber más sobre su caso de uso, es difícil saber si este es uno de ellos.

Por ejemplo, ¿está enviando la información cifrada a una pequeña cantidad de destinatarios o lotes? ¿Tantos que no es práctico tener las claves de sesión cifradas en todas sus claves públicas? ¿Sabe a quién se lo está enviando o si está distribuyendo la clave secreta compartida controlada por otra persona que no sea el remitente (por lo que no puede saber qué claves públicas debe usar, debe confiar en que las personas adecuadas conocen una clave secreta)? - incluso entonces, ¿por qué no puede haber una clave privada compartida? ¿Desea poder ampliar el conjunto de personas que pueden leerlo más adelante cuando es posible que no tenga acceso al mensaje original (revelando la clave secreta a otras personas, cuando no pueda volver a cifrar bajo una nueva clave pública)? )? ¿Está asumiendo implícitamente que el conocimiento del secreto compartido también proporciona la autenticidad del remitente? Si es así, sea muy cauteloso al respecto. (La respuesta de Tom Leek se expande sobre eso. Consulte también consejos para elegir un modo AE .)

No me gusta esta arquitectura en absoluto. Como mínimo, debe utilizar bcrypt con un factor de trabajo muy alto para producir su hash. Esto también agrega sal a tu hash, que te protege contra un ataque basado en la tabla del arco iris. Sin embargo, realmente creo que necesitas leer más sobre la clave pública.

Si su caso de uso requiere que no pueda saber de antemano a quién envía el mensaje, debe aclarar su caso de uso. La criptografía de clave pública no impide en absoluto que un nodo intermedio se reenvíe (piense en el correo electrónico cifrado de clave pública). Solo necesita un protocolo de encapsulación que lleve el texto cifrado.

En particular, parece que usted piensa que la clave pública requiere una negociación de clave activa como con TLS. Este no es el caso. Debe consultar los protocolos como el correo electrónico protegido PGP / GPG o S / MIME. PKI parece la mejor opción para su aplicación. Al aprovechar los servidores de claves públicos, obtiene la revocación y distribución de claves en el centavo de otra persona.

Compartir claves siempre ha sido una tuerca difícil de romper. Esa es la razón por la que se utiliza la criptografía de clave pública.

El sistema que está intentando implementar usaría un algoritmo de hash (SHA-1) para verificar la integridad de la clave compartida. Supongamos que mañana alguien puede descifrar el algoritmo de hash que está usando, entonces su sistema fallará. aunque el algoritmo de cifrado que está utilizando es lo suficientemente fuerte.

En mi opinión, no es una buena idea.

P.S. aunque está seguro con SHA-1 (a menos que sea una organización grande), cambie a SHA-256.para obtener más información, consulte this

No creo que esté debilitando catastróficamente el cifrado AES-128 al revelar el hash SHA-1 truncado de la clave. Es decir, bajo los ataques conocidos públicamente contra los dos en esta fecha.

"Invertir" el hash SHA-1 de un valor aleatorio de 128 bits se realiza en la actualidad de manera más eficiente utilizando ataques de intercambio de memoria de tiempo, como las tablas de arco iris. Pero truncar el hash priva al atacante de los progresos realizados hasta el momento en la precomputación.

[Eso fue para tratar de responder tu pregunta específica. En general, al inventar su propio esquema de criptografía, se encuentra en "aguas peligrosas", como dice otra respuesta. ¿Son tus suposiciones acerca de las habilidades del atacante realistas? ¿Qué otras propiedades de seguridad te importan? No se enterará en Stack Exchange si su solución es segura en las formas en que la necesita. Encuentre una solución que haya recibido suficiente escrutinio o haga que su solución sea examinada por profesionales. Buena suerte!]

Debo agregar que otra forma de hacer esto [sugerida por mi colega], (ya que el hash de la clave solo se necesita para buscar la clave real) es dividir el hash en dos partes y juntarlas para almacenarlas. en el mensaje De esta manera, nada sobre la clave de cifrado se filtra realmente. Pero si conoce la clave de cifrado, es trivial de calcular. Creo que esto es lo que llamamos un pad de una sola vez.