Also.. keep your messages short. Even the best cryptanalyst in the world can’t crack a cipher if it is too short to analyze for patterns.
Use a one-time pad. That's the only method that absolutely, positively cannot be broken.
For the pad, you need a source of true random numbers, e.g., from thermal noise. For instance, if Paul and Alice need to communicate, they each generate a four-gigabyte pad. Then they put both pads on each of a pair of 8 gb USB sticks. If Paul needs to send Alice a 100K message, he XORs his message with the next unused 100K of his pad and sends it to Alice. She decrypts it by XORing it with the next 100K of her copy of Paul's pad. And vice-versa. This lasts until one of them has sent 4 gb. Then they have to meet again and generate more keys (and buy bigger sticks).
More practical methods replace the pads with pseudo-random numbers generated from long keys using algorithms such as RC4. That avoids the need to generate, store, and exchange lengthy pads. However, there is still the need to meet and exchange keys.
Modern methods use public-private key pairs to eliminate the need to meet and exchange keys. Instead, Paul sends his public key to Alice, she generates a long random number (called a session key) and sends it to Paul encrypted with his public key. He decrypts it with his private key (which only he has, unless the NSA has performed a bag job). Then the rest of the session is conducted under the session key. The session key is for performance: session key methods like RC4 are computationally cheap, whereas public-private is expensive.
The other cool thing about public key cryptography is key signing. That is, Paul's key can be digitally signed by a certificate authority (CA) whom Alice trusts. That allows her to verify that the key Paul is presenting is really Paul's and not the NSA's. Of course, that assumes the NSA hasn't compromised the certificate authority.
The above is called transport layer security (TLS). It's what's in effect whenever you use HTTPS in your browser. When you log into your bank, your browser verifies the bank's public key by requiring it to be properly signed by one of a list of trusted CAs pre-stored on your computer. If it doesn't match, you'll have to blow past a warning dialog in order to complete the connection. In that case, your connection will still be secure, but it might not be with your bank.
True. Very good advice. I’ve also been told to skip using the word “the” in all encrypted communications in order to increase the complexity of potential decryption.