gpg.conf

# GnuPG Configuration File for Caesonia
# This configuration file was written for GnuPG 2.1 (modern) in April 2018.


# BASIC USABILITY

# Always assume the --armor flag is used. GnuPG will export everything in
# printable base64 text, rather than binary data.

	armor

# Always use expert mode. This function enables access to special
# functionality, including generation of elliptic curve cryptography (ECC)
# public keys at key generation time when the --full-gen-key parameter is
# used.

#	expert

# Remove comments and greeting.

	no-greeting

	no-comments

# Prevent GnuPG from printing the version in outgoing cleartext signatures.

#	no-emit-version

# Allow UTF-8 only.

	display-charset utf-8

# When operating in the commandline, the computer should ask before it
# overwrites anything.

#	interactive

# Timestamps really don't mean much in GnuPG, since you can always set your
# clock forward or back. So we'll ignore time conflicts.

	ignore-time-conflict

# Include yourself as a default recipient, so you can decrypt what you
# encrypt.

	default-recipient-self

# Always show the fingerprint where possible.

	with-fingerprint

# Where there is a choice, use the long key id format. This is
# cryptographically insecure. NEVER use the long key id format to verify
# keys. Use the full key fingerprint.

	keyid-format long

# Separate user IDs.

	fixed-list-mode

# Prevent GnuPG from stamping key IDs into encrypted material. Normally,
# GnuPG includes "This data is encrypted for the following keys..." to
# indicate which keys are intended to decrypt the data. However, this can in
# some cases present a privacy concern. Note that this is trivially easy to
# defeat with a bit of social engineering, and very often, most recipients
# won't have their instances of GnuPG explicitly set up to handle it, and
# will very often be unable to decrypt incoming messages if they haven't set
# "try key" in their gpg.conf configuration file. Only uncomment this if you
# know what you are doing, and more importantly, your recipients do as well.

#	throw-keyids

# Request "For Your Eyes Only." This requests that when decrypting, the
# recipient's instance of GnuPG to not redirect output to disk unless they
# explicitly command it to. This option only works on the commandline and any
# graphical frontends will ignore it.

	for-your-eyes-only


# WEB OF TRUST

# By default, certification of keys do not expire. Given how quickly trust
# relationships change, this is an unsafe practice and should not be
# followed. When certifying another key through the commandline, this
# parameter will allow you to set an expiry date at which point your
# signature must be renewed.

	ask-cert-expire

# By default, let's set an expiry date of 1 month. You can change this to
# [number]d for days, [number]m for months, or [number]years.

	default-cert-expire 1m


# KEY GENERATION PREFERENCES

# Whenever your key is created, it will be created with a preference list,
# which will typically include obsolete ciphers such as IDEA, BLOWFISH or
# CAST5. By default, 3DES and SHA-1 are always included. Unfortunately, we
# cannot change this behavior at this time since they are included in the
# standard. However, we can tune GnuPG to accept other strong symmetric
# ciphers with 256-bit keys, and prioritize stronger hashing. As of the time
# of writing, AES256, TWOFISH, CAMELLIA256 are strong ciphers and may be used
# with confidence. Also as of the time of writing, SHA512, SHA384, and SHA256
# are all a part of the SHA-2 family, and may all be used with confidence.

	default-preference-list AES256 CAMELLIA256 TWOFISH SHA512 SHA384 SHA256 ZLIB BZIP2 ZIP UNCOMPRESSED MDC NO-KS-MODIFY

# We will prefer strong symmetric ciphers

	cipher-algo AES256
	personal-cipher-preferences AES256 CAMELLIA256 TWOFISH

# SHA-512 will be utilized for certification by default, digests for
# generating cryptographic signatures by default. SHA-512 doubles the digest
# length of SHA-256 to increase collision resistance.

	cert-digest-algo SHA512
	digest-algo SHA512
	personal-digest-preferences SHA512

# When compressing, prefer more efficient first. ZLIB is not supported
# everywhere, so ZIP is included in this list.

	compress-algo ZLIB
	personal-compress-preferences ZLIB BZIP2 ZIP

# Force the use of modification detection code.

	force-mdc


# LOCAL SECURITY

# Key Derivation Options
# GnuPG sadly does not support proper key derivation functions like PBKDF2
# or Argon2, but instead uses a string-to-key function that involves taking
# the password, optionally adding a salt, and hashing it to derive the AES
# key. This behavior might have been adequate in 1993, but these days that's
# dangerously unsafe. Unfortunately, all we can do at this moment is simply
# increase the amount of iterations.

