C++ Logo


Advanced search

Subject: secure_clear follow-up
From: Daniel Papke (danielpapke_at_[hidden])
Date: 2020-12-17 21:25:50

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 (

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:

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

Daniel Papke

SG14 list run by sg14-owner@lists.isocpp.org

Older Archives on Google Groups