lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 09 Apr 2013 07:05:05 -0600
From: havoc <>
Subject: Re: [PHC] Is this really safe ...

On 04/09/2013 02:41 AM, Yann Droneaud wrote:
> Hi,
> Is it really safe to use GitHub to store a secret key ring ?
> Someone point me to this:
>     You may have noticed, yes, I have my private PGP key in here!
> Dangerous?!
>     Maybe, it's an experiment. It's got a strong passphrase on it and I've
>     pumped up the key strengthening settings in GPG, like so,
>     gpg --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3 \
>         --s2k-count 10000000 --edit-key <key id>
>     Then run passwd in the key editor. That's over 10 million rounds of
>     SHA-512 which takes a half-second to compute on my laptop.
> Brute-forcing
>     my passphrase should be completely impractical. I invite anyone to
> prove
>     me wrong

It's secure as long as all of the keys are encrypted. It's what I use
for my off-site backups at Amazon too:

Except I publish just the encrypted private key, not my entire key ring.

The benefit is that it lets you automate the backup encryption and
upload process without having to put the password in the script. As long
as the password protecting the private key is secure, then it can't be
decrypted (hopefully).

[snip key information]

> So if I understand, the iteration count will be equal to "Count / Hash
> output size",
> eg 163840 rounds.

The way the iteration count is stored is actually pretty obscure:

The specific code is:

 * The count is stored as 4.4 bit normalized floating-point.  The high
 * 4 bits are the exponent (with a bias of 6), and the low 4 bits
 * are the mantissa.  0x12 corresponds to (16+0x2) << (0x1+6).
 * The minimum value is (16+0) << (0+6) = 0x400 = 1024.
 * The maximum is (16+0xf) << (0xf+6) = 0x3e00000 = 65011712.
 * These functions convert between the expanded count and a
 * floating-point approximation.
#define EXPBIAS	6
static PGPUInt32
c_to_bytes(PGPByte c)
	return ((PGPUInt32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);

Which gives:

(16 + (212 & 15)) << ((212 >> 4) + 6)
=> 10485760

Which agrees with the output of your commands.

Here's part of the code that does the hashing:

/* Find the length of the material to hash */
bytes = c_to_bytes(priv->buf[10]);
/* Always hash a least the whole passphrase! */
if (bytes < slen + 8)
	bytes = (PGPUInt32)(slen + 8);

/* Hash len bytes of (salt, passphrase) repeated... */
while (bytes > slen + 8) {
	multiHashUpdate (h, v, num, priv->buf+2, 8);
	multiHashUpdate (h, v, num, (PGPByte const *)str, slen);
	bytes -= slen + 8;

slen is the length of the password, and the length of the salt is 8.

The total calls to the compression function is:

Count / Hash *input block* size.

SHA512's block size is 1024 bits, the approximate number of times SHA1's
compression function gets called is:

10485760 / 1024 = 10240.

So he is incorrect to say "That's over 10 million rounds of

> I haven't read any implementation of the Iterated-Salted S2K algorithm,
> but it seems, well,
> worst than PBKDF. I tought PGP would use such algorithm to protect
> secret keys.

I agree the algorithm is not the best, but it's there for backwards
compatibility with old versions of PGP from 1996, before PBKDF2 was
published (RFC2898, 2000) (Source: Solar Designer told me on twitter,
but I can't find the tweet). You can always run the password through
PBKDF2 yourself before you give it to GPG.


Powered by blists - more mailing lists