How do encryption algorithms pick prime numbers?

But it’s not “every other one”, like you wrote.

The disk encryption program Veracrypt does this and several others I’ve used in well under the last 30 years.

I don’t know what crypto you’re using but this is a real thing.

Perhaps not, but that’s how it’s done.

RSA is a relatively slow algorithm. Because of this, it is not commonly used to directly encrypt user data. More often, RSA is used to transmit shared keys for symmetric-key cryptography, which are then used for bulk encryption–decryption.

Wiki.

Just worth reiterating a points made above. For many secure communications the RSA or similar encryption is only used to exchange or protect a session key - ie a key that is actually weaker but only used for a limited time. The actual cost of encrypting directly into RSA or the like is generally too expensive for anything but short messages.

There are some basics in encryption that are hard to avoid.

  • There is only one known unbreakable encryption technique. A one time pad. The problem is that the key for this method is the same length as the message, and you can only use it once. If you use it twice, encryption is easily broken. You can be sure that every security agency on the planet monitoring their opposition tries every message (ciphertext) they get to see if there has been an accidental reuse of a one time pad.
  • The key exchange problem. If you want to communicate you need a key at each end. One time pads need to be securely transported, which used to involve a human with a briefcase handcuffed to their wrist. You swiftly get into Byzantine behaviour problems. Eventually you have to trust everyone in the chain. And hence a plot element of many historical spy movies being access to code books by one side or the other.

To get around the first problem there are key amplification techniques. Take a key and essentially use it to generate a sequence of psuedo-random numbers, which in some sense, becomes a one-time pad. The input plain test also can drive this, so it isn’t exactly a simple one-time pad. The trick is to provide as little leverage on the ciphertext from your chosen key amplification algorithm as possible. If your algorithm has some unexpected properties that reduce the space of the generated number stream, the ciphertext can become subject to attack. If you use the session key for too long the cypher text will become easier to attack. So it is critical that they get renegotiated periodically. Lack of renegotiation has been the source of highly embarrassing holes.

So RSA and the like are used to manage the key exchange problem for session keys.

The problem with key exchange is that if sometime down the track your RSA private key is leaked or found, it is then possible to obtain the session keys for any traffic that has previously been recorded.

Security by obscurity is a waste of time. Assume that the opposition know everything about your algorithms.
One of the stellar examples was the breaking of the German High Command Lorentz SZ encryption. Bill Tutte derived the operation of the cipher without access to a machine - just from analysis of the ciphertext. Indeed the whole story of the operation and breaking of the Lorentz SZ encryption is a beautiful example of the art and is still relevant.

Two others:

Oh my, you’re right—I can’t believe I forgot about that one. I don’t generate new keys too often.

Though, as you say, some or many (I guess one would have to check) operating systems make sure to use a cryptographically secure pseudorandom number generator, which is constantly accumulating entropy and is designed to be resistant to simple attacks like injecting zeros (or anything non-random) into the entropy pool, and is therefore considered “good enough” even for generating long-lived keys.

So GPG has had that warning message for ages, but if the OS’s /dev/random uses best practices your security hopefully does not hinge upon your having to jiggle the mouse exactly right then— but if your entropy was depleted that would serve to inject some randomness. Of course, if your computer is already owned the RNG is not the only thing to worry about…

Not with one-time-pad keys, which is what I was talking about there. Encrypting a one-time-pad using RSA and then using that pad for the actual message would be no faster, no more secure, and otherwise no better than just RSAing the message directly.

The keys that people encrypt using RSA are for other encryption techniques, which are less secure but more practical than one-time pads.

There’s the story, too, that part of the method of decryting German signals at Bletchley Park (Alan Turing, Enigma, and all that) was that many messages were padded with a common phrase (“Heil Hitler” - what else would it be?) to make them long enough to encode. Their computer tried a variety of Enigma settings until it determined some good guesses, and that detail helped.

Yes to me this one is far more impressive than the more well-known Enigma breaking. To come up with a machine that could decrypt that cipher without having any knowledge of the encryption machine itself is amazing.

Actually it wasn’t “Heil Hitler” - at least that was never mentioned by the folks working on it. Instead it was more banal stuff like “ANX” (a followed by space) and the German for “Weather Report at XXXX” and “FORTX” (for continuations of previous messages). Coupled by with laziness in not changing the rotors far enough and some bad operational guidance about how to transmit the session key.