Java/Scala bi-directional MD5

views:

146

answers:

Java/Scala bi-directional MD5

Hello,

I am trying to find some samples of how to take a string and hash it using MD5, and then be able to reverse hash (correct term?) back to the original string.

Does anyone know of any documentation that shows how this can be done, or ideally has any sample code they could share?

I've read about the java.security.MessageDisgest class, but that appears to be only one-way. I need to be able to convert the hash back into its original data. Is MD5 the best algorithm to use, or should i be looking at something else entirely?

+8 A:

MD5 is destructive. You lose data when you hash.

Perhaps you are looking for a symmetric cipher like DES or (better) AES?

The bouncycastle security provider has a DES implementation example at http://www.bouncycastle.org/specifications.html

EDIT: Sorry, I've jumped the gun. What is your objective: Compression, Indexing, Checksumming, Encryption, or something else?

Synesso 2010-09-07 01:48:20

My scenario is needing to encrypt some data on the client side (javascript), send this encrypted data to a web server back-end and have it decrypted to be used to connect to a third party FTP server.

Jason Miesionczek 2010-09-07 01:58:35

You might as well use HTTPS for that?

Porges 2010-09-07 02:00:36

Encryption would be provided by HTTPS. This would prevent unauthorised read or modify whilst the message is on the network. Is that sufficient?

Synesso 2010-09-07 02:01:35

@Jason Be careful. DO NOT just use DES or AES on the client side. Read my answer for more details.

NullUserException 2010-09-07 02:08:27

+5 A:

Hash functions are designed to be irreversible.

What you need is to use a secure transport layer, like SSL or TLS (eg: HTTPS is HTTP with SSL or TLS). Please refrain from rolling your own on this one.

Note that simply using a symmetric cypher like AES on the client (eg: Javascript) is useless, because you'd need to supply the key to said client and thus an attacker would be able to trivially decrypt any intercepted messages.

NullUserException 2010-09-07 02:00:47

SSL generally uses AES for the actual data encryption. In practice, "public key encryption" is a slight misnomer, since the whole dance with the public key exchange is usually used to derive a shared key which is used with an *entirely* different algorithm (generally AES).

Daniel Spiewak 2010-09-07 02:56:39

@Daniel Yes, but the whole initial dance is there to make sure nobody else knows the symmetric key :)

NullUserException 2010-09-07 03:01:33

I was just trying to point out that your advice against AES is misleading, it should have been advising against direct secret key exchange. As long as public/private keys are used to derive the shared key, AES is fine (even on the client).

Daniel Spiewak 2010-09-07 17:16:06

ansaurus

tags:

views:

answers:

Java/Scala bi-directional MD5

related questions