3 ms·

Thanks - that's a good example of what I was trying to convey. The point is Rust already provides safety guarantees. If you don't trust the runtime, then why w

by pslam 12y ago

Thanks - that's a good example of what I was trying to convey. The point is Rust already provides safety guarantees. If you don't trust the runtime, then why would you trust the built-in zero'ing? I get the "defense in depth" argument, but it feels a bit like doing this: { int a = secret; // Get secret. assert(a == secret); // Check "a" is actually that. a = 0; // Ensure "a" is zero'd on exit. assert(a == 0); // Just because. } And yes, I get that you can build this into the language so it's not quite as ridiculous - you actually wipe tainted stack, for example. But the point is: the runtime has an ABI and a machine model. Information is allowed to leak across function boundaries, beacuse it doesn't matter. Without using the "unsafe" keyword, there are no methods of getting around the machine model and dipping into the underlying actual machine. Even if you don't have a "safe" language and runtime, it's still of limited value. It protects against threats involving data or control flow corruption after key usage, and where there isn't sufficient control of the program to perturb the secret-consuming functions. That's more of an annoyance than prevention. On the other hand, it gave the programmer a false sense that it was properly wiping secrets.

erickt 12y ago
It is very probable that a sufficiently smart optimizer could see the assertion was always true and delete it. Then see no one reads "a" and delete it as well. In certain circumstances this can cause a secret to be leaked in, say a register, making our safe function unsafe. You need to be very careful writing secure code, and probably need to go down to the level of writing assembly to be sure the optimizer isn't turning your safe code into unsafe code. We actually have an interesting project in rust where someone is writing a syntax extension to take rust like code and generate assembly [0]. It's probably unsafe to use right now but if sufficiently well implemented it could be the foundation of a lot of interesting cryptography work. [0]: https://github.com/klutzy/nadeko https://github.com/klutzy/nadeko
- pslam 12y ago
  Sorry, I wasn't clear enough that my code was intended as sarcastic. It's obviously silly to zero variables because the compiler is free to ignore you. The point is, the underlying machine is going to do the same. There are many ways to dig out stale memory if you're running at sufficient privilege, for example. Direct cache introspection, for example, or bypass. Zero-izing alone is not sufficiently strong to mitigate the threats people imagine it works against.

by pslam 12y ago

erickt 12y ago

It is very probable that a sufficiently smart optimizer could see the assertion was always true and delete it. Then see no one reads "a" and delete it as well. In certain circumstances this can cause a secret to be leaked in, say a register, making our safe function unsafe. You need to be very careful writing secure code, and probably need to go down to the level of writing assembly to be sure the optimizer isn't turning your safe code into unsafe code. We actually have an interesting project in rust where someone is writing a syntax extension to take rust like code and generate assembly [0]. It's probably unsafe to use right now but if sufficiently well implemented it could be the foundation of a lot of interesting cryptography work. [0]: https://github.com/klutzy/nadeko https://github.com/klutzy/nadeko

pslam 12y ago
Sorry, I wasn't clear enough that my code was intended as sarcastic. It's obviously silly to zero variables because the compiler is free to ignore you. The point is, the underlying machine is going to do the same. There are many ways to dig out stale memory if you're running at sufficient privilege, for example. Direct cache introspection, for example, or bypass. Zero-izing alone is not sufficiently strong to mitigate the threats people imagine it works against.