[hashcash] Re: Digest::Hashcash
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Thu, 5 May 2005 22:59:23 +0100
I've been looking at Digest::Hashcash as a prelude to trying Hashcash
in
conjunction with INN's perl filtering capability (filter_nnrpd.pl).
The results I'm getting from it though aren't what I was expecting...
my $token = "1:24:050505:banana::AV205x9oU7dwKZu3:000000000008d6m";
This returns:
[resource] 050505:banana::AV205x9oU7dwKZu3
[timestamp] 1704067200
[bits] 24
Whilst the bit collision seems correct, the resource and timestamp
components don't. Am I missing something?
I think I know what's happening. The script is assuming (without
checking) that the token is "version 0" format, which had only four
fields: version:timestamp:resource:junk
The script is therefore interpreting "24" as a date, probably by
conversion to 0000z on 1st Jan 2024. This sounds plausible for 1.7
gigaseconds since 1970. It's also clearly forming the resource field
by stripping off the first two and final fields, which in the v1 format
leaves you with rather a lot more than expected.
Note also that the v1 format changes the semantics of "token value"
slightly. The value of a token in bits, is: the declared value in the
value field IFF the measured value is greater than or equal to this,
and zero otherwise. I understand this to be a protection against
statistical leakage, similar to the effects of a complicated content
filter.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi@xxxxxxxxxxxxxxxxxxxxx
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
Other related posts:
