During last week's meeting, I stepped away briefly, but I don't believe we
covered the secure_clear proposal in any depth. Having read through it, I
have a concern with the proposal.
P1315R5 secure_clear (
http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1315r5.html)

Secure clear is definitely a useful function. However, I'm concerned
that the description here is not specific about the resulting value, and
does not provide a means of control over the method for clearing. I believe
that many different destruction methods may be required, depending on the
domain or application.

Consider the Common Criteria standard for evaluating security-related
products (source: https://www.commoncriteriaportal.org/)
Specifically, consider FCS_CKM.4, from this document:
https://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R5.pdf

"FCS_CKM.4 Cryptographic key destruction, requires cryptographic keys to be
destroyed in accordance with a specified destruction method which can be
based on an assigned standard."

The Common Criteria standard does not specify the method of destruction -
only that a specified method is employed. There may be a great deal of
flexibility required by users of the secure_clear function. For example,
some users may need to overwrite multiple times with different values, read
back the value to verify overwrite, or perform other similar checks.

I should also note that a random overwrite may not be desirable for some
users. Where does the random # come from? Is it "sufficiently" random? Such
a software developer might just avoid the secure_clear altogether in order
to supply their own source of random data.

Proposal:
I suggest that secure_clear should allow the user to specify a value for
the overwrite. This would cover multiple overwrites and read-back
requirements. The random overwrite probably won't be good enough for some
applications, but I think that situation is unsolvable by the C++ standard.

-----------
Daniel Papke