Any implementation of Javascript Encryption and Java Decryption of Triple DES Algorithm

[lekurwale amol]

Hi,

A brief description of my client requirement :
1. Even though we are using SSL, a risk analysis test carried out by client reveals that sensitive data (password) can be recovered from client machine cache using specialized tools.
2. They want us to atleast not store the text password in RAM

For that, they are asking us to implement triple DES algorithm, where encryption is done on client side using javascript and decryption on server using Java. The key will be generated everytime the user requests the login page. So, the password submitted will actually the encrypted one.

Please provide me an implementation of triple DES encryption in Javascript and decryption in Java.

Kind note : Do not post comments of how the above requirement is useless. I have already tried my best with the client

Regards,
Amol

[greg stark]

http://lmgtfy.com/?q=javascript+triple+des+encryption

[lekurwale amol]

Ohh..
So there exists something called 'Google' wherein you can search for things. Thanks a lot greg. I would be always greatful to you.

Any updates please.(Ofcourse not like the previous one)

Regards,
Amol

[greg stark]

Are you saying you cannot use google? What is wrong with the solution in the very first result that google returns?

[Pat Farrell]

DES is obsolete. tripple DES is a hack from before AES.

Your requirement is better handled not by encryption but rather by using a one-way-hash. Google for HMAC.

Unix and Linux have been using one-way password hashes for decades.

[lekurwale amol]

greg stark wrote:Are you saying you cannot use google? What is wrong with the solution in the very first result that google returns?

I tried it. But, the issue is that the 'encrypted' is not decrypted by this java code :
http://www.java2s.com/Code/Java/Security/TripleDES.htm

So, I required an end-to-end implementation, which has been implemented and tested.

Pat, I repeat. I have to do what is said. Client is client.

Regards,
Amol

[Pat Farrell]

lekurwale amol wrote:Pat, I repeat. I have to do what is said. Client is client.

Sorry, I missed that part of your post. Sorry that your client is an idiot. Sorry that they didn't listen to you, they are not adding any security to the system with their requirements. Sometimes its better to find better clients.

I wish you good luck. I expect that even if you get the code to work perfectly in your testing, there may be problems with the implementation in other browsers or other versions of the browsers.

[lekurwale amol]

Pat Farrell wrote:

lekurwale amol wrote:Pat, I repeat. I have to do what is said. Client is client.

Sorry, I missed that part of your post. Sorry that your client is an idiot. Sorry that they didn't listen to you, they are not adding any security to the system with their requirements. Sometimes its better to find better clients.

I wish you good luck. I expect that even if you get the code to work perfectly in your testing, there may be problems with the implementation in other browsers or other versions of the browsers.

But, as of now, the situation is like the only thing I can do in this world is to implement it. As of now, they are kind enough saying Firefox and IE compatible will do.
So, waiting for a solution.

Regards,
Amol

[James Sabre]

lekurwale amol wrote:So, waiting for a solution.

I have just tested the decryption mode of the DES Javascript library in the first hit of Greg's Google and it takes about 6 lines of Java to decrypt the example it uses. All it requires is to understand what one is doing. I suggest that you start by reading section 2 of "Applied Cryptography with Java" by David Hook and then go thought the Javascript to see which modes you need to define.

So as to avoid padding ambiguities I suggest you use PKCS7 padding in the Javascript which equivalent to PKCS5 padding in the Java. Since the key is only going to be used once I suggest you use ECB block mode. I suggest that you hex encode the ciphertext before shipping from the client to the server so as to avoid character encoding issues.

Best of luck - with your attitude you are going to need it.

[ UD: fixed quote tag to make clear who said what ]

[lekurwale amol]

James,

Thanks for your solution. Can you provide me those java lines. Unfortunately, I do not have time right now to read through the book you have mentioned. Also, a few points to clarify : 1. I had tried using the PKCS7 encoding you have mentioned, and I had configured the java class accordingly. 2. The hex conversion seems to bring in extended ASCII validation, of whose conversion back code I could not write.

About the usage : I understand that it is useless in some sense. But again, our requirement is simple : Do not have plain text password in memory after form submit.

Regards,
Amol

[Ulf Dittmer]

lekurwale amol wrote:Can you provide me those java lines.

No, he won't; JavaRanch is NotACodeMill. How will you learn if we spoonfeed you everything?

Unfortunately, I do not have time right now to read through the book you have mentioned.

Security is serious business. You need to spend time in order to understand the underlying algorithms, otherwise your implementation will very likely be insecure (not that what you propose to implement is secure to begin with, but that's a different subject). You can also check out the SecurityFaq, which has links to many relevant resources that explain all this.

[James Sabre]

lekurwale amol wrote:James,

Thanks for your solution. Can you provide me those java lines. Unfortunately, I do not have time right now to read through the book you have mentioned. Also, a few points to clarify : 1. I had tried using the PKCS7 encoding you have mentioned, and I had configured the java class accordingly. 2. The hex conversion seems to bring in extended ASCII validation, of whose conversion back code I could not write.

About the usage : I understand that it is useless in some sense. But again, our requirement is simple : Do not have plain text password in memory after form submit.

Regards,
Amol

I don't know why but I'm always surprised when people blatantly ask for code with the excuse that they don't have the time to learn. All I was suggesting was that you read just one chapter of the book; not the whole book. It should take you no more than a day to read that chapter and to write several small test examples. Why should I or anyone else earn your salary for you?

You say that your requirement is simply "Do not have plain text password in memory after form submit". How is that achieved by using encryption? The user enters the password as plain text and encrypting the resulting string does not overwrite the password so it will remain in memory! Also, since DES is a symmetric algorithm and not an asymmetric algorithm, the decryption key is the same as the encryption key and must be available in memory so any attacker can just extract the encrypted password and the key and recover the password.

The requirement is heavily flawed and adds nothing to the security of the system. Your client should be made aware of this.

Edit:

Since cross-platform/language encryption is my interest I have looked more closely at the DES Javascript library. Although on encryption it correctly performs PKCS7 padding, it does not remove it on decryption! Even worse, it applies the padding to decryption as well! It took me just 30 minutes to fix the problem (a bit slow since I'm not a Javascript person) - if you are only going to be encrypting with the library then you should not need to apply your own fix.