Re: Did you *really* zeroize that key?
At 19:30 +0000 on 11/7/02, David Howe wrote:
at Thursday, November 07, 2002 6:13 PM, David Honig <dahonig@cox.net> was seen to say:
Wouldn't a crypto coder be using paranoid-programming skills, like *checking* that the memory is actually zeroed? That is one of the workarounds yes - but of course a (theoretical) clever compiler could realise that
int myflag; myflag=0; if (myflag!=0) { do stuff } ;
can be optimised away entirely as the result is constant.
the problem isn't so much a question of what would work now, but "is it possible that your zeros could be optimised away by a theoretical future compiler, and how do we make portable code that nevertheless can't be optimised away?"
The point is though, that according to C99 today volatile int myflag; myflag=0; if (myflag!=0) { do stuff } ; does _exactly_ what you want, per the spec. The only compilers that don't work this way are by definition out of spec, so adding new stuff isn't going to help. Having said that, most of what your talking about pragma wise is boils down to controlling the optimizer. Most compilers offer options to control this, but it's vendor specific. I can see how adding this to the spec would be worthwhile. But it's not essential to fix the problem above. -- _____________________________________________ Kevin Elliott <mailto:kelliott@mac.com> ICQ#23758827
The point is though, that according to C99 today
volatile int myflag; myflag=0; if (myflag!=0) { do stuff } ;
does _exactly_ what you want, per the spec. The only compilers that don't work this way are by definition out of spec, so adding new stuff isn't going to help. Yup, granted. however, saying after a security breach "this wasn't my fault, the compiler was out of spec" isn't going to help much. in the real world, murphys law applies more often than anyone elses; you can virtually guarantee you will meet up *sometime* with an out of spec compiler
Kevin Elliott wrote: that assumes it knows at compile time if a volatile is actually volatile (in the example above, such a compiler may treat a volatile as such *only* after its pointer has been passed to an external subroutine or a fork... ok, that is out of spec but in the real world would probably work without problems)
Having said that, most of what your talking about pragma wise is boils down to controlling the optimizer. I doubt that the pragma in question was actually meant to be taken seriously as a suggestion - but was a bit of humour appended to a fairly serious warning.
participants (2)
-
Dave Howe -
Kevin Elliott