Live Fast – Die Young

– the story of Erlang Error Handling

I recently had the honor to be guest at the Cofinpro Podcast and we talked about Erlang among other related things. One topic we touched lightly in just one sentence was Erlang’s error handling.

The way an Erlang developer will handle errors and exceptions might surprise other developers. If one writes software in a language like C or Java the developer is used to think about all the possible ways one’s software might fail and handle that failure to prevent crashes.

An Erlang developer will not prevent failure. He will not even think about failure prevention at all. All an Erlang developer will think about is the aftermath of failure and crashes. This post is a first overview of the ways of Erlang’s crash site treatment.

Let It Crash

Before developing software in Erlang I was used to writing software defensively. That means I thought hard about what could go wrong and what should happen instead. The defensive code is littered with checks for arguments and types, with try-catch-finally-frames and log messages.

In most languages working with multiple processes is painful and error-prone. So many programs will not have more than one process. If that process dies from an unhandled error the whole program crashes and leaves the user out in the rain.

So a good developer will test and check and prove that his software works in all possible cases (that one can think of). The result is code that is full of error checking code that is convoluted with the business logic.

In Erlang just let it crash. As simple as that. It is more or less the opposite of defensive programming. Since processes are cheap and in Erlang processes will often be used like objects in other languages an Erlang developer will let the process crash and die. The software that solves the problem will only care about problem-solving. Writing the part the developer will assume that all input will be faultless and failure will not happen.

Let Someone Else Fix It

In the bouquet of processes, an Erlang developer will set up monitoring processes. Those monitors will not contain business logic but they will monitor the health of other processes. If a process crashes and dies it will know what to do with that. This monitoring works across machine boundaries since one cannot make fault tolerant systems on a single machine.

That is the second part of an Erlang software. Next to the problem-solving business logic the failure handling and error-correcting code often is generic so it can be reused in future applications.

In my opinion, this is a nice separation of concerns. Writing code that solves the problem and separating it from code that fixes failures.

For further reading, I recommend Programming Erlang by Joe Armstrong.

Der Wolf und die Kreide

Es klopfte an der Tür und die Geißlein riefen: “Wer da?”“Ich bin’s, eure Mutter!”, sprach der Wolf mit rauer Stimme. Doch die Geißlein waren gewarnt worden: Der Wolf würde versuchen, sich zu verstellen um ins Haus zu gelangen. Sie erkannten seine falsche Stimme und wiesen ihn ab. Im letzten Artikel hatten Romeo und Juliet keine Chance zu erkennen, dass Lady Capulet ihre Briefe manipulierte. Doch die Mutter Geiß war schlauer. Sie setzte eine Senderverifikation ein, um den Geißlein die Chance zu geben, den Wolf zu erkennen. Noch zwei mal musste der Wolf klopfen und jedes Mal seine gesendeten Informationen verbessern, ehe die Geißlein auf sein Schauspiel herein fielen.

Die Mutter Geiß hätte es sich deutlich einfacher machen können, indem sie mit ihren Kindern ein Passwort vereinbart hätte. Das ist für symmetrische Kommunikation möglich und da die Geiß und ihre Kinder zuerst am selben Ort verweilten, wäre das problemlos möglich gewesen. Was ist aber, wenn keine symmetrische Kommunikation möglich ist, wenn sich Sender und Empfänger asymmetrisch verifizieren wollen?

Wenn die Parteien sich kennen, können sie auf gemeinsame Geheimnisse vertrauen. Die Geißlein hätten den Wolf nach den Namen aller Geschwister in der richtigen Reihenfolge befragen können. In dem Falle hätten ihm weder Kreide noch Mehl etwas genutzt.

