Re: Digest::Hashcash

> 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:     [email protected]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.