Seit ich weiss nicht wie vielen Jahren haben wir hier einen Linksys WRT54G mit DD-WRT stehen, der eigentlich immer sehr zuverlässig war. Letzte Woche hat auf einmal das WLAN den Geist aufgegeben. Auf dem Interface waren immer TX-Errors zu sehen. Ich hab mir den Wolf gesucht und nichts gefunden. Firmware upgegraded, Antennen vertauscht, an irgendwelchen obskuren Funkwerten gedreht - nichts.

Nun hatte ich es satt und hab mir neue Hardware organisiert. Da ich unbedingt wieder etwas mit DD-WRT haben wollte, musste es irgendwas kompatibles sein. Und siehe da, bei Reichelt gabs noch einen WRT54GL neu zu kaufen! Heute ist der Neue gekommen, DD-WRT aufgespielt, alte Config wieder eingestellt, et voilá!

Hach wie schön. Nun geht die Nagiosüberwachung wieder, das MRTG vom Terrarium und so weiter, ich kann mich wieder mit dem Lappi ins Wohnzimmer hocken und - am schönsten - das ellenlange Netzwerkkabel das quer durch die ganze Bude in die Küche verlief, ist auch wieder weg :)

Ich hatte schon vor längerer Zeit mal eine Seite für meine bessere Hälfte gebaut gehabt. Damals hatte ich Quietly Confident dafür benutzt, das ich im Grunde extra dafür geschrieben habe. Aber sie musste dafür immer statische HTML Seiten erstellen und bearbeiten, was irgendwann im Chaos endete. Das Tool ist einfach zu primitiv, die Komplexität ist gestiegen und vor allem hat es dem Anwender (meiner Frau also) mehr aufgebürdet als abgenommen. Daher wurde es höchste Zeit das abzulösen.

Nun habe ich die Seite Lindini Leonardo also auf Django umgestellt:

Dort läuft die gleiche Blogengine wie hier, Marke Eigenbau. Das schöne an Django ist, dass der Benutzer da wenig kaputt machen kann und das Ergebnis immer so aussieht, wie es soll. Es gibt eine vernünftige Struktur, man findet sich zurecht und darüber hinaus liegen die Daten auf dem Server und nicht mehr lokal. Jetzt kann ich auch mal eingreifen ohne bei ihr an den Rechner zu müssen.

Von der Perfomance her muss ich mir auch keine Gedanken machen, ebenso wenig wie hier: Ich benutze schon seit längerer Zeit Varnish, was ich nur empfehlen kann. Das ist ein Frontend-Cache bzw. Reverse Proxy, der den Webserver und den Applicationserver (hier also Django) massiv entlastet. Alles wird aus dem Speicher ausgeliefert und Django wird überhaupt nur gefragt wenn sich was geändert hat oder Varnish die URL noch nicht kennt. Ausnahmen sind Loginseiten und SSL-Zugriffe, das ist klar. Varnish ist sogar so cool, dass ich Django und lighttpd anhalten kann, ohne dass man vorn auf der Seite irgendwas davon mitbekommt.

Wenn hier also mal jemand die berüchtigte Meldung "Guru Meditation" bekommt, dann ist das Varnish. Kommt manchmal vor, allerdings eigentlich nur, wenn ich am Basteln bin.

Mittlerweile bin ich mit meinem Projekt Pretty Curved Privacy recht weit vorangekommen, daher dachte ich wird es an der Zeit, das hier mal ausführlicher vorzustellen.

Angefangen hat das alles, als ich - im Zuge der NSA Affäre nach Alternativen suchend - auf Curve25519 gestossen bin. Kryptographie mit eliptischen Kurven ist überaus faszinierend. Das gibt es schon länger, auch OpenSSL bietet entsprechende Algorithmen an, allerdings sind das alles NIST Standards. Und da wir mittlerweile wissen, dass das NIST von der NSA kompormittiert worden ist, muss etwas anderes her. Jedenfalls wenn man paranoid ist so wie ich. Curve25519 ist so etwas. Entwickelt von D.J.Bernstein und verfügbar in der nacl Bibliothek. Da nacl aber nicht so richtig portabel ist, gibt es eine portable Implementierung namens libsodium.

