Boa noite meus queridos!
No versículo passado fechamos a tradução de “A Formal Language for Analyzing Contracts”. Hoje começaremos a obra “Hashcash – A Denial of Service Counter-Measure”, de Satoshi Nakamoto Adam Back, importantíssima obra publicada em 2002.
Hashcash – Uma Contramedida de Negação de Serviço
Adam Back
email: adam@cypherspace.org
1º de Agosto de 2002
1 Introdução
O Hashcash [1] foi originalmente proposto como um mecanismo para controlar o abuso sistemático de recursos não medidos da Internet como email e repostadores [remailers] anônimos em maio de 1997. Cinco anos depois, este artigo captura em um só lugar as várias aplicações, melhorias sugeridas e publicações subsequentes relacionadas e descreve a experiência inicial de experimentos usando hashcash.
A função de custo da CPU hashcash calcula um token que pode ser usado como prova de trabalho. Podem ser construídas variantes interativas e não interativas de funções de custo que podem ser usadas em situações nas quais o servidor pode emitir um desafio (protocolo interativo orientado a conexão) e onde não pode (onde a comunicação é armazenada – e – encaminhada ou orientada a pacotes), respectivamente.
No momento da publicação de [1], o autor não estava ciente do trabalho anterior de Dwork e Naor em [2] que propôs uma função de preços de CPU para a aplicação de combate a lixo eletrônico. Posteriormente, as aplicações para funções de custo foram discutidas em mais detalhes por Juels e Brainard em [3]. Jakobsson e Juels propõem um duplo propósito para o trabalho gasto em uma função de custo: além de executar um cálculo útil em [4].
2 Funções-Custo
Uma função de custo deve ser eficientemente verificável, mas com parâmetros razoavelmente caros de calcular. Usamos a seguinte notação para definir uma função de custo.
No contexto das funções de custo, usamos o cliente para se referir ao usuário que deve calcular um token (denotado T) usando uma função de custo MINT () usada para criar tokens para participar de um protocolo com um servidor. Usamos o termo mint para a função de custo por causa da analogia entre criar tokens de custo e cunhar [verbo to mint em inglês] dinheiro físico.
O servidor verificará o valor do token usando uma função de avaliação VALUE () e continuará apenas com o protocolo se o token tiver o valor necessário.
As funções são parametrizadas pela quantidade de trabalho w que o usuário terá que gastar em média para cunhar um token.
Com funções de custo interativas, o servidor lança um desafio C ao cliente – o servidor usa a função CHAL() para calcular o desafio. (A função de desafio também é parametrizada pelo fator de trabalho.)
C <- CHAL(s,w) função desafio do servidor
T <- MINT(C) cunhar o token baseado no desafio
V <- VALUE(T) função de avaliação do token
Com funções de custo não interativas, o cliente escolhe seu próprio desafio ou valor inicial aleatório na função MINT() e não há função CHAL()
T <- MINT(s,w) cunhar o token
V <- VALUE(T) função de avaliação do token
Claramente, uma função de custo não interativa pode ser usada em um ambiente interativo, enquanto o inverso não é possível.
[1] Adam Back. Hashcash, Maio de 1997. Publicado em http://www.cypherspace.org/hashcash/[2] Cynthia Dwork and Moni Naor. Pricing via processing or combatting junk mail. In Proceedings of Crypto, 1992. Também disponível como http://www.wisdom.weizmann.ac.il:81/Dienst/UI/2.0/Describe/
[3] Ari Juels and John Brainard. Client puzzles: A cryptographic countermeasure against connection depletion attacks. In Network and Distributed System Security Symposium, 1999. Também disponível em http://www.rsasecurity.com/rsalabs/staff/bios/ajuels/publications/client-puzzles/.
[4] Markus Jakobsson and Ari Juels. Proofs of work and bread pudding protocols. In Proceedings of the IFIP TC6 and TC11 Joint Working Conference on Communications and Multimedia Security (CMS ’99), Leuven, Belgium, Setembro de 1999. Também disponível como http://citeseer.nj.nec.com/238810.html.
Esta é a primeira parte de aproximadamente dez, no próximo versículo a segunda. Ricas bençãos!
