[Cryptography] Best practices for paranoid secret buffers

[Fellow Traveler]

If it's useful, I implemented such a class for Open-Transactions.


Here's a secure memset function (for platforms other than Windows):

https://github.com/Open-Transactions/Open-Transactions/blob/master/src/otlib/OTPassword.cpp#L183-196

For Windows:

https://github.com/Open-Transactions/Open-Transactions/blob/master/src/otlib/OTPassword.cpp#L452

Here's the mlock stuff to prevent it being swapped to hard drive:

https://github.com/Open-Transactions/Open-Transactions/blob/master/src/otlib/OTPassword.cpp#L239-285


There's a re-write of this class coming soon but those pieces might be 
useful for you.


-FT



Tony Arcieri 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
> <http://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
> - malloc/free + mlock/munlock + "secure zeroing"
> - mmap/munmap (+ mlock/munlock)
>
> 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?)
>
> 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?
>
> --
> Tony Arcieri
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography