On Fri, 8 Jul 2011 22:54, li...@chrispoole.com said:
> 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 w
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
Thank you.
On 8 Jul 2011, at 20:06, Hauke Laging wrote:
> Am Freitag, 8. Juli 2011, 20:35:57 schrieb Chris Poole:
>> On 8 Jul 2011, at 17:31, David Shaw wrote:
>>> Yes. Note that the list-packets output shows the internal packed value:
>>> 6553600 should come out to 201. The default of 65536
On Jul 8, 2011, at 2:35 PM, Chris Poole wrote:
> On 8 Jul 2011, at 17:31, David Shaw 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 t
Am Freitag, 8. Juli 2011, 20:35:57 schrieb Chris Poole:
> On 8 Jul 2011, at 17:31, David Shaw 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 inter
On 8 Jul 2011, at 17:31, David Shaw 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?
I also changed the digest algorithm to
On 07/08/2011 12:31 PM, David Shaw 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.
>
> You might file an enhancement bug to print the decoded value in
> --list-packets. We already print
On Jul 8, 2011, at 10:10 AM, Chris Poole wrote:
> When changing my secret key's passphrase, I bumped up the s2k-count to
> 6553600 (I just added two zeros; I don't notice any slow down when
> decrypting on a Core2Duo).
>
> How can I confirm that this count is being used?
>
> I ran gpg --list-pac
When changing my secret key's passphrase, I bumped up the s2k-count to
6553600 (I just added two zeros; I don't notice any slow down when
decrypting on a Core2Duo).
How can I confirm that this count is being used?
I ran gpg --list-packets ~/.gnupg/secring.gpg, which told me a number
for "protect
