Re: comment on reducing padding (Re: Re: libfastmint update 20040915)

I have a suggesetion on the fast, but big padding vs relatively fast
but compact padding discussion.

We've determined that it appears not possible to robustly prevent
there being a performance advantage to SHA1 input block boundary
padding.

One could define a rendering which did not display the padding and
added it back prior to hashing, but a) what you see is no longer what
you hash (wysiwyh:-), b) we'd have to change the format again.

So given all this, perhaps we can change the code to allow people to
choose: relatively fast compact, vs big padding fast.

People with server side apps or slow machines etc will lean towards
big and fast; perhaps others will be happy enough with compact
relatively fast.

IIRC the difference was around 15%.

How hard is it to extricate the padding part and have an option to
hashcash_fastmint() to choose.  (Compact would be where padding grows
as the counter wraps, starting with 1 char counter and growing).

Adam

On Fri, Sep 17, 2004 at 07:19:08AM -0400, Eric S. Johansson wrote:
> Justin Guyett wrote:
> >Why should they have a hashcash binary?  Any embedded system without a
> >compiler then has to be supplied with a hashcash binary by whatever
> >entity compiles the rest of the system.
> 
> yes.  That's normally how these things work.  We are providing a 
> standard library or command line tool to generate the hashcash stamp. 
> If you want to use the services, you need to have the library.  Same 
> argument could be had for TCP stacks, memory management, math functions, 
> or configuration file access.
> 
> >Knowledge of and modification to the stamp format should not be required
> >at all in order to measure the raw (version 0 style) value of the stamp.
> 
> but the version 0 style is deprecated as far as I know.
> 
> 
> >Is there a good reason to standardize padding in the last field?  Why
> >not let the generator do whatever it wants, including omitting the
> >counter field entirely?
> >
> >I think it's a bad idea to force people to use unnecessarily complex
> >implementations.
> 
> the complexity comes from the need for speed.  If we can gain a 
> significant performance improvement with padding, then we should take 
> advantage of that because if we don't, spammers will.