Qbi's Weblog

Das National Institute of Standards and Technology (NIST) gab heute bekannt, wer den SHA-3-Wettbewerb gewonnen hat: Keccak. Der Algorithmus wird nun die neue Empfehlung für einen kryptografischen Hash. Er stammt von den Forschern Guido Bertoni, Joan Daemen, Michaël Peeters und Gilles Van Assch. Besonders erwähnenswert ist Daemen. Denn er war schon für den Verschlüsselungsalgorithmus AES zuständig, der vor mehr als zehn Jahren standardisiert wurde.

Die bisher oft genutzten Algorithmen benutzen das so genannte Merkle-Damgård-Verfahren. Keccak geht einen neuen Weg (cryptographic sponge). Das erinnert mich ein wenig an AES. Denn auch damals kamen die Standardisierer von dem Feisteldesign ab.

Daniel Bernstein hat Benchmarks für verschiedene Algorithmen auf verschiedenen Plattformen gemacht. Nach der Seite ist beispielsweise BLAKE wesentlich schneller als Keccak. Im Allgemeinen scheint SHA-3 in Hardware gegossen schneller als SHA-2 zu sein. Aber die Softwarevariante ist wesentlich langsamer. Mal sehen, was die nächsten Tage ergeben. Aber momentan kann man wohl Bruce Schneier recht geben, der mal sagte, dass niemand SHA-3 nutzen wird. Nichtsdestotrotz: Alles Gute zur Wahl.

Der Mathematiker John Nash wird einigen aus dem Spielfilm A beautiful mind bekannt sein. Dort wird sein Leben (zum Teil etwas ungenau) nachgezeichnet. Noch heute ist der Begriff des Nashgleichwichts in der BWL und der Informatik wichtiger Lehrstoff. Vor kurzem veröffentlichte die NSA einen Brief von Nash (lokale Kopie), den er 1955 an den Geheimdienst schrieb.

In dem Brief beschreibt Nash ein Kryptosystem, oder Ver-/Entschlüsselungsmaschine. Es ist unklar, inwieweit die NSA hierauf reagiert hat. Dennoch äußert Nash einige grundlegende Ideen. Ron Rivest hat für seinen Krypto-Kurs eine Implementation in Python geschrieben. Wer es mag, kann ja eine Kryptoanalyse versuchen. :-) 

 via Turing's Invisible Hand: John Nash's Letter to the NSA

Update: Link aktualisiert und lokale Kopie eingebaut

In Deutschland dreht sich derzeit die Diskussion um den Bundestrojaner, der vom CCC gefunden wurde. Derweil spielt sich in den USA ein anderes Drama ab.

Jacob Appelbaum kann man nur als vielseitigen Zeitgenossen bezeichnen. Er arbeitet beim Tor-Projekt als Entwickler, hat in der Vergangenheit einige spektakuläre Ergebnisse im Bereich der IT-Sicherheit gefunden, engagiert sich bei WikiLeaks, half Hurrikanopfern usw. Die Liste lässt sich beliebig erweitern. Doch eines seiner Hobbys brachte ihm Probleme ein. Auf der Konferenz The Next HOPE hielt er im Juli 2010 einen Vortrag zu WikiLeaks (siehe unten). Seitdem wird Jacob bei jedem Grenzübertritt aus den USA oder in die USA kontrolliert. Das heißt, er wird zum Teil stundenlang festgehalten und befragt. Ihm wurden Geräte weggenommen und anderes mehr. Jetzt werdet ihr euch fragen, auf welcher Basis dies passierte. Dies ist bis heute unklar! Es gibt keine Anklage. 

Nachdem das Justizministerium Informationen von Twitter über Jacob Appelbaum und andere Aktivisten wollte, geht die US Regierung noch einen Schritt weiter. Sie forderte von Google und von dem Provider Sonic alle E-Mail-Adressen mit denen Appelbaum in den letzten zwei Jahren kommunizierte. Ein Artikel im Wall Street Journal hat weitere Details zu der Sache.

