Ok,

Like I said, that part was a email onto itself.

You can use hashes and security in many different ways.
If you need to encrypt a value, you can send it to a hashing algorythm, and
your result will be a fixed length random string. You can use that string as
the basis of all future comparisons. This is not good in alot of ways since
if you capture the encrypted string, it is as good as having the password
itself.

Another method, which is better, is that you setup a system like this.

Client and Server are given a 'PUBLIC' password (string value ranging from 0
to 127 bytes)

At time of first transmission, Client generates a random password (string
value ranging from 0 to 127 bytes)

The Client performs a MD5 Hash upon the PUBLIC password and uses it as the
primary seed for a Run block encoding of the random password.

A run block encoding goes (somthing) like this

MD5HASH(initial seed) results in 16 bytes of binary data (32 chars of hex)
XOR the first 16 bytes of the string to be encrypted with the 16 bytes of the
HASH result. this gives the first 16 bytes of the encrypted answer.
Now take the result from the XOR operation and concatenate the PUBLIC
password to the end of it and perform a MD5HASH on the results.
The result is then XOR'd with the second 16 bytes of the string to be
encrypted. The result of this is the second 16 bytes of the encrypted answer.

Do this until you have totally coverted the starting string into a encrypted
string.

One of the parameters of the stored procedure will receive this encrypted
string. (the random password)

Now you perform a MD5Hash, using the origional random password, concatenated
to the PUBLIC password.
Now you use the result to perform a Run block encodeing upon each of the
different values sent to the server (user name, password, role, etc).

Now the server gets these values and it's first job is to figure out what the
random password is.
So the server knows the PUBLIC password and generates a MD5 hash upon it.
The server then XOR's the result of the MD5 hash against the first 16 bytes
of the encrypted string and gets the unencrypted first 16 bytes.
It then takes the origional encrypted 16 Bytes and concatenates the Public
password and performs a MD5HASH on the result, giving the value to XOR with
the second 16 bytes.....continue until done.

Now the server, knowing the random secret, can use it to decode the remainder
of the message.
There are many ways to use run length encoding and hashing algorythms to
encrypt/decrypt information. By putting the Public secret at the beginning
of the strings when concatinating them will result in totally different
looking output, but still with the same level of security.

Our own encryption techniques take it a little further and we have UDF's that
will encypt/decrypt data for us, as well as convert a string to a hex
representation and back. We even extended the XOR routines to handle large
string blocks.

None of what I have explained is very difficult to do yourself, once you
understand the basic principals, and having all the free MD5 hashing
algorythms on the net for your review and use in UDF's.

Hope this has made things clear for you, feel free to ask questions if you
wish.

best regards

Dalton

On Thursday 31 May 2001 09:34, you wrote:
> How is MD5 used to *decode* anything? It is a one-way hash algorithm. I
> know this is kind of off-topic, but I don't understand this part of the
> solution.
>
> At 12:19 PM 5/30/2001 -0400, you wrote:
> >The stored procedure takes the username, password and role as parameters
> > and first decodes them using the md5hash routines. (plus bin_xor) or
> > simple pattern matching.
> >(This is also a very detailed subject, for another email)
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/