On Thu 2015-11-12 15:45:10 -0500, Robert J. Hansen wrote: > One of the major problems with C and C++ is these languages are almost > perfectly designed to resist static analysis. (You can write > analysis-friendly C++ if you limit yourself to a subset, but the instant > you rely on any Cisms you open a gateway to hell. Abandon all hope, ye > who enter here.)
While i agree with Robert on the general hairiness of C, and the difficulties it represents for programmers, it is not as resistant to static analysis has he makes out. http://frama-c.com/ is just one example of a static analysis tool that is designed to run over C code. The argument Robert makes is usually one that directs people to higher-level languages, which offer fewer opportunities for the programmer to screw up on things like memory management, array indexing, or type safety. However, for certain types of security-critical code, you want the opposite: you want to move to a language as low-level as possible. For example, many cryptographic functions risk leaking timing information, processor-cache statistics, or energy-analysis information (collectively, "side-channel leakage") if, for example, they take data-dependent branches. Higher level languages offer the programmer little control over these details, since they work at a different level of abstraction. So for these critical primitives, using C (or assembler, even) is really the best way to go, because you can write code to guarantee that no other process that shares the machine with you (or can observe how much power your CPU draws) can determine some part of your secret key just by seeing how many cycles you consume during a particular decryption attempt. That's not to say, of course, that code written in C *is* free of side-channel leakage. The overwhelming majority of it is not. In fact, some patches addressing side-channel leakage just landed this week in libgcrypt, the underlying C crypto library that modern GnuPG depends on. But in higher-level languages you often *cannot* prevent sidechannel leakage because the programmer has no direct control over the hardware. We're now far afield of Enigmail, so i'll stop posting on this thread here. All the best, --dkg _______________________________________________ enigmail-users mailing list [email protected] To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
