vererst einigermaßen komplett

GPGKeys.mw

@@ -48,3 +48,87 @@ Der Schlüssel ist als Hierarchie gespeichert:
 ** Sub-Key 2
 *** SubKeySig
 **...
+
+=== Main-Key ===
+
+Dies ist der kryptographische Schlüssel mit dem der ganze PGP Key identifiziert wird. Dies ist grundsätzlich ein Signatur-fähiger Key (sonst funktioniert der Rest technisch nicht). Sollte dieser Key kompromittiert werden wird auch der Rest wertlos. Bei der heute üblichen Kombination DSA/ElGamal ist dies der DSA Key. Normalerweise ist dieser Key auch für alle Signaturen zuständig, in Spezialsetups mit zusätzlichen Signaturkeys macht er immerhin alle internen Key-Signaturen.
+
+=== UID ===
+
+Die UID (User IDentification) ist ein beliebiger String (in neueren Setups auch ein Bild), der den Nutzer des Schlüssels identifizieren soll. Üblicherweise ist dies ein Name und eine e-Mail-Adresse, da PGP/GPG normalerweise für Mail benutzt wird.
+
+Man darf eine PGP UID natürlich nicht mit dem verwechseln was ein Beamter meint, wenn der "identifizieren" sagt - für letzteres wird normalerweise eine physische Wohnadresse oder eine Personummer und nicht eine eMail-Adresse verwendet.
+
+=== SelfSig ===
+
+Dies ist eine Signatur mit dem Main-Key unter einer UID. Dies bindet die UID an das kryptographische Material (Main- und Sub-Keys), das in diesem PGP Key gespeichert ist. Eine SelfSig kann ein Ablaufdatum haben.
+
+=== UID Sigs ===
+
+Mit einer Signatur unter einer UID bestätigt ein Nutzer, dass er diese Identität und ihre Zugehörigkeit zum Key geprüft hat. Im Web Of Trust drückt er damit auch ein wenig Vertrauen für den Besitzer des Keys aus.
+
+Man beachte, dass nicht etwa pauschal der Key, sondern jede UID einzeln unterschrieben wird. Man sollte vor dem Signieren also wirklich jede UID einzeln prüfen, bevor man sie unterschreibt.
+
+=== Sub-Key, SubKeySig ===
+
+Ein Sub-Key bekommt Aufgaben vom Main-Key übertragen. Im normalen DSA/ElGamal-Setup ist der ElGamal Key der einzige Sub-Key und bekommt vom DSA Key die Aufgabe der Verschlüsselung (die DSA ja nicht kann) übertragen. Die SubKeySig stellt sicher, dass der SubKey korrekt an den Main-Key gebunden ist (sonst könnte man ja einen beliebigen SubKey druntermogeln).
+
+SubKeys werden ausschließlich vom Main-Key signiert. Niemals von einem anderen Nutzer oder von einem anderen SubKey.
+
+== Key Signing Party ==
+
+"Lockeres Beisammensein von PGP Nutzern unter ständigem Murmeln magischer Zahlen."
+
+Hier soll es nicht um die Organisation einer KSP gehen, sondern um die Elemente dabei:
+
+* "KeyID und Fingerprint mitbringen!"
+** die KeyID dient dazu den Key von einem Server zu ziehen
+** der Fingerprint dient dazu den Key zu identifizieren
+* "Ausweis zeigen"
+** dies dient lediglich dazu den Namen und den Besitzer als real zu identifizieren - da PGP Keys üblicherweise sonst keine Ausweisdaten enthalten ist es müsig den Rest verifizieren zu wollen
+** wenn man nicht darauf besteht mit realen Personen und echten Namen zu kommunizieren, z.B. wenn man gut mit Pseudonymen leben kann, kann man auch darauf verzichten
+
+Was gerne vergessen wird ist folgende wichtige Prozedur:
+
+# Key vom Server ziehen
+# Fingerprint vergleichen (abbrechen wenn er nicht passt!!!)
+# Key lokal signieren (falls das Mail-Programm auf Signaturen besteht)
+# eine verschlüsselte Testmail an JEDE UID des Keys senden (mit unterschiedlichen Zufallsstrings)
+** Zuordnung zwischen KeyID, String, UID sollte irgendwo gespeichert werden
+# (für begrenzte Zeit) auf Antwort warten
+# wenn Antwort kommt kann die jeweilige UID richtig signiert werden
+** der Absender ist egal (manche senden nur auf einer Mailaddi, aber empfangen dutzende)
+** der Zufallsstring muss stimmen
+** der Zufallsstring bestimmt welche UID signiert wird (siehe oben)
+** die Antwort muss nicht unbedingt verschlüsselt sein, da wir ja bitte keine Zufallsstrings wiederverwenden
+# Signaturen auf Keyserver hochladen oder exportierten Key an Besitzer schicken
+# Wenn keine Antwort kommt: lokale Signaturen wieder löschen
+
+Wir erinnern uns: es wird die UID signiert und die enthält eine Mailadresse, also müssen wir auch den Zusammenhang zwischen Key und Mailadresse prüfen bevor wir ihn mit einer Signatur bestätigen. Genau dies tut der obige Algorithmus.
+
+Erzeugung eines Zufallsstrings, z.B.:
+{{{dd if=/dev/urandom bs=100 count=1|md5sum}}}
+
+== Key Rot ==
+
+Schlüssel altern. Es wird allgemein empfohlen Schlüssel (egal ob symmetrisch oder asymmetrisch) nur für eine begrenzte Zeit zu benutzen. Dies hat verschiedene Gründe:
+
+* Attacken werden mit der Zeit besser (nie schlechter) - sowohl technisch (CPU-Power) also auch mathematisch (schnellere Algorithmen)
+* Je länger ein Key benutzt wird, umso mehr Zeit hat ein Angreifer auch um ihn zu knacken, um damit noch Schaden anrichten zu können
+* Jede Benutzung des Keys gibt einem potentiellen Angreifer weiteres Material zum Knacken des Schlüssels
+** zum einen ist jede Signatur ein weiteres "Orakel" an dem ein Kandidat getestet werden kann
+** zum anderen gibt jede Signatur Bruchteile von Bits des Schlüssels preis 
+* Je länger ein Key benutzt wird, umso höher ist auch das Risiko dass man ihn mal mit einer kaputten Implementation benutzt hat:
+** DSA versagt katastrophal wenn der Zufallsgenerator schlecht ist (der Key gilt danach als kompromittiert)
+** RSA versagt wenn die Kodierung des Hashes sich nicht strikt an die Vorschriften hält
+** ElGamal ist ebenfalls empfindlich gegen schlechten Zufall (im Signaturmodus)
+
+Literatur:
+*Bruce Schneier
+** "Applied Cryptography"
+** "Practical Cryptography"
+
+Empfehlungen:
+* symmetischer Key (CBC mode): 20 Mio Blöcke (AES: 1 Block = 8 Bytes)
+* SSL-Key für HTTPS: 1 Jahr
+* andere asymmetrische Keys (z.B. PGP): 5 Jahre