Welchen Erkenntnisgewinn soll eine solche Sache bringen? Wenn man die diversen Schritte der Behörden verfolgt, drängt sich der Verdacht auf, dass es nur um Schikane geht. Jacob kann man wohl nichts Böses nachweisen und so scheinen die Behörden einfach ein Exempel zur Abschreckung aufzubauen. Ich kann nur hoffen, dass die Vorgang ein Ende hat und Jacob sich wieder seinen Interessen widmen kann.  

Continue reading "Behördenwillkür bei Jacob Appelbaum"

Als ich das Buch zur Anonymität im Internet schrieb, gab es eine Person, die mir immer wieder „über den Weg“ lief. Len Sassaman hatte sehr früh Probleme beim Cypherpunk-Remailer gefunden und daraufhin Mixmaster mit entwickelt. The Pynchon Gate war eines der Ideen aus jüngerer Zeit, welches Len zusammen mit Nick Matthewson vom Tor Project und Bram Cohen von BitTorrent entwickelte. Len bat mich damals, eine Beschreibung mit in das Buch aufzunehmen. Die Zeit war jedoch zu kurz, um eine ordentliche Beschreibung einzubauen.

Im Laufe der Zeit sah ich Len Sassaman immer mal wieder auf Konferenzen. Wir unterhielten uns und ich lernte ihn sehr zu schätzen. Denn neben der Tatsache, dass er wirklich ein Fachmann auf seinem Gebiet war, war er ein unheimlich, hilfsbereiter Mensch.

Umso schockierter war ich, als ich gestern eine Twitter-Nachricht seiner Frau Meredith las. Sie schrieb, dass sie gerade mit der Polizei wegen seines Selbstmordes telefoniert hatte. Was zuerst noch wie ein schlechter Scherz klang, hat sich bestätigt. Len Sassaman ist aus dem Leben geschieden. Lebe wohl!

Bild von Wikipedia (Benutzer:AlexanderKlink)

Jetzt ist es endlich soweit. Die letzte Runde im Wettbewerb um einen neuen Hash-Standard wurde eingeläutet. Fünf Kandidaten gehen in die letzte Runde:

• BLAKE
• Grøstl
• JH
• KECCAK und
• Skein

Bis zum Januar nächsten Jahres besteht nochmals die Möglichkeit, die Hashes zu verbessern. Dann gibt es wieder Konferenzen und schließlich steht dann bald die Wahl einer neuen Hashfunktion vor der Tür.

Schönen guten Tag, die von Ihnen entwickelte Verschlüsselung ist zu sicher. Bauen Sie bitte eine Hintertür ein. Sie bekommen von uns steuerfrei n Millionen US-Dollar. Solche Gespräche kennt man üblicherweise aus diversen Agentthrillern. Der Chef der tschechischen Firma CircleTech hat das nun am eigenen Leib erlebt.

Die Firma stellt Verschlüsselungslösungen her. Im Jahr 2006 meldeten Heise, Golem und andere, dass die Firma mit SMS007 eine Java-Anwendung hat. Diese verschlüsselt Kurznachrichten. Die Webseite der Firma listet weitere Produkte.

Nun bekam CircleNet Besuch vom Bezpe?nostní informa?ní služba oder kurz BIS. Das ist der Inlandsgeheimdienst von Tschechien. Die Geheimdienstleute wollten eine Hintertür im Programm haben. Damit soll der BIS dann alle Nachrichten entschlüsseln können. Einer der Firmengründer zeichnete das Gespräch auf und dort ist unter anderem zu hören, dass der Firma steuerfreie Einnahmen versprochen wurden. Nachdem sie nicht darauf einging, gab es weitere Erpressungsversuche.

Der Prague Monitor meldet, dass der Vorfall vom BIS untersucht wird. Angeblich liegen derartige Deals außerhalb der Kompetenzen des Dienstes.

