Hashcash and ecash for spam prevention
Recently someone proposed a system which combined ecash and hashcash for email postage. Here is some analysis. There are already proposals and even some working code for hashcash email postage. See http://www.camram.org/. This is intended as an anti-spam measure. The idea is that to send email, the sender has to create a proof of work token, something which takes a relatively long time to compute but which can be checked quickly. The simplest proposal is a hash collision, as suggested by Adam Back at http://www.hashcash.org/. Spam filter software could be configured so that email containing a valid hashcash token would be presumptively viewed as non-spam. Most non-spammers have low volumes of outgoing mail and so they can generate the necessary hashcash at mail sending time, introducing only a modest delay. Spammers however rely on being able to send enormous volumes of email practically for free, so having to expend potentially several minutes of CPU time for each outgoing email would make their actions unprofitable. The alternative being proposed here is to let there be a way of exchanging hashcash tokens for ecash-like tokens at one or more trusted servers. These ecash tokens would not actually be cash any more than is hashcash, i.e. they would not have a specific monetary value, nor would the ecash servers exchange ecash tokens for cash. Rather, ecash tokens would be exchangeable only for other such tokens, and they could also be purchased with hashcash. These ecash tokens would then be used as a sort of postage, instead of the straight hashcash tokens in Camram. There is not a particularly strong need for the ecash tokens to be blinded or unlinkable, since the value of them is so low. The servers just need a way to distinguish good and unspent ecash from bad or spent ecash. However if they are used and reused for email postage, allowing linkable tokens would show who was sending mail to whom, infringing email privacy. Hence it would be desirable for the tokens to be unlinkable, which will be possible after the Chaum patent expires in 2005. This is not a crypto anarchy system which would bring down the government and usher in a cypherpunk utopia. The value of these cash tokens would be small, pennies at best. However it represents an adaptation of ecash technology for a useful purpose and it would potentially introduce a limited form of cash-like tokens into widespread use. This system has pros and cons in terms of spam resistance, versus the straight hashcash approach. The biggest difference is that this system allows for effective reuse of tokens. You receive a token in an incoming email, you exchange it at the server for a new one (validating it in the process), and you use the new one to send out a message. Reuse is not possible with straight hashcash, because if people could reuse them, then people could multiply-spend them. If hashcash reuse were allowed, a spammer could generate a single hashcash token and put identical copies in all of his outgoing email. In order to prevent reuse, hashcash tokens must include enough information embedded in the hash collision to make them unique for a particular message. Typically this would include the recipient's email address, date/time information, and possibly even a message body hash. Hashcash verification involves checking not only the mathematical validity of the collision, but that these embedded fields are correct, as well. The implication of this requirement is that the hashcash token cannot be generated in advance, but must be created at the time the mail is sent. This reduces the acceptable amount of time required for a typical user to create it. If hashcash could be precomputed overnight, it might be okay to take even an hour to produce a token. But if it has to be done at mail sending time, only a much lower time limit will be acceptable. As a result, the size of hashcash collisions has to be set low enough for end users to generate a token in no more than a few seconds or minutes at most. And this increases the chance that spammers may be able to incorporate economies of scale and generate hashcash fast enough to make spamming still be economical. Some analyses suggest exactly this possibility. Making hashcash reusable by exchanging it for ecash tokens would fix this problem. Instead of the hashcash including information within it to prevent double use, this would be handled by validating the ecash or hashcash at the server to make sure it had not been used before. Now, this means that the spam filter must make an Internet access to check validity, which was not necessary with straight hashcash. However, most spam filters today make many Internet accesses, to check black lists and other communal resources intended to fight spam. Adding a check to validate an ecash token would not change the basic functionality of the spam filter, or materially slow down its operation. Preventing reuse via this method means that
New info on Palladium
For some updated news about NGSCB, aka Palladium, go to the Microsoft NGSCB newsgroup page at http://communities.microsoft.com/newsgroups/default.asp?icp=ngscbslcid=us. This might be a good forum for cypherpunks to ask questions about Palladium. There was a particularly informative posting by Ellen Cram of Microsoft on October 15. Among other things she reveals that the Longhorn pre-release to be distributed at the Microsoft PDC (conference) will include NGSCB technology. It's not clear how this will work without the specialized hardware features, though. Also getting attention is a bizarre attempt at guerrilla marketing, where Microsoft employees are running blogs to promote Longhorn. http://longhornblogs.com/scobleizer/ provides a good example. In How to Hate Microsoft, Robert Scoble, Longhorn technology evangelist, wants you to tell him everything you don't like about Longhorn. Pull no punches, he begs. So far there are a few comments about DRM but not much specifically about Palladium/NGSCB. On another front, John Walker of AutoCAD fame, who supported a number of quixotic projects through the 80s and 90s, like the ill-fated Xanadu, has a new publication out. The Digital Imprimatur, http://www.fourmilab.ch/documents/digital-imprimatur/, presents a dystopian future for the Internet that is heavily based on the potential negative consequences of Trusted Computing technologies like Palladium. In Walker's view, Palladium will spawn a net where you need a certificate to participate, and this will naturally lead to a fully trusted network where not only people, but all their transactions and documents will be certified, hence traceable and accountable. An imprimatur is a government license to run a printing press, and we will experience the same effect in the Trusted Internet of the future. Although Walker's story is meant to be a cautionary tale, the list of properties of the Trusted Net is so attractive that many readers are questioning why we should oppose these developments: an end to copyright violation, (unauthorized) eavesdropping, scams, security fraud, SPAM, worms and viruses. Walker's architecture also supports search engines that are 100% accurate, with low maintenance. The Trusted Net limits child pornography (and children's access to adult porn), hate speech, employee internet abuse, and tax evasion. It inherently supports DRM, satisfying the concerns of content providers and providing a foundation for wide-scale distribution of copyrighted content. Walker has put an intentionally favorable slant on his presentation in order to demonstrate how plausible it is that people will accept the restrictions of Palladium in exchange for all these benefits. The spam menace is already leading to calls for an Internet Drivers License even from some circles within the pro-freedom crowd, and a Trusted Net would be only a small additional step. While Walker's description of how to put the Internet genie back in the bottle is sobering, his track record as a prognosticator is not promising. He was wrong about the net before, and he's probably wrong about it now. A rather dull discussion forum for the essay is running at http://www.fourmilab.ch/wb/digital-imprimatur.pl. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Interlock protocol chat program source code
(mybuf+PADLEN) + PADLEN;
/* Strip end of line characters */
while ((mybuf[mylen-1] == '\n' || mybuf[mylen-1] == '\r')
mylen PADLEN)
--mylen;
/* Hash message and exchange hashes */
hashmsg (myhash, mybuf, mylen, prio, 1);
if (prio)
{
fwrite_enc (myhash, sizeof(myhash), f_out);
fread_dec (hishash, sizeof(hishash), f_in);
} else {
fread_dec (hishash, sizeof(hishash), f_in);
fwrite_enc (myhash, sizeof(myhash), f_out);
}
/* Exchange messages and verify remote hash */
if (prio)
{
mylen2 = htonl(mylen);
fwrite_enc ((uchar *)mylen2, sizeof(mylen2), f_out);
fwrite_enc (mybuf, mylen, f_out);
}
fread_dec ((uchar *)hislen, sizeof(hislen), f_in);
hislen = ntohl(hislen);
if (hislen = sizeof(hisbuf)-1 || hislen PADLEN)
{
fprintf (stderr, Incoming buffer bad size, %d bytes\n,
hislen);
exit (2);
}
fread_dec (hisbuf, hislen, f_in);
hisbuf[hislen] = '\0';
hashmsg (hishash2, hisbuf, hislen, !prio, 0);
if (memcmp (hishash, hishash2, sizeof(hishash)) != 0)
{
fprintf (stderr, Incorrect hash, protocol failure or attack
detected\n);
exit (2);
}
printf (OTHER: %s\n, hisbuf+PADLEN);
if (!prio)
{
mylen2 = htonl(mylen);
fwrite_enc ((uchar *)mylen2, sizeof(mylen2), f_out);
fwrite_enc (mybuf, mylen, f_out);
}
}
}
/* Setup and handshake functions */
/* Do an anonymous DH exchange */
static int
dodh (int prio, FILE *f_in, FILE *f_out)
{
my_x = BN_new();
my_y = BN_new();
shared = BN_new();
p = BN_new();
q = BN_new();
g = BN_new();
BN_hex2bn( p, p_hex );
BN_hex2bn( q, q_hex );
BN_hex2bn( g, g_hex );
BN_rand (my_x, XBITS, 0, 0);
BN_mod_exp (my_y, g, my_x, p, bnctx);
if (prio)
{
bnwrite (my_y, f_out);
fflush (f_out);
bnread (his_y, f_in);
} else {
bnread (his_y, f_in);
bnwrite (my_y, f_out);
fflush (f_out);
}
BN_mod_exp (shared, his_y, my_x, p, bnctx);
}
/* Generate a key of the given length and name, using HMAC-SHA1 */
static void
keygen (uchar *key, unsigned keylen, char *name)
{
int namelen = strlen(name) + 1 + 1;
char *namebuf = malloc (namelen);
uchar hbuf[SHA_DIGEST_LENGTH];
int hbuflen;
int iter = '0';
unsigned sharedlen = BN_bn2mpi(shared, NULL);
uchar *sharedbuf = malloc(sharedlen);
BN_bn2mpi (shared, sharedbuf);
while (keylen)
{
/* put a prefix char on the name for wide keygen */
namebuf[0] = iter++;
strcpy (namebuf+1, name);
HMAC (EVP_sha1(), sharedbuf, sharedlen, namebuf, namelen,
hbuf, NULL);
hbuflen = MIN(keylen, SHA_DIGEST_LENGTH);
memcpy (key, hbuf, hbuflen);
keylen -= hbuflen;
key += hbuflen;
}
memset (sharedbuf, 0, sharedlen);
memset (hbuf, 0, SHA_DIGEST_LENGTH);
free (namebuf);
free (sharedbuf);
}
/* Do the handshake and fall into the communications loop */
static int
docomm (int prio, FILE *f_in, FILE *f_out)
{
dodh (prio, f_in, f_out);
if (prio)
{
keygen (enckey, sizeof(enckey), Client interlock encrypt);
keygen (deckey, sizeof(deckey), Server interlock encrypt);
keygen (mymackey, sizeof(mymackey), Client interlock HMAC);
keygen (hismackey, sizeof(hismackey), Server interlock HMAC);
} else {
keygen (enckey, sizeof(enckey), Server interlock encrypt);
keygen (deckey, sizeof(deckey), Client interlock encrypt);
keygen (mymackey, sizeof(mymackey), Server interlock HMAC);
keygen (hismackey, sizeof(hismackey), Client interlock HMAC);
}
intercomm (prio, f_in, f_out);
/* Never returns */
return 0;
}
static int
client (char *target, int port, int nsides)
{
struct hostent *targetinfo;
int s, s1;
int n;
struct sockaddr_in sockaddr;
FILE *f_in, *f_out;
int err;
s = socket(AF_INET
Re: traffic analysis
John S. Denker writes: More specifically, anybody who thinks the scheme I described is vulnerable to a timing attack isn't paying attention. I addressed this point several times in my original note. All transmissions adhere to a schedule -- independent of the amount, timing, meaning, and other characteristics of the payload. And this does not require wide-area synchronization. If incoming packets are delayed or lost, outgoing packets may have to include nulls (i.e. cover traffic). Suppose you are engaged in a video conference with another party via an anonymous real-time communications network. Don't you agree that you cannot remain anonymous to that party, if they have the power to insert arbitrary delays into communication links? How could you prevent frame dropouts when she delays your link into the anonymizing cloud? You can insert nulls, or get the cloud to do it for you, but it will be obvious to the recipient that your video has stopped. This again demonstrates that you cannot remain anonymous with realtime communication against an adversary who can corrupt selected endpoints and who can insert traffic delays. If you disagree, explain how you will counter this attack. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: traffix analysis
John S. Denker writes: A scenario of relevance to the present discussion goes like this: -- There exists a data haven. (Reiter and Rubin called this a crowd.) -- Many subscribers have connections to the haven. -- Each subscriber maintains a strictly scheduled flow of traffic to and from the haven, padding the channel with nulls if necessary. -- All the traffic is encrypted, obviously. Then the opponent can put unlimited effort into traffic analysis but won't get anything in return, beyond the _a priori_ obvious fact that some pair of subscribers *may* have communicated. This is not true, and in fact this result is one of the most important to have been obtained in the anonymity community in the past decade. The impossibility of practical, strong, real-time anonymous communication has undoubtedly played a role in the lack of deployment of such systems. The attack consists of letting the attacker subvert (or become!) one of the communication endpoints. This can be as simple as running a sting web site offering illegal material. Then the attacker arranges to insert delays into the message channels leading from subscribers into the crowd. He looks for correlations between those delays and observed delays in the message traffic to his subverted endpoint. This will allow him to determine which subscriber is communicating with that endpoint, regardless of how the crowd behaves. It will often be possible to also trace the communication channel back through the crowd, by inserting delays onto chosen links and observing which ones correlate with delays in the data observed at the endpoint. This way it is not necessary to monitor all subscribers to the crowd, but rather individual traffic flows can be traced. Wei Dai's PipeNet proposal aims to defeat this attack, but at the cost of running the entire crowd+subscriber network synchronously. The synchronous operation defeats traffic-delay attacks, but the problem is that any subscriber can shut the entire network down by simply delaying his packets. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Precomputed DH parameters
A number of SSL-enabled applications use precomputed public DH parameters (p and g) generated for use in the SKIP protocol. The original page appears to be off the air; here's an archived version: http://web.archive.org/web/20011212141438/http://www.skip-vpn.org/spec/numbers.html#params Question: Are these safe for use as precomputed parameters for generating OpenPGP ElGamal keys? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
James A. Donald writes: Suppose the e-gold, to prevent this sea of spam trying to get people to login to fake e-gold sites, wanted people to use public keys instead of shared secrets, making your secret key the instrument that controls the account instead of your shared password. They could not do this using the standard IE webbrowser. They would have to get users to download a custom client, or at least, like hushmail, a custom control inside IE. Why do you say that? You were already given pointers to how they could configure their web servers to use certificate based client authentication. These techniques work with standard browsers. I have used Netscape to access corporate-internal sites which required me to have a client certificate. HTTPS assumes that the certificate shall be blessed by the administrator out of band, and has no mechanism for using a private key to establish that a user is simply the same user as last time. HTTPS is just HTTP over SSL/TLS. It says nothing about the trust model for the certificates; it merely specifies how each side can deliver its cert(s) to the other side. Deciding which ones to trust is out of scope for TLS or HTTPS. E-Gold could set things up to allow its customers to authenticate with certs issued by Verisign, or with considerably more work it could even issue certs itself that could be used for customer authentication. Why doesn't it do so? Well, it's a lot of work, and it would have some disadvantages - for one thing, customers would have difficulty accessing their accounts from multiple sites, like at home and at work. Further, it would require customers to use some features of their browser that most of them have never seen, which is going to be difficult and error-prone for most users. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
