37 ms·

I'm conflicted on the issue. As a general principle, writing security-conscious code in C should be avoided. On the other hand, the issue is a tad more subtle.

I'm conflicted on the issue. As a general principle, writing security-conscious code in C should be avoided. On the other hand, the issue is a tad more subtle. There seems to be an almost Pavlovian revilement and panic against C code, and this usually comes from people who haven't dealt with the language in a long time or at all in any depth. For one thing, the blanket assertion that secure C code is a Herculean task, doesn't quite pan out. djb showed one way, based on a few general principles espoused in qmail, that has since successfully been reapplied by people like Wayne Marshall, Laurent Bercot, Bruce Guenter, Paul Jarc, JdeBP and so on. Much of it comes from abandoning the C standard library in favor of more robust alternatives like libdjb variants, clearly architecting process/module boundaries, using simple formats like netstrings and text0 that need not be "parsed" in the conventional sense, etc. Further along the line, we have the SEI CERT C Coding Standard that comprehensively identifies many pitfalls. [1] Deeper still, cryptography is one area where abstraction can be an enemy. You actually have to deeply worry about time complexity, branch prediction, precise timing, compiler optimizations and so on [2]. A tool like C becomes desirable here. Lastly, but crucially - you're on Unix, for better or for worse. POSIX, SUS, all of those standards? They're deeply written with the conventions and API/ABI semantics of C in mind. Such is life. When you primarily write code at that level, the easiest way not to have any impedance mismatch is to just write it in C. [1] https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard https://www.securecoding.cert.org/confluence/display/c/SEI+C... [2] https://cryptocoding.net/index.php/Coding_rules https://cryptocoding.net/index.php/Coding_rules

jerf 11y ago
I don't consider my revulsion Pavlovian. Even if I have had that particular connection repeatedly made, the point is that if it requires super-mega-experts to code in a totally specialized manner, using libraries other than the easiest to use, using levels of care attainable only by the top 1% of programmers, it's not a suitable language for the vast bulk of people to pick up. And even the top 1% of programmers would probably be well suited to do something else with their cognitive firepower. The fact that somebody once proved capable of walking on a tightrope between World Trade towers does not prove tightrope walking above vast chasms to be a safe mode of transport. For crypto, at this point, C is now too abstracted from the hardware to be useful. You need assembler, and that's getting dangerously abstract too, since it's actually an abstract language over the microcode that actually execute, the entire point of which is generally to provide lovely, wonderful things... that trash timing guarantees that crypto would like. "I had to write code that allows remote attackers to own the machine because it was the only way to avoid impedence mismatch." Incidentally, since it hasn't come up, note that I consider "C + useful static analysis tools" to be a different language. "C + useful static analysis tools" can be a sensible choice. I still at least have questions about the cognitive load being loaded on to the developer vs. a language that removes the problems entirely, but it must be acknowledged as having radically different cost/benefit profiles. However, I observe that very few people seem to be using useful static analysis tools beyond -Wall.

jerf 11y ago

I don't consider my revulsion Pavlovian. Even if I have had that particular connection repeatedly made, the point is that if it requires super-mega-experts to code in a totally specialized manner, using libraries other than the easiest to use, using levels of care attainable only by the top 1% of programmers, it's not a suitable language for the vast bulk of people to pick up. And even the top 1% of programmers would probably be well suited to do something else with their cognitive firepower. The fact that somebody once proved capable of walking on a tightrope between World Trade towers does not prove tightrope walking above vast chasms to be a safe mode of transport. For crypto, at this point, C is now too abstracted from the hardware to be useful. You need assembler, and that's getting dangerously abstract too, since it's actually an abstract language over the microcode that actually execute, the entire point of which is generally to provide lovely, wonderful things... that trash timing guarantees that crypto would like. "I had to write code that allows remote attackers to own the machine because it was the only way to avoid impedence mismatch." Incidentally, since it hasn't come up, note that I consider "C + useful static analysis tools" to be a different language. "C + useful static analysis tools" can be a sensible choice. I still at least have questions about the cognitive load being loaded on to the developer vs. a language that removes the problems entirely, but it must be acknowledged as having radically different cost/benefit profiles. However, I observe that very few people seem to be using useful static analysis tools beyond -Wall.