¿El cálculo de un hash MD5 consume menos CPU que las funciones de la familia SHA?

115

¿El cálculo de un hash MD5 consume menos CPU que SHA-1 o SHA-2 en hardware x86 portátil "estándar"? Me interesa información general, no específica de un determinado chip.

ACTUALIZACIÓN: En mi caso, me interesa calcular el hash de un archivo. Si el tamaño del archivo importa, supongamos que es 300K.

— Mick
fuente

Esa no es una respuesta a su pregunta, pero los defensores de Skein plantearon su velocidad, y ciertamente no es más débil que el MD5 al final de su vida útil en este momento. En los mensajes que tiene que hacer hash son muy cortos, la velocidad puede ser una desventaja para una función de hash criptográfica (específicamente, qué tan rápido puede implementarlo otra persona, no qué tan rápido se ejecuta en su computadora portátil). schneier.com/skein1.2.pdf

— Pascal Cuoq

4

@Pascal: Sin embargo, Skein no es el más rápido de los candidatos SHA-3, especialmente en plataformas de 32 bits. En un x86 de 64 bits, Skein alcanza aproximadamente 300 MB / s (Skein-512 es algo más rápido que Skein-256), que es comparable a SHA-1, pero en el modo de 32 bits, el rendimiento cae a menos de 60 MB / s, dos veces más lento que SHA-256. Por otro lado, SHABAL, otro candidato de SHA-3, ofrece un rendimiento similar al SHA-1 en plataformas de 32 y 64 bits.

— Thomas Pornin

123

Sí, MD5 consume menos CPU. En mi Intel x86 (Core2 Quad Q6600, 2.4 GHz, usando un núcleo), obtengo esto en modo de 32 bits:

MD5       411
SHA-1     218
SHA-256   118
SHA-512    46

y esto en modo de 64 bits:

MD5       407
SHA-1     312
SHA-256   148
SHA-512   189

Las cifras están en megabytes por segundo, para un mensaje "largo" (esto es lo que obtiene para mensajes de más de 8 kB). Esto es con sphlib , una biblioteca de implementaciones de funciones hash en C (y Java). Todas las implementaciones son del mismo autor (yo) y se realizaron con esfuerzos comparables en las optimizaciones; por tanto, las diferencias de velocidad pueden considerarse realmente intrínsecas a las funciones.

Como punto de comparación, considere que un disco duro reciente funcionará a aproximadamente 100 MB / s, y cualquier cosa a través de USB superará los 60 MB / s. Aunque SHA-256 parece "lento" aquí, es lo suficientemente rápido para la mayoría de los propósitos.

Tenga en cuenta que OpenSSL incluye una implementación de 32 bits de SHA-512 que es bastante más rápida que mi código (pero no tan rápido como el SHA-512 de 64 bits), porque la implementación de OpenSSL está en ensamblaje y usa registros SSE2, algo que no puede hacerse en C. simple. SHA-512 es la única función entre las cuatro que se beneficia de una implementación SSE2.

Editar: en esta página ( archivo ), se puede encontrar un informe sobre la velocidad de muchas funciones hash (haga clic en el enlace "Telechargez maintenant"). El informe está en francés, pero en su mayoría está lleno de tablas y números, y los números son internacionales. Las funciones hash implementadas no incluyen los candidatos SHA-3 (excepto SHABAL) pero estoy trabajando en ello.

— Thomas Pornin
fuente

2

No creo que sus puntos de referencia sean útiles. Una comparación de velocidad de dos algoritmos basada en una optimización equivalente pero incompleta es irrelevante. En el mundo real, usted no lanza su propia implementación, sino que utiliza implementaciones totalmente optimizadas. Los resultados de esos son los que deben compararse.

— Edward Brey

10

@EdwardBrey En realidad, estos están bastante cerca de estar completamente optimizados. De hecho, su implementación md5 funciona mucho más rápido que la que ofrece OpenSSL, por lo que no todas las implementaciones se optimizarán en el "mundo real" como usted dice. Además, aunque estos no son perfectos (tienes razón en eso) en mi humilde opinión, sirven como una respuesta perfecta a esta pregunta en particular.

— Gaspa79

50

En mi MacBook Air 2012 (Intel Core i5-3427U, 2x 1.8 GHz, 2.8 GHz Turbo), SHA-1 es ligeramente más rápido que MD5 (usando OpenSSL en modo de 64 bits):

$ openssl speed md5 sha1
OpenSSL 0.9.8r 8 Feb 2011
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              30055.02k    94158.96k   219602.97k   329008.21k   384150.47k
sha1             31261.12k    95676.48k   224357.36k   332756.21k   396864.62k

Actualización: 10 meses después con OS X 10.9, SHA-1 se volvió más lento en la misma máquina:

$ openssl speed md5 sha1
OpenSSL 0.9.8y 5 Feb 2013
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              36277.35k   106558.04k   234680.17k   334469.33k   381756.70k
sha1             35453.52k    99530.85k   206635.24k   281695.48k   313881.86k

Segunda actualización: en OS X 10.10, la velocidad SHA-1 ha vuelto al nivel 10.8:

$ openssl speed md5 sha1
OpenSSL 0.9.8zc 15 Oct 2014
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              35391.50k   104905.27k   229872.93k   330506.91k   382791.75k
sha1             38054.09k   110332.44k   238198.72k   340007.12k   387137.77k

Tercera actualización: OS X 10.14 con LibreSSL es mucho más rápido (aún en la misma máquina). SHA-1 todavía se destaca:

$ openssl speed md5 sha1
LibreSSL 2.6.5
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              43128.00k   131797.91k   304661.16k   453120.00k   526789.29k
sha1             55598.35k   157916.03k   343214.08k   489092.34k   570668.37k

— Nwellnhof
fuente

2

raro, mi aire es el mismo que el tuyo y obtuve resultados de referencia opuestos. con 8192 bytes: md5 305549.52k; sha1 204668.57k

— Carlos Fontes

3

Hmm, también obtengo resultados diferentes a los del año pasado en la misma máquina: md5 381756.70k, sha1 313881.86k. Quizás debido a la actualización a 10.9 (OpenSSL 0.9.8y).

— nwellnhof

6

Esa es una gran respuesta. demuestra que te preocupas. gracias hombre por compartir

— M el

13

La verdadera respuesta es: depende

Hay un par de factores a considerar, los más obvios son: la CPU en la que está ejecutando estos algoritmos y la implementación de los algoritmos.

Por ejemplo, mi amigo y yo ejecutamos exactamente la misma versión de openssl y obtenemos resultados ligeramente diferentes con diferentes procesadores Intel Core i7.

Mi prueba en el trabajo con una CPU Intel (R) Core (TM) i7-2600 a 3.40GHz

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              64257.97k   187370.26k   406435.07k   576544.43k   649827.67k
sha1             73225.75k   202701.20k   432679.68k   601140.57k   679900.50k

Y el suyo con una CPU Intel (R) Core (TM) i7 920 @ 2.67GHz

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              51859.12k   156255.78k   350252.00k   513141.73k   590701.52k
sha1             56492.56k   156300.76k   328688.76k   452450.92k   508625.68k

Ambos estamos ejecutando exactamente los mismos binarios de OpenSSL 1.0.1j 15 de octubre de 2014 desde el paquete oficial de ArchLinux.

Mi opinión sobre esto es que con la seguridad añadida de sha1, es más probable que los diseñadores de CPU mejoren la velocidad de sha1 y más programadores trabajarán en la optimización del algoritmo que md5sum.

Supongo que algún día ya no se usará md5 ya que parece que no tiene ninguna ventaja sobre sha1. También probé algunos casos en archivos reales y los resultados fueron siempre los mismos en ambos casos (probablemente limitado por la E / S del disco).

md5sum de un archivo grande de 4.6GB tomó exactamente el mismo tiempo que sha1sum del mismo archivo, lo mismo ocurre con muchos archivos pequeños (488 en el mismo directorio). Hice las pruebas una docena de veces y obtuvieron constantemente los mismos resultados.

-

Sería muy interesante investigar esto más a fondo. Supongo que hay algunos expertos que podrían proporcionar una respuesta sólida a por qué sha1 se está volviendo más rápido que md5 en los procesadores más nuevos.

— Johnride
fuente

6

Realmente necesita comprar un SSD (y / o eliminar McAfee) :)

— Maarten Bodewes

1

@owlstead maldita sea, me olvidé de apagar el "modo lento" de mis cajas Linux cuando probé esto.

— Johnride

4

@Johnride, no compares desde un archivo. Ejecútelo desde los datos en la memoria o incluso más simple, simplemente vuelva a procesar el mismo valor.

— Robino

1

@Robino eso es lo que openssl speedhace, que es el primer y más significativo punto de referencia.

— Johnride

1

MD5 también se beneficia del uso de SSE2, consulte BarsWF y luego dígame que no es así. Todo lo que se necesita es un poco de conocimiento sobre ensamblador y puede crear sus propias rutinas MD5 SSE2. Sin embargo, para grandes cantidades de rendimiento, existe una compensación de la velocidad durante el hash en oposición al tiempo que se dedica a reorganizar los datos de entrada para que sean compatibles con las instrucciones SIMD utilizadas.

— Bob el Constructor
fuente

3

A primera vista, no está claro si SSE2 se utiliza para acelerar un hilo MD5 o para emparejar algunos hilos MD5 paralelos; esto último es, por supuesto, fácil para la mayoría de los algoritmos, pero eso no cuenta como beneficio de SSE2 ya que normalmente lo que se necesita es un único flujo de datos.

— lapo

0

sha1sum es bastante más rápido en Power9 que en md5sum

$ uname -mov
#1 SMP Mon May 13 12:16:08 EDT 2019 ppc64le GNU/Linux

$ cat /proc/cpuinfo
processor       : 0
cpu             : POWER9, altivec supported
clock           : 2166.000000MHz
revision        : 2.2 (pvr 004e 1202)

$ ls -l linux-master.tar
-rw-rw-r-- 1 x x 829685760 Jan 29 14:30 linux-master.tar

$ time sha1sum linux-master.tar
10fbf911e254c4fe8e5eb2e605c6c02d29a88563  linux-master.tar

real    0m1.685s
user    0m1.528s
sys     0m0.156s

$ time md5sum linux-master.tar
d476375abacda064ae437a683c537ec4  linux-master.tar

real    0m2.942s
user    0m2.806s
sys     0m0.136s

$ time sum linux-master.tar
36928 810240

real    0m2.186s
user    0m1.917s
sys     0m0.268s

— B Abali
fuente