improve GnuPG configuration file /etc/skel/.gnupg/gpg.conf

[adrelanos]

Stronger ciphers?

Any other hardening suggestions?

https://github.com/Kicksecure/security-misc/blob/master/etc/skel/.gnupg/gpg.conf

https://forums.whonix.org/t/anon-gpg-tweaks-gpg-conf-enhancements-duraconf-a-collection-of-hardened-configuration-files/5378

https://www.kicksecure.com/wiki/Air_Gapped_OpenPGP_Key

https://www.kicksecure.com/wiki/OpenPGP

[monsieuremre]

This should not be too hard. Just choose the one that keeps winning the cipher competitions.

Also, we should make post quantum options the default as soon as possible, for the asymmetric stuff I mean.

Reasonable path for the future is follow this draft really closely.

There are individual post-quantom implementations, but these are not standardized. We should just follow closely the developments in standardization of this. Many big boy projects are already sponsoring the development of such standards. These will be available in the wild. We just want to be ahead of the curve to adapt. Not to mention, the other side should also support these technologies for them to work as intended.

[adrelanos]

Unless using live mode, writing to RAM is too difficult for users.

/tmp isn't guaranteeing that nothing is written to the disk. (Swap, crash dumps. This goes into the topic of anti-forensics. In short: forget about it and use live mode.)

But what is the point of writing to RAM anyhow in this context? The private key needs to be stored persistently somewhere anyhow.

[ben-grande]

Another hardend GnuPG configuration:

• https://gist.github.com/sebmellen/b0d0424caefa1221cbe4d9aaf2172d2c

[ben-grande]

Thats many years old and wonder if key size beyond 4096 are really more secure at this point?

1. Many years old and still newer than the currently used gpg.conf.
2. I didn't say to trust everything in that file, it has outdated settings, yes, but it has many valuable ones.