[cryptography] Best practices for paranoid secret buffers

Swair Mehta swairmehta at gmail.com
Wed May 7 10:27:28 EDT 2014

Mprotect() to keep stray pointers out. 
Obfuscate data kept in that memory.

You can do a lot in software and in practice that might be enough. In theory, true security can only be achieved through hardware based security modules-atleast thats what I feel, others might disagree.

Paranoid buffers do have some overhead involved but if that overhead is going to delay obtaining secrets from a memory dump, i'd say its worth it.

> On May 6, 2014, at 8: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
> - 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
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20140507/db22bd4e/attachment-0001.html>

More information about the cryptography mailing list