Während ich so am herumforschen war, wie man das am besten nutzen könnte, bin ich dann auf das Messaging-Framework ZeroMQ gestossen. Abseits kryptographischer Erwägungen ist ZeroMQ eine coole Sache wenn man netzwerkfähige Software schreiben will. Und es unterstützt Curve25519 über das CurveCP Protokoll. Ich spielte also mit dem Zeug so vor mich hin und irgendwann hat mich das bei CZMQ (ein Wrapper für ZeroMQ) mitgelieferte Schlüsselerzeugungstool "makecert" nur noch genervt. Es ist unflexibel und blöd. Wie es sich für einen OpenSource-Anhänger gehört, habe ich mich daher aufgerafft und etwas neues geschrieben: curve-keygen. Um das als Ersatz für makecert in das ZeroMQ Repository zu bekommen, habe ich mit den Entwicklern Kontakt aufgenommen. Die waren (und sind es noch) ohnehin gerade dabei, das Format für Curve25519 Schlüssel zu überarbeiten. Es gab dazu eine rege Diskussion auf der Mailingliste, inzwischen ist da aber Ruhe eingekehrt. Und irgendwann während dieser Diskussion habe ich angefangen, mein curve-keygen Tool neu zu schreiben. Es wurde grösser und grösser und am Ende kam Pretty Curved Privacy (PCP) heraus.

Mit PCP kann man im Grunde all die Sachen machen, die man auch mit PGP (bzw GnuPG) machen kann: Schlüssel erzeugen, verwalten, exportieren, importieren usw., Dateien ver- und entschlüsseln sowie signieren. Nur dass dabei eben keine Algorithmen zum Einsatz kommen, bei deren Entwicklung die NSA ihre Finger im Spiel hatte. Einzige Ausnahme ist SHA256 bzw SHA512, das derzeit noch für Hashes verwendet wird. Das soll aber abgelöst werden, sobald es entsprechenden Ersatz gibt.

Wie Kryptographie mit eliptischen Kurven (ECC) genau funktioniert, werde ich hier nicht erklären. Zum einen weil ich das gar nicht kann, die Mathematik ist mir viel zu heftig, das ist aus meiner Sicht mehr Magie als Mathematik. Und zum anderen wird das woanders bereits gut erklärt. Vereinfacht ist das Grundprinzip folgendes:

Bob erzeugt ein Curve25519 Schlüsselpaar bestehend aus einem öffentlichen und einem privaten Schlüssel. Alice tut das gleiche. Nun gibt Bob seinen öffentlichen Schlüssel Alice und sie tut es umgekehrt mit ihrem. Alice kann nun aus ihrem privaten Schlüssel und Bobs öffentlichen Schlüssel ein sogenanntes "shared secret" erzeugen (im Grunde eine Zahl) und Bob kann ebenfalls mit seinem privaten Schlüssel und Alice's öffentlichen Schlüssel ein "shared secret" erzeugen. Die Magie bei ECC ist nun, dass dieses "shared secret" bei beiden identisch ist! Man kann das also verwenden um Daten zu verschlüsseln, die nur der jeweilige Kommunikationspartner entschlüsseln kann. Wirklich abgefahren. Der dramatische Unterschied zum bei PGP verwendeten RSA ist, dass wenn Alice eine Nachricht für Bob verschlüsselt, dieser die nur unter Verwendung seines privaten UND Alice's öffentlichem Schlüssel entschlüsseln kann. Man kann also nicht einfach den öffentlichen Schlüssel von irgendjemand nehmen und dem dann eine Nachricht schicken. Dieser jemand muss auch einen öffentlichen Schlüssel vom Absender haben, sonst kann er damit nichts anfangen.

