[hashcash] Re: stamp collisions
- From: Hubert Chan <hubert@xxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Tue, 31 Aug 2004 01:36:28 -0400
>>>>> "Atom" == Atom 'Smasher' <atom@xxxxxxxxxxxxxx> writes:
Atom> On Mon, 30 Aug 2004, Hubert Chan wrote:
> Of course, your probabilities get reset at the beginning of the day, since
>> the date is part of the stamp. (Although if you live to be over 100
>> years, you might run into problems, since it only has 2-digit
>> years. ;-) (of course, by then, you would undoubtedly need to
>> generate a larger bit-value stamp anyways)) If the stamp contained
>> the time down to the second, along with the sender= extension,
>> collisions would be pretty much impossible, although this is probably
>> not needed.
Atom> ===========
Atom> would resolution to the second really help? i was under the
Atom> impression (but i'm no expert on it) that certain inferior OSs
Atom> give too much consideration to the time when generating a "random"
Atom> number... if that's the case, then 2 stamps being independently
Atom> minted for the same address and at the same second would still
Atom> have a fairly high chance of being the same.
Yes. That's why you still need the sender=<email address> extension.
Anyways, I feel pretty safe using a resolution that's on the order of
one day. But for people really worried about collisions, that's one
thing that you can do. Even if the date in the stamp stays with a
one-day resolution, you can add a time value as an extension.
>> Another way to guarantee no collisions (in addition to the sender=
>> extension) is to have a few bits in the "random" field be a
>> sequential counter that gets incremented for every stamp generated.
Atom> ===========
Atom> that leaks too much information... such as how many emails one
Atom> sends out in a given period... it might hint at BCC being used...
OK, it doesn't have to be sequential then. Use a pseudo-random number
generator with a large cycle length and that depends on your own secret
key.
(of course, having this "counter" also requires that hashcash save the
seed/counter value between runs, which probably should be avoided.)
--
Hubert Chan <hubert@xxxxxxxxx> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Other related posts:
