Jeff Janes 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.
Talking about deep rabbit holes ...
I gave this a look. I adjusted it here and there for project style and
general cleanliness (something that could be applied to pgcrypto much
more generally) and eventually arrived at trying to figure out how is
the s2k count actually used by the underlying algorithm. I arrived at
the function calc_s2k_iter_salted which is where it is actually used to
encrypt things. But that function is completely devoid of comments and
not completely trivial. At this point I cannot for the life of me
determine whether that function should use the one-byte format specified
by the relevant RFC (4880) or the decoded, human-understandable number
of iterations.
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 ...
I CCed Marko here. Hopefully he can chime in on whether this patch is
correct.
Anyway, assuming that the iteration count was already being used
correctly, then as far as I'm concerned we're ready to go. The attached
patch is what I would commit.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services