>> Interesting. I have added test cases about this. Could you describe
>> how you arrived at the second test case?
>
> Sure -- that second ciphertext is the result of running
>
> SELECT encrypt_iv('abcdefghijklmnopqrstuvwxyz', '0123456', 'abcd', 'aes');
>
> and then incrementing the last byte of the first block (i.e. the 16th
> byte) to corrupt the padding in the last block.
I have added this information to the test file.
>> Is there any reasonable meaning of the previous behaviors?
>
> I definitely don't think the previous behavior was reasonable. It's
> possible that someone built a strange system on top of that
> unreasonable behavior, but I hope not.
>
>> Does bad padding even give correct answers on decryption?
>
> No -- or rather, I'm not really sure how to define "correct answer" for
> garbage input. I especially don't like that two different ciphertexts
> can silently decrypt to the same plaintext.
>
>> What does encryption without padding even do on incorrect input sizes?
>
> Looks like it's being silently zero-padded by the previous code, which
> doesn't seem very helpful to me. The documentation says "data must be
> multiple of cipher block size" for the pad:none case, though I suppose
> it doesn't say what happens if you ignore the "must".
Right, the previous behaviors were clearly faulty. I have updated the
commit message to call out the behavior change more clearly.
This patch is now complete from my perspective.
