Hashcash é un sistema de proba de traballo empregado para limitar o correo lixo e os ataques de denegación de servizo. Hashcash foi proposto en 1997 por Adam Back e descrito máis formalmente no artigo de Back de 2002 «Hashcash - A Denial of Service Counter-Measure». En Hashcash, o cliente concatena un valor variable cunha cadea e calcula o resumo desta nova cadea. Repite estas operacións con distintos valores ata atopar un resumo que comece cun determinado número de bits a cero.
Antecedentes A idea de esixir a un usuario o cálculo dunha función moderadamente difícil, pero non intratable, para acceder a un recurso foi proposta por Cynthia Dwork e Moni Naor no traballo «Pricing via Processing or Combatting Junk Mail», presentado en CRYPTO '92 e publicado nas actas do congreso en 1993.
Como funciona Hashcash baséase nunha busca cuxa dificultade se pode escoller. Un selo válido demostra que se atopou unha solución que cumpre esa dificultade; non permite deducir o número exacto de intentos realizados para obtela. No correo electrónico, o selo engádese nunha cabeceira e pode empregarse como sinal para a filtraxe, pero non certifica que o contido sexa lexítimo.
A hipótese é que os remitentes de correo lixo, cuxo modelo de negocio depende da súa capacidade para enviar grandes cantidades de mensaxes cun custo moi baixo por mensaxe, deixarán de ser rendibles se existe incluso un pequeno custo por cada mensaxe de correo lixo que envían. Os receptores poden verificar se un remitente realizou ese investimento e empregar os resultados para axudar a filtrar o correo electrónico.
Detalles técnicos O formato da versión 1 contén sete campos separados por dous puntos, como no seguinte exemplo ilustrativo: X-Hashcash: 1:20:260914:[email protected]::hK0Usl9SvFdZn+vm:1699bb
O resumo SHA-1 deste selo é: 000005caada1171b07537ca538f3dff707fada2b
A cabeceira contén: ver: versión do formato Hashcash, 1 (que substitúe a versión 0). bits: número de bits de «preimaxe parcial» (cero) no código resultante da función hash. date: momento de creación do selo en UTC, no formato YYMMDD[hhmm[ss]]. resource: cadea que identifica o recurso, por exemplo, un enderezo IP ou un enderezo de correo electrónico. ext: extensión (opcional; ignórase na versión 1). rand: cadea aleatoria formada con caracteres do conxunto a-zA-Z0-9+/=, tamén empregado en base 64. counter: cadea do mesmo conxunto de caracteres que se modifica en cada intento; a implementación non está obrigada a contar secuencialmente.
O selo vincúlase ao recurso indicado, por exemplo o destinatario dunha mensaxe, e á data de creación. A política do receptor pode limitar a antigüidade aceptada e gardar os selos xa usados para detectar repeticións.
Lado do remitente O remitente prepara os campos do selo, incluída unha cadea aleatoria e un contador. Despois calcula o resumo SHA-1 de 160 bits do selo. Nun exemplo cunha dificultade de 20 bits, se os primeiros 20 bits (é dicir, os 5 díxitos hexadecimais máis significativos) do resumo son todos ceros, o selo cumpre o requisito de traballo. Se non, o remitente modifica o contador e volve calcular o resumo. Dos 2160 valores de resumo posibles, hai 2140 que satisfán este criterio. Así, a probabilidade de seleccionar aleatoriamente un selo cuxo resumo comece con 20 bits a cero é de 1 entre 220 (aproximadamente 1 entre 106, ou arredor dunha entre un millón). O número de tentativas que o remitente necesita para obter un valor de resumo válido modélase mediante unha distribución xeométrica. Polo tanto, o remitente terá que probar, de media, 220 valores para atopar un selo válido. Nun artigo de 2004, David Mertz estimaba que un selo de 20 bits podía xerarse en menos dun segundo nos procesadores daquela máis recentes con implementacións compiladas, e en poucos segundos en máquinas máis antigas; non é unha estimación de rendemento independente do equipamento.
Segundo a explicación do proxecto, o custo por mensaxe sería pequeno para un usuario que enviase poucas mensaxes, mentres que os remitentes de correo lixo acumularían un custo maior polo seu gran volume de envíos.
Lado do destinatario Tecnicamente, o sistema impleméntase cos seguintes pasos: O computador do destinatario calcula o resumo SHA-1 de 160 bits de toda a cadea do selo (por exemplo, "1:20:260914:[email protected]::hK0Usl9SvFdZn+vm:1699bb"). Só precisa un cálculo do resumo para comprobar o traballo. Nun selo de 20 bits, se os primeiros 20 bits non son todos cero, a proba non é válida; o destinatario pode esixir unha dificultade maior. O computador do destinatario comproba a data de creación do selo (por exemplo, "260914", que representa o 14 de setembro de 2026). Na ferramenta hashcash, a validez por defecto é de 28 días, cunha tolerancia adicional de dous días para compensar o desaxuste dos reloxos. Ambos os valores son configurables; os dous días non constitúen a xanela total de validez. O computador do destinatario comproba se o enderezo de correo electrónico da cadea hash coincide con algún dos enderezos de correo electrónico válidos rexistrados polo destinatario ou con algunha das listas de distribución ás que está subscrito. Se non se atopa unha coincidencia, a cadea hash non é válida. O computador do destinatario comproba se o selo xa figura na base de datos de selos usados. Se figura, rexéitao por reutilización; se supera as comprobacións, rexístrao para impedir o seu uso posterior.
Se o selo supera todas estas probas, considérase válido. A comprobación da proba de traballo é moito máis rápida que a súa xeración, aínda que o receptor tamén ten que realizar as comprobacións de data, recurso e reutilización.
Esforzo requirido O tempo medio de busca dunha preimaxe parcial deste tipo é exponencial respecto do número de bits a cero. Por iso, pódense engadir bits a cero adicionais (duplicando o número medio de intentos necesario para calcular un resumo con cada bit a cero adicional) ata que resulte demasiado custoso para os remitentes de correo lixo xerar liñas de cabeceira válidas.
Comprobar a proba de traballo é moito máis rápido: para unha cadea dada só require unha operación de cálculo do resumo, independentemente de cantos bits a cero se esixan. Isto non substitúe as demais comprobacións de validez do selo.
Custos e limitacións Hashcash non require un pagamento monetario ao destinatario por cada selo, pero a súa xeración consome recursos de cálculo. A dificultade debe equilibrar o custo que impón ao abuso co que soportan os usuarios lexítimos. As diferenzas entre equipamentos e volumes de correo impiden identificar unha cantidade de traballo óptima para todos os casos. Versión 0.2, revisada despois de WEIS04.
A verificación dos selos non precisa unha autoridade emisora central. No uso por correo, os clientes que descoñecen a cabeceira poden ignorala, o que permite unha introdución gradual do mecanismo.
Ben Laurie e Richard Clayton analizaron en 2004 o custo dun esquema que esixise unha proba por cada correo. Cos datos e supostos empregados, concluíron que non disuadiría suficientemente os emisores de correo lixo sen prexudicar a unha parte dos usuarios lexítimos. Tamén discutiron as listas de distribución, as listas brancas e outros mecanismos de exención. Estas conclusións refírense ao modelo estudado e non constitúen unha demostración sobre calquera combinación posible.
Aplicacións Minaría de Bitcoin En contraste co Hashcash das aplicacións de correo, que depende de que os destinatarios establezan manualmente unha cantidade de traballo destinada a disuadir os remitentes maliciosos, a rede da criptomoeda Bitcoin emprega un desafío de proba de traballo diferente, baseado nunha función hash, para permitir a minaría competitiva de Bitcoin. Un mineiro de Bitcoin executa un programa informático que recolle transaccións sen confirmar dos usuarios da rede. En conxunto, estas poden formar un «bloque» e proporcionarlle un pagamento ao mineiro, pero a rede só acepta un bloque se o seu resumo cumpre o obxectivo de dificultade da rede. Así, como en Hashcash, os mineiros varían os datos do bloque, incluído o nonce que, ao incluílo no bloque, produce un resumo aceptable.
Filtros de correo lixo Hashcash empregouse para axudar a evitar os falsos positivos dos sistemas automatizados de filtraxe de correo lixo. A FAQ do proxecto describía os selos como un mecanismo de exención dos filtros e consideraba pequeno o custo para quen enviase poucas mensaxes.
SpamAssassin 3.0.0 incluía un complemento para verificar selos Hashcash e regras que lles asignaban puntuacións negativas, é dicir, favorables á clasificación como correo lexítimo. O seu desenvolvemento comezara coa numeración 2.70, que se cambiou a 3.0.0 antes da publicación. Ficheiros Changes, rules/init.pre e rules/50_scores.cf da distribución. O complemento estaba activado por defecto, pero requiría configurar os patróns dos enderezos que debían coincidir co recurso do selo. Os selos só podían usarse unha vez e o complemento gardaba un rexistro para detectar a reutilización.
O soporte eliminouse da rama principal de SpamAssassin o 26 de xuño de 2019. Commit 87ef5855736b662cdb82eb39a758a39b46a7f046, revisión SVN 1862148; cambios en UPGRADE e no complemento. Na distribución 3.4.3 aínda figuraba o código do verificador, pero xa non a súa activación por defecto nin as regras Hashcash distribuídas. Ficheiros lib/Mail/SpamAssassin/Plugin/Hashcash.pm e rules/init.pre. Paquete de regras da mesma versión.
Clientes de correo O proxecto de software Penny Post, aloxado en SourceForge, propuxo combater o correo lixo facendo que o remitente dedicase tempo de cálculo a cada envío. A súa extensión para o cliente de correo electrónico Mozilla Thunderbird permitía configurar a xeración e a verificación de selos Hashcash mediante un programa externo de selado.
Email Postmark Microsoft documentou o algoritmo «Email Postmark», que permite engadir ás mensaxes unha proba de traballo computacional para axudar aos filtros a distinguir o correo lexítimo do correo lixo. Revisión 13.0; seccións 1.3, 2.2.3.1 e 2.3.3 e apéndice A. A Coordinated Spam Reduction Initiative (CSRI) de Microsoft xa describía en 2004 unha proposta de desafíos computacionais chamada HashedPuzzle, baseada nos traballos de Dwork, Naor e Back.
Email Postmark emprega Son-of-SHA-1, unha variante de SHA-1, e require un conxunto de dezaseis solucións. Os datos de entrada inclúen os destinatarios e campos como o remitente, a data, o identificador e o asunto da mensaxe, pero non o seu corpo. A proposta CSRI xa descartaba incorporar o resumo do corpo polos problemas de fraxilidade que esa vinculación ocasionaba.
Outlook 2010 deixou de xerar estes selos e retirou as políticas relacionadas co seu uso. Pola súa banda, a documentación de Exchange 2013 describe a validación dos selos recibidos polo axente de filtraxe de contido.
Blogs Do mesmo xeito có correo electrónico, os blogs sofren a miúdo spam nos comentarios. Algúns propietarios de blogs usaron scripts de Hashcash escritos en JavaScript para frear os emisores de comentarios non desexados. Algúns destes scripts afirman implementar Hashcash, pero en realidade dependen da ofuscación de JavaScript para forzar o cliente a xerar unha chave coincidente; aínda que iso require certa capacidade de procesamento, non empregan o algoritmo de Hashcash nin os seus selos.
Reputación Sonbol Rahimpour e Majid Khabbazian propuxeron un sistema de reputación baseado en Hashcash para mercados dixitais. Para construír esa reputación, un provedor de servizos selecciona unha chave pública como identificador e busca por forza bruta un nonce que, concatenado co identificador do provedor e co identificador do mercado, produza un resumo hash con varios ceros iniciais. O número destes ceros determina a súa reputación no sistema, vinculada a ese par de identificadores. Preprint v1, arXiv:2012.10825, sección III.A, p. 3. Edición posterior:
Propiedade intelectual