2011-01-03 // GnuPG on Android with APG and K-9 Mail
I'm using a separate1) email address for my Android 2.2 based mobile phone. This makes it possible for close friends and my family to write me when I'm on the road. For free and without the need for crappy SMS phone GUIs. Additionally, it is very handy to mail yourself a grocery list or a quick note before leaving the house. 
However: All unencrypted2) mails for your phone are clear for the telco provider and others to see. But there are comfortable applications to change this.
Quick and superficial guide about the needed actions:
- Install the needed applications on your phone (click on the app names for QR Codes containing an Android Market search query):
- Astro File Manager (optional but recommended)
- Generate a new key pair for your phone. IMHO, it is a bad idea to place your main private key on an unencrypted mobile device. The risk of theft/loosing it is too high. I created the new key pair on my PC (even it would be possible on Android) because I prefer some kind of key hierarchy
and a keyboard makes the creation more comfortable. Additionally, it is not a bad idea to have a backup copy of the new key on your PC. - Export you new key pair into
.ascfiles:gpg -ao ~/privkey.asc --export-secret-key KEY-ID gpg -ao ~/pubkey.asc --export KEY-ID
If you don't like the terminal, use Enigmail or another GPG GUI for the export. It is also a good idea to export the public keys of the persons you want to write encrypted mails from your phone. Even APG provides the possibility to use keyservers, it makes no fun to search and import dozens of keys using that way.
- Copy the
.ascfiles on your phone (e.g. via USB), the location does not matter (you can delete these files after the import was done). - On your phone:
- Open APG→click Menu button→“Manage Public Keys”. The screen changes→click Menu button→“Import Key”. The program is asking where the
.ascfile containing your public key to import is located. Click on the file browser icon and run the action with “ASTRO”. Browse to the file and click on it. Check “Delete After Import” and click OK. - Open APG→click Menu button→“Manage Private Keys”. The screen changes→click Menu button→“Import Key”. The program is asking where the
.ascfile to containing your private key to import is located. Click on the file browser icon and run the action with “ASTRO”. Browse to the file and click on it. Check “Delete After Import” and click OK. - Open K-9-Mail→click Menu button→“More”→“Accounts”. The sceen changes→Click and hold on your account→“Advanced”→Cryptography→Select “APG” as the OpenPGP Provider. And check “Auto-sign” if it makes sense for you.
That's all. But you should know that K-9 Mail brings no support for PGP/MIME right now. This means you have to tell your friends to write Inline-PGP encoded mails, not PGP/MIME mails. But this should be default in most environments. If not: Enigmail provides a non-global select box for this setting at the “Per-Recipient Rules” menu.
but nearly everybody who writes mails to me is using GnuPG. Even my Mom. No excuses for not using it!2010-04-13 // GnuPG-Schlüsselhierarchie: passender Algorithmus für jede Aufgabe, Schlüsselaustausch ohne Verlust des Web of Trust
Vor ein paar Wochen habe ich mir einen neuen Key für GnuPG/PGP (im Folgenden einfach “GPG” genannt) zugelegt, weil mein bisheriger abgelaufen ist. Das habe ich zum Anlass genommen meine Vorgehensweise beim Erstellen eines GPG-Schlüssels zu überarbeiten. Die Erkenntnisse will ich hier festhalten, vielleicht bringt es ja jemandem etwas . Ziel war:
- Fein granulare Schlüsselhierarchie: Eine GPG-Aufgabe → Ein Schlüssel.
- Die verschiedenen Schlüssel sollen den jeweils passendsten Algorithmus für die Aufgabe verwenden und bei Bedarf nach relativ kurzer Zeitspanne verfallen dürfen.
Der Austausch eines Schlüssels soll NICHT zur Folge haben, dass das eigene Web-of-Trust verloren geht.
Dabei ist der letzte Punkt IMHO der Wichtigste. Er erspart einem, dass man wieder mühsam Signaturen für die neue Schlüssel einsammeln muss (den neuen Key vor Ablauf des alten Key mit selbigen zu signieren ist IMHO nur eine Notlösung, aber besser als nichts). Die Vorteile liegen auf der Hand:
- Geeignetere Algorithmen und Schlüsselstärken für die jeweilige Aufgabe
Beispiel: RSA erzeugt irrsinnig lange Signaturen, ist aber gut für Verschlüsselung geeignet. Wenn man dennoch zur Verschlüsselung auf RSA setzen will, kann man seinen Signierschlüssel über DSA realisieren. Zudem kann man die nötige Schlüssellänge (Bit) besser zwischen Aufgabe und Performance abwägen. - Mehr Sicherheit
Selbst wenn mal ein Schlüssel mit brachialer Großrechnerpower über Jahre geknackt werden könnte, so hat der Angreifer bei regelmäßig wechselnden Schlüsseln dann immer nur einen Teil der Daten und muss für weiteren Zugang zu älteren/neueren Daten erneut genausoviel Aufwand in Kauf nehmen. Dies gilt natürlich auch, wenn ein Schlüssel anderweitig kompromittiert wird (was wahrscheinlicher ist als Brute-Force). Es ist ein deutlicher Unterschied, ob jemand ein einziges Jahr oder z.B. fünfzehn Jahre Kommunikation nachvollziehen kann. Oder ob nur ein Webserver-Login ermöglicht wird oder gleich alle jemals verschickten Daten entschlüsselt werden können.
2010-02-01 // New GnuPG public key
- Key-ID:
0x423B2839 - Key-Fingerprint:
4E2C 79E1 C986 36B4 CE7B 193D ECC4 69C3 423B 2839
I will write a posting about this key during the next weeks or so (Update: There it is). It comes with a nice hierarchy, making subkey changes possible without loosing the WebOfTrust plus usage of the best fitting algorithm for the different tasks.
2007-12-21 // Microsoft und gar nicht so zufällige Zahlen
Bruce Schneier hat einen neuen US-Standard zur Erzeugung von Zufallszahlen und den darin enthaltenen Generator Dual_EC_DRBG schon etwas länger im Visier, da er darin eine Backdoor für die NSA vermutet, die über die ggf. gar nicht so zufälligen Zahlen kryptographische Schlüssel angreifen könnte.
Nun ist Bruce Schneier ein bedeutender Krypto-Experte – um so unverständlicher (außer es ist etwas dran, an Schneiers Vermutung ) ist es, dass Microsoft Dual_EC_DRBG ohne Veränderung im SP1 für Vista eingebaut hat und damit bald an seine Kunden ausliefert. Schneier rät daher allen Programmieren einschlägiger Software ab, Dual_EC_DRBG in den eigenen Programmen zu nutzen. Ein Rat, den man befolgen sollte.
2007-10-04 // Für Verschlüsselung in den Knast - endgültiger Dammbruch in Großbritannien?
Seit dem 01. Oktober ist auf der Insel ”Part III of the Regulation of Investigatory Powers Act 2000 (RIPA)” in Kraft getreten. RIPA ist ein Gesetz, das die Abhörbefugnisse von Sicherheitsbehörden massiv ausweitet. Darin enthalten ist auch “Section 49”.
Abschnitt 49 beschreibt u. a. die Pflicht des Bürgers, der Polizei auf Verlangen den Schlüssel bzw. das Passwort für verschlüsselte Daten zu übergeben, damit der Staat diese entschlüsselt kann. Dazu reicht es, dass die Entschlüsselung der Daten aus Sicht der Behörden folgende Vorteile versprechen:
- Interesse der nationalen Sicherheit
- Verhinderung oder Aufdeckung eines Verbrechens
- Interesse des wirtschaftlichen Wohlergehens des UK
- um Behörden die effektive Durchführung einer gesetzlichen Handlung oder Pflicht zu ermöglichen
…also praktisch immer und überall. Vorallem “wirtschaftliches Wohlergehen des United Kingdom” als Begründung… Man muss als Ermittler lediglich einen Amtsträger mit dem Rang des Polizeipräsidenten[sic!], Zollpräsidenten, Brigadier oder Richter finden, der die Begründung nach den oben genannten Kriterien absegnet. Falls man das Passwort nicht herausrücken will oder kann,1) wird man deswegen bis zu zwei Jahre hinter Gitter wandern. In Fällen, in denen die Behörden eine Gefahr für die nationale Sicherheit vermuten sogar bis zu fünf Jahre.
Um es wirklich klarzumachen: Man wird schlimmstenfalls fünf Jahre ins Gefängnis geworfen, weil man ein Passwort vergessen hat oder es eben bewusst verschweigt.2) Zu allem Überfluss sind die Umstände ebenfalls ziemlich unklar, so werden evtl. Ereignisse, die schon Jahre zurückliegen dazu verwendet, um das Verlangen des Passworts zu gerade beschlagnahmten Daten zu begründen.
Was ist nur aus der Insel geworden, die bisher sogar gänzlich ohne Personalausweise auskam? Überall Kameras und jetzt auch noch das. Mir macht das zunehmend Angst, hoffentlich schlagen wir in DE nicht auch noch endgültig diese Richtung ein.
Achso, falls nun jemand nach England reisen muss könnte dies von Interesse sein: vom Abschnitt 49 sind “nur” Daten betroffen, die im UK gespeichert sind. Datenbestände auf “Durchreise” sind erstmal ausgenommen, der Palm, Blackberry und das Handy eines Touristen ist also vorerst “sicher”.
Und ich glaube auch nicht, dass Hidden Volumes das Problem lösen. Das kann funktionieren, muss aber nicht. Im Gegenteil, es könnte IMHO sogar schlecht sein wenn da gar kein Hidden Volume existiert, man einem aber nicht glaubt… würde dann vielleicht Gefängnis bedeuten! 
