Hashcash and ecash for spam prevention

2004-05-25 Thread Anonymous
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

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

2003-11-12 Thread Anonymous
For some updated news about NGSCB, aka Palladium, go to the Microsoft
NGSCB newsgroup page at
This might be a good forum for cypherpunks to ask questions about

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

2003-10-06 Thread Anonymous
(mybuf+PADLEN) + PADLEN;
/* Strip end of line characters */
while ((mybuf[mylen-1] == '\n' || mybuf[mylen-1] == '\r')
 mylen  PADLEN)
/* 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, 
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 
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

2003-08-29 Thread Anonymous
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

 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

2003-08-28 Thread Anonymous
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

2003-07-07 Thread Anonymous

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:


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

2003-06-07 Thread Anonymous Sender
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 

 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]