OpenEuphoria

Re: Crack better hash()

• Posted by Derek Parnell <ddparnell at bigpond.com> Jun 20, 2003
• 383 views

On Fri, 20 Jun 2003 14:14:06 +1000 (06/20/03 14:14:06)
, Derek Parnell <ddparnell at bigpond.com> wrote:

>
>
> On Thu, 19 Jun 2003 18:48:01 -0400 (06/20/03 08:48:01)
> , Lucius Hilley <l3euphoria at bellsouth.net> wrote:
>
>>
>> I must concede the first one somehow turns out to be a fancy way of
>> a one to one conversion.  Sort of like a XOR with some constant value.
>> a 'u' would always encode to a #E7.  or something like that.
>> Would simple be a process of building a decryption table from the
>> encoder.  This algorithm is slightly different in nature and doesn't
>> have that problem.  Now, where is it's weakness?
>>
>> function hash(sequence s)
>> integer size
>> sequence result
>> size = length(s)
>> result = repeat(0, size)
>> for A = 1 to length(s) do
>> for B = 1 to size do
>> result[B] += 1
>> result[B] *= s[A] + B
>> result[B] = and_bits(result[B], #FF)
>> end for
>> end for
>> return result
>> end function
>
> Just a few thoughts.
>
> Because this ends up with the same number of independant equations as you 
> have unknowns, one could derive the plain text by solving the 
> simultaneous equations.
>

Ooops. I forgot to mention that one way to mitigate this effect is to 
introduce some unknown material. This emans that you could consider 
allowing the caller of the routine to supply a key that is used to effect 
the resulting hash. This makes it much harder to reverse the process.

I have a routine that gives reasonably strong hash keys. I think I sent it 
to the RDS contributions page once.

-- 

cheers,
Derek Parnell