Skip to main content
5 events
when toggle format what by license comment
Dec 19, 2014 at 8:26 comment added FooF "If you're worried about physical attacks on the RAM, a bigger concern would be to ensure that the data is ovewritten in RAM and not just in the CPU cache." -- You can force memory barrier (at lowest level implemented as a CPU instruction) to enforce flushing CPU cache to RAM. If the programming language is higher level, one way to do it is to employ some memory sharing primitive like for example mutex (lock, erase, unlock) which use memory barriers as part of the implementation.
Dec 7, 2014 at 22:41 comment added corsiKa I have to admit, it does seem like the security experts writing crypto libraries would also incorporate other security practices even if they aren't directly related to the crypto itself. But you'd want to make sure, hopefully it's open source (if for no other reason than to verify its cryptographic integrity).
Dec 5, 2014 at 14:03 comment added Gilles 'SO- stop being evil' @Lawtonfogle Cryptographic libraries are often written in such a way to erase at least keys after use. It's considered good hygiene among crypto implementers and I expect (though I have no firm data on the topic) that it's correlated with reasonable quality measures. Even if the library doesn't do it, you can often control the library's memory management from the application.
Dec 5, 2014 at 14:00 comment added Lawtonfogle Normally secrets aren't directly acted upon. A cryptographic library is used (as implementing an algorithm, even a good one, is difficult and am implementation bug can render your security useless). So does one limit themselves to libraries that only change data before deleting it (possibly eliminating the best library for the job)? Or does one use a library that allows data to hang around until deleted, thus losing the benefit of applying this to ones own code?
Dec 4, 2014 at 18:02 history answered Gilles 'SO- stop being evil' CC BY-SA 3.0