[hashcash] Re: Hi!
- From: Adam Back <adam@xxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Fri, 26 May 2006 15:09:23 -0400
Hi
On Fri, May 26, 2006 at 06:39:53PM +0200, Máté Soós wrote:
> I was wondering, if the following idea would solve the BCC-related
> hashcash problem:
>
> [...] hash the address, and use that(or some first bytes of that)
> instead of the email string. We are done - hmm, well, almost. Except
> that if the person thinks that the email might have been sent to
> someone he knows the email address of, he could check.
I think you identified the problem with the hash of email address for
Bcc -- a guess can be confirmed. To expand on that also note that a
"guess" can mean hashing a database of 1 billion email addresses to
see which it is -- hashcash shows us this will take just an hour or
so.
The other thing is it leaks the number of Bccs. Perhaps one could
defend against it by adding a few extra bogus email addresses
if there aren't any bcc's so you cant tell.
(The current Bcc defense is to deliver Bcc's separately.)
> Also, another thing. Is the length of the 0-bits that must be calculated
> by the sender fixed ? Because if so, the whole idea will be useless in
> about 8-12 years, given that the barrier will remain the same, but the
> runners (the computers) will become 4-8 times better jumpers(faster).
> Maybe the number of 0's that needed to be calculated should be increased
> propotionally(linearly, btw, since its effect is exponential anyways)
> to time(i.e. 2004, 2006, etc)?
We need some extension to communicate updates to it scalably, without
any central bandwidth overhead. Something like each sender sends
their highest received hashcash bits requirement. We can have some
transparent process for deciding the current (some formula on current
hardware say), and update it say once a year. And have a requirement
to create one more bit than required so that people who haven't got
the update yet dont get their mail misfiled. Then basically updates
would distribute via software update, and via received mails.
Another option is DNS some text record on hashcash.org eg
bits.hashcash.org returns a text record lets say. However people will
misimplement their DNS clients or caches and it'll get hammered :(
> Also, a note on implementation. The random digits at the end of the
> 'date:email:random' that needs to hash to (00[..]xxx) should truly be
> random. Otherwise, the probability of collisions would rise high above
> the probablility of winning the lottery weeks on end. This is a matter
> of implementation, but I believe it should be emphasised. Generating
> truly random numbers is not as easy as people(programmers) think.
Yeah its a valid point, but taken care of in the C implementation: it
uses /dev/urandom on linux and CryptGenRand from CAPI on windows.
Adam
Other related posts:
