Dr. Daniel Julius Bernstein

7.25: web.cs/sec/Dr. Daniel Julius Bernstein:
. Dr. Daniel Julius Bernstein
is an authority on computer security;
he's a big fan of extreme sandboxing
(where the app is cooperative)
and safe programming languages.
djb's main page, his papers
(and who they are cited by).

Bernstein 2005`Anti-bug programming environments:
For more than a decade
I have been systematically identifying
error-prone programming habits
—by reviewing the literature,
by analyzing other people’s mistakes,
and by analyzing my own mistakes—
and redesigning my programming environment
to eliminate those habits.
For example, “escape” mechanisms, such as
backslashes in various network protocols
and % in printf, are error-prone:
it’s too easy to feed “normal” strings to those functions
and forget about the escape mechanism.
I switched long ago to explicit tagging of “normal” strings;
the resulting APIs are wordy but no longer error-prone.
The combined result of many such changes
has been a drastic reduction in my own error rate.

Removing all bugs would be quite expensive.
Fortunately, there’s a less expensive way
to eliminate most security problems.
UNIX makes it possible (though unnecessarily difficult)
to build a [sandboxed] program ... .
[. the designer of Qubes claimed that
unix sandboxing with chroot is too easily defeated;
you need to replace unix with a microkernel.]
Bugs in the code are then irrelevant to security:
if the input is from an attacker who seizes control,
the most the attacker can do is write arbitrary output,
which is what the input source was authorized to do anyway.

A completely different way to accomplish the same result
—to build an “extreme sandbox” —
is to run those lines of code inside an interpreter
that imposes the same constraints.

There are some transformations that produce output
trusted more highly than the input;
these transformations have to be bug-free.
(There are also a few transformations that are run so often
that putting them into an extreme sandbox
would impose an unacceptable speed penalty.)
But these exceptions account for only
a small fraction of the code in a system.

I should emphasize here that
there’s a fundamental difference between
this project and typical sandboxing projects
described in the literature.
The goal of a typical sandboxing project
is to apply as many restrictions as possible to a program
while receiving no help from the programmer;
the problem is that this doesn’t stop all attacks.
[
Goldberg, Wagner, Thomas, Brewer:
A Secure Environment for Untrusted Helper Applications
(Confining the Wily Hacker).
Many popular programs use untrusted helper applications
to process data from the network.
Unfortunately, the unauthenticated network data they interpret
could well have been created by an adversary,
and the helper applications are usually
too complex to be bug-free.
This raises significant security concerns.
Therefore, it is desirable to create a secure environment
to contain untrusted helper applications.
We propose to reduce the risk of a security breach
by restricting the program's access to the operating system.
In particular, we intercept and filter dangerous system calls
via the Solaris process tracing facility.
This enabled us to build Janus:
a simple, clean, user-mode implementation
of a secure environment
for untrusted helper applications.
Our implementation has negligible performance impact,
and can protect pre-existing applications.
]
. that described a sandboxing tool ...
The subsequently discovered libresolv bug
was a security hole in that program despite the sandbox.
Imposing heavier restrictions
would have meant changing the program
[getting the programmer's cooperation]
In contrast, I insist on an extreme sandbox
guaranteeing complete security, ...
the programmer cooperates with the sandboxing tools.

Daniel Bernstein's accomplishments:

. a German-American cryptologist,
and professor of mathematics and computer science.
In the mid 90's internet software was
not designed for security,
and cryptography was controlled
(couldn't publish about strong encryption).
Bernstein addressed cryptography by
suing the United States Government
in 1995 Bernstein v. United States
and by writing secure software for email, web, and DNS.
Edward Snowden's disclosure about the mass surveillance
by the National Security Agency,
especially a backdoor inside Dual_EC_DRBG,
and suspicions of the NIST's P curve constants
led to concerns that the NSA had chosen values
that gave them an advantage in factoring public keys.
Since then Bernstein's Curve25519 and EdDSA
became the de facto replacement of NIST P curve.
Google has also selected his ChaCha20
along with his Poly1305 message authentication code
as a replacement for RC4 in TLS,
which is used for Internet security.
Many protocols based on his works have now standardized
and are used in a variety of applications,
such as Apple iOS, Linux kernel, OpenSSH, and Tor.

Bernstein was merciless in his criticism of
then leading email (Sendmail) and dns (BIND) software packages
and both the large teams which supported them
and people that distributed them.
Sendmail and BIND were both significantly less efficient,
more difficult to configure, and bug prone by design,
resulting in a regular flow of significant bugs.

Bernstein 2005`criticism of DNSSEC team:
The Domain Name System is a distributed database
that maps domain names, such as cr.yp.to,
to IP addresses (and other data), such as 131.193.178.160
Today’s DNS records are not cryptographically protected.
By giving fake IP addresses to your computer,
an attacker can easily steal your incoming and outgoing mail,
substitute fake web pages, etc.
DNSSEC, a project to cryptographically sign DNS records,
has been under development for ten years
by a large (and obviously rather incompetent)
team of protocol developers.
I’ve designed a new DNS security system, DNSSEC2,
with several advantages over DNSSEC:
it’s faster; it uses much stronger cryptographic tools;
it protects against denial of service;
it allows end-to-end security without help from
the centralized root servers;
and, most importantly,
it works with existing DNS database software,
so it’s much easier than DNSSEC to deploy.
See slides.

Aaron Swartz:
it’s time to remind people that D. J. Bernstein
is the greatest programmer in the history of the world.
... Oddly, there are many people who profess to
hate djb. Some of this is just
the general distaste of genius:
djb clearly has a forceful, uncompromising vision,
which many misinterpret as arrogance and rudeness.
And some of it is the practical man’s
disregard for great design:
djb’s programs do not work like most programs,
for the simple reason that the way most programs work
is wrong.
But the animosity goes much deeper than that.
I do not profess to understand it, ... .
This is not to say that djb’s work is perfect.
There are the bugs, as mentioned before,
and the log files, which are nothing if not inelegant,
and no doubt djb would make numerous changes
were he to write the software again today.
But who else is even trying?
Who else even knows this is possible?
I did not realize what great art in software could be
until I read djb.