Acerca de las implementaciones de código abierto de la función hash GOST R 34.11-2012 y su impacto en la firma electrónica de GOST R 34.10-2012

En un momento, la implementación de algoritmos criptográficos domésticos en la biblioteca libgcrypt me inspiró mucho. Se hizo posible usar estos algoritmos en Kleopatra y en Kmail y GnuPg en general, para considerar la biblioteca libgcrypt como una alternativa a openssl con el motor GOST. Y todo estuvo genial hasta el viernes pasado.

Me pidieron que verificara la firma electrónica de GOST R 34.10-2012-256 para un documento creado en Microsoft Office en MS Windows. Y decidí comprobarlo en Kleopatra (tengo Linux). Y qué piensas, la firma resultó ser incorrecta. Las dudas surgieron. Decidí comprobar en OpenSSL con el motor GOST . La firma ha sido verificada con éxito. Re-firmó urgentemente el archivo en Kleopatra y no pasó la verificación en MS Windows. Intentamos firmar y verificar otros archivos, todo estaba bien. La pregunta era ¿cuál es el problema? Dado que el hash del documento está involucrado en la firma, se decidió verificar el cálculo del hash por diferentes programas. En primer lugar, estaban involucradas implementaciones de código abierto para stribog :

• La famosa implementación de Degtyarev
• Implementación de Libgcrypt
• Libressl
• Motor Openssl

Y luego hubo un shock! El hash calculado por la "famosa implementación de Degtyarev" coincidió con el hash calculado en openssl con el GOST del endine, pero no coincidió con el valor de hash calculado usando libgcrypt y libressl.

Cómo ru_crypt tenía razón cuando escribió al principio de su artículo :

Inmediatamente le advierto que no verifiqué la corrección de las implementaciones.

Por cierto, el estándar en GOST R 34.10-2012 también dice que los ejemplos de control son solo de referencia. Debe entenderse claramente que los casos de prueba no garantizan que diferentes implementaciones den el mismo resultado para todas las ocasiones.

Para calcular los valores hash, se utilizaron las siguientes utilidades:

1) openssl

$ openssl dgst [–md_gost12_256|-md_gost12_512] <file> 

2) libressl

 $libressl dgst [–streebog256|streebog512] <file> 

3) libgcrypt

 $gchash [stribog256|stribog512] <file> 

4) La famosa implementación de Degtyarev

 $gost3411-2012 [-2|-5] <file> 

Aquí también hay algo interesante: en la transcripción latina, los stribogs escriben stribog o streebog. Sería bueno llegar a la uniformidad. Y entonces parece que estas son funciones diferentes. Personalmente, prefiero la primera opción: stribog.

Necesitaba un árbitro.

Como árbitro, se decidió utilizar el token PKCS # 11 RUTOKEN EDS-2.0, que admite los estándares criptográficos rusos GOST R 34.10-2012, GOST R 34.11-2012, VKO GOST R 34.10-2012 (RFC 7836) con una longitud de clave de 256 y 512 bits y está certificado por el FSB de Rusia como un medio de protección de información criptográfica (CPSI) y un medio de firma electrónica.

Además, el token RUTOKEN EDS-2.0 está ampliamente distribuido y muchos certificados de tienda en él para acceder a los servicios estatales y otros portales.
Para calcular el valor hash en el token, utilizaremos el script test_digest.tcl en Tcl :


¿Cuándo aparece esta discrepancia en la implementación? Hasta ahora, ha sido posible determinar que esta discrepancia se produce al calcular el hash de los archivos doc creados en MS Office. Además, el hash de los primeros 143 bytes se considera igual, y cuando se calcula el hash de 144 bytes, los valores son diferentes.

Los primeros 143 bytes en hexadecimal se ven así:

 d0cf11e0a1b11ae1000000000000000000000000000000003e000300feff0900060000000000000000000000010000000100000000000000001000002400000001000000feffffff0000000000000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 

Guárdelos en el archivo Doc1_143_hex.txt.

Los primeros 144 bytes en hexadecimal se ven así:

 d0cf11e0a1b11ae1000000000000000000000000000000003e000300feff0900060000000000000000000000010000000100000000000000001000002400000001000000feffffff0000000000000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 

Guárdelos en el archivo Doc1_144_hex.txt.

Es conveniente usar el script hex2bin.tcl para traducir de hexadecimal a binario:

 #!/usr/bin/tclsh proc usage {use error} { if {$use == 1} { puts $error puts "Usage:\nhex2bin <file with hex> <file for bin>\n" } } set countcert [llength $argv] if { $countcert != 2 } { usage 1 "Bad usage!" exit } set file [lindex $argv 0] if {![file exists $file]} { usage 1 "File $file not exist" exit } set fd [open $file] chan configure $fd -translation binary set cert_user [read $fd] close $fd if {$cert_user == "" } { usage 1 "Bad file with hex: $file" exit } set cert_user [binary format H* $cert_user] set fd [open [lindex $argv 1] w] chan configure $fd -translation binary puts -nonewline $fd $cert_user close $fd 

