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 <basc...@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@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