Es wäre gut, wenn ich tschechisch könnte. Denn die meisten Nachrichten zu CircleTech sind in der Landessprache und die automatischen Übersetzer sind nicht ausgereift. Falls also jemand weitere Details zu dem Vorfall kennt, die Kommentare sind offen.

Vor nicht allzu langer Zeit sass ich entspannt bei einem Kaffee und wollte meinen Rechner starten. Einschaltknopf gedrückt und der Bildschirm lächelte mich mit einer Fehlermeldung an:

error: unexpectedly disconnected from boot status daemon
Begin: Waiting for root file system ...

grml, warum muss das ausgerechnet jetzt passieren? Sehr schnell war klar, dass ich an dieser Stelle nicht weiter komme. Also bootete ich einen alten, funktionierenden Kernel und änderte meine grub-Einstellungen entsprechend. Damit lebte ich einige Zeit gut, bis mir mal wieder der Workaround auffiel. Jetzt wollte ich das Problem mal genauer angehen.

Die Fehlermeldung, die irgendwas von dem Boot Status Daemon erzählte, schien auf plymouth hinzudeuten. Der Sinn der Software ist es, den Bootprozess zu verschönern. Das heißt, es macht schicke Bildchen anstatt der Kernelmeldungen.

Der Bugtracker von Debian hatte einen Eintrag zu meiner Meldung. Die in dem Bugreport genannten Einstellungen änderten bei mir nichts am Problem. In meinem nächstem Versuch wollte ich plymouth deinstallieren. Aber da gab es eine winzige Abhängigkeit zu mountall(8). Der Zufall führte mich zu einem angepasstem Paket, mit dem plymouth deinstalliert werden kann. In freudiger Erwartung startete ich den Rechner neu. Aber es wäre nur zu schön gewesen, wenn sich das Problem so leicht lösen ließe.

Zu diesem Zeitpunkt kam mir in den Sinn, die Bootoptionen quiet und splash zu entfernen. Siehe da, ein wenig mehr kam zum Vorschein:

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Waiting for root file system ...

Warten, warten und nochmal warten. Oh, nun noch eine BusyBox-Shell:

(initramfs) Gave up waiting for root device. Common problems:
...
ALERT! /dev/disk/by-uuid/.... does not exist. Dropping to a shell!

Nebenbei stellte ich dann fest, dass die Meldung mit dem Boot Status Daemon nur bei einer speziellen Kernelversion auftrat. Die Meldung oben konnte ich mit jeder Standard-Ubuntu-Kernelversion größer als 2.6.32-20 erzeugen. Für mich wäre es viel wichtiger zu erfahren, woher denn diese Meldung stammt!

Ein Hinweis brachte mich dann zu den Mainline-Builds. Das sind spezielle Pakete des Ubuntu Kernelteams, die recht nahe am Original-Kernel sind. Ich versuchte wieder diverse Versionen. Alle brachten mir die Fehlermeldung. Na gut, dann baue ich eben einen eigenen Kernel.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cp /boot/config-2.6.32-24-generic /usr/src/linux-2.6/.config
make oldnoconfig
make deb-pkg
dpkg -i ../linux*.deb
reboot

Beim ersten Reboot startete der Kernel tatsächlich korrekt. Sollte Ubuntu wirklich einen Bug in den eigenen Kernel eingebaut haben? Plötzlich fiel mir ein, dass die Zeile im grub einen kleinen, aber feinen Unterschied zu den restlichen Einträgen aufwies. Ich hatte root=/dev/sda1 angegeben. Alle anderen Einträge trugen root=UUID=.... Also versuchte ich die Änderung bei den anderen Kerneln und es klappte. Jede Kernelversion bootete mit dieser Änderung.

Jetzt muss ich nur noch herausfinden, warum das nicht klappt und ich bin wieder ein glücklicher Mensch.

Das Bild stammt vom Blog Linux und ich