If your messages are longer than the size of an AES or 3DES key, you're less efficient. If they're ever going to be longer, you're stuck. :)
Hmm the messages are 9 digit license numbers. so i think it is going to simple to just use asymmetric crypt for this. Any suggestions?
MD5 should be avoided except where it has to be used for legacy apps.Ok will use SHA1 :)
In my diagram there is a fat arrow at the bottom left, in the arrow it reads "Encrypt MD5 Checksum using Sender's Private Key" . Am I not showing this appropriately in the diagram? How can I improve it to make more clear?Your message digest was encrypted by the recipient's key, not the senders. Did I read your diagram wrong? If not, then why keep the digest private? Is sender authentication handled somewhere else? What is to stop an adversary from replacing the digest? Etc.
All the public key's will be stored in LDAP repository. When the user receives the Checksum, she/he will retrieve the public key from LDAP, and derypt the MD5 Checksum, and compare it against the Checksum of the received data. Is this acceptable?
Thanks Sarah
_________________________________________________________________
Get MSN 8 Dial-up Internet Service FREE for one month. Limited time offer-- sign up now! http://join.msn.com/?page=dept/dialup
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
