On 31 Aug 2025, at 12:40, Tiago Freire via Std-Discussion <std-discussion_at_[hidden]> wrote:
> AES like all encryption standards has not been proven safe. If you were to adopt std::aes, and later found out that this algorithm has a very bad vulnerability I would want to sunset it. But now because it is in the standard you can't just remove it because it's going to be in many people's and you don't want to break it.

If AES were to be proven unsafe, that if it were in the C++ standard would be the least of your problems. It’s that it’s used in many, many protocols that people rely on. And changing those makes changing C++ look trivial. Compare cryptographic hash functions, where SHA-1 is still in widespread use, despite being unsafe in some regards, and there being a SHA-2 that should be used instead whenever possible. (There’s also a SHA-3, but we can ignore it here.)

But there is at least one possible issue with AES. (There could be more, I’m not an expert.) The much greater emphasis on constant time algorithms to prevent side channel attacks means that had AES been standardised early, probably without a content time requirement, the version in most C++ libraries would be unsuitable for really serious use. Where you would use a third party ;library - and be prepared to change if that was found to be unsuitable. In this case, changing libraries is more likely to be an issue than changing algorithms. (That different libraries might have different interfaces is a nuisance here of course.)

So, yes, there are things that are just too specialised - in use and/or implementation - to be suitable for the standard C++ library. Although more easily used than some are wouldn’t hurt.