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.
Cheers,
Jeff