[cryptography] Best practices for paranoid secret buffers
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
Re: [cryptography] Best practices for paranoid secret buffers
On Tue, 6 May 2014, Tony Arcieri wrote: 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?) I've never trusted OSs that cleared buffers in the finaliser. Do it yourself, then you know it's done. For that matter, I've never trusted malloc() either, but at least calloc() promises to clear it. 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? Even paranoids have enemies :-) -- Dave ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
