supporting caller provided IV in AES encrypt/decrypt

[GoogleCodeExporter]

supporting caller provided IV in AES encrypt/decrypt

[GoogleCodeExporter]

Forgot to mention that now I can AES encrypt/decrypt back and forth between 
node.js crypto and crypto-js so I can encrypt/decrypt on client-side and 
optionally decrypt at server-side when browser is too slow (like IE). I used to 
run crypto-js server-side too but node.js is much faster (10x) so I switched 
over.

Original comment by [email protected] on 14 Mar 2011 at 9:28

[GoogleCodeExporter]

Hi Don,

I apologize for the delay.

For encrypt(), I copied your options.iv into the repo. For the ciphertext 
result, however, I did something a little different, which I hope will be even 
more flexible. Rather than returning a string, encrypt() now returns a 
ciphertext object. For backward compatibility, that object has a toString 
method that will turn the encrypted message and the IV into a string in the 
same way previous versions did. But it also allows you to access the ciphertext 
and IV individually.

    var ciphertextObj = Crypto.AES.encrypt("Message", "Secret Passphrase", { iv: Crypto.util.hexToBytes(yourIV) });

    ciphertextObj.rawCiphertext
    ciphertextObj.iv

Likewise, when you're preparing to decrypt, you can pass in a ciphertext object 
in place of a string.

    var ciphertextObj = new Crypto.Ciphertext(
        Crypto.util.base64ToBytes(yourRawCiphertext),
        Crypto.util.hexToBytes(yourIV)
    );

    Crypto.AES.decrypt(ciphertextObj, "Secret Passphrase");

I'd like to hear your thoughts, suggestions or concerns. Barring any issues, 
I'll be tagging and packaging a new version soon.

Revision r324: http://code.google.com/p/crypto-js/source/detail?r=324

Original comment by Jeff.Mott.OR on 22 Mar 2011 at 10:50

• Changed state: Accepted

[GoogleCodeExporter]

Hi Jeff,

Only concern I have is that this breaks API backward compatibility. Besides, if 
caller provided the IV, it's already known to the caller. If they didn't, I 
doubt they would need it beyond being wrapped within encrypted text.

Anyway, my recommendation is to add it as another method (like encryptIV) to 
maintain backward compatibility.

- Don

Original comment by [email protected] on 23 Mar 2011 at 6:06

[GoogleCodeExporter]

Indeed. At first, I was also worried about the ciphertext object breaking 
backward compatibility. But it seems to be safe for all the use cases I can 
think of. If the ciphertext object is sent by ajax, or assigned to a form 
control, or used in any kind of string context, then the toString method is 
called automatically, and the result will be the same as it was in previous 
versions. Though, I suppose it's always possible someone somewhere is doing 
something I never planned on or accounted for.

I understand that in your case you don't need to access the IV. But I'm hoping 
to use this opportunity to ease other pain points, beyond this specific issue. 
In your case, you only needed the raw ciphertext. But in other cases, people 
are allowing CryptoJS to generate the IV, and sending the result to a 
server-side application. But not every application packages ciphertext data in 
the same way, and sometimes it's easier for people to handle the IV and the raw 
ciphertext separately.

A lot of this is going to be addressed in the next major release, so I may 
still opt for your simpler fix that solves the immediate issue. I'm still 
mulling it over.

Original comment by Jeff.Mott.OR on 23 Mar 2011 at 7:22

[GoogleCodeExporter]

r326

Original comment by Jeff.Mott.OR on 13 Apr 2011 at 11:49

• Changed state: Fixed