Jeff Janes wrote:
> On Tue, Mar 8, 2016 at 4:09 PM, Alvaro Herrera <alvherre@2ndquadrant.com> 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 http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services