—BEGIN PGP SIGNED MESSAGE—

Side effects include all of your contacts calling you freakin nerd.

—END PGP SIGNED MESSAGE—

People will assume you work on Cybersecurity.

Edit: Also, people will use this method to verify an email is from you.

Signing every message should have zero effect for people who don’t use PGP; they’ll just have a cryptic block of text at the bottom of the message you sent.

It’s overkill to ship your pubkey with every email. Most people just publish to a trusted keyserver and call it a day since pretty much every client worth its salt can look up your pubkey directly.

deleted by creator

Your public key block is a cumbersome thing and it’s enough to just append its fingerprint, if you consider email to be trusted against forgery but not against eavesdropping. The other person can then use the hash to authenticate your key that they get some other way (or they could just ask you to email it).

Back in the day, lots of nerds would have their PGP key fingerprint (32 hex digits) printed across the bottom of their business cards. So if someone got a card in person, they could use the fingerprint to authenticate a key that they later received by email.

Your post doesn’t ask about signing your emails without a good reason, but some commenter seems to think you are asking about that. That can be good, bad, or both, since it means that anyone who gets a copy of the message, including attackers, can now authenticate that the message came from you. Anything that gives attackers capabilities that they didn’t already have, must be examined critically. Dan Bernstein came up with an clever authenticator scheme designed to prevent this exact attack, but PGP doesn’t implement it and I actually don’t know of any software that does.

Finally, at least some of the old-time PGP community now thinks that PGP solved, to some extent, the wrong problem. It not only made no attempt to conceal metadata, but it actually advertised it, in the form of key servers and key signatures connected with keys. Even if the attackers couldn’t read the encrypted messages, they could still tell who was talking to who, which is almost as bad. Remailer and broadcatch systems tried to solve this, with mixed success. A quote by cryptographer Silvio Micali has stuck with me for a long time: “a good disguise does not reveal the person’s height”. I.e. don’t just try to conceal the message contents from attackers while letting them collect other information. Rather, don’t give them ANY information.

It’s possible to get rather “Spy vs Spy” about this type of stuff but it can help you think about security. As always, “Security Engineering” by Ross Anderson is a fantastic book if you’re interested in the general topic of how to be paranoid. Or to quote the proverb, it’s not paranoia if they really are out to get you ;). The book is here, 1st and 2nd editions downloadable as pdfs: https://www.cl.cam.ac.uk/~rja14/book.html

One thing I can think of is an overzealous corporate security solution blocking or holding back your email purely for having an attachment, or because it misunderstands/presumes the cipher-looking text file to be an attempt to bypass filtering.

Other than that might be curious questions from curious receivers of the key/file they may not understand, and will not be expecting. (“What’s this for? Is this part of the contract documents? Oh well, I’ll forward it to the client anyway”)

Other than that it’s a public key, go for it. Hard (for me anyway) to decide to post them to public keychains when the bot-nets read them for spam, so this might be the next best thing?

I don’t know if it’s still the case, but in my experience (years ago) PGP messed with the proper rendering of HTTP email bodies.

From a security standpoint also, the signature confirming that the email is from your is a double edged sword: Yes, your contacts get to verify that it’s you, but you’re also losing plausible deniability (privacy).

No

Get an S/MIME certificate and send from an S/MIME compatible email client.