If you're not clear on why compressed keys give you a different address and how they are handled in Bitcoin-Qt, you should do a little research before moving keys between wallets.
I'm working on that right now. From my existing knowledge of compression, however, compressed keys should just need to be decompressed. Obviously, that's not the case, so I'll be looking into it.
I was short because I was in a hurry to respond. Now I have 30 more seconds
The reason is that your bitcoin address is the hash of your public key. If you use a compressed public key, you get a different hash than if you used the uncompressed key. The ECDSA is all the same after uncompressing, but you need to make sure you're using the right address.
As such, the Bitcoin-Qt devs decided to add a 0x01 byte to the end of all private keys that use compressed public keys. If it was not there, then having the raw ECDSA key would give no indiciation of whether to use compressed or uncompressed for hashing to create the address. For instance -- in Armory, the 0x01 byte will be added when keys are "encoded" to be moved around, but in the file format, they will be stored as 32-byte integers with a one-bit flag identifying whether they are compressed. That's why it matters.
I see. Also, while examining the code to pywallet, I see they have an AES implementation. Good thing I already have one I wrote, or this could take a while.
