¿Es seguro usar un prefijo único para cada conjunto de datos, en lugar de usar IV (en AES)?

4

Continúe con mi pregunta aquí: Cómo evitar que el usuario adivine la clave (contraseña), si tiene acceso a todos los datos (excepto la clave)

Pensé, que en lugar de usar el campo sepreate IV para cada SSN (por ejemplo). Puedo usar un prefijo para eso.

Por ejemplo, en lugar de encrpyt {{ssn}} , cifro: {{user_id:ssn}} Cada usuario tenía una identificación única. Así que nadie puede encontrar duplicación en la base de datos.

Mi pregunta es: si cada vez que cifro datos, estoy usando un prefijo único para los datos. ¿Es cierto que no necesito usar IV?

    
pregunta Aminadav Glickshtein 17.11.2016 - 14:02
fuente

2 respuestas

2

En tu caso, correcto. No necesitas un IV al azar. La combinación de user_id , ssn y su Clave es única a nivel mundial, por lo que el atacante no podrá encontrar duplicados de un algoritmo seguro. (es decir, AES-128 o superior)

Editar: los IV deben ser siempre aleatorios. Mientras que en el caso de la OP puede que no sea tan importante, generalmente es, y es fácil de implementar, así que use IVs aleatorios. Ver comentarios.

Vale la pena señalar que no está utilizando un algoritmo de encadenamiento porque la cantidad de datos que está cifrando es muy pequeña. Esto reduce lo que tiene que preocuparse. El propósito de la IV es asegurar que el primer "bloque" sea único, y el propósito del Método de Encadenamiento es hacer que los bloques restantes parezcan aleatorios para que no haya un patrón discernible en los datos largos.

Pero sus datos encajan en un bloque (128 bits para AES-128), por lo que no es necesario.

    
respondido por el George Bailey 17.11.2016 - 14:48
fuente
2

Esta pregunta no se puede responder sin saber qué cifrado o modo está en uso, porque los diferentes tienen diferentes requisitos en sus IV y diferentes modos de falla. Hay dos casos generales aquí:

  1. Cifrados que requieren IV únicos .
    • AES-CTR es un buen ejemplo. El modo de falla para la reutilización IV aquí es pérdida catastrófica de confidencialidad : es probable que un atacante pueda descifrar todos sus valores.
  2. Cifrados que requieren IV aleatorios .
    • AES-CBC es un buen ejemplo. El modo de falla para la reutilización IV es pérdida de seguridad semántica : el mismo texto simple cifrado dos veces produce el mismo texto cifrado, de modo que el atacante puede decir que el mismo texto cifrado en dos contextos diferentes representa el mismo texto simple.

Claramente, si está usando algo como AES-CTR, debe usar IV únicos, no hay forma de evitarlo. Más generalmente, usted debe seguir las instrucciones para los cifrados específicos que está usando, lo que ni siquiera nos ha dicho, en lugar de intentar inventar una forma ad hoc que no lo haga. (¡Eso debería ser una enorme bandera roja!)

Segundo, estás jugando rápido y suelto con la idea de que estás usando un prefijo "único", porque estás describiendo este prefijo como user_id . Pero eso implica que los prefijos que tiene en mente son únicos para cada usuario . Pero lo que los cifrados normalmente quieren que use es un IV que es único para cada operación de cifrado : si encripta el mismo texto simple dos veces, se espera que suministre dos IV diferentes para que los cifrados produzcan diferentes. ciphertexts.

En tercer lugar, sus preocupaciones sobre la "duplicación" van por el camino equivocado. Dependiendo de lo que quieras decir con eso (¡lo que no está claro!):

  • Si usa IV aleatorios y los añade al texto sin formato, no puede haber textos cifrados en absoluto , ya que los cifrados son inyectivos : cada cifrado se puede "deshacer" y tienes la garantía de que recuperas el texto original. Esto implica que los pares duplicados (IV, texto cifrado) son imposibles.
  • Si le preocupa que cifrar el mismo texto simple dos veces en contextos diferentes produzca textos cifrados "duplicados", su propuesta de prefijo el user_id no lo resolverá. Cifrar el mismo texto sin formato {{user_id:ssn}} dos veces siempre producirá el mismo texto cifrado de todos modos.

Dije esto en mi respuesta a su otra pregunta reciente , y lo repito: no debe seguir adelante con sus planes para implementar la seguridad de su aplicación. Necesitas ayuda profesional y experta.

    
respondido por el Luis Casillas 17.11.2016 - 23:43
fuente

Lea otras preguntas en las etiquetas