[Cryptography] Swift and cryptography

[Jerry Leichter]

On Jun 9, 2014, at 8:14 PM, Nemo <nemo at self-evident.org> wrote:
>> Apple's new programming language, Swift,
> 
> "What we need most, at this juncture, is another programming language"
> 
> ...said nobody over the age of 30, ever.
Apple had a very specific need:  To replace a language that had long passed its sell-by date (Objective C, which was an important improvement of C in 1983 when it was first introduced) with something that would be compatible with 30 years of libraries, interfaces, and programming/development approaches, none of which fit will with any other language out there.

Special problem, special solution.

On the more general question of whether we need yet another programming language to add to the thousands we already have - well, it's not like people are going to stop developing new languages.  And it's not a bad thing, since historically expressive new ideas go hand in hand with new languages, and often end up enriching old ones.  Both C++ and Java now have "for each" style loops, but neither of those languages invented the idea; it came from a long series of (almost entirely) now-dead languages, probably going back to Clu from the mid-1970's.  As a languages guy, I'm on in favor.

On the more specific issue of fastening on the latest shiny new language as, *finally*, the right one in which to implement crypto algorithms ... there I call bullshit.  OK, maybe RUST is nice.  (I haven't actually looked at it.)  Is its semantics well understood - not just in some formal sense, but by a significant community?  Are there trustworthy compilers - yes, plural, no matter how careful the designers are, a language with only one compiler is defined by that compiler, not by its specs?  Will it still be around and being actively used, maintained, and extended 5 years from now?  Ten?  Only a tiny fraction of neat new language survive - but good crypto algorithms and protocols can live for decades.

And just what is it an implementation language for crypto needs?  Automatic range checking?  Sure ... but you do realize that FORTRAN compilers starting doing that before many of the people on this list were born.  If C has a single major fault, it's that it fed *generations* of programmers the line that arrays were just shorthand for pointers and that range checking was for wimps - and idea that even got transplanted in the C++ standard library's iterators.  Fortunately, this particular virus has infected few other language families.  GC?  Very nice to have, but hardly at the top of the list for the kinds of code that's common in crypto implementations.  (A bit more in protocol implementations.)  And it brings with it a bunch of related issues about tight management of the lifetime of sensitive data in memory.  User-defined operations?  Hardly.  Better ways to express parallelism?  Maybe for protocols, but you're buying into multiple layers of complexity and system-specific approaches if you go that route, both very wrong for general-purpose crypto or protocol implementations.  What else?

The ideal crypto implementation language has three features:  The ability to generate highly efficient code; the ability to control that code very closely (to prevent or at least control things like timing attacks); and a semantics that allows for formal verification (whether you actually do it right now or not; that's an indirect way of saying that the language's semantics is completely and tightly specified).  I don't see anything out there that gives you all three; I don't really see anything on the horizon either.  We have languages that give you the first two, and languages that give you the third.  As the paper Perry recently forwarded shows, after years of research we're getting to the point where we can add the third on to a language that has the first two.  (Languages that have the third property have been promising to get the first two for decades.  I saw claims that network protocols - not crypto protocols - implemented in S/ML could be compiled to produce code at least as good as C code 15-20 years ago.  But somehow the work there didn't generalize, or just plain wasn't picked up - or maybe things were never quite as good as was claimed at the time.)  Frankly, I think we're more likely to get the "ideal" programming language for crypto this way than by jumping to the latest craze.

                                                        -- Jerry