Check that s2k-count has changed

[Chris Poole]

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 <dshaw at jabberwocky.com> wrote:

> On Jul 8, 2011, at 2:35 PM, Chris Poole wrote:
> 
>> On 8 Jul 2011, at 17:31, David Shaw <dshaw at jabberwocky.com> 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
>