1. Crack better hash()
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
Lucius L. Hilley III - Unkmar
2. Re: Crack better hash()
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.
Also, the strength of the hash is limited by the length of the input
string. It might be better to enable the user to specify an arbitary return
length. The longer the return string, the stronger the hash.
Just for performance, you might like to do this...
for A = 1 to length(s) do
result += 1
for B = 1 to size do
result[B] *= s[A] + B
end for
result = and_bits(result, #FF)
end for
--
cheers,
Derek Parnell
3. Re: Crack better hash()
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
4. Re: Crack better hash()
On Thu, 19 Jun 2003 18:48:01 -0400, Lucius Hilley
<l3euphoria at bellsouth.net> wrote:
<snip>
> This algorithm is slightly different in nature and doesn't
>have that problem. Now, where is it's weakness?
<snip>
You can't decode it. "5", "A", "u" (and several others) all encode
to the same value.
Pete
5. Re: Crack better hash()
Lucius,
I took the liberty of using your basic algorithm and tweaking it a bit to
increase its security. The caller to this version can specify how many
output characters to give, plus they can add some 'unknowns' by supplying
two seed values.
Also, to cater for nested input sequences, I've included a small routine to
flatten out the input first.
---------------------
function flatten(sequence s)
---------------------
sequence r
r = {}
for i = 1 to length(s) do
if sequence(s[i]) then
r &= flatten(s[i])
else
r &= s[i]
end if
end for
return r
end function
---------------------
global function qhash(sequence s,integer l, atom seed1, atom seed2)
---------------------
sequence result
integer m
s = flatten(s)
if l < 1 then
l = length(s)
end if
result = repeat(seed1*seed2, l)
m = or_bits((1+length(s)) * (l+1),1)
for A = 1 to length(s) do
result += 1
for B = 1 to length(result) do
m = and_bits(or_bits(m+seed2,1),#FFFF)
result[B] = xor_bits(result[B],(s[A] + B + m))
end for
result = and_bits(result, #FF)
end for
return result
end function
---------------------
---------------------
Here is an example of how it might be used...
---------------------
sequence s, prodkey
s = qhash({"Version=2.4",
"Client=OpenEU Group",
"MaxUsers=20",
"Products=EuInterp,EuTrans"}
, 16, 3.1473, 6981)
prodkey = {}
for i = 1 to length(s) do
prodkey &= sprintf("%02x", s[i])
if i != length(s) and remainder(i,4) = 0 then
prodkey &= '-'
end if
end for
printf(1,"Licence key is : %s\n", {prodkey})
---------
By varying the seed values, you can get different results for the same
input. This means that it is much harder to crack if you don't know which
seeds were used to generate it.
You can get a similar effect by varying the output length too.
--
Derek
