Modern gnupg.conf setup
mistave at countermail.com
Sun Dec 15 21:42:09 CET 2019
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
> 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
Hey, thanks for all the help. That was really an educational read.
I ended up with this config file contents:
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
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.
More information about the Gnupg-users