Subject: [openpgp] On composing scrypt and openpgp s2k key stretching for symmetric encryption

From: Brian Gitonga Marete <[email-masked]>
Date: Thu, 22 May 2014 16:48:09 +0300

Hello all!

What would be the security effect of generating a 32 byte key from a
passphrase using scrypt and then using that as a "passphrase" for openpgp's
symmetric encryption (this 32 byte key will of course then be acted upon by
openpgp's s2k algorithm). Specifically, can one expect that this will make
brute-forcing a symmetric passphrase (theoretically or practically) harder?
(Given the same strong passhrase).

Please note that I am asking this from an application point of view and not
calling for the inclusion of scrypt into the openpgp standard.

Thanks!

Brian Gitonga Marete.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 22 May 2014 17:42:11 -0400

> (Given the same strong passhrase).

sounds to me like it would make things harder, but you might need to be
careful with your tooling to ensure that the passphrase handed off to
s2k "looks like" a normal human-typed passphrase.

For example, if the raw scrypt 32-byte key contains a NUL byte or a
newline char, and you pass it to a tool that expects the passphrase as a
single line of null-terminated text, you could have a pretty nasty
failure mode.

you could always base64-encode the output of scrypt before it gets fed
into the later tools just to be sure.

> calling for the inclusion of scrypt into the openpgp standard.

Why would you want to do it this way instead of including it in the
standard?

if you do this to a piece of passphrase-encrypted OpenPGP data, and then
hand the data to some other person or machine, and expect them to be
able to decrypt it, how will that person or machine know to use scrypt
on the passphrase before invoking s2k?

we are not short on available s2k identifiers [0] -- allocating another
one for scrypt given a reasonable specification doesn't seem like a bad
idea to me, especially if people are interested in implementing it.

	--dkg

[0] https://tools.ietf.org/html/rfc4880#section-3.7

---

From: Jon Callas <[email-masked]>
Date: Thu, 22 May 2014 16:41:37 -0700

On May 22, 2014, at 6:48 AM, Brian Gitonga Marete <[email-masked]> wrote:

> Hello all!
> 
> What would be the security effect of generating a 32 byte key from a passphrase using scrypt and then using that as a "passphrase" for openpgp's symmetric encryption (this 32 byte key will of course then be acted upon by openpgp's s2k algorithm). Specifically, can one expect that this will make brute-forcing a symmetric passphrase (theoretically or practically) harder? (Given the same strong passhrase).

Meh.

Intuitively, yes, it would. However, there's really nothing theoretic that says it's better. Most things that are intuitively better but unmeasurable turn out to be far less good than your intuition says. Depressingly often, someone comes up with a clever attack that reduces the intuitive thing to being no better than a bit or two, and in the case of passwords, I've rarely seen anything that's better than adding another character to your password.

> Please note that I am asking this from an application point of view and not calling for the inclusion of scrypt into the openpgp standard.

If you are set on doing it, Dan Gillmor brings up an important point (and a way one could shoot oneself in the foot). An easy way to protect against that is to take your scrypt() result and put it into text -- base64, hex, whatever -- and then use *that* as your input to s2k.

	Jon

---

From: Lutz Donnerhacke <[email-masked]>
Date: Fri, 23 May 2014 11:03:34 +0200

On Thu, May 22, 2014 at 04:41:37PM -0700, Jon Callas wrote:
> Most things that are intuitively better but unmeasurable turn out to
> be far less good than your intuition says. Depressingly often, someone
> comes up with a clever attack that reduces the intuitive thing to being

Yep. One aspect was already mentioned "NUL" characters. The obvious counter
measurement was also mentionen "base64". But this reduces the possible input
variation. It might be possible to mount an attack on it.

The general rule is: If you fear, that the default algorithm is not safe,
change it! You can't incease security by chaining algorithms.

---

From: Jon Callas <[email-masked]>
Date: Fri, 23 May 2014 07:41:05 -0700

> variation. It might be possible to mount an attack on it.

If you can, the hash function is broken. Assuming of course that you're taking then entire expanded string. Any textification of a string is just a sloppy coding, and if the hash function has odd properties, then it's very, very broken.

> change it! You can't incease security by chaining algorithms.

Yes! I couldn't agree more. 

	Jon

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 23 May 2014 10:46:14 -0400

> variation.  It might be possible to mount an attack on it. 

The amount of entropy going into a base64 encoding is *exactly* equal to
the amount of entropy coming out of it.  From a brute-force perspective,
nothing is lost.

The only attacks that fit what you're describing would be an attack
based on plaintext patterns of specific bits of the input (e.g. the high
bit of every octet of input is known to be zero), but i have not heard
of any such attack on an s2k transformation.

If the s2k input tends to come directly from the keyboard, the same
patterns are likely to be present as well (and even more, since
human-memorable passwords have much more structure than base64-encoded
scrypt output).

	--dkg