Question regarding s2k algorithms

[Robert J. Hansen]

Kevin Hilton wrote:
> I would assume however if this file along with the password was
> distributed, that the recipient's gpg version would need to
> specifcally have to have the SHA256 enabled in their build or a
> problem would result.

Potentially.  This is why we tell people not to muck about with the
defaults.  If there's an actual critical need to alter the s2k, then
fine, tweak it: otherwise, leave it with the defaults and don't muck
about with it.

By default, GnuPG will use SHA1 for this task.  All OpenPGP applications
are guaranteed to support SHA1, so it's a nonissue.  Further, the recent
attacks against SHA1 are irrelevant in this particular crypto domain.
For this purpose, SHA1 is still as strong as it's ever been.

> 2. Asymmetric Encrytion -- Am I wrong to assume, but isn't the
> session key salted and hashed in the same manner?  Again, wouldn't
> the recipient need the specific hashes installed.

No.  A random session key is generated.  There's no need to hash random
data; in fact, you can argue that hashing random data will probably
decrease its randomness.

> If you are using a "stock" gpg.conf file, and say for example this 
> variable is set to Camellia, or IDEA.

Contradiction.  The stock gpg.conf file does not set this option.  If a
user is going to muck about with the defaults, then they're responsible
for the consequences of that mucking.  You may wish to clarify what you
mean.

> If you use this "stock" gpg.conf file with another gpg version that
> doesn't have these ciphers compiled in -- What results?  A default
> back to CAST5?

Beats me.  GnuPG tends to bail out if there's an invalid option in the
gpg.conf file.  I don't know if that's the case for this option, but
that's what's happened to me in the past.

> What if you change this parameter after keys are already stored on
> the keyring? Will this confuse things?

No.

> And lastly what specifically is the purpose of the
> -for-your-eyes-only flag?  Is this option currently still in use, or
> only included for backwards compatibility purposes.

The specific purpose is to be compatible with a PGP 2.6 'feature' which
was really just marketing hype.  As the GnuPG manpage says, this option
does not actually do what people want it to do.  That said, I am
absolutely certain if the GnuPG developers were to remove it there would
be a hue and cry.