October 20, 2011: Serious issues with encrypted pastes

Due to me misinterpreting the php mcrypt API I created some very serious bugs in the encrypted paste code. The short explanation is that the encryption was not using AES-256 but Rijndael with 256 bit block sizes. Additionally the pastes were encrypted using insecure keys directly derived from the passphrase provided.

The longer explanation: In addition to using the wrong cipher the encryption keys were the plaintext password paddedwith \0 to 128, 192 or 256 bits. If your passphrase was longer than 32 bytes it was simply trunctated.
Another less serious problem was the way thunkbin detected if you entered the correct passphrase, it decrypted the data with the passphrase you provided and verified if the first 4 bytes had the correct magic value. What this means is that you could let the server print out an incorrctly decrypted text with 2^32 operations. The implications of this are unclear to me, I don't believe it could be used to leak the correct ciphertext due to the IV being unknown.

All the flaws described here are now fixed and to protect the contents of encrypted pastes I have deleted all encrypted pastes. All offsite backups will also be deleted as soon as it becomes clear that no problems arise with the new thunkbin version. Encryption keys are now derived from the password using PBKDF2-HMAC-SHA256 with 4096 iterations. To verify the passphrase HMAC-SHA256 is used to authenticate the ciphertext (the HMAC key is also derived from the password using PBKDF2). For more specific information on how the code was fixed please review the source code patch.