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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers