Krypto

Kürzlich hatte ich eine Prüfung im Fach Kryptologie. Das war eine Prüfung mit mehreren Personen. Eine wurde gefragt, warum der Algorithmus DES unsicher ist. Nachdem keine Antwort kam, versuchte der Prüfer eine Brücke zu bauen und fragte, wieviele Schlüssel es gäbe. Es entspann sich folgender Dialog:

P: Wie groß ist der Schlüsselraum?
S: 10¹⁰⁰?
P: Gut geraten. Aber daneben. Aus welchen Zeichen besteht der Schlüssel bei DES?
S: ?
P: Bitfolgen! Was sind Bitfolgen?
S: 0 und 1
P: Welches Zeichen kommt in Frage?
S: 2
P: *augenroll*

Übermorgen ist es wieder soweit. Der CCC läd zum 26C3. Ab dem 27. Dezember treffen sich Hacker aus aller Welt im bcc in Berlin, um zu lauschen, diskutieren, hacken und Spass zu haben. Der Fahrplan sieht recht stabil aus. Wobei sich gerade mein Vortrag verschiebt. Wahrscheinlich findet der schon am ersten Tag um 12:30 Uhr statt.

Für alle, die es nicht nach Berlin schaffen, gibt es Dragons everywhere. An verschiedenen Orten rund um die Welt gibt es Beamer, WLAN etc. und Interessierte können sich dort treffen. In Jena findet das Treffen im Cafe Wagner statt.

Von woauchimmer ihr zuseht oder kommt: Ich wünsche viel Spass auf dem 26C3.

Heute hielt ich im Rahmen der Vorlesung Kryptologie einen Vortrag zu AES. Wie erwähnt, gibt es dazu eine Ausarbeitung. Diese und den Vortrag selbst könnt ihr unter den folgenden URLs runterladen.

• http://kubieziel.de/studium/aes-ausarbeitung.pdf
• http://www.kubieziel.de/studium/vortrag-vl-kryptologie.pdf

Die Animation liegt bei http://www.formaestudio.com/rijndaelinspector/archivos/Rijndael_Animation_v4_eng.swf.

Du willst ein hochwertiges Buch lesen und dazu noch kostenlos? Nichts leichter als das! die IACR möchte gern die Bücher in ihrem Bestand bewerten. Wenn du also gern ein Buch lesen willst, suchst du dir eines aus, liest es und schickst eine Bewertung an die IACR. Das Buch darfst du behalten und dein Review erscheint auf der Webseite.

Ähnliche Programme gibt es auch mit anderen Verlagen. Die LUG Jena nimmt an einem Programm mit O'Reilly teil. Hier haben wir schon eine ansehnliche Bibliothek zusammen.

Die Anonymisierungssoftware Tor bietet neben vielen nützlichen Anwendungen auch Risiken in sich. In der Vergangenheit haben diverse Leute versucht, Passwörter anderer Nutzer auszulesen oder sonst an geheime Informationen zu kommen. Heute stieß ich beim Surfen auf einen Exit-Knoten, der falsche SSL-Zertifikate präsentiert. Damit ließe sich die sonst geschützte Kommunikation von dritter Seite mitlesen, ohne das man selbst etwas davon merkt. Der Knoten trägt den Namen JustANode mit der IP-Adresse 89.138.155.193 und läuft unter Windows XP. Offensichtlich läuft dort das Finjan Secure Web Gateway, welches sich für Active Real-Time Content Inspection rühmt. Ich hoffe, der Knoten bekommt schnellstens ein BadExit-Flag. Das schützt andere Tor-Nutzer davor, diesen zufällig zu nutzen.

Wenn du selbst mal in den Genuss kommen willst, kannst du folgendes probieren. Allerdings solltest du wissen, was du tust und auf keinen Fall schützenswerte Daten über die Leitung schicken!

