On Fri, Dec 18, 2020 at 9:19 AM Daniel Papke <danielpapke_at_[hidden]> wrote:

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

No worries! Ideally the paper would have a summary of previous discussions
(and point at the full thing), to save newcomers the time of re-discovering
the discussion.

You're in agreement with prior discussions too, and you came to it
independently, so it's a useful signal.


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