On Tue, Mar 8, 2016 at 4:09 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > 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.
Thanks for taking this up. 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. > 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. 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. And I see that you committed it now, so thanks for that too. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
