Re: [cryptography] TrueCrypt
1) Microsoft ended support for XP. 2) Elcomsoft claims the ability to retrieve master secondary (XTS mode) keys for TrueCrypt volumes/partitions from hibernation files. 3) Passware same as above. 4) https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf- header key derivation uses low iteration count 5) not sure if there is anything else. On Wed, May 28, 2014 at 1:35 PM, Sadiq Saif li...@sadiqs.com wrote: http://truecrypt.sourceforge.net/ https://gist.github.com/anonymous/e5791d5703325b9cf6d1 https://twitter.com/matthew_d_green So WTF happened? -- Sadiq Saif ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- Swair Mehta ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
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 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
Re: [cryptography] urandom vs random
I think the programs block when reading from random, if the kernel doesnt have enough entropy. When reading from urandom, that is not the case. Basically the internal pool is reused to generate pseudo random bits so that the call doesnt need to block. As far as I know, there is no measure like 50 or so for /dev/random. On 16-Aug-2013, at 6:32 AM, shawn wilson ag4ve...@gmail.com wrote: I thought that decent crypto programs (openssh, openssl, tls suites) should read from random so they stay secure and don't start generating /insecure/ data when entropy runs low. The only way I could see this as being a smart thing to do is if these programs also looked at how much entropy the kernel had and stopped when it got ~50 or so. Is this the way things are done when these programs use urandom or what? ___ 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
