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

On 04/12/2015 05:41 PM, Solar Designer wrote:
> Thank you!  I've just confirmed our current understanding here:
> 
> https://tools.ietf.org/html/rfc4880#section-3.7.1.3
> 
> "  [...] The total number of octets to be hashed is specified in the
>    encoded count in the S2K specifier.  Note that the resulting count
>    value is an octet count of how many octets will be hashed, not an
>    iteration count."
> 
> I think GnuPG documentation is wrong, and should be revised.  Both
> texinfo and man.

I think even the rfc is somewhat misleading, and the misleading
information in gpg's man page and info are a result of the rfc text:

-----------------------------------------------------------------------
3.7.1.3.  Iterated and Salted S2K

   This includes both a salt and an octet count.  The salt is combined
   with the passphrase and the resulting value is hashed repeatedly.
   This further increases the amount of work an attacker must do to try
   dictionary attacks.
-----------------------------------------------------------------------

"The salt is combined with the passphrase and the resulting value is
hashed repeatedly" can easily be misunderstood as "iteration count",
if you stop reading before the "Note that the resulting count
value is an octet count of how many octets will be hashed, not an
iteration count".

> Would you care to report this to GnuPG, perhaps along
> with a documentation patch?

Actually I think you found the problem, so I do not deserve being
credited for this. But I'll see if I find the time during the next week.

Frank

Powered by blists - more mailing lists

Your e-mail address:

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