Re: pgcrypto: Remove internal padding implementation

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Jacob Champion <pchampion@vmware.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-03-16T10:12:06Z
Lists: pgsql-hackers

Attachments

>> 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.

Commits

  1. pgcrypto: Remove internal padding implementation