[Cryptography] Subject: Re: Swift and cryptography

[Arnold Reinhold]

On Jun 11, 2014, at 8:23 AM, Phillip Hallam-Baker <phill at hallambaker.com> wrote:

> On Tue, Jun 10, 2014 at 5:57 PM, Ben Laurie <ben at links.org> wrote:
>> On 10 June 2014 19:25, Arnold Reinhold <agr at me.com> wrote:
>>> // Initialize n to 255.
>>> int n = std::numeric_limits<uint8_t>::max();
>>> 
>>> 
>>> That is exactly the syntax bear was complaining about. Not very easy to
>>> remember
>> 
>> If you do C++, it is not rocket science. And if you don't, you
>> probably shouldn't.
> 
> Well it all depends on the argument being made.
> 
> If the argument is 'yes you can do this in C++ if you hold your nose
> while doing it' then its a valid argument.
> 
> If the argument is that the C++ way is so good that there is never a
> need to consider doing it any other way then BS.
> 
> The problem of programming is how to get the intention of the designer
> into machine code. A programming language, formal methods are only
> tools to help to that end.
> 
> The way I view the problem, I want to reduce the mental gap to the
> shortest span possible. I want the programmer thinking in terms of the
> problem space.

Thank you. David Kahn in The Codebreakers pointed out that security was not possible as long as code clerks were the lowest paid members of an embassy's staff. There is a parallel in modern times where software maintenance is done by the least expensive programmers available. Human factors are as important for cryptography as mathematics. A clean, safe language will result in fewer exploits. I particularly find loathsome the term "semantic sugar" which implies that understandable constructs are an unhealthy and morally dubious concession to human frailty. Assembly language is just semantic sugar for hexadecimal machine language.

> ...
> On the plus side it is certainly cleaner than C. But thats about it.
> How easy would it be to convert AES code from SWIFT to C or Python? Do
> they intend to provide a formal semantics that would allow the
> conversion to be done rigorously?

That likely isn't Apple's priority, but I'll bet other people are already hard at work figuring out how to convert Swift to Android's flavor of Java.

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

I think eliminating pointers and null-terminated strings and getting overflow right are also wins. 

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

I'm not sure what you mean by "drop in". Apple is betting the company that Swift will serve as a full replacement for Objective-C, which is a strict superset of C.

I started this thread asking what other features Swift should have for security. The two I came up with are a circular shift operator and class destructor semantics that do not equate x=0 with a no-op.  People tell me that the latter is platform dependent, though I am not clear why.  

Like it or not, Apple is a major player in computing. Swift is about to turn 9 days old and is still in beta. There is time to influence its final form. What else should Swift have?

Arnold Reinhold