[Cryptography] [FORGED] Re: How programming language design can help us write secure crypto code

[Ray Dillinger]

On 10/24/2015 01:44 PM, Watson Ladd wrote:

> Does anyone have a minimal example on this list, and can point to the
> formal semantics and the standard with enough detail to demonstrate
> the existence of a gcc bug here?

Sufficiently useless compliance to a standard is indistinguishable
from having a useless standard.

I would be in favor of an extended standard for "Crypto C" such
that all code whose behavior is specified in C would be specified
identically in Crypto C, no new syntax or keywords would be
introduced, and most of things that are left unspecified in the
C standard would be either guaranteed to be compile-time errors
or specified with an exact semantics.

If we had that we could at least point at as a coherent,
implementable standard when we try to get compiler writers
to "be reasonable and consistent" from the point of view of
cryptography development.  If they didn't want to make it the
default mode, or if they hid it behind obscure command-line
switches, that would be okay.  Specifying all the undefined
crap would even make it a valuable mode for those general
developers who value the specified behavior more than the
speed.

The gcc developers have a policy of delivering the most useless
possible conformance to every language standard they implement,
on the presumption that "good" code shouldn't rely on anything
unspecified ever.  Under this definition the C standard makes
"good" code very difficult to write, and by that criterion isn't
a very good standard.  A "crypto c" standard would make things
a hell of a lot better just by being less possible to conform
to in an utterly useless way.

That said, I truly believe the same thing the gcc developers
do about "good" code and whenever such a facility is available
I use whatever compiler switches and options force an immediate
abort or compile failure on unspecified behavior.

The "expected but not specified" stuff that the gcc devs have
failed or refused to do has played a huge part in exposing the
flaws of previous language standards which needed to be improved
or clarified.  Most of which, sigh, *STILL* need to be improved
or clarified.

					Bear






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151024/f62ed690/attachment.sig>