Jeff Janes wrote:
> On Tue, Mar 8, 2016 at 4:09 PM, Alvaro Herrera <> 
> wrote:

> Yeah, I find that pretty impenetrable too.  I just treated it as a
> black box, I changed how the number passed into it gets set, but not
> the meaning of that number.  Initially I had the user set the one-byte
> format directly because that was much simpler, but before submitting
> the patch I changed it to take the human-readable value and do the
> conversion to the one byte format, because the gpg command-line tool
> takes the number of iterations, not the one byte format, as the input
> for its own s2k-count setting.

Funny -- I partially edited the patch to use the one-byte number instead
too, because that seemed more reasonable, but eventually (looking at
gnupg) decided not to.  And deleted the email on which I explained that,
without sending.

> > I would love to be able to read gnupg's code to figure out what it is
> > that they do, but the structure of their code is even more impenetrable
> > than pgcrypto's.  Perhaps it would be easier to measure the time it
> > takes to run some s2k operations ...
> The timings are about the same between the patched pgcrypto and gpg
> when using the same settings for s2k-count.  Also, if I encrypt with
> gpg with a certain setting, pgcrypto properly detects that iteration
> count and uses it (if it didn't get it correct, it would be unable to
> decrypt).  And vice versa.

OK, it seems we're good then.

> Do we know why the default for pgcrypto is to use a stochastic number
> of iterations?  I don't see how that can enhance security, as the
> number of iterations actually done is not a secret.

Nope, unless Marko has some input there.  I find it baffling too.

> And I see that you committed it now, so thanks for that too.

You're welcome, thanks for the patch.

Álvaro Herrera      
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to