[cryptography] Best practices for paranoid secret buffers
noloader at gmail.com
Wed May 7 08:15:54 EDT 2014
On Tue, May 6, 2014 at 11:56 PM, Tony Arcieri <bascule at gmail.com> wrote:
> Can anyone point me at some best practices for implementing buffer types for
> storing secrets?
> There are the general coding rules at cryptocoding.net for example, that say
> you should use unsigned bytes and zero memory when you're done, but I'm more
> curious about specific strategies, like:
> - malloc/free + separate process for crypto
I think this is a good idea. I seem to recall the new FIPS 140 will
have some language for it. I also seem to recall something about
Microsoft's CryptNG, but I don't recall the details.
> - malloc/free + mlock/munlock + "secure zeroing"
On Microsoft platforms, you have `SecureZeroMemory`
It is guaranteed *not* to be removed by the optimizer. On Linux, you
have `bzero`, but I'm not sure about any guarantees. On OpenSSL, you
have OpenSSL_cleanse. OpenSSL_cleanse is most acrobatic of the three.
> - mmap/munmap (+ mlock/munlock)
Keeping secrets out of the page file or swap file can be tricky. VMs
can be trickier.
> Should finalizers be explicit or implicit? (or should an implicit finalizer
> try to make sure buffers are finalized if you don't do it yourself?)
Not all languages have finalizers.
Java has finalizers but tells you to put secrets in a char or byte
so you can overwrite them manually: See, for example,
(I think that link may be dead now).
For those languages that do provide fianlizers, its sometimes
impossible to ask them to wipe. See, for example, " EditText and
Sensitive Information (Wipe/Zeroize)",
> Are paranoid buffers worth the effort? Are the threats they'd potentially
> mitigate realistic? Are there too many other things that can go wrong (e.g.
> rewindable VMs) for this to matter?
I think they are worth the effort. Target's data breach was the result
of (among others): memory scraping malware. At minimum, they cost next
You also have wrapping. That is, a buffer get a quick dose of XOR to
mask the secrets while in memory but not in use.
.Net's SecureString uses wrapping
and NIST has a key wrap for symmetric encryption keys
Maybe the later would have helped with Heartbleed, too... who knows.
More information about the cryptography