A while ago, I began purchasing music off of beatport. Unfortunately they do not offer FLAC downloads, so I pay the extra dollar to download wav files. The downside is that I have to manually enter metadata. This is painful, so I created a quick python script using their almost invisible api that does it all for me (the wav files must have kept their original filenames, because the numbers in front represent the track id).

If you ever want to use a crypto library in Python, you’ll be sad to note that there isn’t one built into Python impressive repertoire of modules. In fact, you’ll most likely hit pycrypt on your Google search to find one. And there is some dirty work you’ll have to do if you want to use symmetric cryptography using this library. And one of the hard/easy parts is knowing the difference between ECB and CBC.

Here, we start initializing the AES object using CBC mode:

>>> from Crypto.Cipher import AES;
>>> aes = AES.new('some key here', AES.MODE_CBC, 'INIT_VECTOR')
Traceback (most recent call last):
File "<console>", line 1, in <module>
ValueError: IV must be 16 bytes long

oops. You’ll have to make you’re initialization vector 16 bytes long. Also, your key has to be 16, 24, or 32 bytes long as well. Let’s do something better :

>>> aes = AES.new('J2-+sfd%932mIt:{', AES.MODE_CBC, 'wir&/>H54mgd9a";')

ah! much better. Even if it was me smashing my hand against the keyboard. Now let’s encrypt/decrypt something important.

>>> aes.encrypt('the answer to life the universe and everything is 42')
Traceback (most recent call last):
File "<console>", line 1, in <module>
ValueError: Input strings must be a multiple of 16 in length

You’ll have to do the dirty work remember:

>>>> ciphertext = aes.encrypt('the answer to life the universe and everything is 42195479204957')
>>> ciphertext
'f0\xa9\xf9f&X)\x0e\x08=\x06\x97\xcbF\xddK\x1a\xa6i\x1d\x02"}\xd9\\\xaa\xb6\xd9J\xe3Q\x07\xaev\x012\xbf\rPN\xd2\xf9\xf7$\x93\xe0/\xcb\xae9\x91K\xd01\xab\xb7\xdb\reR\xff\xef\x1c'

Much better. Now lets decrypt it:

>>> aes.decrypt(ciphertext)
'\xc8\xaf.\x97\x05\x80\n\xe9\xe6\xc4Ju\x04\xbe\xa1Nfe the universe and everything is 42195479204957'

Woah! That isn’t the whole message! So what’s going on?

Remember that initialization vector you set in the beginning? That sets the stage for the first block. But each block becomes the initialization vector for the second block, and so on. So when you decrypt, it is using the initialization vector from the block before. That’s why the first 16 bytes are screwed up. This is a feature of CBC, but not ECB:

>>> aes = AES.new('J2-+sfd%932mIt:{', AES.MODE_ECB, 'wir&/>H54mgd9a";')
>>> ciphertext = aes.encrypt('the answer to life the universe and everything is 42195479204957')
>>> aes.decrypt(ciphertext)'the answer to life the universe and everything is 42195479204957'

And yes, this is a feature. Read the block cipher modes wikipedia article for a better explination. So what’s the answer? Simply, to call aes.new() again before calling decrypt!

I came across a bug in the zipfile python module yesterday that I had to fix today. The problem occurs when you try to create a ZipFile object and passing it a corrupt zip file. It doesn’t handle it gracefully like returning None or throwing an exception. Rather it heads into an infinite loop.

This is rather unfortunate for me. How would I get around this problem? The first thing I did was check for an updated python. Which there was a minor version upgrade. I found the changelog (why do they hide these things?) and noticed a few bugs resolved with the zipfile module. So I installed. Unfortunately, this didn’t solve my problem.

I managed to find a bug number in the python bug tracking software about people having similar problems. There was a patch, but hasn’t landed. I downloaded the latest stable version, but the patch wouldn’t go through. So I had to cvs checkout trunk and apply it. Once installed, I tried it and it worked! Success.

However, it broke other library I was using (PyXML). Unfortunate for me, the recent trunk build didn’t seem to fair any better.

At this point, I wasn’t in the mood for debugging. I had a few options at my disposal :

1. Ignore this particular file
2. Suck it up and debug it.
3. Find a whacky work-around

Option 1 isn’t an option. Option 2 I tried for a fair while, but nothing worked. So Option 3 was my only option!

I tried using a lower level library to see if I can fix the problem (zlib library), but that didn’t work well at all.

I finally thought I had no choice but to initiate a thread to try and unzip the xpi, and if it took longer than 10 seconds, to kill the thread somehow. While seriously looking into this, and fighting the temptation to take tequelia shots at work. I came across signals (which I thought I could use to send to the thread. I’m so naive). It turns out, you can throw a signal after a specific number of seconds and it throws the SIGALRM. This was exactly what I needed without the extra complexity. The example provided was almost exactly what I did too! Here is my solution to the problem :

		signal.signal(signal.SIGALRM, signal_handler)
		signal.alarm(10)
		try:
			zippy = zipfile.ZipFile(io, 'r')
			signal.alarm(0)
		except:
			print "\tZipFile Timeout"
			continue

Maybe python isn’t just for programming sissies after all.