Modern gnupg.conf setup

[Defiant]

On 15. 12. 19 19:32, Robert J. Hansen wrote:
>
>> 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.
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

Hey, thanks for all the help. That was really an educational read.

I ended up with this config file contents:
keyid-format 0xlong
with-fingerprint
personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192
CAMELLIA192 AES CAMELLIA128
personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
ZLIB BZIP2 ZIP Uncompressed
cert-digest-algo SHA512


Do you also have any suggestions for generating new keypairs with GnuPG
v2.2? I'm planning to use a Raspberry Pi (Raspbian) to create a RSA-4096
master key with CS capabilities (the UID comment should obviously be
left empty) and three RSA-4096 subkeys for E, S and A. The subkeys will
be put on a smartcard (Nitrokey Pro) while the master key will remain on
the raspi, airgapped.

main: RSA-4096 SC, 5y
sub: RSA-4096 E, 2y
sub: RSA-4096 S, 2y
sub: RSA-4096 A, 2y

Also I was told to armor export the secret keys to a file and then print
that file as a last resort paper backup.


Best regards!