On 15.02.22 00:07, Jacob Champion wrote:
> After this patch, bad padding is no longer ignored during decryption,
> and encryption without padding now requires the input size to be a
> multiple of the block size. To see the difference you can try the
> following queries with and without the patch:
>
> select encrypt_iv('foo', '0123456', 'abcd', 'aes/pad:none');
> select encode(decrypt_iv('\xa21a9c15231465964e3396d32095e67eb52bab05f556a581621dee1b85385789', '0123456',
'abcd','aes'), 'escape');
Interesting. I have added test cases about this. Could you describe
how you arrived at the second test case?
> Both changes seem correct to me. I can imagine some system out there
> being somehow dependent on the prior decryption behavior to avoid a
> padding oracle -- but if that's a concern, hopefully you're not using
> unauthenticated encryption in the first place? It might be worth a note
> in the documentation.
Hmm. I started reading up on "padding oracle attack". I don't
understand it well enough yet to know whether this is a concern here.
Is there any reasonable meaning of the previous behaviors? Does bad
padding even give correct answers on decryption? What does encryption
without padding even do on incorrect input sizes?