javascript triple des encryption value and java triple des encryption values not matched why ? -

hi guys have java code produce triple des encryption code me trying use on javascript using crypto-js both codes provides different keys dont know why , how same key here code

 public string _encrypt(string message) throws exception {  messagedigest md = messagedigest.getinstance("sha-1");  byte[] digestofpassword = md.digest(secretkey.getbytes("utf-8"));  byte[] keybytes = arrays.copyof(digestofpassword, 24);  system.out.println(bytestohex(keybytes));   secretkey key = new secretkeyspec(keybytes, "tripledes");  cipher cipher = cipher.getinstance("tripledes");  cipher.init(cipher.encrypt_mode,key);  byte[] plaintextbytes = message.getbytes("utf-8");  byte[] buf = cipher.dofinal(plaintextbytes);   system.out.println(bytestohex(buf));     byte [] base64bytes = base64.encodebase64(buf);  string base64encryptedstring = new string(base64bytes);   return base64encryptedstring; }   public static string bytestohex(byte[] in) {  final stringbuilder builder = new stringbuilder();  for(byte b : in) {      builder.append(string.format("%02x", b));  }  return builder.tostring();  }    public string _decrypt(string encryptedtext) throws exception {   byte[] message = base64.decodebase64(encryptedtext.getbytes("utf-8"));  messagedigest md = messagedigest.getinstance("sha-1"); byte[] digestofpassword = md.digest(secretkey.getbytes("utf-8")); byte[] keybytes = arrays.copyof(digestofpassword, 24); secretkey key = new secretkeyspec(keybytes, "desede");  cipher decipher = cipher.getinstance("desede"); decipher.init(cipher.decrypt_mode, key);  byte[] plaintext = decipher.dofinal(message);  return new string(plaintext, "utf-8"); } 

and java script code follows

 key = cryptojs.sha1(key);  console.log(key.tostring());  var iv = string.fromcharcode(0) + string.fromcharcode(0) +    string.fromcharcode(0) + string.fromcharcode(0) + string.fromcharcode(0) + string.fromcharcode(0) + string.fromcharcode(0) + string.fromcharcode(0);  var ivhex = cryptojs.enc.hex.parse(iv);  var options = { mode: cryptojs.mode.cbc, padding: cryptojs.pad.pkcs7, iv: ivhex };  var encrypted = cryptojs.tripledes.encrypt(pt, key, options); var encryptedbase64 = encrypted.tostring(); console.log(encryptedbase64);  var ct = { ciphertext: cryptojs.enc.base64.parse(encryptedbase64) };                                                     var decrypted = cryptojs.tripledes.decrypt(ct, key, options); console.log(decrypted.tostring(cryptojs.enc.utf8)); 

key ="3ad5485e60a4fecd" message="texttoencrypt"

encrypted got java chkl5nvtbxesekfniokpdw==

encrypted got javascript chkl5nvtbxetfwswp882vw==

can me or give me brief knowledge why happens.

there multiple differences in 2 codes:

• you're using different modes of operation. java using ecb , js using cbc.

  always use qualified cipher string.

  cipher.getinstance("tripledes"); may result in different ciphers depending on default security provider. results in "tripledes/ecb/pkcs5padding", doesn't have be. if changes, you'll lose compatibility between different jvms. reference: java default crypto/aes behavior

  also, pkcs#5 padding , pkcs#7 padding equal intents , purposes.

• your key different. sha-1 hash has output of 20 bytes, full 3des key 24 bytes long. arrays.copyof(digestofpassword, 24); fills remaining 4 bytes 0x00 byte values. in cryptojs, you're directly passing short key encrypt function. you'd need fill remaining bytes 0x00 bytes. since cryptojs handles binary data in wordarray, can done in way:

  key = cryptojs.sha1(key); key.sigbytes += 4; // 32 bit more marked key.words.push(0); // 32 bit of zeros 

• your iv strange. easy:

  var ivhex = cryptojs.enc.hex.parse('0000000000000000'); // 8 bytes 

  this can done testing, in production iv must unpredictable (read: random). don't use static iv, because makes cipher deterministic , therefore not semantically secure. attacker observes ciphertexts can determine when same message prefix sent before. iv not secret, can send along ciphertext. usually, prepended ciphertext , sliced off before decryption.

i suggest throw away code (only provides 80 bit of security , uses bad defaults) , use library such rncryptor.

---

security considerations

never use ecb mode. it's deterministic , therefore not semantically secure. should @ least use randomized mode cbc or ctr. better authenticate ciphertexts attacks padding oracle attack not possible. can done authenticated modes gcm or eax, or encrypt-then-mac scheme.

don't use triple des nowadays. provides @ best 112 bit of security if use largest key size of 192 bit. if shorter key size used, provides 56 or 57 bits of security. aes faster (processors have special aes-ni instruction set) , more secure lowest key size of 128 bit. there practical limit on maximum ciphertext size 3des. see security comparison of 3des , aes.