1. Stelle sicher, dass Tor installiert ist und funktioniert (eventuell hilft das Tor-Browser-Paket).
2. Wähle eine SSL-Seite (https://torproject.org oder https://www.ccc.de sind zwei Möglichkeiten.)
3. Gib in die Adresszeile des Browsers die URl gefolgt von .JustANode.exit ein: https://www.example.com.JustANode.exit/.
4. Wirf einen genauen Blick auf das präsentierte Zertifikat.

Das Beispiel zeigt mal wieder, dass man beim Surfen im Web immer die Augen und das Gehirn offen halten sollte.

Ich hatte meine Vortragsunterlagen zu einem Seminarvortrag kürzlich verbloggt. Mittlerweile ist auch die dazugehörige Ausarbeitung fertig. Die 257 kB große PDF-Datei behandelt den AES-Algorithmus und Public-Key-Verfahren (RSA und Diffie-Hellman-Schlüsseltausch). Vielleicht ist es für den einen oder anderen von Nutzen.

"Hä?", werden jetzt einige denken, "was soll denn das?" Der US-Präsident wurde doch schon gewählt und die nächsten Wahlen sind noch ein paar Jahre hin. Beim Klicken durch das Blog stieß ich auf den alten Beitrag Der nächste US-Präsident wird. Demnach hatten drei Wissenschaftler den Ausgang der Wahl errechnet und die Hash-Summe der PDF-Datei veröffentlicht. Die Datei Jeb Bush.pdf sagt Jeb Bush als nächsten Präsident voraus und hat die vorab angekündigte Hash-Summe. "Moment mal", sagt ihr zurecht, "es ist doch Obama und kein Bush mehr." Es gibt auf der Webseite des Projektes auch eine PDF-Datei, die Barrack Obama als Präsidenten verkündet. Genauso werden Paris Hilton, John McCain und andere genannt. Alle Dateien haben die korrekte Hash-Summe. Letztlich soll die Aktion wirksam auf die Schwächen von MD5 hinweisen. Die Forscher schreiben ganz klar:

MD5 should no longer be used as a fingerprint function for electronic documents.

Vor vielen Jahren berichtete ich über Banken, die sicheres Login (SSL) abschalten. Sebastian twitterte über Truecrypt, die den Aufruf von https://truecrypt.org auf die HTTP-Seite umleiten. Gerade TrueCrypt als Anbieter von Sicherheitslösungen (Verschlüsselung der Festplatte) ist da ein schlechtes Beispiel. Einige weitere Beispiele nannte Sebastian in einer weiteren Nachricht. Ich habe das mal auf der Seite BadHTTPS gesammelt. Wenn euch weitere Beispiele einfallen, so hinterlasst entweder hier einen Kommentar oder schreibt es direkt auf die obige Wikiseite. Es wäre sehr interessant, weitere Beispiele zu kennen. Solch eine Sammlung liess sich in einem weiteren Schritt nutzen, um die betreffenden Firmen anzusprechen und auf eine Verbesserung der Situation hinzuwirken.

Der Crypto-Experte Nate Lawson hielt kürzlich bei Google einen Vortrag, den so genannten Tech Talk. Darin beschreibt er, was man bei der Implementierung von Kryptografie alles falsch machen kann. Wer von euch ein wenig Interesse an Krypto hat, sollte sich den unbedingt anhören:

via Google Tech Talk on common crypto flaws

Im Rahmen eines Seminars an der Uni hielt ich kürzlich einen Vortrag über AES und eine Einführung in Public-Key-Kryptografie. Die Unterlagen sind als PDF-Dokument verfügbar. Zum Grundverständnis finde ich auch diese Animation interessant. Sie enthält aus mathematischer Sicht nur ein paar Unzulänglichkeiten.

Der Vortrag verlief aus meiner Sicht sowie der der Teilnehmer gut. Nur der betreuende Professor meinte, er finde es schade, dass so wenig Mathematik dabei ist.

Mittlerweile gibt es einen neuen Angriff auf den Algorithmus. Bruce Schneier verweist im Beitrag New attack on AES auf die Veröfentlichung. Die Autoren haben auch eine FAQ zu den wichtigsten Fragen des Angriffs. Ich muss das demnächst mal lesen und verstehen.

Heute haben 38 Akademiker und Forscher einen offenen Brief (HTML-Version)an den CEO von Google, Eric Schmdit, geschrieben. So fordern auf sechs Seiten (plus zwei Seiten Fußnoten) die Standardnutzung von HTTPS und somit adäquate Sicherheit und den Schutz der Privatsphäre für die Nutzer.

Aus der Zusammenfassung:

Google already uses industry-standard Hypertext Transfer Protocol Secure (HTTPS) encryption technology to protect customers’ login information. However, encryption is not enabled by default to protect other information transmitted by users of Google Mail, Docs or Calendar. As a result, Google customers who compose email, documents, spreadsheets, presentations and calendar plans from a public connection (such as open wireless networks in coffee shops, libraries, and schools) face a very real risk of data theft and snooping, even by unsophisticated attackers. Tools to steal information are widely available on the Internet.

Google supports HTTPS encryption for the entire Gmail, Docs or Calendar session. However, this is disabled by default, and the configuration option controlling this security mechanism is not easy to discover. Few users know the risks they face when logging into Google’s Web applications from an unsecured network, and Google’s existing efforts are little help.

Support for HTTPS is built into every Web browser and is widely used in the finance and health industries to protect consumers’ sensitive information. Google even uses HTTPS encryption, enabled by default, to protect customers using Google Voice, Health, AdSense and Adwords. Google should now extend this degree of protection to users of Gmail, Docs and Calendar.

Rather than forcing its customers to “opt-in” to adequate security, Google should make security and privacy the default.

Das nächste Keysigning steht an und wieder einmal stellt sich für alle Teilnehmer die Frage, wie man am besten alle Schlüssel unterschreibt. Ich nutze dafür caff und will euch im folgenden kurz eine Einführung in die Konfiguration des Programmes geben. Hoffentlich hilft das, leichter und schneller zu Ergebnissen zu kommen.

Die Software gehört bei Debian und darauf basierenden Distributionen zum Umfang der Distribution und wird im Paket signing-party ausgeliefert. Andere Distributionen können die Dateien aus dem Subversion auschecken.

caff wird über die Datei .caffrc gesteuert. Im folgenden sind einige Einstellungen genauer erläutert. Dabei reichen meist die ersten vier oder fünf genannten Einstellungen, um caff zum Laufen zu bekommen.

$CONFIG{'owner'} = 'Max Mustermann';

$CONFIG{'email'} = 'mm@example.org';

$CONFIG{'keyid'} = [ qw{01234567890ABCDE} ];

In den beiden Variablen legt ihr euren Namen, E-Mail-Adresse und die Key-ID eures Schlüssels fest. In der letzten Einstellung kann auch eine Liste von Schlüsseln stehen. Die Key-ID bzw. den Fingerprint eures Schlüssels erhaltet ihr durch Eingabe des Befehls: gpg --fingerprint emailadresse.

$CONFIG{'mail-template'} = <<'EOM'
Text der E-Mail
EOM

Diese Variable trägt den Text der E-Mail, die an die Adressaten verschickt wird. Ihr könnt dort beliebigen Text reinschreiben und auch Variablen lassen sich expandieren. So wird {$owner} durch den oben festgelegten Namen ersetzt, {$key} steht für die Key-ID und {@uids} ist ein Array über alle UIDs. In der Beispieldatei, die mitgeliefert wird, findet ihr auch ein Beispiel zur Anwendung dieser Variablen.

$CONFIG{'mailer-send'} = [ 'smtp', Server => 'mail.example.org', Auth => ['mm', 'GehHeim'] ];

Wenn ihr einen lokalen Mailserver habt, dann ist die obige Einstellung nicht nötig. Sie betrifft vielmehr Anwender, die üblicherweise Programme wie Thunderbird, Evolution etc. nutzen und ohne lokalen Mailserver unterwegs sind. Dann hier muss caff wissen, wie es die E-Mails versenden soll. Meist wird zum Versand ein Smarthost des Providers genutzt. Der Name des Mailservers wird oben eingetragen und innerhalb der eckigen Klammern nach Auth kommen die Zugangsdaten (Benutzername und Passwort).

$CONFIG{'keyserver'} = 'subkeys.pgp.net';

Es könnte sein, dass ihr einen anderen Keyserver als den obigen standardmäßig eingestellten Nutzer wollt. Dann solltet ihr subkeys.pgp.net durch den Keyserver eurer Wahl ersetzen. Im Allgemeinen ist dieser aber eine gute Wahl.

Die Software bietet noch eine Vielzahl weiterer Möglichkeiten zur individuellen Steuerung. Diese sind in der Handbuchseite zu caff erklärt. Wie ihr oben schon gesehen habt, hat jede Option den Aufbau $CONFIG{'optionsname'} = 'einstellung';. So könnt ihr auch die weiteren in der Manpage genannten Optionen belegen.

Nachdem alle Einstellungen getroffen sind, kannst du dich ans Unterschreiben machen. Das Programm muss mit einer Liste von Key-IDs aufgerufen werden. Doch woher kommen diese? Ich stelle bei den Keysignings, die ich leite, am Ende einen Keyring aller Teilnehmer zur Verfügung. Das macht es einfach, die Key-IDs zu extrahieren:

gpg --no-default-keyring --keyring=KEYRINGDATEI --with-colons --list-keys \
 | awk -F: '/^pub/ { print $5 }'

Nun ruft ihr das Programm auf: caff -m yes -u 0x012345 KEYIDS. Die Variable -m steht dafür, die E-Mails ohne Nachfrage zu versenden. Es gibt vier Möglichkeiten, diese zu belegen und wer es will, kann die Einstellungen auch in der .caffrc treffen. Ich persönlich nutze hier lieber die Kommandozeile, um die Option zu übergeben. Mittels -u übergebt ihr die Key-ID eures eigenen Schlüssels. Auch diese Einstellung kann bereits in der .caffrc getroffen werden. Nach einem beherzten Druck auf die Entertaste geht die eigentliche Arbeit los. Ihr werdet Schlüssel für Schlüssel nach eurer Unterschrift gefragt und könnt unterschreiben.

Ich hoffe, diese Anleitung ist für Teilnehmer an einem Keysigning nützlich und hilft, den Aufwand auf ein Minimum zu reduzieren.

Foto von NoirinP.

Du bist am 2008-12-12 in Zürich und nutzt GnuPG (bzw. ein anderes OpenPGP-kompatibles Programm)? Dann nichts wie hin zur Keysigning-Party. Um 19:00 Uhr treffen sich Interessierte im Campus Zentrum der ETH und stärken ihr Web of Trust. Auf einer Infoseite sind alle Details zur Teilnahme beschrieben. Viel Spass beim Treffen und Unterschreiben!

Ich sinniere schon seit einiger Zeit, wie ich ausgehende E-Mails weitgehend automatisch verschlüsseln kann. Vor längerer Zeit stiess ich dabei auf das Perlskript von Martin Grandrath. Auf der Seite ist gut beschrieben, wie das einzurichten ist. Das problem am Skript ist die relativ lange Startzeit. Es vergehen in der regel mehrere Sekunden bis mutt einsatzfähig ist.

Vor kurzem unterhielt ich mich mit Jörg Sommer darüber. Er hat eine Lösung mit zsh-Mitteln gebastelt. Diese ist zudem noch wesentlich schneller als die obige Variante:

#!/bin/zsh

hook_name=send-hook
blacklist_file=$HOME/Mail/crypt_blacklist
output_file=$HOME/Mail/crypt_hook_list

setopt extendedglob

gpg_dump=( ${(f)"$(gpg --list-keys --with-colons)"} )

# filter out lines without @
people=( ${(f)"$(for line in ${(M)gpg_dump:#(pub|uid):*@*}; do 
  print ${"${(@s.:.)line}"[10]}; done)"} )

typeset -a -U addresses
# possible bad lines:
# • email@example.com  -- only an address
# • name (<…>) 
addresses=( ${${people%>}##*<} )

[[ -r $blacklist_file ]] &&
  addresses=( ${addresses:#${(j:|:)~${${(f)"$(<$blacklist_file)"}:#\#*}}} )

print -l "$hook_name\t~A\tunset crypt_autoencrypt" \
  "$hook_name\t'~t \""${(j:|:)addresses//./\\\\.}"\"'\tset crypt_autoencrypt" \
  > $output_file

Was macht das Skript? Anfangs werden zunächst ein paar Variablen festgelegt und das erweiterte Globbing der zsh eingeschalten. In der Variable gpg_dump wird alsdann die Ausgabe von gpg --list-keys --with-colons gespeichert. Nun folgt ein wenig zsh-Magic. Die Anweisung hinter people entspricht in etwa der Shellzeile awk -F: '/^(pub|uid)/ { print $10 }' gpg_dump, d.h. dort liegen dann alle E-Mail-Adressen, die auf den Schlüsseln angegeben waren. Schließlich wird für alle Adressen auf der Blackliste ein enstprechender Eintrag erzeugt und die Konfiguration in die Variable output_file geschrieben.Die Adressen in der Blackliste werden entfernt. Was übrig bleibt, schreibt das Skript in Datei, deren Name in output_file gespeichert ist. Dabei muss man beachten, dass mutt nicht unendlich viele Einträge akzeptiert. Es scheint eine Begrenzung irgendwo bei 200 Einträgen zu geben.

Das ist aus meiner Sicht eine gute Alternative zu Martins Skript. Solltet ihr Anmerkungen, Fragen, Kommentare haben, schreibt mir es unten rein oder schreibt direkt eine E-Mail an Jörg.

Update: Eine Zeile im Beitrag war ungenau formuliert. Nach einem Hinweis von Jörg habe ich das verbessert.

Gestern hat die CSU erhebliche Fortschritte bei ihren Mathematik-Kenntnissen gemacht. Denn die Formel 50+x hat auf einmal 43 ergeben. Neben den natürlichen Zahlen gibt es eben noch die ganzen Zahl bzw. rationale und reelle Zahlen. Bei der nächsten Wahl sollte die Partei vielleicht einfach als Wunsch 50+i ausrufen. Das Gute bei komplexen Zahlen ist, dass sie dann einfach behaupten können, mehr Stimmen als beim letzten Mal oder als eine andere Partei erhalten zu haben (und wieder etwas über Mathematik gelernt haben).