AES-CBC luego SHA vs AES-GCM para cifrar y autenticar un token web

-1

Estoy intentando tener algo como JWT pero algo ad hoc y cifrado. El token en sí mismo es simplemente un JSON stringificado que contiene el ID de usuario y la marca de tiempo de Unix. Ahora, traté de usar AES-128-GCM; sin embargo, realicé algunas modificaciones simples en el texto cifrado antes de descifrarlo, solo agregué algunos bytes al texto cifrado y descubrí que se descifra correctamente. Eso significa que esos bytes se contabilizaron como relleno y ¿Que AES GCM es autentificar y luego cifrar el algoritmo? Porque siento que cifrar luego autenticar se siente más seguro para mí. Además, ¿la autenticación AES GCM es lo suficientemente segura como para compararse con SHA256 por ejemplo o es el nivel CRC para una integridad rápida y no se puede usar para una autenticación segura como HMAC?

En otras palabras : ¿es AES-128-CBC luego SHA-256 más seguro que AES-128-GCM?

    
pregunta pls no 10.05.2018 - 06:10
fuente

1 respuesta

3
  

¿AES-128-CBC es SHA-256 más seguro que AES-128-GCM?

No son comparables en absoluto. ¡SHA-256 es no un MAC! Un MAC requiere un secreto. AES-128-CBC con un HMAC-SHA-256 en el texto cifrado sería más similar a AES-128-GCM, pero aún así se preferiría GCM simplemente porque le da menos oportunidad de arruinarlo.

  

Intenté usar AES-128-GCM, sin embargo, realicé algunas modificaciones simples en el texto cifrado antes de descifrar, solo anexé algunos bytes al texto cifrado y descubrí que se descifra correctamente

Esto suena como si estuvieras usando la biblioteca incorrectamente o la biblioteca tiene un error. ¿Qué es la biblioteca? ¿Tiene un ejemplo que reproduzca el problema?

  

AES GCM es autenticar y luego cifrar el algoritmo?

En realidad no. No estoy completamente seguro de la terminología aquí, pero no creo que se considere realmente MAC-luego-cifrar o cifrar-luego MAC, está en una clase separada de modos AEAD que incluyen un MAC en el algoritmo de cifrado en lugar de antes o después Sin embargo, diría que está más cerca de encriptar, luego de MAC, como se puede ver en el diagrama en Wikipedia es el texto cifrado que se alimenta a la función GHASH, no al texto sin formato.

  

cifrar y luego autenticar se siente más seguro para mí

Consulte esta pregunta sobre cifrar, entonces, MAC vs MAC, luego, encriptar. Cifrar-luego-MAC generalmente se recomienda, ya que previene cosas como el oráculo de relleno (si se hace correctamente), sin embargo También hay que tener en cuenta cosas como no olvidar incluir el IV en el MAC. No deberías estar haciendo esto por ti mismo, deberías usar una biblioteca que maneje todas las "cosas criptográficas" por ti.

  La autenticación

AES GCM es incluso lo suficientemente segura como para compararse con SHA256, por ejemplo, o es el nivel CRC para una rápida integridad

Como se indicó anteriormente, SHA-256 no es un MAC, pero la mejor comparación que encontré de HMAC-SHA-256 y GHASH es aquí . HMAC-SHA-256 truncado a 16 bytes parece estar seguro a los 128 bits completos, mientras que la seguridad de GHASH depende del tamaño del texto cifrado. Si un atacante intenta falsificar un texto cifrado de 1 bloque, tiene una probabilidad de éxito de 1/2 128 , sin embargo, si intentan un mensaje de bloqueo 2 32 - 1 (el tamaño máximo para GCM) su probabilidad aumenta a aproximadamente 1/2 96 . Es poco probable que esto importe en la práctica, ya que 2 96 sigue siendo prohibitivamente grande, especialmente porque requiere el uso de un texto cifrado de muchos gigabytes.

La otra cosa que hay que recordar acerca de GCM es que su autenticidad depende de fuentes únicas. Si alguna vez se reutiliza un nonce, ya no se puede confiar en la autenticidad de los mensajes, lo que es una preocupación si no está extremadamente seguro de que los nonces nunca se reutilizarán. La desventaja es que GCM es generalmente mucho más rápido que CBC + HMAC, razón por la cual TLS suele preferir que las claves duren poco (lo que hace que la reutilización de nonce sea aún menos probable) Como se explica en aquí , siempre que use un contador de 12 bytes, está muy seguro nunca retrocederá (por ejemplo, debido a un fallo de hardware) o un 16 byte IV aleatorio que debería estar bien.

    
respondido por el AndrolGenhald 10.05.2018 - 15:43
fuente

Lea otras preguntas en las etiquetas