Convierta el código hexadecimal a binario:

 $./hex2bin Doc1_143_hex.txt Doc1_143.bin $./hex2bin Doc1_144_hex.txt Doc1_144.bin $ 

Ahora puede verificar cómo se calcula el hash mediante diversas implementaciones:
Primero, considere el hash para el archivo Doc1_143, bin:

 $ ./openssl dgst -md_gost12_256 Doc1_143.bin md_gost12_256(Doc1_143.bin)= e63bd3edc44f9a03fece4198b690a8ae291b973ae61b2a0f512a9a7479431a63 $ ./libressl dgst -streebog256 Doc1_143.bin streebog256(Doc1_143.bin)= e63bd3edc44f9a03fece4198b690a8ae291b973ae61b2a0f512a9a7479431a63 $ ./gchash stribog256 Doc1_143.bin e63bd3edc44f9a03fece4198b690a8ae291b973ae61b2a0f512a9a7479431a63 Doc1_143.bin $ ./gost3411-2012 -2 Doc1_143.bin GOST R 34.11-2012 (Doc1_143.bin) = e63bd3edc44f9a03fece4198b690a8ae291b973ae61b2a0f512a9a7479431a63 $ 

Ha llegado el momento más importante, el momento de la verificación en un sistema de protección de información criptográfica certificado:

 $ ./test_digest.tcl stribog256 Doc1_143.bin Connect the Token and press Enter Loading file for digest: Doc1_143.bin digest_hex= e63bd3edc44f9a03fece4198b690a8ae291b973ae61b2a0f512a9a7479431a63 $ 

Como puede ver, todo terminó para siempre.

Veamos qué sucede con el archivo Doc1_144.bin:

 $ ./openssl dgst -md_gost12_256 Doc1_144.bin md_gost12_256(Doc1_144.bin)= c766085540caaa8953bfcf7a1ba220619cee50d65dc242f82f23ba4b180b18e0 $ ./libressl dgst -streebog256 Doc1_144.bin streebog256(Doc1_144.bin)= 3965c99777eb1b64c783496fe950aa6540bc7baa399a3889995145afbdd76250 $ 

Eso es todo, los valores de los hashes no coinciden. Para la pureza del experimento, verificamos las implementaciones restantes:

 $ ./gchash_1.7.10 stribog256 Doc1_144.bin 3965c99777eb1b64c783496fe950aa6540bc7baa399a3889995145afbdd76250 Doc1_144.bin $ ./gost3411-2012 -2 Doc1_144.bin GOST R 34.11-2012 (Doc1_144.bin) = c766085540caaa8953bfcf7a1ba220619cee50d65dc242f82f23ba4b180b18e0 $ ./test_digest.tcl stribog256 Doc1_144.bin Connect the Token and press Enter Loading file for digest: Doc1_144.bin digest_hex= c766085540caaa8953bfcf7a1ba220619cee50d65dc242f82f23ba4b180b18e0 $ 

El hash calculado por la "famosa implementación de Degtyarev" coincide con el hash calculado en openssl con el motor GOST, pero no coincide con el valor de hash calculado usando libgcrypt y libressl.

Obtenemos un resultado similar si consideramos el hash stribog512.

Hay una conclusión Si desea que la firma electrónica GOST R 34.10-2012 generada por libressl y libgcrypt (u otros) sea compatible con openssl y, lo más importante, con la protección de la información criptográfica certificada en el sistema de certificación FSB de Rusia, use verificado implementaciones para calcular hashes. Espero que esta publicación evite muchos malentendidos, y los autores de la implementación de stribog en libressl, libgrypt y posiblemente otros ayudarán a eliminar estas discrepancias. Hoy, debo admitir que, en los productos anteriores, en realidad no se implementa GOST R 34.10-2012, sino algo más. Este es un algoritmo diferente. El ejemplo de prueba dado probablemente sería bueno incluirlo como ejemplo de prueba para GOST R 34.10-2012. Y voy a editar libgcrypt para Kleopatra y KMail. La leyenda de Cleopart y la criptografía rusa estaba inacabada.

PD: El artículo ya estaba listo cuando mi colega dijo que la discrepancia entre las implementaciones aparece cuando se encuentra una secuencia suficientemente larga de 0xFF. Ella, esta secuencia, por cierto, está presente al comienzo de los archivos doc de MS Office. Lo comprobé tal como está. El archivo contenía 189 bytes.