[Cryptography] Languages, languages (was Re: Swift and cryptography)

[Perry E. Metzger]

On Wed, 11 Jun 2014 08:23:06 -0400 Phillip Hallam-Baker
<phill at hallambaker.com> wrote:
> This is of course what the functional language advocates claim they
> do but I don't see that they succeed. All they have is a different
> model of computing that is closer to one particular set of problems.

I'm not sure that's particularly true. There are disadvantages to
functional programming -- it is generally "further from the machine"
and doesn't give you much control over memory management, and thus
more difficult to do things like producing truly efficient OS kernels
and such, but for most uses it is no more or less a reasonable way of
thinking about problems than most other programming paradigms. If
efficiency isn't an issue, functional usually wins, and often even if
it is an issue.

> Crypto is a problem that is almost uniquely suited to a conventional
> imperative language.

I see no evidence of that -- indeed, lots of work has been done on
building native crypto libraries in functional languages.

There is another distinct advantage to doing work in a functional
language that hasn't been mentioned so far, but I'll throw it out
there anyway -- it is currently much easier to do proofs and formal
verification over functional languages, and this is only partially an
artifact of the present tooling situation. I expect this will become
better over time, but that there will always be a gap.

Re swift, you note:

> On the plus side it is certainly cleaner than C. But thats about it.

It is also a safe language. Swift has (so far as I can tell) no
undefined behaviors, while C11 has over 200 of them and another 50 or
so unspecified behaviors. Buffer overflows aren't the only issue --
there are a huge number. Swift even catches integer overflow, and the
only other recently proposed systemsy language that does that which
I'm aware of is my own Cx.

> Apart from that, they add array bounds checking to C and make it
> ubiquitous. That is a major, major win for security code.

It is commonly believed that array bounds checks are the only or
"main" issue with C. They aren't. C has hundreds of ways for a
programmer to hang themselves. Consider, for example, what happens
when you accidentally capture the address of a local variable past
function exit, or what happens when you pass the wrong type to a
varargs function, or when you invoke signed overflow and the compiler
(quite rightfully) optimizes it out, or when a programmer depends
accidentally on the order of invocation of parameters to a function
call and the optimizer changes its mind one day.

If the language manual doesn't tell you all you need to know about how
a program will behave, a programmer's life gets "interesting", and it
is surprisingly easy even for the most skilled programmers to get into
trouble with C.

> Unfortunately what it does not do is to provide a drop in
> replacement for C.

That's what my own research work has been on for some time now. You
need an unusual design for that, one that one would normally not
select if you were designing afresh. Unfortunately I'm working alone
and have no particular expectation of producing a usable product for
non-academic purposes any time soon.

Perry
-- 
Perry E. Metzger		perry at piermont.com