Boa noite amigos!
No último versículo vimos a segunda parte da tradução de “Hashcash – A Denial of Service Counter-Measure”. Hoje vemos a terceira.
3 A função-custo do Hashcash
O Hashcash é uma função-custo não interativa, auditável publicamente e livre de trapdoor com custo probabilístico ilimitado
O Hashcash é calculado relativo à um nome de serviço s, para prevenir que os tokens cunhados por um servidor seja usado por outro (servidores aceitam apenas tokens cunhados usando seu próprio nome de serviço). O nome de serviço pode ser qualquer bit-string que identifique unicamente o serviço (por exemplo, o host name, endereço de email, etc).
Compre seu Ingresso Agora
A função hashcash é definida como (note que esta é uma variante simplificada melhorada desde a publicação inicial, veja a nota na seção 5):
A função-custo do hashcash é baseada em achar colisões parciais de hash em todos 0 bits k-bit string 0 [elevado à k] . O algoritmo mais rápido para calcular colisões parciais é a força bruta. Não há desafio já que o cliente pode seguramente escolher seu próprio desafio aleatório, e então a função-custo é livre de trapdoor e não-interativa. Em adição, a função-custo do Hashcash é auditável publicamente, porque qualquer um pode eficientemente verificar qualquer token publicado. Na prática |x| deve ser escolhido para ser grande o suficiente para tornar a probabilidade de que os clientes usem novamente um valor inicial previamente utilizado negligenciável.; |x| = 128 bits deve ser suficiente mesmo para um servidor ocupado.)
O servidor precisa manter uma base de dados de duplo-gasto de tokens gastos, para detectar e rejeitar tentativas de gastar o mesmo token de novo. Para prevenir a base de dados de crescer indefinitivamente, o string de serviço pode incluir a hora em que ele foi cunhado. Isso permite que o servidor descarte entradas da base de dados de gastos depois que já eles já tenham expirado. Algum período razoável de expiração deve ser escolhido para levar em conta a imprecisão do relógio, o tempo de computação, e od atrasos de transmissão.
O Hashcash foi originalmente proposto como uma contramedida contra spam de email, e contra abusos sistemáticos de remailers anônimos. É necessário usar funções-custo não-interativas para esses cenários pois não há canal para o servidor enviar um desafio. No entanto uma vantagem de funções-custo interativas é que é possível prevenir ataques de pré-computação. Por exemplo, se há um custo associado a mandar cada email isso pode ser suficiente para limitar a escala de abuso perpetrados por spammers; embora para um ataque motivado puramente por DoS [negação de serviço] um adversário determinado pode gastar um ano pré-calculando tokens para que todos estejam válidos em um determinado dia, e neste dia ser capaz de temporariamente sobrecarregar o sistema.
Seria possível reduzir o escopo de tais ataques de pré-computação usando um beacon [sinalizador] que muda lentamente (transmissão imprevisível, valor autenticado mudando ao longo do tempo), como, digamos, os números vencedores da loteria desta semana. Nesse caso o valor do beacon atual é incluído naquele string, limitando os ataques de pré-computação de serem conduzidos dentro do período entre as trocas de valor do beacon.
Fechada a terceira parte, no próximo versículo a quarta. Deus os abençoe!