# When using string-to-key, a value of 3 will instruct GnuPG to properly
# salt, then hash the password. Changing this value to anything except 3 will
# dangerously weaken the symmetric encryption utilized by GnuPG.

	s2k-mode 3

# Use SHA512 as a digest algorithm.

	s2k-digest-algo SHA512

# Use AES256 for storing private keys.

	s2k-cipher-algo AES256

# Use lots of iterations for password stretching. Higher numbers will hash
# the password iteratively to increase security. This adds something of a
# work factor in order to slow down systematic guessing attacks. SHA512 is a
# hash function and not a key derivation function, so you still must use a
# high entropy password to offset the weak key derivation function, ideally
# of sufficient bit strength to require at least 2^128 operations to crack.
# Ideally you should make the computer take a second or more to calculate the
# symmetric key. If this option is commented out, GnuPG will automatically
# adjust the iterations to take approximately one tenth of a second on the
# device it is running on. Just bear in mind: even if you use a device that
# is slow, it doesn't mean your attacker will be!

	s2k-count 640000000

# Remember that the security gains of using passwords on private keys are
# minimal, and if Full Disk Encryption or file based encryption is utilized,
# somewhat redundant, as an attacker that gains access to your PC or that can
# execute arbitrary code upon it may either exfiltrate the password or the
# plaintext private key as it resides in the memory of your device. A far
# better option to protect your private key is to locate it in a separate
# virtual machine using Qubes Split GPG, a physically airgapped computer that
# does not have network connectivity nor USB, a smartcard, or even a hardware
# security module.

# GnuPG usually attempts to opportunistically lock secure memory for
# cryptographic operations, but if unable to, will often fail open and still
# allow the operation to proceed even if it can't. Often, it will print
# "Warning: Unable to use secure memory!" to the console, which won't be
# visible to the MUA. So we're going to force it to use secure memory, and if
# it can't, fail entirely.

	require-secmem

# The no-random-seed-file flag is used to indicate to GnuPG not to
# pre-cache randmoness to disk for later use to help generate entropy.
# Pre-caching of entropy is done to help speed up key generation and to
# produce signatures for the DSA and ECDSA signature algorithms, which
# consume additional randomness (in the form of nonces) to produce their
# signatures. Although this flag may slow down signature and key generation
# somewhat, it helps to ensure that the sources of random numbers (which must
# be kept secret!) won't end up on your disk, where they could be exploited.

	no-random-seed-file

# Enable graphical frontends to show progress. Unless you somehow find
# yourself with the irresistable urge to use hardware from 1994, the
# performance impact of the software being polled for progress is negligible.

	enable-progress-filter


# KEYSERVER AND WEBKEY DIRECTORY SECTION

# Before any of you use a keyserver, first understand the risks. If a
# keyserver is to be utilized, it should be utilized over Tor. This field has
# been commented out since this configuration file assumes that we trust the
# server with our login and E-mail metadata, and a http anonymizing proxy is
# not required.

#	keyserver-options	http-proxy=socks5h://127.0.0.1:9050

# If you wish to use a keyserver, use an onion keyserver. SSL is
# technically redundant when using a Tor hidden service, so hkps:// is not
# used here. This option has been commented out since we will not be
# utilizing the keyservers, but has been left here in case it is required.

#	keyserver	hkp://qdigse2yzvuglcix.onion hkp://gnjtzu5c2lv4zasv.onion hkp://pgpkeysximvxiazm.onion/

# Keyservers are 'always untrusted' and should only be considered to be
# there to act as an undeletable repository of public keys. Rather than
# utilize the old 1990s-era PGP Sharing Key Servers, we are going to use Web
# Key Directory.

	auto-key-retrieve
	auto-key-locate		local,wkd

# Rely on the fingerprint, rather than the url.
	keyserver-options 	no-honor-keyserver-url

# We're going to comment out this option to prevent automatic key
# retrieval, so as to permit key synchronization.
#	keyserver-options 	no-auto-key-retrieve

# Don't trust the PKA record
	keyserver-options 	no-honor-pka-record

# Include the revoked public keys.
	keyserver-options 	include-revoked

# Always get the subkeys.
	keyserver-options	include-subkeys

# Do not send photo IDs to the keyserver.
	keyserver-options 	no-include-attributes