Dieses Szenario kann man mit PCP verwenden, es ist aber nicht die empfohlene Vorgehensweise. Obwohl ein öffentlicher Curve25519 Schlüssel zwar durchaus veröffentlicht werden kann, sollte man das lieber nicht tun. Statt dessen wird z.b. beim CurveCP Protokoll für jede Session ein dynamisches Schlüsselpaar erzeugt. Auf diese Weise kann in der Vergangenheit aufgezeichneter Traffic nicht nachträglich entschlüsselt werden, sollte einmal ein Teil der Schlüssel bekannt werden.

Bei PCP kann ich dieses Vorgehen allerdings nicht umsetzen, weil PCP offline arbeitet. Ich kann da kein Protokoll verwenden um dynamische Schlüssel auszuhandeln. Ich habe mir mit sogenannten "derived keys" abgeholfen: abgeleiteten Schlüsseln. Man sendet einem Partner also nicht den öffentlichen Schlüssel des primären Schlüsselpaars, sondern errechnet aus seinem privaten Schlüssel und einer ID einen dynamischen Schlüssel. Die ID kann die Schlüssel-ID, der Name oder die Emailadresse des Empfängers sein. Davon exportiert man den öffentlichen Schlüssel, schickt das dem Empfänger, der tut das gleiche umgekehrt und dann kann man Nachrichten austauschen. So ein abgeleiteter Schlüssel ist nur von einem bestimmten Kommunikationspartner benutzbar. Sollte er in die falschen Hände geraten, kann maximal die Kommunikation mit dieser einen Person kompromittiert werden - nicht mit allen.

Was gibts noch zu sagen? Nun, PCP ist in C geschrieben und das war eine ausgezeichnete Gelegenheit für mich, wieder da rein zu kommen. War schon eine Weile her inzwischen. Ich habe beim Entwickeln Valgrind entdeckt und lieben gelernt. Man kann gar nicht ermessen, wie sehr mit das geholfen hat, die obskursten Fehler zu finden. Ich habe ausserdem eine Unmenge an Unittests, mit denen ich sämtliche Funktionen prüfen kann. Insbesondere bei Änderungen ist das ungemein hilfreich. Das Framework dazu habe ich in Perl selber geschrieben, basierend auf dem Perlmodul Test::More, weil ich nichts passendes gefunden habe, mit dem man Unittests für command-line Tools schreiben kann. Die Unittests befinden sich im Verzeichnis tests/ im Source.

Einer der drastischsten Fehler, den ich damit gefunden hatte, war der "22-Key-Bug": neben den Unittests gibt es auch einen Stresstest, der eine grosse Menge Schlüssel verarbeitet. Das ging gut bis zum 22ten Schlüssel und dann ist PCP mit einem Segmentation Fault abgestürzt. Da hab ich vielleicht gewühlt, bis ich dem Bug auf die Schliche gekommen bin (es war ein double free, warum auch immer der erst ab dem 23ten Schlüssel anfing habe ich nie herausgefunden). Ohne Valgrind und die Unittests wäre dieser Bug noch immer im Code und ich hätte keine Ahnung davon.

Zum Schluss sei auf die Webseite von PCP hier auf dem Server verwiesen: Pretty Curved Privacy. Dort wird eigentlich alles erklärt (wie üblich auf englisch). Es gibt dort auch die aktuelle Unix Manpage pcp1(1). Den Sourcecode gibt es bei Github. Ich habe es erfolgreich unter FreeBSD, Linux (ein älteres Debian) und unter Windows 7 mit Cygwin compilieren können. Einzige Abhängigkeit ist wie erwähnt libsodium. Es gibt einen ASCII-Cast (eine Art Terminal Video), in dem ich die Verwendung demonstriere: ASCII-Cast PCP.

