Modern gnupg.conf setup

[Robert J. Hansen]

> It seems I was right to have asked here after all. It's amazing how many
> outdated tutorials exist...

That presumes they were ever accurate in the first place.  Many of them
were not.

>> personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192
>> CAMELLIA192 AES CAMELLIA128
>> personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160
> 
> Should these also be included in the default-preference-list? I think
> the latter is only used when generating new keys (setpref), yes?

Not necessarily.  Personal-cipher-preferences is the list of ciphers
you're willing to use, but the list of ciphers on your key (what's put
there via setpref) is the list of ciphers you ask *other people* to use.

Will they often be the same?  Yes.  But not always, and there's a
subtlety there that's often overlooked.  You might be willing to
generate traffic using ciphers you're not willing to accept.

>>> cert-digest-algo SHA512
>>
>> Still valid, still useful.
> 
> This I'm uncertain about. Should probably be removed too?

Probably not.

The reason why cipher-algo and digest-algo are recommended against is
because GnuPG already has a robust mechanism for choosing a strong
cipher that you're willing to generate (via personal-cipher-preferences)
and the recipient is willing to receive (via prefs on the key).

There is no such mechanism for certificate signatures.  That's entirely
generated by you.  You have zero knowledge of what algorithm other
people will use.  If you want maximum interoperability, you have to use
SHA-1; everyone can read SHA-1 signatures.

But that's SHA-1, and SHA-1 isn't exactly a highly recommended digest
any more.

Use something better and stronger.  SHA512 is probably the best option
right now.  If someone can't read your certificate signatures, well --
that's on them: they should be moving away from SHA-1.

> The RFC 4880 standard (section 9) does say that 3DES and SHA-1 must be
> implemented, but the reason I included these is because I read on some
> websites that you do NOT want to use these at all due to their
> weaknesses and there should be some way of warning the user that weak
> algorithms are being used.

I question the credentials of anyone calling 3DES "weak".  It has one
and only one serious cryptographic weakness: due to its 64-bit block
size, it should not be used to encrypt more than about 4Gb of data with
the same session key.

40 years after it was first released, the best attack on it is a
meet-in-the-middle that requires -- hand to God, I am not making this up
-- 64 pebibytes of RAM, 2**112 operations, and several strategic nuclear
weapons to generate enough energy to run the computer.

Let me repeat: I am not making that up.

So, yeah, if your attacker has technology straight out of _Star Trek_
and is willing to cause untold ecological catastrophe, you're hosed.
Otherwise, 3DES is still solid.

That's not to mean it's perfect.  It's not.  It's slow, it shouldn't be
used to encrypt bulk data due to its 64-bit blocksize, and more.  There
are lots of reasons to prefer other, better ciphers than 3DES.  And
maybe I can understand people calling it "weak" because really, that's a
lot easier for people to understand than talking about block sizes and
clock-cycles-per-block and everything else.

But it's *not weak*.  And any website that tells you to avoid 3DES
because it's weak is, to be honest, either too ignorant to be taken
seriously, so patronizing they'll handwave away complex issues behind
the comforting veneer of "it's weak", or is outright lying to you.

SHA-1, on the other hand...

*At the present moment* SHA-1 is still trustworthy in the places where
it's baked into the RFC4880 spec.  The attacks against it don't affect
the (few) places where it's baked into OpenPGP.  But attacks can get
better quite suddenly, and it's a good idea to avoid SHA-1 whenever
possible.

But please don't use weak-digest on SHA-1.  The only thing it'll do is
drown you in false positives.  99.999% of the time when you get a
warning of "SHA-1 is being used!!!!  You asked me to warn you about
it!!!!!", in fact nothing is amiss at all.

A 'warning' that's wrong 99.999% of the time is worse than receiving no
warning at all.