JF,

I apologize - having read through the enormous secure_clear chain here (https://lists.isocpp.org/sg12/2020/04/date.php), I can see that I'm beating a dead horse. What I'm hearing is that the abstract machine doesn't really support the guarantees needed to make the secure_clear do what its name suggests, so the #2 solution is to leave the details up to compiler implementers. If that's the case, I think the function will be useful for some people, but not everyone. That's ok.

My post to Arthur might clarify why a specified value for the overwrite helps (allows introspection).

Daniel

On Fri, Dec 18, 2020 at 10:42 AM JF Bastien <jfb@chromium.org> wrote:


On Fri, Dec 18, 2020 at 4:55 AM Daniel Papke via SG14 <sg14@lists.isocpp.org> wrote:
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.

The design guidance offered by the language evolution incubator was to have the value be unspecified: http://wg21.link/P1315/github
I don't see how your rationale offered above doesn't line up with the proposed resolution, can you clarify how specifying a value addresses the concerns you raise above?
I think you'll hit the design wall most have so far: this function cannot be cleanly specified in today's abstract machine. We have 3 choices:

1. Overhaul the abstract machine to support the function
2. Specify the function in a slightly handwavy way (as we do for `volatile`)
3. Don't standardize this function at all

The paper currently takes approach 2., and it therefore won't be able to meet some of the points you bring up. A specific implementation of it might, depending on what the vendor decides to do, but the general standardize function doesn't mandate this.