Viel interessanter ist aber die asymmetrische Verifikation, wenn sich die Parteien nicht kennen. In dem Fall macht man sich die asymmetrische Verschlüsselung zu nutze. Wie wir bereits gelernt haben, bedeutet asymmetrische Verschlüsselung, dass zwei Parteien jeweils einen privaten und einen öffentlichen Schlüssel erzeugen und Letzteren austauschen. Dabei kann der öffentliche Schlüssel an beliebig viele Parteien weiter gegeben werden. Die Mutter Geiß berechnet also zwei Schlüssel, einen privaten Gprivate und einen öffentlichen Gpublic. Den öffentlichen Schlüssel sagt sie jedem Geißlein und schreibt ihn zur Erinnerung auch noch an die Wand. Den privaten Schlüssel behält die Geiß im Kopf und verrät ihn keiner Seele. Als sie dann das Haus verlässt, sagt sie ihren Kindern, sie wird ihnen bei ihrer Rückkehr zwei Zahlen nennen. Wenn sie den öffentlichen Schlüssel auf die zweite Zahl anwenden, sollte als Ergebnis die erste Zahl heraus kommen. Dann verbietet sie den Geißlein, irgendwem die Tür zu öffnen, außer er könne solche Zahlen nennen.

Der Wolf hat sich gut vorbereitet. Mit Kreide und Mehl bewaffnet erscheint er an der Tür. Seine Stimme klingt hell und klar, seine Pfote ist weiß wie Schnee. Die Geißlein sind begeistert und wollen schon die Tür öffnen, da fragt das Jüngste: “Nenn uns doch die Zahlen, liebe Mutter!”.

Der Wolf überlegt und späht durch das Fenster. Er sieht den öffentlichen Schlüssel, denkt sich eine Zahl aus und verschlüsselt sie mit dem Schlüssel an der Wand. Er nennt die beiden Zahlen. Als die Geißlein ihrerseits Gpublic darauf anwenden, ergibt sich alles, nur keine Gleichheit. Sie verrammeln die Tür und verwehren dem Wolf den Zutritt.

Später am Tag kommt die Mutter nach Haus. Auch sie wird von ihren Kindern mit der Frage nach den Zahlen empfangen, denkt sich spontan eine beliebige Zahl aus, berechnet mit Gprivate die zweite Zahl und nennt beide den Geißlein. Die wenden darauf Gpublic an und reißen die Tür auf, in dem Wissen, ihre Mutter davor zu finden.

__

Dieser Text ist etwas abstrakt. Ich hoffe aber doch, dass klar geworden ist, wie genau Senderverifikation funktionieren kann. Ich habe vor, in einem späteren Artikel noch einmal darauf einzugehen, wenn wir mehr über RSA und andere Algorithmen wissen, die zu Signaturen fähig sind. Nicht jeder asymmetrische Algorithmus ist in der Lage, den Sender zu verifizieren. So ist zum Beispiel das Merkle-Hellman-Kryptosystem nicht fähig, den Sender zu beglaubigen. Ich werde aber noch genauer darauf eingehen, welche Voraussetzungen es benötigt und warum man nicht einfach eine plausible Verifikation aus dem öffentlichen Schlüssel berechnen kann. Stay tuned …

Romeo, Juliet, Diffie & Hellman

Als Whitfield Diffie und Martin Hellman 1976 ihr Papier mit dem Titel “New Directions in Cryptography” veröffentlichten, waren sie von der Idee getrieben, geheime Informationen über einen öffentlichen Kanal auszutauschen. Und das ohne vorher über einen sicheren Kanal irgendwelche Absprachen getroffen zu haben. Mehr noch, die Absicherung des Geheimnisses sollte vollständig mit öffentlich bekannten Techniken erfolgen. In diesem Teil der Reihe “Asymmetrische Kryptographie” soll der Schlüsselaustausch nach Diffie und Hellman im Mittelpunkt stehen. Continue reading

Ein wenig Mathe …

Die hohe Kunst der Verschlüsselung kommt ohne ein paar mathematische Grundlagen nicht aus. Dabei ist “Grundlagen” ernst zu nehmen, denn über die Schulmathematik geht es kaum hinaus. In diesem Abschnitt der Reihe zur asymmetrischen Kryptographie versuche ich ein Verständnis für das Rechnen mit modulo, den größten gemeinsamen Teiler und die Vielfachsummendarstellung zu schaffen. Es wird einfach. Versprochen. Continue reading