[hashcash] Re: libfastmint update 20040915
- From: Atom 'Smasher' <atom@xxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Thu, 16 Sep 2004 04:27:00 -0400 (EDT)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, 16 Sep 2004, Jonathan Morton wrote:
The padding places the "tail" of the count field at byte 32 or 52 (mod
64), which are the two most efficient places to calculate changes in
SHA-1 for. Most practical e-mail addresses will end up as 96-byte tokens
(32+64), though particularly short ones can be 52 bytes. If the
extension field gets substantial use, 116-byte tokens may also become
common.
==============
there seems to be "dead spots" where some stamps are generated without a
counter. these are tested using resources from 0-200 bytes with a 6 byte
date and no extension. the file shows stamps that do not have a counter
and the size of the resources used to create the stamps.
MD5 (stamps.gz) = c2e35a10d4b09c73cab049c631013df0
thoughts (after i should be in bed) about getting rid of the padding...
hhmmm... what if the padding was done internally? instead of padding the
stamp that's output, a minting application would create a stamp _as_if_ it
were padded and a verifying application would internally add appropriate
padding before calculating the hash.
ok, this would break compatibility, and no one wants to rush and create a
v2 stamp format... but an extension could exist for specifying the ~type~
of padding used (pad=x). this would still create a backwards compatibility
issue, but if time passes before that behavior is turned on by default it
shouldn't cause too many problems.
i'm going to bed soon... i promise.
...atom
_________________________________________
PGP key - http://atom.smasher.org/pgp.txt
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------
"States of war are also understood to require the opposition
in the legislature to moderate its otherwise essential
functions of criticism. Calls are issued to stand behind
the political leadership and to display unity, with the
implication that the enemy is watching and that failure to
unite is tantamount to treason. These are not healthy
conditions for a democracy; indeed, they are the opposite of
democracy."
-- Philip E. Agre, Department of Information Studies,
University of California, Los Angeles
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.6 (FreeBSD)
Comment: What is this gibberish?
Comment: http://atom.smasher.org/links/#digital_signatures
iQEcBAEBCAAGBQJBSU5aAAoJEAx/d+cTpVciiXIH/3xdRrowCtu/Qi8WPej1jwbY
MvJpY0qg3vIYqe2OJBQW2Ju+0c9Jxm65PgBpstZufU5Ks0Vx3FA0Ii6fp5AfOdqT
yfzJVLuB4MHmv4YZIqRWxiybTuOmzz0Eg1JNsfgnRntMu1oMVHydX/60o4BBWtAL
Kp1/1aFNyJERvHV+8VxZ8FB2ucO1IXo3NqxPT9j5RAZlQG/58IagkorPj/zE9qxA
psqxhlgNNAj7yGE0obzMHL45b38PyjnTTJuLOW6unACi1qcm7jdWkE/05SP5y3Gv
1+395zaxRX7pwnbErswuDup+5JlIbtGyvU7u/U/HPtczKm5Hbvivxkf4Ao3ANAE=
=aMUt
-----END PGP SIGNATURE-----
- Follow-Ups:
- References:
- [hashcash] libfastmint update 20040915
- From: Jonathan Morton
- [hashcash] Re: libfastmint update 20040915
- From: Atom 'Smasher'
- [hashcash] Re: libfastmint update 20040915
- From: Jonathan Morton
Other related posts:
- » [hashcash] libfastmint update 20040915
- » [hashcash] Re: libfastmint update 20040915
- » [hashcash] Re: libfastmint update 20040915
- » [hashcash] Re: libfastmint update 20040915
- » [hashcash] Re: libfastmint update 20040915
- » [hashcash] Re: libfastmint update 20040915
- » [hashcash] Re: libfastmint update 20040915
thoughts (after i should be in bed) about getting rid of the padding...
...atom
- [hashcash] libfastmint update 20040915
- From: Jonathan Morton
- [hashcash] Re: libfastmint update 20040915
- From: Atom 'Smasher'
- [hashcash] Re: libfastmint update 20040915
- From: Jonathan Morton