O cálculo de um hash MD5 exige menos da CPU do que as funções da família SHA?

115

O cálculo de um hash MD5 exige menos da CPU do que o SHA-1 ou SHA-2 no hardware de laptop x86 "padrão"? Estou interessado em informações gerais, não específicas de um determinado chip.

ATUALIZAÇÃO: No meu caso, estou interessado em calcular o hash de um arquivo. Se o tamanho do arquivo for importante, vamos supor que sejam 300 K.

— Mick
fonte

Isso não é uma resposta à sua pergunta, mas os proponentes do Skein apresentaram sua velocidade, e certamente não é mais fraco do que o MD5 em fim de vida neste momento. Embora as mensagens que você tem que fazer o hash sejam muito curtas, a velocidade pode ser uma desvantagem para uma função de hash criptográfica (especificamente, a rapidez com que outra pessoa pode implementá-la, não a velocidade com que ela é executada em seu laptop). schneier.com/skein1.2.pdf

— Pascal Cuoq

4

@Pascal: Skein não é o candidato mais rápido do SHA-3, especialmente em plataformas de 32 bits. Em um x86 de 64 bits, Skein atinge cerca de 300 MB / s (Skein-512 sendo um pouco mais rápido do que Skein-256), que é comparável ao SHA-1, mas no modo de 32 bits, o desempenho cai para menos de 60 MB / s, duas vezes mais lento que SHA-256. Por outro lado, SHABAL, outro candidato a SHA-3, oferece desempenho semelhante ao SHA-1 em plataformas de 32 e 64 bits.

— Thomas Pornin

123

Sim, o MD5 consome menos CPU. No meu Intel x86 (Core2 Quad Q6600, 2,4 GHz, usando um núcleo), recebo isso no modo de 32 bits:

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

e isso no modo de 64 bits:

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

Os números estão em megabytes por segundo, para uma mensagem "longa" (isso é o que você obtém para mensagens com mais de 8 kB). Isto é com sphlib , uma biblioteca de implementações de função hash em C (e Java). Todas as implementações são do mesmo autor (eu) e foram feitas com esforços comparáveis de otimizações; assim, as diferenças de velocidade podem ser consideradas realmente intrínsecas às funções.

Como um ponto de comparação, considere que um disco rígido recente funcionará a cerca de 100 MB / s, e qualquer coisa através de USB vai chegar a menos de 60 MB / s. Embora o SHA-256 pareça "lento" aqui, é rápido o suficiente para a maioria das finalidades.

Observe que OpenSSL inclui uma implementação de 32 bits de SHA-512 que é bastante mais rápida do que meu código (mas não tão rápida quanto o SHA-512 de 64 bits), porque a implementação de OpenSSL está em montagem e usa registros SSE2, algo que não pode ser feito em C. SHA-512 é a única função entre aquelas quatro que se beneficia de uma implementação SSE2.

Edit: em esta página ( arquivo ), pode-se encontrar um relatório sobre a velocidade de muitas funções hash (clique no link "Téléchargez maintenant"). O relatório está em francês, mas está quase todo cheio de tabelas e números, e os números são internacionais. As funções hash implementadas não incluem os candidatos SHA-3 (exceto SHABAL), mas estou trabalhando nisso.

— Thomas Pornin
fonte

2

Não acho que seus benchmarks sejam úteis. Uma comparação de velocidade de dois algoritmos com base na otimização equivalente, mas incompleta, é irrelevante. No mundo real, você não lança sua própria implementação, mas, em vez disso, usa implementações totalmente otimizadas. Os resultados desses são o que deve ser comparado.

— Edward Brey

10

@EdwardBrey Na verdade, eles estão quase totalmente otimizados. Na verdade, sua implementação md5 funciona muito mais rápido do que a que o OpenSSL oferece, então nem toda implementação será otimizada no "mundo real", como você diz. Além disso, embora não sejam perfeitos (você está certo sobre isso), eles servem como uma resposta perfeita para essa pergunta em particular.

— Gaspa79

50

No meu MacBook Air de 2012 (Intel Core i5-3427U, 2x 1,8 GHz, 2,8 GHz Turbo), SHA-1 é ligeiramente mais rápido do que MD5 (usando OpenSSL no 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

Atualização: 10 meses depois com OS X 10.9, SHA-1 ficou mais lento na mesma 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 atualização: no OS X 10.10, a velocidade SHA-1 voltou ao nível 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

Terceira atualização: OS X 10.14 com LibreSSL é muito mais rápido (ainda na mesma máquina). SHA-1 ainda sai por cima:

$ 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
fonte

2

estranho, meu ar é igual ao seu e obtive resultados de benchmark opostos. com 8192 bytes: md5 305549,52k; sha1 204668,57k

— Carlos Fontes

3

Hmm, também obtive resultados diferentes do ano passado na mesma máquina: md5 381756,70k, sha1 313881,86k. Talvez por causa da atualização para 10.9 (OpenSSL 0.9.8y).

— nwellnhof de

6

Essa é uma ótima resposta. isso mostra que você se importa. obrigado homem por compartilhar

— M em

13

A verdadeira resposta é: depende

Há alguns fatores a serem considerados, os mais óbvios são: a cpu na qual você está executando esses algoritmos e a implementação dos algoritmos.

Por exemplo, eu e meu amigo executamos exatamente a mesma versão do openssl e obtemos resultados ligeiramente diferentes com processadores Intel Core i7 diferentes.

Meu teste no trabalho com uma CPU Intel (R) Core (TM) i7-2600 @ 3,40 GHz

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

E o dele com uma CPU Intel (R) Core (TM) i7 920 @ 2,67 GHz

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 executando exatamente os mesmos binários do OpenSSL 1.0.1j 15 de outubro de 2014 do pacote oficial do ArchLinux.

Minha opinião sobre isso é que, com a segurança adicional de sha1, os designers de cpu são mais propensos a melhorar a velocidade de sha1 e mais programadores estarão trabalhando na otimização do algoritmo do que md5sum.

Acho que o md5 não será mais usado algum dia, pois parece que ele não tem nenhuma vantagem sobre o sha1. Também testei alguns casos em arquivos reais e os resultados foram sempre os mesmos em ambos os casos (provavelmente limitados por E / S de disco).

md5sum de um arquivo grande de 4,6 GB demorou exatamente o mesmo tempo que sha1sum do mesmo arquivo, o mesmo acontece com muitos arquivos pequenos (488 no mesmo diretório). Eu executei os testes uma dúzia de vezes e eles estavam obtendo os mesmos resultados consistentemente.

-

Seria muito interessante investigar isso mais profundamente. Acho que há alguns especialistas que podem fornecer uma resposta sólida sobre por que o sha1 está ficando mais rápido do que o md5 nos processadores mais novos.

— Johnride
fonte

6

Você precisa seriamente comprar um SSD (e / ou remover o McAfee) :)

— Maarten Bodewes

1

@owlstead caramba, eu esqueci de desligar o "modo lento" de minhas máquinas Linux quando tentei isso.

— Johnride

4

@Johnride, não faça benchmark de um arquivo. Execute-o a partir dos dados da memória ou, ainda mais simples, apenas refaça o mesmo valor.

— Robino

1

@Robino é isso que openssl speedfaz, que é o primeiro e mais significativo benchmark.

— Johnride

1

O MD5 também se beneficia do uso do SSE2, verifique BarsWF e diga que não. Basta um pouco de conhecimento em assembler para criar sua (s) própria (s) rotina (s) MD5 SSE2. Para grandes quantidades de taxa de transferência, no entanto, há uma compensação da velocidade durante o hashing em oposição ao tempo gasto reorganizando os dados de entrada para serem compatíveis com as instruções SIMD usadas.

— Bob o construtor
fonte

3

À primeira vista, não está claro se o SSE2 é usado para acelerar um encadeamento MD5 ou para emparelhar alguns encadeamentos MD5 paralelos; o último é obviamente fácil para a maioria dos algoritmos, mas isso não conta como um benefício do SSE2, pois normalmente o que é necessário é um único fluxo de dados.

— lapo

0

sha1sum é um pouco mais rápido no Power9 do que 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
fonte