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.
SG14 list run by firstname.lastname@example.org
Older Archives on Google Groups