782746 - Switch to using M2Crypto

Status: VERIFIED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect)

Description

[Andy McKay]

As pointed out MySQL AES uses ECB which actually isn't that good.

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29

We should just do this in M2Crypto (or other Python library) for a couple of other reasons:

- less hits to the db
- no logging of the secret key in any mysql logs (let's just not log it in Python)
- more portable.

This will mean adding in the relevant Python libs (M2Crypto is already on redhat) and then forking django-mysql-aesfield to something else and using that.

Comment 1

[Frederik Braun [:freddy]]

I just thought of this hack:

AES in MySQL uses a block size of 128 bits (16 bytes). Subtracting the padding byte, you have 15 bytes of information left.

As long as you store only IDs, you wouldn't be affected by the major ECB drawback. If you pack your IDs with python's struct.pack() the 15 bytes will give you an integer storage up to (2^15)-1.

I guess logging might be disabled and encryption is a negligible CPU overhead - whether it is in databse or web application.
My hack will leave the portability issue untouched though.

Comment 2

[Kumar McMillan [:kumar]]

Hah! Clever. We should really port to M2Crypto though. No reason not to. We already have M2Crypto in our stack because we do RSA signing.

Comment 3

[Andy McKay]

https://github.com/mozilla/solitude/commit/036be1
https://github.com/andymckay/django-aesfield

This will mean dropping all using old encryption data, which is all irrelevant anyway.