Re: pgcrypto: Remove internal padding implementation

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgcrypto: Remove internal padding implementation
Date: 2022-02-21 10:42:07
Message-ID: fd7e87e6-a741-97dc-ada4-1da55c4224aa@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

Attachment Content-Type Size
v3-0001-pgcrypto-Remove-internal-padding-implementation.patch text/plain 10.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-02-21 10:49:59 Re: pg_stat_get_replication_slot and pg_stat_get_subscription_worker incorrectly marked as proretset
Previous Message Drouvot, Bertrand 2022-02-21 10:29:51 Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns