Signatures are generally used for authentication of the sender, with such programs as GNU Privacy Guard, which you can download for free (you will need to make a public key and a private key, before you can do any signing/verifying, and so will the sender): e.g. gpg -a --detach-sig myfile.txt and gpg --verify myfile.txt.asc myfile.txt. They also do the work of a hash: If the file is altered, then the verification will fail. They don't verify the filename or the creation date, though (just the contents).
To make a public/private key, either do gpg --full-generate-key or gpg --gen-key.
Encrypted messages in and of themselves don't authenticate the sender, unless the sender signs it. The sender uses the sender's own secret key to sign the message, and the sender uses the recipient's public key to encrypt the message. The recipient uses the sender's public key to verify the signature, and the recipient's private key to decrypt the message.
Without the sender signing, even though no one else can read the message but you, you don't know who sent it to you for sure.
You can enarmor encrypted files to turn them into plain text in order to post them somewhere that doesn't allow for private messaging. It would be kind of weird, but you can do it. You can enarmor the signatures, too, as I did above.
Using online tools to handle all the decryption for you probably isn't a good idea, from a security standpoint. I mean, if you're not the only one who has charge of your own private key, then you're just trusting the online service (and anyone who hacks them) not to abuse it. Even if you still have to enter your keyring passphrase, they could just take the passphrase when you enter it (beause it's their website and they could easily have access to any data you enter on it).
To automate part of the process, you (or some programmer) can write one or more scripts to do it, which call gpg with the right arguments. Then, give others the script(s) to help them.
