Re: [cryptography] Best practices for paranoid secret buffers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/07/2014 01:38 PM, Dave Horsfall wrote: > Probably time to mention this classic: > http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf It is probably time for this one, too: http://www.dwheeler.com/trusting-trust/dissertation/h

Re: [cryptography] Best practices for paranoid secret buffers

On Thu, May 8, 2014 at 2:32 AM, Kevin W. Wall wrote: ... > > However, I don't think it's a panacea. Didn't someone have an > attack where they were able to reconstruct AES encryption keys > by recovering some fraction of the S-box values? I thought that > was either Felten, et al, Cold Boot attack

Re: [cryptography] Best practices for paranoid secret buffers

On Wed, May 7, 2014 at 8:15 AM, Jeffrey Walton wrote: > On Tue, May 6, 2014 at 11:56 PM, 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 for example, that say >> yo

Re: [cryptography] Best practices for paranoid secret buffers

On Wed, 7 May 2014, Kevin 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?) Probably time to mention this classic: http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.p

Re: [cryptography] Best practices for paranoid secret buffers

On 5/6/2014 11:56 PM, 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 for example, that say you should use unsigned bytes and zero memory when you

Re: [cryptography] Best practices for paranoid secret buffers

On 07/05/2014 16:27, Swair Mehta wrote: > 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 wha

Re: [cryptography] Best practices for paranoid secret buffers

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

Re: [cryptography] Best practices for paranoid secret buffers

On 05/07/2014 05:56 AM, Tony Arcieri wrote: - malloc/free + separate process for crypto - malloc/free + mlock/munlock + "secure zeroing" - mmap/munmap (+ mlock/munlock) Separate process protects from a different threat than mlock/munlock (the latter prevents swapping out the pages to the swap

Re: [cryptography] Best practices for paranoid secret buffers

On Tue, May 6, 2014 at 11:56 PM, 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 for example, that say > you should use unsigned bytes and zero memory when you're done,

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

[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