AES - Encryption with Crypto (node-js) / decryption with Pycrypto (python)

So we started from the "How can i decrypt... OpenSSL" 's answer.

• We needed to modify the encryption script which gave:

  crypto = require "crypto"[...]var iv = new Buffer('asdfasdfasdfasdf')var key = new Buffer('asdfasdfasdfasdfasdfasdfasdfasdf')var cipher = crypto.createCipheriv('aes-256-cbc', key, iv);cipher.update(new Buffer("mystring"));var enc = cipher.final('base64');[...]

  iv needs to be 16bytes long, key is 32bytes. And we changed createCipher to createCipheriv.

• Back to the python decryption script:

  Process was simply reading PyCrypto's documentation, and compare with the code we started from.

  Then we decided to just stick to the API, and start from scratch. And it gave:

  from base64 import b64decodefrom Crypto.Cipher import AES[...]iv = 'asdfasdfasdfasdf'key = 'asdfasdfasdfasdfasdfasdfasdfasdf'encoded = b64decode('my_encrypted_string')dec = AES.new(key=key, mode=AES.MODE_CBC, IV=iv)value = dec.decrypt(encoded)

And it was as simple as that...Hope it'll help some of you!

Update:

As Perseids wrote in the comments of his answer, the IV has to be random and different for every message

The system you are building is probably insecure

Except for storage you basically never want to just encrypt your data, but also authenticate it. Authentication in this context means that a valid message can only be generated by someone who knows the key. A widely used authentication scheme is HMAC.

If you do not authenticate your messages anyone can feed data into your service. An attacker might not be able to fully control the outcome after decryption but he/she might still be very dangerous. For example, if you use CBC (which you do) and the most common paddings schemes (AES is a block cipher and can only encrypt 128bit Blocks of data) and an attacker can differentiate between a padding error and any other error then all your messages can be decrypted by an attacker. This is called a padding oracle attack and is far too common.

To protect from this class of attacks you can use an authenticated encryption scheme, for example the GCM blockcipher mode.

Also you have to protect against replay attacks. Consider a banking application and the data you are transmitting is a bank transfer order. Barring any TAN an attacker might record a previous transaction and replay this transaction to your service again and again thus transferring a multiple of the money the customer originally wanted to.

Is the form you are getting the data from transmitted over HTTPS? If not: Can the key be eavesdropped by an attacker? How does a user know he got the form from you and not anybody else (SSL/TLS is as much about authentication as it is about confidentiality).

Probably I have forgotten some other attack vectors simple CBC-encryption offers.

Alternatives

Probably the easiest way to protect against these attacks is to transmit the form data over HTTPS. SSL/TLS was designed to prevent all of the above attacks and the client and server side implementations had a long time to mature.