Re: MD5 Algorithm

On Jun 9, 8:33 pm, f...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (***
Wesseling) wrote:
In article <1181432495.588632.241...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Jean-François Michaud <come...@xxxxxxxxxxx> writes:



On Jun 8, 7:20 am, Frank <fjru...@xxxxxxxxx> wrote:
I was reading in the POP3 literature something about MD5 and securing
the connection. But it also mentions using a 'Key' as provided by the
mail server. I have down loaded the Forth code for MD5 but I don't
see where a key string is used to initiate this.

Here is what I understand: you apply the MD5 to the timedate stamp
provided by the server and you use a key code string also provided.

I have run the MD5 on the Timedate stamp and saw the results. So I
know the code works but what or how does the 'Key' come into play?

Frank

It looks like you're describing keyed MD5. Just Google "keyed MD5" for
more information. It's an additional security layer that allows the
recipient of a message to verify that you are who you say you are
(working with asymetric encryptions; private + public key combo and a
message digest that is the message + appended randomly generated key)
and that the message wasn't tempered with.

The idea is sending a message, message digest (firstly mentioned
message + appended random key that ran through MD5), and encrypted
random key (firstly mentioned random key, encrypted using your private
key on an asymetric algo).

The recipient of the message decrypts the key with your public key ,
takes the decrypted key, appends it to the message and runs it through
MD5. The sent digest should match the message + appended key combo
passing through MD5. If it doesn't, uh oh!

The key that your server sent you would either be a public key to
decrypt asymetric encryptions coming from the server or, if the key
came with a message, a randomly generated key encrypted with a private
key that needs to be decrypted by you using the server's public key so
that you can verify that the message digest that you also received
corresponds to the message digest that you get if you append the
decrypted key to the clear message and run it through MD5.

There is no decryption involved. From the top of my head:

We have a user "joe6pack" password "beer". We don't want the password

to go over the wire naked.

Hmm, well in the keyed MD5 scheme I'm familiar with, there is
encryption of the randomly generated stream on the sender's side using
his prive key on an asymetric algo (RSA for example). No password
circulates on the wire in the scheme I'm mentioning.
_______

Sender:
_______
1- Write plain text A
2- Client generates a random stream B
3- Client appends random stream B to A and applies MD5 on the
resulting message to generate C
4- Client encrypts the random stream B using *private* key on RSA algo
to generate an encrypted stream D
5- A C and D are sent to the recipient.

__________

Recipient:
__________
1- Recipient receives A C and D from sender
2- Recipient decrypts D using the sender's *public* key to extract the
decrypted stream B
3- Recipient appends the B stream to received plain message A and runs
it through MD5 to generate message E
4- C and E are compared and should be identical.

End result, we verified that the client is who he says he is (most
probably because we decrypted using his public key) and we verified
that the message hasn't been tampered with (most probably since the
received message digest is identical to the plain text to which we
append decrypted stream B after digesting it through MD5), and we have
a checksum on the message all in one clean sweep.

This scheme is superior to APOP I would say because no shared secret
is required. That's the beauty of asymetric encryption algos ;-). I
also prefer this scheme to the HMAC scheme which also requires a
shared secret to the keyed MAC-MD5 sheme I'm talking about (HMAC is
better than no security though).

Having shared secrets isn't as safe as having no secrets :).

[SNIP]

Regards
Jean-Francois Michaud

.