Or should Botan's public API leverage the type system to try and prevent programming errors?

That was the original idea behind SymmetricKey and InitializationVector. But I think in practice this doesn't really help that much because if you can "mistakenly" write

aead->set_key(thats_not_a_key_you_dummy);

you can just as easily write

// this stupid API makes you convert a key to its internal key type
aead->set_key(SymmetricKey(thats_not_a_key_you_dummy));

which is why SymmetricKey and co are not really used in new APIs and tbh should be deprecated and eventually removed. (I don't think that can happen right now because there are various APIs that still require them, but that should probably occur eventually.)

The real errors, the subtle problems that cause systems to actually fail: nonce reuse, reusing a key in two different contexts, allowing cut-and-paste attacks, etc etc are not fixable with the typesystem, and the way to prevent those is to provide good out of the box tools, for those who don't really know what they are doing (eg, TLS, PGP, Signal protocol, whatever) and for those who need low level functionality (ie, implementations of different protocols), offer that functionality with as little mess and inconvenience as possible.

I'm all in favor of using the type system to prevent errors when that is feasible but in this instance I think the costs (syntactic, performance overhead, etc) outweigh the benefits (which tbh seem near zero, in terms of real bugs prevented).

Codecov Report

Patch coverage: 90.00% and project coverage change: -0.01 ⚠️

Comparison is base (c810e6c) 88.10% compared to head (d43d565) 88.10%.

❗ Current head d43d565 differs from pull request most recent head 2ae13f6. Consider uploading reports for the commit 2ae13f6 to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##           master    #3297      +/-   ##
==========================================
- Coverage   88.10%   88.10%   -0.01%     
==========================================
  Files         615      610       -5     
  Lines       70315    68655    -1660     
  Branches     6997     6844     -153     
==========================================
- Hits        61949    60486    -1463     
+ Misses       5422     5307     -115     
+ Partials     2944     2862      -82     

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

The real errors, the subtle problems that cause systems to actually fail: nonce reuse, reusing a key in two different contexts, allowing cut-and-paste attacks, etc etc are not fixable with the typesystem.

Agreed. Bottom line: Low-level programming convenience over type safety in this particular case. You nailed my concern regarding "intrusive API" with your example, btw. 😏 I'll close #3296 on this basis. Thanks.

One more thing: Making OctetString's c'tors explicit is a breaking API change after all. Is that acceptable? Otherwise this wrapper is actually standing in the way of rolling out std::span here (and potentially other places).

Rebased to master to solve conflicts. Now waiting for CI, then merging.

Re:SymmetricKey: Yeah, I think it isn't used consistently throughout the API and causes more confusion than its actually useful.