[Cryptography] programming languages and the people who (don't) love them, was "NSA-linked Cisco exploit poses bigger threat than previously thought"

[Ray Dillinger]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160826/06e1689c/attachment.sig>