On Wed, Feb 10, 2016 at 12:44 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> pgcrypto supports s2k-mode for key-stretching during symmetric
> encryption, and even defaults to s2k-mode=3, which means configurable
> iterations.  But it doesn't support s2k-count to actually set those
> iterations to be anything other than the default.  If you are
> interested in key-stretching, the default is not going to cut it.
> (You could argue that pgp's s2k doesn't cut it either even at the max,
> but at least we should offer the maximum that the pgp spec makes
> available.)
> This patch implements s2k-count as an option to pgp_sym_encrypt.
> Demo (note the password is intentionally wrong in the last character):
> select pgp_sym_decrypt(
>     pgp_sym_encrypt('foobar','acf86729b6b0289f4d1909db8c1aaf0c','s2k-mode=3'),
>     'acf86729b6b0289f4d1909db8c1aaf0d');
> ERROR:  Wrong key or corrupt data
> Time: 1.606 ms
> select pgp_sym_decrypt(
> pgp_sym_encrypt('foobar','acf86729b6b0289f4d1909db8c1aaf0c','s2k-mode=3,s2k-count=65000000'),
>    'acf86729b6b0289f4d1909db8c1aaf0d');
> ERROR:  Wrong key or corrupt data
> Time: 615.720 ms
> I did not bump the extension version.  I realized the migration file
> would be empty, as there no change to SQL-level functionality (the new
> s2k-count is parsed out of a string down in the C code).  Since only
> one version of contrib extensions binary object files are installed in
> any given postgres installation, people using the newer binary gets
> the feature even if they have not updated the extension version.  So I
> don't know if it makes sense to bump the version if people inherently
> get the feature anyway.

There's zero reason to bump the extension version if the SQL interface
hasn't changed.

(I have no opinion on the underlying patch.)

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to