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_at_[hidden]> wrote:

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