Hashcash er et proof-of-work- system, der bruges til at reducere spam og DoS-angreb . Senere blev det brugt i bitcoin og andre kryptovalutaer [1] som en del af dataanalysealgoritmen . Hashcash-systemet blev foreslået i maj 1997 af Adam Back . [2]
Hashcash er en proof-of-work-algoritme, der kræver en selektiv mængde data at beregne, men beviset kan effektivt verificeres. E-mail-brugere har tilføjet hashcash-stempelteksten til overskriften for at bekræfte, at der er brugt noget tid på at beregne stemplet før afsendelse. Afsenderen bruger med andre ord lidt tid på at beregne stemplet og sende, hvilket er usædvanligt for spammere. Modtageren kan på bekostning af ringe computerkraft bekræfte mærkets gyldighed. Den eneste kendte måde at finde en header med de nødvendige parametre er en komplet søgning . Og selvom det er nemt nok at teste en enkelt streng, med et tilstrækkeligt lille antal tilfredsstillende svar, vil der kræves et tilstrækkeligt stort antal forsøg for at finde svaret. Hypotesen er, at spammere, hvis forretningsmodel er baseret på deres evne til at sende et stort antal e-mails til meget lave omkostninger pr. besked, ikke længere vil drage fordel, selvom prisen på hver spam, de sender, er lille. Modtagere kan kontrollere, om afsenderen har fulgt denne procedure, og bruge resultaterne til at filtrere e-mail.
Mærkets titel ser således ud: [3]
X-Hashcash: 1:20:1303030600:[email protected]::McMybZIhxKXu57jd:FOvXXOverskriften indeholder:
ver: Hashcash-versionen, 1 (som erstattede version 0). bits: Antallet af "pre-" (nul) bits i den hash-kodede kode. dato: Det tidspunkt, hvor beskeden blev sendt, i formatet ÅÅMMDD[ttmm[ss]]. ressource: Oplysninger om afsenderen, såsom IP-adresse eller e-mail-adresse. ext: Udvidelse (valgfrit; ignoreret i version 1). rand: En streng af tilfældige tal kodet i [[Base64|base-64]] format. tæller: Base-64-kodet binær tæller.Overskriften indeholder adressen på modtageren, datoen for meddelelsen, oplysninger, der bekræfter, at alle de nødvendige beregninger er blevet foretaget. Tilstedeværelsen af en modtageradresse kræver, at overskriften genberegnes for en anden. Datoen gør det muligt for modtageren at tage hensyn til overskrifterne på nyligt modtagne beskeder og sikre sig, at overskriften på den indgående besked er unik.
Afsenderen forbereder overskriften og tilføjer et tilfældigt tal til den. Den beregner derefter en 160-bit SHA-1 hash af headeren. Hvis de første 20 bit af hashen er nuller, er denne overskrift acceptabel. Ellers øger afsenderen tælleren og prøver igen. Af de 2.160 mulige hash-værdier opfylder 2.140 dette kriterium. Sandsynligheden for, at en tilfældigt valgt hash starter med 20 nuller er således 1 ud af 2 20 . Antallet af forsøg, som afsenderen er tvunget til at gøre, før han modtager en gyldig hash-værdi, modelleres af en geometrisk fordeling . Derfor skal afsenderen i gennemsnit prøve 220 (lidt over en million ) tilfældige tal for at finde den korrekte overskrift. Givet rimelige skøn over den tid, det tager at beregne hashen, vil dette tage omkring 1 sekund. Samtidig er der ingen effektiv metode til at finde en gyldig titel udover brute force.
Den gennemsnitlige pc-bruger vil ikke opleve væsentlige problemer på grund af den tid, det tager at generere en hashcash-streng. Samtidig vil spammere opleve betydelige problemer, da de sender et meget stort antal breve.
Teknisk set implementeres systemet i følgende trin: modtagerens computer beregner en 160-bit SHA-1 hash af hele strengen (f.eks. "1:20:060408:[email protected]::1QTjaYd7niiQA/sc:ePa"). Dette tager omkring to mikrosekunder på en 1GHz-processor, hvilket er meget mindre end den tid, det tager at downloade resten af e-mail-beskeden. Hvis de første 20 bit ikke er nul, er hashen ugyldig (der kan være behov for flere nul bits i nyere versioner, efterhånden som processorkraften vokser). Modtagerens computer tjekker datoen i overskriften (f.eks. "060408", hvilket betyder 8. april 2006). Hvis forskellen fra den aktuelle dato er mere end to dage, er hashen ugyldig (to-dages vinduet kompenserer for forskellen i tid og rejsetid på tværs af netværket mellem forskellige systemer). Modtagerens computer tjekker, om e-mailen i hash-linjen matcher en e-mailadresse, der er registreret af modtageren, eller en hvilken som helst adresse på listen over dem, som modtageren abonnerer på. Hvis der ikke er nogen match, er hashen ugyldig. Modtagerens computer tilføjer hash-strengen til databasen. Hvis en sådan streng allerede er til stede i databasen (det viser sig således, at der er blevet forsøgt at genbruge hash-strengen), er hashen ugyldig. Hvis hash-strengen består alle test, anses den for at være gyldig. Alle disse test optager ikke meget tid og diskplads sammenlignet med at modtage hovedparten af e-mailen.
Den tid, der kræves til at beregne disse hash-kollisioner, vokser eksponentielt , efterhånden som antallet af nulbit stiger. Det vil sige, at nul bit kan tilføjes, indtil generering af nye gyldige hash-strenge bliver for dyrt for spammere (fordobling af den tid, det tager at beregne en hash med hvert ekstra nul). Det tager lige lang tid at bekræfte, at titlen er gyldig. Det er lige meget, hvor mange nuller, der er nødvendige for en gyldig overskrift, da der kun kræves én hash-handling.
Hashcash-systemet har en fordel i forhold til de mikrobetalingstilbud , der anvendes på e-mail, da det ikke involverer involvering af rigtige penge. Hverken afsender eller modtager skal betale. På denne måde undgås alle administrative problemer forbundet med mikrobetalinger.
På den anden side kræver hashcash betydelige beregningsressourcer for at sende hver besked. Det er ret svært at finde den gennemsnitlige tid, som kunderne er villige til at bruge på at beregne titlen. Dette kan betyde, at indlejrede systemer på lavt niveau enten ofrer tilgængelighed eller ikke giver tilstrækkelig beskyttelse mod fjendtlige værter til effektivt at filtrere spam.
Hashcash er let nok at implementere til tilpassede mailagenter og spamfiltre. Der kræves ingen central server. Systemet kan anvendes konsekvent - den ekstra hashcash-header ignoreres, når den modtages af en mailklient, der ikke forstår den.
En af analyserne [4] kom til den konklusion, at det højst sandsynligt er, at enten sætter mail fast på grund af manglende processorkraft hos afsenderen, eller også vil spam stadig komme igennem. Eksempler på hver omfatter henholdsvis en centraliseret e-mail-topologi (såsom en postliste ), hvor nogle servere skal sende enorme mængder af legitim e-mail; og botnets eller klyngefarme, hvorfra spammere kan øge deres processorkraft enormt. De fleste af disse problemer kan løses. For eksempel kan botnets opdages hurtigere, fordi brugere bemærker højt CPU-forbrug og kan gøre gengæld, og servere, der bruger en mailingliste, kan hvidlistes af abonnentklienter og er dermed fritaget for Hashcash-problemer. Men generelt repræsenterer de alvorlige hindringer for udbredelsen af Hashcash, som endnu ikke er løst.
Et andet forudsigeligt problem er, at computere fortsætter med at stige i kraft i overensstemmelse med Moores lov . Derfor skal kompleksiteten af de nødvendige beregninger øges. Udviklingslandene vil dog fortsat bruge gammelt udstyr, hvilket betyder, at de vil have svært ved at bruge e-mail-systemet. Dette gælder også for personer med lav indkomst i udviklede lande, som ikke har råd til det nyeste udstyr.
Hashcash ligner konceptuelt de valideringssystemer, der bruges i " Bitcoin ". Hvor mail-applikationer antager, at modtageren manuelt styrer arbejdsbyrden af valideringssystemer for at opnå processorkraft ved Moores lov, så repræsenterer Bitcoin et p2p-netværk, der internt automatisk justerer arbejdsbyrden. I modsætning til mail, som bruger 20 bits (i størrelsesordenen 1 million forsøg til succesfuld søgning), bruger bitcoin 67,5 bit (i størrelsesordenen 200 millioner trillioner forsøg er nødvendige) og et varierende sværhedskriterium for at generere en af de blokke, der oprettes hvert 10. minut. I Bitcoin blev algoritmen justeret til at understøtte brøkbits (den originale HashCash-specifikation var begrænset til justering af heltalspotenser på 2), og derved opnåede højere nøjagtighed.
Hashcash bliver brugt som en potentiel løsning på problemet med automatiske spamfiltre falske positiver, da den gennemsnitlige bruger ikke oplever den ekstra tid, det tager at markere. [5]
SpamAssassin har tjekket for hashcash-stempler siden version 2.70 ved at tildele negative scores (dvs. mindre spam-lignende) til tidligere ubrugte hashcash-stempler. I version 3.3x (den seneste version i skrivende stund) giver systemet bonuspoint for alle 20-bit eller flere point (maksimalt -5 point for 26-bit eller flere marks). Der registreres dog en lille straf for et allerede brugt mærke. [6]
Penny Post [7] på SourceForge implementerer Hashcash til Mozilla Thunderbird -e- mail-klienten . [8] Projektet er opkaldt efter en overkommelig posttjeneste, der kun kostede afsenderen én øre (du kan læse om sådanne posttjenester på Penny Post -siden ).
Microsoft designet og implementerede også en nu forældet [9] åben specifikation svarende til, men inkompatibel med hashcash, Email Postmark, [10] , som blev en del af Coordinated Spam Reduction Initiative (CSRI). [11] Den hashcash-variant, der er foreslået af Microsoft, er implementeret i komponenter af Microsofts mailtjenester såsom Exchange, Outlook og Hotmail. Forskellen i format mellem hashcash og Microsoft-stempler er, at Microsoft-stemplet også hashes af e-mailens brødtekst og også bruger en modificeret SHA-1 som hash-funktion.
På en meget lignende måde bliver blogs ofre for kommentarspam. Nogle blogejere har brugt hashcash-scripts skrevet i JavaScript til at bremse spammernes kommentarer. [12] Nogle scripts (såsom wp-hashcash) hævder at implementere Hashcash, men er afhængige af JavaScript-obfuscation for at tvinge klienten til at generere den passende nøgle; mens det kræver en vis processorkraft, bruger de ikke Hashcash- eller Hashcash-stempelalgoritmen.
Hashcash er ikke patenteret, og referenceimplementeringen [13] og de fleste andre implementeringer er fri software. Hashcash er inkluderet eller tilgængelig for mange Linux-distributioner . RSA har fremsat IPR-erklæringer til IETF om klient-puslespil-algoritmer [14] i forbindelse med en RFC [ 15] der beskriver forskellige klient-puslespil (ikke hashcash). RFC inkluderede hashcash i artiklen og nævnte algoritmen, men mekanismen beskrevet i den løser mere af et interaktivt problem, som mere ligner Client-Puzzles. Hashcash er ikke interaktiv og har derfor ingen kendte løsninger. Under alle omstændigheder kan RSA IPR-erklæringen ikke anvendes på hashcash, da hashcash er før [2] (marts 1997) offentliggørelsen af Client-puzzle [16] (februar 1999) og patentansøgning US7197639 [17] (februar 2000).