Re: compact stamps optimization

i suddenly understand the problem...

length <= 55
all data is in first block, 9 bytes terminator is in first block

56 <= length <= 64 worst case.
all string data is in the first block, but the 9 bytes terminator is in the 
second block. 2 block transforms needed for each attempt.

65 <= length
terminator and the least significant base64 char are both in second block.

however one can do things with the length of the anti collision string. i think 
16x6 bits for it is overkill, especially considering it only has to be unique 
for an email address + date combination. but the random generation of it has to 
be good.

bas wrote:
> Adam Back wrote:
> 
>> I think the issue is that SHA1 is chained thru the 5x 32-bit (160-bit)
>> chaining/state variables A,B,C,D,E.  So in the 2nd case you have to
>> recompute the 2nd block even though the 2nd data doesn't change.
>>
> i know. i was mentioning the 2 cases where one has to calculate both 
> blocks, and that these don't happen for every attempt.
> 
>> (It would be nice to find a way to remove the -Z options, we tried
>> before, and failed so far).
>>
>> Adam
>>
>> On Wed, Dec 07, 2005 at 11:19:11PM +0100, bas wrote:
>>
>>> [...]
>>> changes which would require calculation of both blocks are
>>> 1: the string becoming longer (because the counter becomes longer), 
>>> so it becomes 2 blocks
>>> 2: a char of the counter, other than the least significant, changes, 
>>> which is in the first block.
>>>
>>> what does the padding refer to? what am i missing?
>>>
>>> i think if its possible at all to optimize -Z2 so it's like 1.1 
>>> slowdown, and not 2x, this is a good idea and it should become the 
>>> default, and the existing -Z1 setting becomes obsolete.
>>
>>
>>
>>
>>
> 
> 
> 
>