Conceptually, the class OctetString is nothing but a strong type. Just that it is typed out explicitly as a class. Same is true for the SymmetricKey and InitializationVector aliases, of course.

This is an attempt to replace this class with:

using OctetString = Strong<secure_vector<uint8_t>, ...>;

Long story short: It seems that it would take significant effort to keep the API of OctetString stable despite it being a (special case) of Strong<>.

My initial idea was to introduce "capabilities" to strong types. For instance Strong_Capability::XORable would yield a container type that implements operator^ and operator^= (just like OctetString). That's not a big deal and probably useful regardless of this draft.

Another "capability" would be "legacy octet string behaviour" to retrofit (and probably deprecate) bits_of(), length(), to_string() and maybe more. That's quirky, but doable.

Bigger problems come from OctetString::begin() and OctetString::end() that return raw pointers rather than iterators. By the way: That's the main reason OctetString does not satisfy concepts::container (or bind to std::span<>).

I stopped working on that when it got out of hand to get some feedback whether this is actually useful. My feeling is, that OctetString and its type aliases are somewhat a historic artifact, right? But if so: at least a migration strategy (for the sake of consistency) would be worth discussing, I find.