Zu erwähnen wäre noch, dass es sich trotz allen Aufwands, den ich bereits hineingesteckt habe, um experimentelle Software handelt, die man besser nicht für ernstzunehmende produktive Zwecke einsetzen sollte. Die Version ist auch noch unter 1 (aktuell: 0.1.3), daher können sich jederzeit Schlüssel- oder Datenbankformate ändern. Trotz allem würde ich mich natürlich über jede Art Feedback freuen :)

 

Update 2013-11-12:

Telekom kooperiert mit RSA. Mehr als die Überschrift braucht es nicht.

Update 2013-11-11:

Haha: Die IETF vertraut dem NIST auch nicht mehr.

Nach relativ viel Arbeit habe ich Pretty Curved Privacy nun in einem recht passablen Zustand. Es compiliert unter FreeBSD, Linux und Cygwin sauber durch und läuft auch auf allen 3 Platformen. MacOSX müsste ich noch probieren, aber mein alter Mac ist auf dem Dachboden. Keine Ahnung ob ich mir das antun will.

Finally, I'm done wit the first working version of "Pretty Curved Privacy". It's late, so for today only an ASCII-Cast about how to use it.

Meanwhile, here are the install instructions, intro and quickstart:

DESCRIPTION

Pretty Curved Privacy (pcp1) is a commandline utility which can be used to encrypt files. pcp1 uses eliptc curve cryptography for encryption (CURVE25519 by Dan J. Bernstein). While CURVE25519 is no worldwide accepted standard it hasn't been compromised by the NSA - which might be better, depending on your point of view.

Caution: since CURVE25519 is no accepted standard, pcp1 has to be considered as experimental software. In fact, I wrote it just to learn about the curve and see how it works.

Beside some differences it works like GNUPG. So, if you already know how to use gpg, you'll feel almost home.

QUICKSTART

Lets say, Alicia and Bobby want to exchange encrypted messages. Here's what the've got to do.

First, both have create a secret key:

 Alicia                             Bobby
 pcp1 -k                            pcp1 -k

After entering their name, email address and a passphrase to protect the key, it will be stored in their vault file (by default ~/.pcpvault).

Now, both of them have to export the public key part of their key:

 Alicia                             Bobby
 pcp1 -p -O alicia.pub              pcp1 -p -O bobby.pub

They've to exchange the public key somehow (which is not my problem at the moment, use ssh, encrypted mail, whatever). Once exchanged, they have to import it:

 Alicia                             Bobby
 pcp1 -P -I bobby.pub               pcp1 -P -I alicia.pub

They will see a response as this when done:

 key 0x29A323A2C295D391 added to .pcpvault.

Now, Alicia finally writes the secret message, encrypts it and sends it to Bobby, who in turn decrypts it:

 Alicia                             Bobby
 echo "Love you, honey" > letter
 pcp1 -e -i 0x29A323A2C295D391 -I letter -O letter.z85
 cat letter.z85 | mail bobby@foo.bar
                                pcp1 -d -I letter.z85 | less</pre>

And that's it.
Please note the big difference to GPG though: both Alicia AND Bobby have to enter the passphrase for their secret key! That's the way CURVE25519 works: you encrypt a message using your secret key and the recipients public key and the recipient does the opposite, he uses his secret key and your public key to actually decrypt the message.
Oh - and if you're wondering why I named them Alicia and Bobby: I was just sick of Alice and Bob. We're running NSA-free, so we're using other sample names as well.
INSTALLATION
There are currently no packages available, so pcp has to be compiled from source. Follow these steps:
First, you will need libsodium:
 git clone git://github.com/jedisct1/libsodium.git
 cd libsodium
 ./autogen.sh
 ./configure && make check
 sudo make install
 sudo ldconfig
 cd ..
Next, pcp:
 git clone git://github.com/tlinden/pcp.git
 cd pcp
 ./configure
 sudo make install
 cd ..
Optionally, you might run the unit tests:
 make test