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:
http://www.postgresql.org/mailpref/pgsql-hackers
