¿Se pueden usar las funciones hash con el modo CTR o OFB?

Question

¿Se pueden usar las funciones hash con el modo CTR o OFB?

#1 de David Wachtfogel (2 votos)
#2 de B-Con (2 votos)
#3 de GdD (1 votos)
#4 de Tom Leek (1 votos)
#5 de CodesInChaos (1 votos)

6

He estado escribiendo una clase que cifra y descifra con cifrados de bloques. Quiero usar el modo de contador (CTR / CM). Sabemos que el modo de contador genera una secuencia de teclas basándose en contadores, luego XOR la secuencia de teclas con texto sin formato para producir texto cifrado. Por lo tanto, uno puede descifrar mientras pueda reproducir el flujo de claves, es decir, reproducir el contador y obtener la clave correcta.

Observé que el método de descifrado de un cifrado no es necesario en el modo CTR, ya que para reproducir el flujo de claves solo necesitamos cifrar los bloques de contador nuevamente.

Entonces, ¿por qué no puedo reemplazar el cifrado ordinario con una función hash (por lo tanto, hacer parte clave del contador) o una función HMAC (que acepta una tecla)? ¿Las funciones hash no son tan pseudoaleatorias en comparación con los sistemas de cifrado en la generación de cadenas de claves, o hay más razones?

p.s .: Esta pregunta también funciona con el modo OFB: la aplicación de una IV con o sin una clave una y otra vez también produce algo que parece una secuencia de teclas.

p.s.2: un ejemplo:

1) Construyamos un contador de 16 bytes:

aPADDING00000000
aPADDING00000001
aPADDING00000002

Aquí obtenemos 3 bloques.

2) Luego use HMAC de MD5 para generar el flujo de claves:

key = 'This is a key.'
stream[0] = HMAC('This is a key.','aPADDING00000000').hexdigest()
stream[1] = HMAC('This is a key.','aPADDING00000001').hexdigest()
stream[2] = HMAC('This is a key.','aPADDING00000002').hexdigest()

# now stream is:
# ['73f2e665c30aaec5bbead51166aaa85f',
#  '91392d0755638fbce5c689f96b02494f',
#  '1d18a81751179858d151dd86179385f9']

stream_str = "".join(stream).decode('hex') # stream_str = '73f2 ... 85f9'.decode('hex')

3) Ahora stream_str se parece mucho a una secuencia de teclas. Para encriptar:

plaintext = 'This is a plaintext that has length of 48 bytes.'
ciphertext = stream_xor(plaintext,stream_str) # stream_xor XORs the two inputs bit by bit.

o, para descifrar:

decrypted = stream_xor(ciphertext,stream_str) # ciphertext produced before.

hash encryption

pregunta Lucifer Orichalcum 17.07.2012 - 17:07

fuente

5 respuestas

Lea otras preguntas en las etiquetas hash encryption

Usar un certificado verificado para firmar a otros Asegurando una arquitectura multi-tenant

score 2 · Answer 1

Angelo Rosiello y Roberto Carrozzo propusieron este esquema exacto (OFB basado en hash) en un documento de 2005 llamado "ARC: un cifrado de flujo síncrono de funciones hash" y mostraron que es seguro siempre y cuando se use una función criptográfica hash fuerte. La función hash es pseudoaleatoria.

Pero la pregunta es: ¿por qué usar una función hash en lugar de un cifrado de bloque? Los cifrados de bloque como AES han demostrado ser más resistentes con el tiempo para atacar en comparación con las funciones hash. AES es generalmente más rápido que un SHA256 HMAC. ¿Qué ventaja tiene usar HMAC para esto?

score 2 · Answer 2

Entonces, ¿por qué no puedo reemplazar el cifrado ordinario con una función hash (por lo tanto, hacer parte clave del contador) o una función HMAC (que acepta una tecla)? ¿Las funciones hash no son tan pseudoaleatorias en comparación con los sistemas de cifrado en la generación de cadenas de claves, o hay más razones?

En teoría, CTR puede trabajar con cualquier PRF seguro. Con un tamaño de bloque de 16 bytes, un cifrado de bloque (modelado como un PRP) actúa de manera suficiente como un PRF que puede usarse como uno solo, pero cualquier PRF funcionará. HMAC es un PRF basado en hash, por lo que funciona en modo CTR.

(Creo que OFB tiene la misma propiedad de trabajar con cualquier PRF seguro. Parece que tiene sentido, pero no veo ninguna referencia explícita que lo confirme).

score 1 · Answer 3

Puedes, sin embargo, ¿por qué quieres hacerlo? El punto de los cifrados de bloque y de flujo es aumentar la fuerza de los protocolos de cifrado cuando se supone que los datos se descifran. Si utiliza un método hash, no podrá descifrar los datos, ya que los hashes son una forma.

Si está intentando crear datos clave en lugar de cifrarlos, entonces sí, podría hacerlo de esta manera, sin embargo, está reinventando la rueda.

score 1 · Answer 4

Vea NIST SP800-90A que describe algunos generadores de números pseudoaleatorios , en particular Hash_DRBG y HMAC_DRBG, que se basan en hash de una manera similar a lo que sugieres. La parte difícil es diseñar el sistema de modo que la seguridad pueda ser probada de alguna manera (es decir, reducida a una suposición "razonable" sobre la función hash en sí).

Una buena razón para usarlos es en sistemas embebidos con un tamaño de código limitado, y que ya tienen una implementación de una función hash para otros usos.

Una buena razón no para usarlos es que tienden a ser bastante más lentos que los cifrados en bloque y, más aún, los cifrados de flujo especializados.

score 1 · Answer 5

Puede usar una función hash o HMAC en una construcción en modo CTR para crear un cifrado de flujo seguro. Esto no funciona con funciones hash que solo intentan proporcionar resistencia a la colisión y la imagen previa, pero requiere algunas propiedades de pseudo aleatoriedad. Por suerte, las funciones hash más modernas tienen esta propiedad.

Como ejemplo práctico, puede ver el Salsa20 stream-cipher, que es esencialmente una función hash en el modo CTR .

Con OFB tienes que tener cuidado. Necesita mezclar la clave en cada paso, y no solo en el primero. En particular $ C_i = Hash (C_ {i-1}) $ es trivialmente vulnerable a un ataque de texto simple conocido. Si aprende parte del flujo de claves, puede predecir todo el flujo de claves después de ese punto.

Hay algunas preguntas relacionadas sobre crypto.SE: