Executando verificação de segurança...
7
maniero
2 min de leitura ·

Para um algoritmo de hash, é interessante ter um seed?

Deixa-me explicar melhor.

Para melhorar a segurança ou até obter outros efeitos, em algum cenário de nicho, eu penso se seria interessante semirandomizar a geração do código de hash e assim em cada execução a ordem dos elementos na tabela que é montada com esse hash deve ser diferente, mesmo que sejam os mesmos dados.

Obviamente que isso só mudaria a cada execução e não em cada instância, e principalmente em cada adição de um novo elemento. Só para deixar claro para quem não tem domínio do assunto.

Então você tem uma fórmula padrão, mais um termo que já costuma ser usado na fórmula (o seed, se é que podemos chamar assim) e ele seria determinado no início de cada execução. Poderia ser até dentre uma lista de números pré-definidos e não algo geral, assim não atrapalharia a chave ser ruim e gerar muitas colisões.

Garantindo que não é tão determinístico assim, alguns tipos de ataque podem ser minimizados. Nada relacionado com criptografia.

Não preciso dizer que este código não seria usado para persistência e nenhum hash deveria.

Mas não consigo pensar em todas as implicações disso. Qual seria a justificativa contra ou a favor? Estou pensando algo errado?

Também seria legal saber se você já fez ou viu algo assim, e a motivação.

Já que obviamente eu não tenho todo o domínio do assunto, se houver dúvidas estou disposto a esclarecer nos comentário e editar aqui.

Para ver mais:

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Carregando publicação patrocinada...
2
Silva97

Já existe esse conceito e se chama salt, é usado nas hashes de senhas do Linux por exemplo e é uma prática comum já faz alguns anos. É comum ser usado em aplicações WEB também. Veja a função crypt() do PHP por exemplo que usa salt: https://www.php.net/manual/en/function.crypt.php

Isso serve para evitar ataques de rainbow table, que são tabelas com senhas pré-hasheadas. Sem salt se a senha estiver na tabela leva menos de 1 segundo para quebrá-la. Por outro lado, com salt você tem que fazer o hash de cada senha usando o mesmo salt. Mesmo que a senha esteja no dicionário poderia levar bastante tempo para quebrá-la.

EDIT

Antes que mais alguém cometa o mesmo erro vale deixar claro aqui: nesse comentário não estou falando sobre encriptação de dados mas sim sobre algoritmos de hash.

O que acontece é que no Brasil a grande maioria comete o erro de achar que criptografia e encriptação são a mesma coisa. Criptografia é o nome de uma área de estudos, onde algoritmos de hash são estudados por essa área. Por isso que sim: hash tem a ver com a área de criptografia. E por isso que nos links que passei a palavra "criptografia" será utilizada, mas não, os conteúdos não estão falando sobre encriptação de dados.

Esse artigo corrige muito bem esse erro cometido pelos brasileiros: https://medium.com/@leocavalcante/hash-digest-n%C3%A3o-%C3%A9-criptografia-940374fe565c

1
cyp

"Menos de 1 segundo para quebrá-la" você está muito otimista em relação à isso, presupondo que algoritmos de hash criptográficos, oq não é o que o OP quer dizer, são muito ineficazes e inseguros.

Além disso, mesmo com salto, você pode facilmente quebrar um hash. Só que "facilmente" leva algum tempo.

1
Silva97

Leia sobre rainbow table que você vai entender porque leva menos de 1 segundo para quebrar. E não é ótimismo, é realmente assim que acontece.

Além disso, mesmo com salto, você pode facilmente quebrar um hash. Só que "facilmente" leva algum tempo.

Eu falei isso no meu comentário. Não ficou claro?

1
maniero
Autor
Autor

Com computação quântica, parece que a maioria das criptografias vão virar pós :) Vamos ver, não é um assunto que sei muito. Vai ter solução.

-1
maniero
Autor
Autor

"Nada relacionado com criptografia."

Todos os lugares que eu postei acharam que era sobre criptografia, apesar de todos os links que eu mandei mostrando sobre o uso. Só um usuário entendeu que não era sobre isso, mandou link muito bom para ajudar, mas não quis responder, e é usuário daqui também.

Não é sobre criptografia, senhas ou coisas desses tipo, é sobre códigos hash simples, geralmente usados, mas não limitados a tabelas de espalhamento.

Inclusive o sal permite diferenciar objetos, que eu mostro que não é o caso.

E coloquei links mostrando mais contexto.

Eu segui os links acima e todos remetem à criptografia.

O ensinamento disto é que as pesssoas acham que hash é sobre criptografia, quando na verdade é um dos múltiplos usos, e um até de uso limitado, a maioria não é sobre isso. Preciso fazer algo para mudar essa situação, mesmo. Pena que a maioria das pessoas que possuem esses equívocos não vou gostar ou até saber que existe.

E o mais importante. O que eu estou usando é a parte de não criptografia de hash. Está lá todas informações que mostram isso. Depois eu falo mais que não é sobre isso. Potanto qualquer coisa que envolva criptografia, pode ser útil, pode ser a maior verdade do mundo (e pelo que li, nem tudo é), se enolve criptografia é outro assunto que não serve para o que eu preciso saber. E depois de um tempo começaram aparecer mais pessoas em outras plataformas que entenderam e deram mais infrmações úteis que não são sobre criptografia, mas sim sobre geração de códigos de hash, especialmente, mas não só, para usar em tabelas de espalhamento, que nada tem a ver com criptografia. Só porque hash pode ser usado criptograficamente, e nunca neguei isso, pelo contrário, fiz questão de mostrar que falo da outra parte, não indica que ambos são a mesma coisa, pelo contrário, Hash é muito maior que criptografia, e criptografia pode exitir sem hash, apenas há uma intersecção entre os dois em um momento.

4
kht

Obrigado pela menção :-)

Eu não respondi antes porque não tenho domínio de certos detalhes, mas enfim, segue um exemplo com o pouco que sei.

Python faz algo do tipo com o hash de strings. Ou seja, se vc fizer um programa que faz print(hash('abc')) e rodar várias vezes, a cada execução terá um resultado diferente.

Isso porque o algoritmo de hash usa um seed aleatório cada vez que o Python é executado. Ou seja, durante uma execução do programa, o hash de uma string será o mesmo, mas entre diferentes execuções, não é mais garantido que seja o mesmo das execuções anteriores.

Neste caso, seria completamente inadequado para criptografia ou verificação de integridade (checksum), os usos mais comuns de um algoritmo de hash.

O objetivo de se usar um seed aleatório é para evitar esta vulnerabilidade. Esta é a parte que não domino, então vou só mencionar a documentação:

By default, the hash() values of str and bytes objects are "salted" with an unpredictable random value. Although they remain constant within an individual Python process, they are not predictable between repeated invocations of Python.

This is intended to provide protection against a denial-of-service caused by carefully-chosen inputs that exploit the worst case performance of a dict insertion, O(n^2) complexity. See http://www.ocert.org/advisories/ocert-2011-003.html for details.

Em tradução livre (ênfase minha):

Por padrão, para objetos str e bytes, é adicionado um salt aleatório ao valor de __hash__(). Embora este permaneça constante ao longo de um processo Python, os valores não são previsíveis entre repetidas invocações do Python.

Isto é intencional, para proteger contra ataques de negação de serviço causados por entradas bem escolhidas que exploram o pior caso de desempenho de inserção em dicionários, que é O(n^2). Veja http://www.ocert.org/advisories/ocert-2011-003.html para mais detalhes.

Enfim, este é um caso em que o uso do seed é interessante.

0
Silva97

Ué, achei curioso porque está falando justamente sobre salt que eu mencionei no meu comentário.

Acho que a má interpretação do que eu disse foi causada pelo nome da função crypt() que não, não é uma função para encriptar dados. Ela é para fazer o hash de dados mesmo (vide documentação).

Enfim, talvez eu devesse ter explicado com mais detalhes. Mas é que eu confiei que leriam o conteúdo nos links que eu passei. Ledo engano da minha parte.

0
Silva97

O equívoco é na tradução para a língua Portuguesa onde as pessoas confudem criptografia com encriptação. Criptografia é uma área de estudos e, sim, hash faz parte dessa área. Encriptação (de dados) que realmente não é o que um algoritmo de hash faz.

E se não ficou claro no meu comentário vou deixar aqui: o que eu respondi no seu post não tem relação nenhuma com encriptação de dados. Estou falando sobre hash mesmo.

Eu segui os links acima e todo remetem à criptografia.

Que bom que você alterou seu comentário após abrir os links. E sim, todos vão usar a palavra "criptografia" porque, como expliquei acima, criptografia é uma área de estudos e algoritmos de hash são estudados nessa área. Então sim, hash tem relação com a área de estudos chamada criptografia.

Repito: você tá confundindo criptografia com encriptação. Não é a mesma coisa. Mas a grande maioria comete esse erro mesmo.

Se você observar apenas uma palavra avulsa e fechar a aba do navegador em seguida sem ler nada, não vai compreender o que está sendo explicado.

Prova disso é que o conteúdo que você elogiou está falando sobre literalmente a mesma coisa que eu falei. É literalmente o mesmo assunto.