DEUTSCHE PGP ANLEITUNG

Schlüsselerzeugung und Empfehlungen zur Schlüssellänge

Vor der Keyerzeugung sollte man unbedingt noch einen Blick auf den Punkt ADVANCED werfen und sich die Mantra FAQ durchlesen.

  1. 1xMK auf PGPtrayicon ", dann Launch PGPkeys" oder direkt im Startmenü auf das PGPkeyicon klicken
  2. Menüpunkt "Keys"
  3. "New Key"
  4. Full Name: (Vorname) Nachname eingeben
  5. E-mail Address: user@adresse eingeben
  6. Key-Typ wählen

    Anmerkung
    Es ist vorteilhaft, nacheinander sowohl ein RSA-Keypaar, als auch ein DH-Keypaar zu erzeugen, damit auch Benutzer anderer 2.6.X Versionen von PGP mit dem Keybesitzer kommunizieren können.

  7. Key Pair Size (Schlüssellänge) wählen

    Vorschlag
    Abseits der Diskussionen, welche Länge ausreicht oder nicht, sollte man m. M. nach aus der Perspektive der Zukunftssicherheit für den Verschlüsselungskey eine Länge von ca. 3100-bit wählen.
    Für einen Signierkey ist die Keylänge bei der ElGamal/DSA Kombination (DH/DSS) auf 1024-bit begrenzt, ansonsten sollte man für einen Signierkey eine Länge von 1880 bis 2100-bit wählen.
    Der längste Key nützt natürlich nichts, wenn u. a. eine schwache Passphrase gewählt wird.
    Dabei ist jedoch zu beachten, dass eine Keybenutzung mit PGP 2.6.3 (i/a) nicht mehr möglich ist, sondern nur bei Verwendung der PGP 2.6.3 IN - Version. PGP 2.6.3 i/a sollte nicht mehr verwendet werden.


    Dazu als Einleitung ein Zitat aus dem Jahr 1998 vom PGP Erfinder, P. Zimmermann:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    
    There is no advantage for using the keys larger than about 3000 bits.
    The 128-bit session keys have the same work factor to break as a 3000
    bit RSA or DH key.  Therefore, the larger keys contribute nothing to
    security, and, in my opinion, spread superstition and ignorance about
    cryptography.  They also slow everything down and burden the key servers
    and everyone's keyrings, as well as cause interoperability problems
    with present and future releases of PGP.  Perhaps even more importantly,
    they also undermine other people's faith in their own keys that are of
    appropriate size.  While it may have been well-intentioned, this massive 
    expansion of key size is a disservice to the PGP community.
    
    Also, larger DSA keys don't contribute anything unless the hash grows
    bigger with it.  That requires selecting a good well-designed bigger hash
    that has been specifically designed to have the full work factor for
    breaking it.  Using two SHA1 hashes in that manner has not been adequately
    shown to achieve this result.
    
    Anyone with a sophisticated understanding of cryptography would not make
    the keys bigger this way.
    
    Experimental code that we put into PGP during its development should not be
    used.  It was protected with conditional compilation flags and should never
    have been revealed to uninformed users who decide to perform a "public
    service" by enabling the code and releasing it.  This is part of the reason
    why we ask people not to release code changes on their own, but to send them
    to us, so that we may incorporate some of them (if they seem like good ideas)
    into our next product release.  That is how PGP enhancements from the user
    community have always been managed since PGP source code was released in
    1991.
    
     -Philip Zimmermann
    
    -----BEGIN PGP SIGNATURE-----
    Version: PGP 6.0b16
    
    iQA/AwUBNcIZ0GPLaR3669X8EQIblACePP3jorZ6Y+wjYDRomxMfKgLF2h4AoNmI
    tjDuzHfhdIqDd6s5BUNIlhBu
    =3BJC
    -----END PGP SIGNATURE-----
    

    Also: Um die 3000-bit RSA/DH, 2048-bit DSA und SHA-2 könnten es schon sein.

  8. Verschiedene Studien zur Stärke bestimmter Schlüssellängen

    A. "Probleme beim PGP-Einsatz in Zertifizierungsstellen und deren Lösung durch PGP2.6.3in und OpenPGP"
    von Ingmar Camphausen und Lutz Donnerhacke

    (Workshop Sicherheit in vernetzten Systemen, DFN-CERT & PCA, Hamburg (D), 4-5 March 1998, pp. B 1 - 16.)

    aus dem Kapitel "Lange Schlüssel":
    "...Nach aktuellen Studien entsprechen sich die Schlüssellängen bei asymmetrischer und symmetrischer Verschlüsselung gemäss Tabelle, was ihre Resistenz gegen Angriffe angeht. Damit ist klar, dass die Entscheidung, in den IN-Zertifizierungsrichtlinien eine Schlüssellänge von 2048 bit RSA für die Root-CA und mindestens 1024 bit RSA für Nutzer zu fordern, nicht überzogen war.

    PGP 5 (mit DH-Keys,Anm. d. Autors) kann diese Forderungen nicht erfüllen, da sein Signaturalgorithmus DSA entwurfsbedingt auf 1024 bit DLP (DLP: Discrete logarithm problem) beschränkt ist. Das im Gegensatz dazu skalierbare ElGamal-Verfahren wurde in PGP 5 so implementiert, dass Unterschriften nach diesem Verfahren einer Veröffentlichung des geheimen Schlüssels gleich kämen. Hier muss also eine vernünftige OpenPGP Implementation abgewartet werden.
    Gleichzeitig wird aus der Tabelle auch klar, dass eigentlich um 2500 bit RSA oder 3100 bit DLP der Normalfall seien sollten."

    RSA-Modulus <=> symmetrisch DLP-Modulus <=> symmetrisch
    512
    786
    1024
    2048
    2500
    3072
    4096
    63
    76
    86
    117
    128
    139
    157
    1024
    2048
    3072
    4096

    56
    112
    128
    168

    Bitlängen gleicher Kryptoresistenz

    B. "Selecting cryptographic key sizes in commercial applications"
    von Verheul und Lenstra

    Empfohlene Keylängen, die im Jahr X noch als sicher angesehen werden können, gemessen an Moore's Law (das besagt, dass sich die Rechenkapazität eines Prozessors durch neue Typen des gleichen Prozessors alle 18 Monate verdoppelt), der Berechenungszeit mit einem 450 Mhz Pentium II Prozessor, bzw. der Berechnungszeit in Mips Jahren und der Höhe des zur Verfügung stehenden Bugets auf Seiten des Angreifers (das sich alle 10 Jahre verdoppelt) nach Lenstra und Verheul.
    Beide Autoren sagen auch, dass durch eine zukünftige Weiterentwicklung in der Computertechnik, wie Quantum Computer, die bis jetzt nur in hypothetischer Form existieren, das Modell hinfällig werden könnte.
    Eigene Berechnungen nach diesem Modell können hier durchgeführt werden.

    Jahr Länge sym. Key (Bits)
    (IDEA,CAST)
    <=> Länge asym. Key (Bits)
    (RSA,ElGamal,DH)
    <=> Subgroup DLP Keylänge
    (DSA,DSS)
    2000 70 952 125
    2002 72 1028 127
    2005 74 1149 131
    2010 78 1369 138
    2015 82 1613 145
    2020 86 1881 151
    2023 88 2054 156
    2025 89 2174 158
    2026 90 2236 160
    2030 93 2493 165
    2035 97 2840 172
    2040 101 3214 179


    Nach diesem Modell wäre ein 1024-Bit Key bis ca. Mitte 2001 und ein 2048-Bit Key bis ca. Mitte 2023 als sicher vor Berechnung anzusehen.

    C. Frequently Asked Questions About Today's Cryptography?
    der RSA Laboratories

    Empfehlungen zur Schlüssellänge:

    Grad
    Block Cipher
    RSA
    DSA/DSS
    nach US-Exportgesetz
    40 Bits
    512-Bit
    512/80 Bits
    persönlicher Bereich
    (E-Mail, unwichtige Daten)
    56/64 Bits
    768 Bits
    768/136 Bits
    kommerzieller Bereich
    128 Bits
    1024 Bits
    1024/160 Bits
    militärischer Bereich
    160 Bits
    2048 Bits
    2048/200 Bits
    Tabelle RSA FAQ 4.0

     
    Block Cipher
    RSA
    Elliptic Curve
    DSA
    Export Grade
    56
    512
    112
    512 / 112
    Traditional
    recommendations
    80
    1024
    160
    1024 / 160
    112
    2048
    224
    2048 / 224
    Lenstra/Verheul 2000
    70
    952
    132
    952 / 125
    Lenstra/Verheul 2010
    78
    1369
    146 /160
    1369 / 138

    "Minimal key lengths in bits for different grades" der Tabelle RSA FAQ 4.1

    D. IEEE [Institute of Electrical and Electronics Engineers] Standard
    P1363 / D13 Standard Specifications for Public Key Cryptography vom 12.11.99
    - Annex A (Informative). Number-Theoretic Background

    Kapitel A.3.10 Parameters for Common Key Sizes:

    When selecting domain parameters for DL-based [ Anm.: Discrete Logarithm ] cryptography over binary fields, it is necessary to begin by choosing the following:

    The degree m of the field (so that the field has 2 m elements)
    The prime number r which is to serve as the order of the base point

    These two numbers are related by the condition that r must be a primitive divisor of 2 m 1 (see Annex A.3.9). Moreover, it is a common practice to choose the two numbers to provide comparable levels of security. (See Annex D.4.1.4, Note 1.) Each parameter depends on the size of the symmetric keys which the DL system is being used to protect.
    The following table lists several common symmetric key lengths. For each length is given a set of parameters of m and r which can be used in conjunction with symmetric keys of that length.
    Key size: m r
    40 189 207617485544258392970753527
    56 384 442499826945303593556473164
    314770689
    64 506 282255152946033084760426208
    6149015242689
    80 1024 745560282564788420833739573
    6200454918783366342657
    112 2068 162845635541041154750961337
    4150158051231656743052344513161858038422883778013
    128 2880 1919487818858585561290806193
    6944281464039294965346491767953330250249208842371201

    Nach dem IEEE würde also ein DSA-Key mit 1024-Bit Länge einem symmetrischen Key von 80-Bit Länge entsprechen.
    Der DSA/DSS Master-Signierschlüssel des ElGamal-Schlüsselpaares von PGP hätte also die Stärke eines symmetrischen Keys mit einer Länge von 80-Bit.
    Erst Keys mit einer Mindestlänge von 2880-Bit würden einem symmetrischen Key mit der als (zukunfts)sicher eingestuften Länge von 128-Bit entsprechen, wie es z. B. bei den bekannten IDEA Schlüsseln der Fall ist.
    Das IEEE erwähnt, dass 1024-Bit das heute als üblich akzeptierte Minimum darstellen.

    E. Daniel J. Bernstein: Circuits for integer factorisation

    In seinem Papier beschreibt Bernstein den Versuch, sich mit Hilfe von Spezialhardware zahlentheoretischer Probleme zu nähern, darunter auch der Faktorisierung von Zahlen, auf denen u.a. die RSA Verschlüsselung beruht.
    Eine einfache Erläuterung des Papiers findet sich im Artikel
    Spezialhardware bedroht möglicherweise RSA-Sicherheit
    .
    Eine Betrachtung der RSA Security im Artikel
    Has the RSA algorithm been compromised as a result of Bernstein's Paper?
    In Kryptografiekreisen und im Artikel wird, beruhend auf Bernsteins Papier, die Empfehlung ausgesprochen, RSA-Keys sollten mindestens 2048-Bit gross sein, besser darüber liegen.
    Im Artikel "Bernstein's Factoring Breakthrough?" des Crypto-Gram Newsletters vom 15. 03.02 kommentiert Bruce Schneier die Diskussionen zum Bernstein-Papier.

    F. Im Artikel "Is 1024 Bits Enough?"

    des Crypto-Gram Newsletters vom 15.04.02 nimmt er nochmals Bezug auf die Debatte, in dem es u.a. heisst:
    "...Way back in 1995, I estimated key lengths required to be secure from different adversaries: individuals, corporations, and governments (Applied Cryptography, 2nd Edition, table 7.6, page 162). Back then I suggested that people migrate towards 1280-bit keys, and even 1536-bit keys, if they were concerned about large corporate or government adversaries:
    Recommended Public-Key Key Lengths (in bits)
    Year Ind. Corp. Govt.
    1995 768 1280 1536
    2000 1024 1280 1536
    2005 1280 1536 2048
    2010 1280 1536 2048
    2015 1536 2048 2048
    Looking back on those numbers written seven years ago, I think they were conservative but not unduly so. Factoring, at least in the academic community, has not progressed as fast as I expected it to. But mathematical progress is bursty, and a single breakthrough could more than make up for lost time. So if I were making recommendations today, I would still stand by my 2000 estimates above.

    I have long believed that a 1024-bit key could fall to a machine costing $1 billion. And that a 1024-bit RSA key is approximately equivalent to a 80-bit symmetric key. (In Applied Cryptography, I wrote that a 768-bit RSA key is equivalent to an 80-bit symmetric key; that's probably too low an RSA key.)

    Comparing symmetric and public-key keys is a lot like comparing apples and oranges. I recommend 128-bit symmetric keys because they are just as fast at 64-bit keys. That's not true for public-key keys. Doubling the key size roughly corresponds to a six-times speed slowdown in software. This might not matter with PGP, but it will make client-server applications like SSL slow to a crawl. I've seen papers claiming that you need 3072-bit RSA keys to correspond to 128-bit symmetric keys and 15K-bit RSA keys for 256-bit symmetric keys. This kind of thinking is ridiculous; the performance trade-offs and attack models are so different that the comparisons don't make sense..."

    G. Empfehlung „Geeignete Kryptoalgorithmen" gemäß §17 (1) SigG (Update 2002)
    Stellungnahme Secorvo Security Consulting GmbH

    Die Studie trifft Aussagen zu den Hashfunktionen SHA, RIPEMD und den Signieralgorithmen RSA und DSA. Bei der Betrachtung stützen sich die Autoren neben anderen Studien stark auf die Untersuchung Selecting Cryptographic Key Sizes von Lenstra und Verheul, November 1999.

    Der Studie nach entsprechen für die Hashfunktionen 160-bit einer Blockchiffre von 80-bit und sind bis 2012 als sicher anzusehen.
    Es wird die Empfehlung ausgesprochen, "...die aktuellen Entwicklungen von Hashfunktionen mit mehr als 160-bit Ausgabe zu verfolgen und ggf. voranzutreiben..."
    Für RSA als Signieralgorithmus treffen die Autoren die Aussage, dass mit der Faktorisierung eines RSA-Keys mit 1024-bit frühestens 2020 und mit 1280-bit 2027 zu rechnen sei.
    Für die Sicherheit von DSA wird die Aussage getroffen, eine Sicherheit von 160-bit Keylänge erscheine bis 2007/2008 als ausreichend.

    H. ECC, Future Resiliency and High Security Systems

    Die Studie vom 6. Juli 1999 von Don B. Johnson hat die Merkmale und Vorteile der Nutzung von Elliptic Curve Cryptography (ECC) zum Thema.
    Die Studie enthält u. a. die Tabelle
    "Ungefähre Gleichwertigkeit von Keys in Bits in Bezug auf bekannte allgemeine Angriffe"

    Security Analysis

    For RSA, the strength of the algorithm increases by increasing the primary security parameter, which is the size of the modulus n. For example, ANSI X9.31 mandates a minimum size of n of 1024 bits.

    For DSA, there are two primary security parameters, the size of the prime p (the order of the arithmetic field) and the size of the prime q (the order of the subgroup generated by the generator g). For example, the revision of ANSI X9.30 DSA now being discussed by ANSI X9 will mandate a minimum size for p of 1024 bits and a minimum size for q of 160 bits. To increase the effective security, both must be increased appropriately; increasing one without the other is not effective.

    (...)

    Assume for purposes of this discussion that the known best method to attack a symmetric key is by brute-force key exhaustion, which is the ideal goal of a symmetric key algorithm. Note that this attack is inherently able to be run in parallel, if a single cracker machine is expected to take m years and an adversary has k cracker machines, then his expected time to crack a key is m/k years. One would like to be able to calculate the appropriate size for the asymmetric key used to protect a n-bit symmetric key.

    For an elliptic curve cryptosystem, the known best general-purpose attack is a square-root attack based on the Pollard rho algorithm [X9.62]. Note that this attack can also be run in parallel. If one assumes that a symmetric algorithm encryption takes about the same time as an elliptic curve scalar multiplication (this is a very conservative assumption), this means that one should use an ECC keysize of about double the symmetric keysize. For 128-bit AES, an appropriate ECC key size is 256 bits. This is a very simple and straightforward calculation.

    The Pollard rho algorithm is also the basis of the known best general-purpose method to attack the subgroup of size q in the DSA, this means that the size of q should be about 256 bits. However, the known best method to attack either the security associated with the size of DSA’s p parameter or the size of RSA’s modulus n is a complicated formula based on the General Number Field Sieve method for taking discrete logarithms or factoring. As specified in the current draft of the revision of X9.30 DSA, for 128-bit AES, an appropriate size of p is 3072 bits. An attack on the DSA field p is considered (very) slightly harder than an attack on the RSA modulus n, but for simplicity, just assume the same difficulty. As can be seen from the following table, for very high levels of security, the large keysizes for RSA and DSA keys will simply be unwieldy, ECC is the most practical choice. However, note that many experts believe that 192 or 256 bits of symmetric key security may never be needed.
    Symmetrisch 56 80 112 128 192 256

    RSA n 512 1024 2048 3072 7680 15360
    DSA p 512 1024 2048 3072 7680 15360
    DSA q 112 160 224 256 384 512
    ECC n 112 161 224 256 384 512

    Fazit

    wenn man Verschlüsselungs- und Signierkeys mit maximaler Stärke/Sicherheit einsetzen will, die, gemessen am jetzigen technologischem Wissen und Standard (und den Vermutungen über die technologischen Kapazitäten eines Geheimdienstes wie der NSA - eine Annahme geht von einem Vorsprung von ca. 10 Jahren aus), zukunftssicher für die nächsten Jahrzente sein sollen und der Stärke eines symmetrischen, 128-Bit Keys entsprechen, sollte:

    • die Länge von RSA und ElGamal (DH) Keys ca. 3100-Bit betragen
    • die Länge von DSA Keys ca. 3100/256-Bit, mindestens 2048/224-Bit betragen
    • die Länge des Hashalgorithmus ca. 256-Bit betragen
    • DSA Keys sind aktuell durch den Standard auf 1024/160-Bit, der Hashalgorithmus auf 160-Bit beschränkt

    Bei Anwendung von kryptografischen Techniken im Bereich von Serveranwendungen kann die Keylänge geringer ausfallen (1024- bis 2048-Bit), weil dort der Aspekt der Verarbeitungsgeschwindigkeit eine wichtige Rolle spielt.
  9. Key Expiration angeben
    hier kann man angeben, ob die Keys unbegrenzt oder zeitlich begrenzt genutzt werden sollen.
    Never: Keys sind unbegrenzt benutzbar
    Expires in xy Tagen: Keys sind nur xy Tage benutzbar.
    Mit dem Tool Abattoir von Imad R. Faiad ist es möglich, die Verfallszeit eines DH/RSA v.4 Keys nachträglich zu editieren.

    Anmerkung
    Das bedeutet für den Keybesitzer, dass er nach Verfall des Keys weiterhin an ihn verschlüsselte E-mails entschlüsseln, aber keine neuen E-mails mit diesem Key signieren kann.
    Für den E-mailpartner, der den Public Key benutzt, heisst das, er kann nach Verfall des Keys keine E-mails mehr an den Keybesitzer mit diesem Key verschlüsseln, aber noch dessen Signaturen überprüfen.
    Das bedeutet auch, dass nach Verfall neue Keys erzeugt werden müssen.

  10. Passphrase angeben
    "Hide typing" Wenn die Gefahr besteht, beobachtet zu werden,
    wird damit die Monitoranzeige der Passphrase unterdrückt.

    Anmerkung
    Wähle eine möglichst lange und aus zufällig gwählten Zeichen bestehende Passphrase, um das Erraten oder Berechnen der Passphrase zu verhindern.
    Eine Passphrase die aus "Quark" besteht, wird leicht zu erraten sein, eine Passphrase, die aus "WerQu23 Das///?Nureiella51?? wekshh_/" besteht, dagegen nicht.
    Allerdings sollte man die Passphrase auch jederzeit nutzen können, denn wenn die Passphrase verloren geht oder vergessen wird, kann ein Key nicht mehr benutzt oder zurückgezogen werden !
    Selbstverständlich ist dafür zu sorgen, dass nur der Keybesitzer allein Zugriff auf die Passphrase erhalten kann.
    Detaillierte Informationen zur Gestaltung einer sicheren Passphrase und einigen Hintergrundinformationen finden sich in der Mantra FAQ

    Nach Beendigung dieser Prozedur befindet sich der Public Key im Pubring.
    Dabei wurde nicht nur der Public Key an sich erstellt, sondern gleichzeitig dieser Public Key mit dem Secret Key unterschrieben. d.h. der Keybesitzer selbst hat seinen Public Key mit seiner eigenen Signatur versehen.
    Warum dieser Schritt automatisch vollzogen wird und die eigene Signierung des Public Keys notwendig ist, beschreibt anschaulich die Eigensignatur (Selfsign) FAQ

    Befehl zur Schlüsselerzeugung bei PGP 2.6.3:

    PGP 2.6.3> pgp -kg

  11. Key Revocation erzeugen
    Die Key Revocation dient dazu, den Public Key als zurückgezogen, bzw. ungültig zu erklären.

    Anlässe, zu denen es nötig wird, die Key Revocation an einen Keyserver zu senden und die Kommunikationspartner davon zu unterrichten, sind zum Beispiel:

    - die versehentliche Löschung des Secret Keys
    - der Diebstahl des Secret Keys und der Passphrase
    Siehe auch Web of Trust

    Warum jetzt schon ?
    Es ist sinnvoll, bereits nach der Keyerzeugung die Key Revocation für den eigenen RSA- und DSS/DH-Public Key zu erzeugen, denn im Falle eines Verlustes oder Diebstahls des Secret Keys und der Passphrase, ohne vorher die Key Revocation erzeugt zu haben, kann der Keybesitzer die Key Revocation nicht mehr herstellen und damit seinen Key nicht als zurückgezogen, bzw. ungültig auf den Keyservern markieren.
    Eine Löschung des eigenen Public Keys durch den Administrator des Keyservers ist nicht möglich.

    Auch mit einem zurückgezogenen Key ist es weiterhin möglich, mit diesem Key verschlüsselte oder signierte Daten zu entschlüsseln, bzw. zu überprüfen.
    Es ist nicht möglich, mit einem zurückgezogenen Key Daten weiter zu signieren, bzw. mit diesem Key Daten zu verschlüsseln.

    Vorgehensweise

    1. Kopien des Public und Secret Keys herstellen (zum Beispiel durch Kopieren auf Diskette)
    2. PGPkeys aufrufen
    3. den eigenen Public Key markieren
    4. 1xMTrT, Eintrag "Revoke" oder Menü "Keys", Eintrag "Revoke" anklicken
    5. Sicherheitsabfrage mit "ja" bestätigen
    6. Passphrase eingeben, danach erscheint der eigene Public Key mit einem roten Querbalken im PGPkeys Window
    7. den Key exportieren (z. B. als "RSArevoke.asc" und "DHrevoke.asc") und sicher vor unbefugtem Zugriff abspeichern
    8. die Kopien von Public und Secret Key wieder zurückspielen

    Befehl zur Erzeugung einer Key-Revocation bei PGP 2.6.3:

    PGP 2.6.3> pgp -kd User-ID des eigenen Keys

Versendung einer Revocation

RSA-Key
Sende eine E-mail an einen PGP Keyserver, z. B. pgp-public-keys@informatik.uni.hamburg.de mit dem Subject: ADD.
In den Body wird nur die Datei "RSArevoke.asc" eingefügt, die ja bereits vorliegt.

DSS/DH-Key
Suche einen der PGP 5 kompatiblen WWW-Keyserver auf, wähle die Seite aus, wo Keys an den Server versendet werden können, und füge in das Formularfenster die Datei "DHrevoke.asc" ein.

Eine andere Möglichkeit:
Der Keybesitzer ist noch im Besitz von Secret Key und Passphrase. Dann erstellt er die Revocation wie oben beschrieben und sendet sie direkt mit PGP an den Keyserver

Vorschlag
Auf die gleiche Weise kann man direkt die Public Keys als Datei "MeinPublicKey.asc" abspeichern, so steht der Public Key immer direkt zum Versand an E-mail Partner bereit.