David Honig <dahonig@cox.net> writes:
Wouldn't a crypto coder be using paranoid-programming skills, like *checking* that the memory is actually zeroed? (Ie, read it back..) I suppose that caching could still deceive you though?
You can't, in general, assume the compiler won't optimise this away (it's just been zeroised, there's no need to check for zero). You could make it volatile *and* do the check, which should be safe from being optimised. It's worth reading the full thread on vuln-dev, which starts at http://online.securityfocus.com/archive/82/297827/2002-10-29/2002-11-04/0. This discusses lots of fool-the-compiler tricks, along with rebuttals on why they could fail. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
At 8:40 PM -0800 11/7/02, Peter Gutmann wrote:
It's worth reading the full thread on vuln-dev, which starts at http://online.securityfocus.com/archive/82/297827/2002-10-29/2002-11-04/0. This discusses lots of fool-the-compiler tricks, along with rebuttals on why they could fail.
In that discussion, Dan Kaminsky wrote:
You also need to ignore that bizarre corner case where the same memory address is mapped to multiple *physical* addresses -- such a memory architecture could simply alter one of the addresses and tag the rest as "tainted" without in fact clearing them. But I don't think anyone actually does this -- I'm at least significantly more sure of that than I am of the precise semantics of "volatile" vis-a-vis dead code elimination.
Yours Truly,
Dan Kaminsky DoxPara Research http://www.doxpara.com
There is a common example of this corner case where the memory is paged. The page containing the key is swapped out, then it is read back in and the key is overwritten, and then the page is deallocated. Many OSs will not zero the disk copy of the key. Crypto coders have discussed many kludges to ensure that keys are not swapped out, but they are all quite system specific. Since the problem we were trying to solve is different environments producing different results, I don't feel we are any closer to safe, portable code. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | The principal effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave. frantz@pwpconsult.com | fair use. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
There is a common example of this corner case where the memory is paged. The page containing the key is swapped out, then it is read back in and the key is overwritten, and then the page is deallocated. Many OSs will not zero the disk copy of the key. Given the nature of this problem, perhaps a *better* solution would be to work on getting the spec updated to include a "security-sensitive" declaration for variables in c/c++? such variables could be held in such a way that they (where the os permits) a) are never swapped to disk b) are automagically wiped with three passes of pseudo-random data when destroyed c) are in a "security data" area of memory that can't be accessed by
Bill Frantz wrote: programs not owning the data there d) are register variables when possible (for security, not speed) the "always wipe when the variable is discarded" functionality shouldn't be that hard to impliment, and would remove the only real reason we don't want optimisation for those variables - that we want to be able to blank them. not sure a #pragma Leave_This_Intact_You_Bastard is the right solution though :) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
participants (3)
-
Bill Frantz -
Dave Howe -
pgut001＠cs.auckland.ac.nz