On Fri, Dec 18, 2020 at 4:55 AM Daniel Papke via SG14 <sg14_at_[hidden]>
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.