Was thinking I should perhaps clarify even more. Informally, we know that, AES run in CTR mode is provably secure (which we can formally define). Security proofs come with assumptions / requirements, and here, we have a few that are mostly reasonable to achieve. The major assumptions include: The key has to have enough entropy (unpredictability) in it, ideally 128 bits of it. The block cipher we use has to not be considered 'broken' (which we can formally define actually, and AES is vastly far from that). And, the model doesn't cover side-channel problems, assuming that operations have no inherent side channels (basically, avoiding branches helps us here), which is all reasonably straight-forward with counter mode.
CTR mode is one of the simplest constructs in all of cryptography, so while there are still a bunch of little things to worry about, it's all vastly manageable compared to basically ANYTHING else you might try to do with cryptography ever, and relatively easy to get high assurance. And, once you have seeded your random number generator (i.e., CTR mode), all the algorithm consists of is two things: AES-encrypt a 128-bit value (which is obviously pretty darn fast), and increment that 128-bit value, modulo pow(2, 128). Again, this is now a single instruction on many many platforms. For instance, you can get a sense of how little assembly you need on x86 or ARM: <https://tinycrypt.wordpress.com/2018/03/16/aes-tiny/> In short, as long as a modest bit of work is put into optimization, this will never come close to being anybody's bottleneck. And it's worth doing to avoid the MANY issues I've seen over the years where people didn't give it a second thought, and ended up totally owned.
