C still rules some domains, including software seeking "maximum certainty" it seems...
Aka "in defense of C". Enjoy, ----- Forwarded message from Ray Dillinger <b...@sonic.net> ----- Date: Fri, 26 Aug 2016 18:54:26 -0700 From: Ray Dillinger <b...@sonic.net> To: cryptogra...@metzdowd.com List-Id: The Cryptography and Cryptography Policy Mailing List <cryptography.metzdowd.com> Subject: Re: [Cryptography] programming languages and the people who (don't) love them, was "NSA-linked Cisco exploit poses bigger threat than previously thought" On 08/26/2016 01:46 PM, John Levine wrote: >>> ObCrypto: very little of the crypto code I use has to run in the kinds >>> of environments where C's advantages are important, so it's a reasonable >>> question why application libraries like openssl are still in C. >> >> It is still important that crypto code be callable as efficient >> libraries. One wouldn't want to, say, instantiate an entire Python >> environment every time the caller starts a new hash or encryption. And >> it seems a good idea to program pretty close to the metal to head off >> timing attacks, not let keys drift off into garbage collection land, etc. > > Of course, but there are languages like Rust that purport to provide > code efficiency comparable to C's with better type safety, and can use > calling sequences compatible with C. > I use C when writing crypto code because there exist compilers for C that allow me to control whether or not "redundant" copies of sensitive data get made, whether things get overwritten before they get released, exactly how representations work, allow me to assure that there are no bits unaccounted for (and potentially not overwritten) when a structure is built in memory, etc, and all that dangerous stuff. All that dangerous stuff which causes exploitable security flaws in languages where you CAN'T do them. C is a language that in practical terms and in most implementations allows you to control side effects and therefore side channels. It makes it terrifyingly easy to screw up in some ways, but I simply have no way to avoid screwing up in other ways unless I use it. I can write C code, compile it using TCC with no optimizing, and go check the machine code to make sure that buffers get erased when they're supposed to get erased, that unsecured copies don't made just because that would make some operation faster, that the compiler didn't substitute an algorithm subject to a timing attack for the one I intended to get, that the fields in a structure don't get realigned in ways that might leave sensitive bits unerased between fields, make sure that variable writes that clear sensitive bits happen immediately when they're supposed to happen, including those parts the compiler can prove won't affect later computation affecting the things it considers the important outputs, etc. etc. etc. C even gives me tools like 'volatile' that mean I *DON'T* usually have to go all the way down to machine code to get it done. To be fair the C standard no longer guarantees all these things, but at least in many C compilers they are still available. In almost no other language save assembly is it possible to write code where you know what it *WON'T* do, or that it WILL do what you tell it regardless of whether it affects a side-channel output the compiler won't believe anyone cares about. Bear _______________________________________________ The cryptography mailing list cryptogra...@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message -----