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.
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.