[Cryptography] Subject: Re: Swift and cryptography

[Phillip Hallam-Baker]

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.

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.


Crypto is a problem that is almost uniquely suited to a conventional
imperative language. So the question of interest should probably be
whether SWIFT is a language that would be useful as a medium for
interchange of algorithm specifications.

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?


Apart from that, they add array bounds checking to C and make it
ubiquitous. That is a major, major win for security code.
Unfortunately what it does not do is to provide a drop in replacement
for C.