[Cryptography] I don't get it.

[Lodewijk andré de la porte]

2014-04-15 22:46 GMT+02:00 Peter Fairbrother <zenadsl6186 at zen.co.uk>:

> The specific advice may have been meant only for me in my situation, but
> it contains a basic truth - languages are, or can be, too powerful.
> (...)
> Or best of all, I think we need better compilers. Better in the sense that
> they will only compile secure code. And which can prevent coders from doing
> bad things.
>

The problem is that a programmer (human) is not a processor (computer). A
programmer translates intent into processing steps. For me powerful means
expressive but also how much it resembles intent. In other words: how much
translating from idea to program.

C is not at all expressive. It's nearly assembly macro's. Maybe not nearly,
but you can still see the metal baselayer shining through.

It's always small mistranslations at a lower level. From SQL-injections to
buffer overflows to forgetting a "check security" statement.

It's like raindances, maybe. You want to have rain. You know you have to
raindance for rain. But if you curve your toe (too much) you get lightning.
That's only a problem in some cases (when it has to be safe), and then
you'll forget.

Aside from this, yes: a code checker will help in many cases. But code
checkers are not at all trivial, and they are no replacement for proper
code review and writing code in such a way that review would expose errors.
OpenSSL with only 1 reviewer definitely did not. Which is strange,
considering how important the project is.

I also feel a strong need for minimalism, to reduce possible problems and
make checking easier.

I also feel like using 3 different implementations and a sort of proxy
comparing the three outputs and only relaying if they are the same would be
a good idea. That way an exploit in a single *SSL will not turn into an
error. Just a whole lot of "MAGICSSL WARNING: INCONSISTENT RESULTS,
CONNECTION DESTROYED".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140416/4fa07676/attachment.html>