Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 12 Apr 2015 14:41:52 +0200
From: Frank Dittrich <frank.dittrich@...lbox.org>
To: john-dev@...ts.openwall.com
Subject: Re: gpg and gpg-opencl benchmarks

On 04/05/2015 07:34 PM, Solar Designer wrote:
> On Sun, Apr 05, 2015 at 07:16:24PM +0200, Frank Dittrich wrote:
>> yes you are right, thanks for noticing.
>>
>> I just took my_salt->count and reported it as iteration count.
>> But in gpg_fmt_plug.c we have
>>
>> 532:		n = cur_salt->count / bs;
>> 533-		while (n-- > 0) {
>> 534-			SHA1_Update(&ctx, keybuf, bs);
>> 535-		}
> [...]
> 
> Does this mean that our test vectors used for benchmarking don't
> correspond to GnuPG's default s2k count of 65536?  Or does it mean that
> GnuPG's default s2k count of 65536 corresponds to this many bytes
> processed through SHA-1, rather than to this many iterations of SHA-1?

I created a new issue on github, also asking Dhiru for clarification:
https://github.com/magnumripper/JohnTheRipper/issues/1202

I did some experiments and found that
gpg --gen-key
with dfault parameters results in a count of 65536, while
gpg --gen-key --s2k-count 262144
results in a hash with count 262144.
I also verified that john --format=gpg successfully cracks these hashes,
so I think the gpg format implementation is correct, except for the cost
reporting.

man gpg says for --s2k-count:


       --s2k-count n
              Specify how many  times  the  passphrase  mangling  is
              repeated.   This  value  may  range  between  1024 and
              65011712 inclusive.  The default is inquired from gpg-
              agent.   Note that not all values in the 1024-65011712
              range are legal and if an illegal value  is  selected,
              GnuPG  will round up to the nearest legal value.  This
              option is only meaningful if --s2k-mode is 3.


But looking at the real code, I think the description is misleading, and
your observation that this count represents the number of bytes
processed through the specific hash algorithm is correct.

Frank

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