Thanks for the detailed response. I've done some C programming so it's not too alien to me.
I don't know if this would be of any real use (perhaps just for those that are pretty sure of the slowest machine they'll be decrypting their private key on), but a function to calculate how many rounds it takes to run for x.y seconds would be useful. KeePass, for example, automatically calculates how many rounds can be calculated in 1 second, and will set the count accordingly. On 8 Jul 2011, at 20:08, David Shaw <[email protected]> wrote: > On Jul 8, 2011, at 2:35 PM, Chris Poole wrote: > >> On 8 Jul 2011, at 17:31, David Shaw <[email protected]> wrote: >>> Yes. Note that the list-packets output shows the internal packed value: >>> 6553600 should come out to 201. The default of 65536 would encode to 96. >> >> I do indeed get 201. Out of interest, how is that calculated? > > Brace yourself. This is not pretty: > > #define S2K_DECODE_COUNT(_val) ((16ul + ((_val) & 15)) << (((_val) >> 4) + 6)) > > OpenPGP historically has a bit of a phobia about using two or four bytes when > it could be squeezed into one. Or even better, part of one. That's why the > range of valid s2k-count values is 1024 through 65011712, but not all values > are actually possible. > >> I also changed the digest algorithm to SHA512; the iter+salt line shows >> this, but still mentions SHA1 protection. > > It's using SHA512 for passphrase mangling. The SHA1 protection it is > referencing is a checksum on the while secret key packet itself. You can see > the details in section 5.5.3 of RFC-4880, but basically it was added in > response to the Klima-Rosa attack (which involved modifying the secret key in > a way that the simple checksum used previously could not detect). > > David > _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
