My requirement : need to exchange some keys between server and client (J2EE). Key is just a piece of text, could be a number, string whose size would probably be not more than 30 chars. Since the key is sensitive, I'm thinking of encrypting it, and decrypt it back when I receive the same. Q1) Legacy code is using 'PBEWithMD5AndDES'. I would like to know whether it's appropriate. In the context of performance, which could be better? UPDATE: There will be no logic on the client side. Server sends an encrypted string to the client, and client returns it. Just like jsessionid. The key is not too sensitive like a credit card number. But it needs to be exchanged in an unreadable format, better than plain encoding technique UPDATE 2: Here is the scenario. We send an email to the client in which we include 'unsubscribe' from alerts. Clicking on that link should deactivate alerts with out prompting for the login. So, I encrypt his userID and include it the unsubscribe link. On the server side, I decrypt and deactivate his/her alerts. So, the parameters passed by hackers would not work.

javaencryption

Firefox

Reputation: 951

Deciding encryption algorithm

My requirement : need to exchange some keys between server and client (J2EE).

Key is just a piece of text, could be a number, string whose size would probably be not more than 30 chars.

Since the key is sensitive, I'm thinking of encrypting it, and decrypt it back when I receive the same.

Q1) Legacy code is using 'PBEWithMD5AndDES'. I would like to know whether it's appropriate.

In the context of performance, which could be better?

UPDATE:

There will be no logic on the client side. Server sends an encrypted string to the client, and client returns it. Just like jsessionid.
The key is not too sensitive like a credit card number. But it needs to be exchanged in an unreadable format, better than plain encoding technique

UPDATE 2:

Here is the scenario. We send an email to the client in which we include 'unsubscribe' from alerts. Clicking on that link should deactivate alerts with out prompting for the login. So, I encrypt his userID and include it the unsubscribe link. On the server side, I decrypt and deactivate his/her alerts. So, the parameters passed by hackers would not work.

Upvotes: 1

Answers (4)

fgysin

Reputation: 11923

I would suggest AES-256. It is at the moment unbreakable and becoming a standard for strong symmetric encryption.

Also it is seamlessly supported by Java (see java.security and javax.crypto). Furthermore AES is supported by lots of freeware tools, you can use it for example with OpenSSL on Unix.
AES256 is heavy on the performance side, but this will not be an issue when your encrypting 30 char strings/documents. (Unless there's millions of them, obviously.)

You will also need to decide on some other encryption specs like block mode and padding. Here my suggestion - this is what I used up to now when I was required to do solid encryption with Java:

Encryption Algorithm: AES using a 256 bit key
Block Mode: CBC (Cipher-Block-Chaining)
Padding: PKCS5Padding

Upvotes: 0

mtraut

Reputation: 4740

If its not used by the client, as a kind of session token, then why do you encrypt at all?

You could use a hash or random value that is held in the session in addition to the secret.

Upvotes: 0

Tom O'Connor

Reputation: 490

I'd probably just get both server and client to generate private and public keys, then encrypt the key to exchange with the receiving party's public key.

Or just use something strong, and a symmetric key, like AES256.

I'd avoid using DES for new systems, it's quite old, and has been proven to be breakable.

As far as the actual implementation is concerned, I'm not entirely sure there's enough detail in the question.

Upvotes: 1

notthetup

Reputation: 1137

AES256 would be a good option.. Solid and looking to be future proof. But it would be performance heavy. Another option is RC4.

Upvotes: 0

Deciding encryption algorithm

Answers (4)

Related Questions