On 05/22/2014 09:48 AM, Brian Gitonga Marete wrote:
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).
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.
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.
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
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp