die raven homepage
Informationen und Empfehlungen zur Schlüsselgröße
Inhalt
Vorbemerkung

Solange wie es GnuPG und PGP gibt, solange gibt es die Diskussionen um die Fragen, welche Längen bei Elgamal und RSA Verschlüsselungs- und DSA und RSA Signierkeys sinnvoll oder notwendig sind, wie groß der verwendete Hashalgorithmus sein sollte und welchen symmetrischen Algorithmus man wählt, um die maximale Sicherheit mit GnuPG verschlüsselter und signierter Daten für einen bestimmten Zeitraum bei vertretbaren Verarbeitungsgeschwindigkeiten zu erhalten.

Diese Seite sammelt zu diesem Fragenkomplex Vergleiche, Untersuchungen und Aussagen von Kryptologen, Wissenschaftlern, Programmierern und Institutionen wie dem NIST (National Institute of Standards and Technology), um dem GnuPG Anwender - bevor er seine Schlüssel mit GnuPG erstellt - Perspektiven und Informationen am die Hand zu geben.

Neben den Längen von Schlüsseln und Algorithmen sind zwei Faktoren für die Sicherheit eines GnuPG Schlüssels genauso wichtig: Die Länge und die Qualität der Passphrase und der Schutzlevel des Kontexts (notierte oder memorierte Passphrase, Speicherort des privaten Schlüssels, eingesetztes Betriebssystem und dessen Absicherung, Wahrscheinlichkeit eines direkten Angriffs oder Zugriffs etc.) in dem GnuPG angewendet wird.

P. Zimmermann, 1998
-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

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

"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 [Anm.: mit DH-Schlüsseln] 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		 <=> sym-
metrisch		 DLP
Modulus		 <=> sym-
metrisch
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
"Selecting cryptographic key sizes in commercial applications"
von Verheul und Lenstra

Empfohlene Schlüsselgrößen, 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 Berechnungszeit 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 Quantencomputer, die bis jetzt nur in hypothetischer Form existieren, das Modell hinfällig werden könnte.

Tabelle nach Lenstra und Verheul
Jahr Länge sym. Schlüssel (Bits)
(IDEA,CAST)		 <=> Länge asym. Schlüssel (Bits)
(RSA,Elgamal,DH)		 <=> Subgroup DLP Schlüssellä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
Frequently Asked Questions About Today's Cryptography?
der RSA Laboratories
Tabelle RSA FAQ 4.0
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.1
Minimal key lengths in bits for different grades
Grade 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
Tabelle
Recommended minimum symmetric security levels and RSA key sizes based on protection lifetime
aus dem RSA Laboratories Artikel "TWIRL and RSA Key Size" Mai 2003
Protection Lifetime of Data Present - 2010 Present - 2030 Present - 2031 and Beyond
Minimum symmetric security level 80 bits 112 bits 128 bits
Minimum RSA key size 1024 bits 2048 bits 3072 bits
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
415015805123165674305234451
3161858038422883778013
128 2880 1919487818858585561290806193
6944281464039294965346491767
953330250249208842371201

Nach dem IEEE würde also ein RSA Schlüssel mit 1024-bit Länge einem symmetrischen Schlüssel von 80-bit Länge entsprechen. Der DSA/DSS Hauptsignierschlüssel hätte also die Stärke eines symmetrischen Schlüssels mit einer Länge von 80-bit.
Erst Schlüssel mit einer Mindestlänge von 2880-bit würden einem symmetrischen Schlüssel mit der als (zukunfts)sicher eingestuften Länge von 128-bit entsprechen. Das IEEE erwähnt, dass 1024-bit das heute als üblich akzeptierte Minimum darstellen.

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 Schlüssels 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 Schlüssellänge erscheine bis 2007/2008 als ausreichend.

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
National Institute of Standards and Technology
Special Publication 800-57 Recommandation for Key Management
Draft vom 27.01.2003
8.8.1 Equivalent Algorithm Strengths

Cryptographic algorithms provide different strengths of security, depending on the algorithm and the key size used. In this discussion, two algorithms are considered to be of equivalent strength for the given key sizes (X and Y) if the amount of work needed to break the algorithms or determine the keys (with the given key sizes) is approximately the same using a given resource. The strength of an algorithm (sometimes called the work factor) for a given key size is traditionally described in terms of the amount of work it takes to try all keys for a symmetric algorithm with a key size of "X" that has no short cut attacks (i.e., the most efficient attack is to try all possible keys). In this case, the best attack is said to be the exhaustion attack. An algorithm that has a "Y" bit key, but whose strength is equivalent to an "X" bit key of such a symmetric algorithm is said to provide X bits of security or to provide "X-bits of strength". An algorithm that provides X bits of strength would, on average, take 2X-1T to attack, where T is the amount of time that is required to perform one encryption of a plaintext value and comparison of the result against the corresponding ciphertext value.
(...)
The recommended key size equivalencies discussed in this section are based on assessments made as of the publication of this guideline. Advances in factoring algorithms, advances in general discrete logarithm attacks, elliptic curve discrete logarithm attacks and quantum computing may affect these equivalencies in the future. New or improved attacks or technologies may be developed that leave some of the current algorithms completely insecure. In the case of quantum computing, the asymmetric techniques may no longer be secure. Periodic reviews will be performed to determine whether the stated equivalencies need to be revised (e.g., the key sizes need to be increased) or the algorithms are no longer secure.

When selecting a block cipher cryptographic algorithm (e.g., AES or TDES), the block size may also be a factor that should be considered, since the amount of security provided by several of the modes defined in [SP 800-38] is dependent on the block size.

Erklärungen zu den Spalten

Spalten 1 + 2 sollten selbsterklärend sein.

Spalte 3: provides the equivalent hash functions that are specified in FIPS180-2 for the given level of security for applications where collisions are a concern (e.g., for digital signature and MAC applications). For these applications, the maximum strength is achieved when at least b/2 bits of random data are input into the hash function, where b is the size of the output block of the hash function.

Spalte 4: provides the equivalent hash functions that are specified in FIPS180-2 for the given level of security for applications where collisions are not a concern (e.g., for the computation of random numbers in some cases). For these applications, the maximum strength is achieved when at least b bits of random data are input into the hash function, where b is the size of the output block of the hash function.

Spalte 5: indicates the size of the parameters associated with the standards that use discrete logs and finite field arithmetic (DSA as defined in [FIPS186-3] for digital signatures, and Diffie-Hellman (DH) and MQV key agreement as defined in [ANSI X9.42] and [SP 800-56]), where L is the size of the modulus p and the public key, and N is the size of q and the private key.

Spalte 6: defines the value for k (the size of the modulus n) for the RSA algorithm specified in [ANSI X9.31] and [PKCS #1] and adopted in [FIPS 186-2] for digital signatures, and specified in [ANSI X9.44] and adopted in [SP 800-56] for key establishment. The value of k is commonly considered to be the key size.

Spalte 7: defines the order of ∫ (the size of n, where n is the order of the base point G) for the discrete log algorithms using elliptic curve arithmetic that are specified for digital signatures in [ANSI X9.62] and adopted in [FIPS 186-2], and for key establishment as specified in [ANSI X9.63] and adopted in [SP 800-56]. The value of ∫ is commonly considered to be the key size.

Table 8: Equivalent strengths 15.
Bits of
Security		 Symmetric
key algs.		 Hash
functions
(collision
concerns)		 Hash
functions
(no collision
concerns)		 DSA, D-H, MQV RSA Elliptic Curves
80 2TDES SHA-1 L = 1024
N = 160		 k = 1024 ∫ = 160
112 3TDES L = 2048
N = 224		 k = 2048 ∫ = 224
128 AES-128 SHA-256 L = 3072
N = 256		 k = 3072 ∫ = 256
160 SHA-1
192 AES-192 SHA-384 L = 7680
N = 384		 k = 7680 ∫ = 384
256 AES-256 SHA-512 SHA-256 L = 15360
N = 512		 k = 15360 ∫ = 512
384 SHA-384
512 SHA-512

15 When no algorithm or key size is available to provide a given security strength, the cell is left empty.

Table 9: Recommended algorithms and minimum key sizes.
Year Sym-
metric
key algs.
(Encr.
& MAC)		 Hash
functi.
(colli-
sions)		 Hash
funct.
(no colli-
sions)		 DSA, D-H, MQV RSA Elliptic
Curves
Present -
2015
(min. of
80 bits of
strength)		 2TDES
3TDES
AES-128
AES-192
AES-256		 SHA-1
SHA-256
SHA-384
SHA-512		 SHA-1
SHA-256
SHA-384
SHA-512		 Min.:
L = 1024;
N =160		 Min.:
k=1024		 Min.:
∫=160
2016 -
2035
(min. of
112 bits of
strength)		 3TDES
AES-128
AES-192
AES-256		 SHA-256
SHA-384
SHA-512		 SHA-1
SHA-256
SHA-384
SHA-512		 Min.:
L = 2048
N = 224		 Min.:
k=2048		 Min.:
∫=224
Adi Shamirs TWINKLE und TWIRL Gerät und die Untersuchungen von E. Daniel J. Bernstein
Faktorisierungen

Vorab ein wenig grobe Mathematik [als nicht der Mathematik zugetan, bitte ich Ungenauigkeiten zu entschuldigen und mir Fehler mitzuteilen].

Die Sicherheit des RSA-Algorithmus, bzw. der RSA-Schlüssel beruht auf dem Faktorisierungsproblem.
Der öffentliche und private Schlüssel wird durch die Multiplikation zweier großer Primzahlen (p und q) und der Berechnung zweier weiterer Zahlen (e und d), die sowohl untereinander als auch mit dem Produkt der beiden Primzahlen (dem sogenannten Modulus oder n) in Beziehung stehen, errechnet. Die beidem Primzahlen nennt man auch die Primfaktoren des Produktes n. Der private Schlüssel besteht danach aus dem Zahlenpaar des Modulus n und der Zahl d (n,d), der öffentliche Schlüssel aus dem Zahlenpaar des Modulus n und der Zahl e (n,e). Wenn ein Angreifer nun aus dem Modulus n, der ja Bestandteil des öffentlichen Schlüssels (n,e) ist, die ursprünglichen Bestandteile berechnen, d. h. den Modulus n wieder in die beiden Primfaktoren p und q zerlegen kann, dann ist es ihm auch möglich mit der ebenfalls bekannten Zahl e des öffentlichen Schlüssels aus denn dann vorliegenden Zahlen p, q und e die Zahl d und damit den privaten Schlüssel zu berechnen. Diese Rechenoperation wird auch Faktorisierung oder Primfaktorzerlegung genannt.

Was sich hier so einfach anhört, stellt in der mathematischen Welt ein großes Problem dar. Einen universalen Algorithmus, mit dem man in überschaubarer Zeit jede große Zahl faktorisieren könnte, gibt es nicht.
Zur Faktorisierung bedient man sich aktuell dem sogenannten General Number Field Sieve (GNFS, "Zahlkörpersieb") Verfahren, bei dem in einem Siebungsschritt "...eine große Zahl von Quadratzahlen mit bestimmten algebraischen Eigenschaften (smoothness) gesucht, bzw. bestimmte 'Relationen gesammelt' werden" und in dem Schritt der Matrix-Reduktion, bei der "...Abhängigkeiten in einer sehr grossen Matrix (in der Praxis mehrere Millionen Zeilen und Spalten) gesucht" werden. Der Rechenaufwand für den Siebungsschritt ist dabei am größten.

Aufwand für die Faktorisierung von RSA-155 (512-Bit)

Das Problem wird auch für Laien erahnbar, wenn man sich einmal die Zahl RSA-155 (512-bit RSA Schlüssel) ansieht, die im Rahmen des Wettbewerbs zur Faktorisierung von RSA im Jahr 1999 faktorisiert wurde und die gefunden Primfaktoren:

109417386415705274218097073220403576120037329454492059909138421314763499842889 34784717997257891267332497625752899781833797076537244027146743531593354333897 =

102639592829741105772054196573991675900716567808038066803341933521790711307779 *
106603488380168454820927220360012878679207958575989291522270608237193062808643

Für die Faktorisierung wurden im Jahr 1999 sieben Monate gebraucht, daran beteiligt waren 160 175-400 MHz SGI und Sun Workstations, 8 250 MHz SGI Origin 2000 Prozessoren, 120 300-450 MHz Pentium II PCs und 4 500 MHz Digital/Compaq Computer.

Aufgrund der gegebenen und kaum zu verbessernden Verfahren und Algorithmen zur Faktorisierung konzentrierte man sich auf Möglichkeiten zur Verbesserung, bzw. Beschleunigung des Verfahrens, speziell des rechenintensiven Siebungsschrittes, die sich durch Entwicklung und Einsatz von spezieller Hardware ergeben können. Dabei spielen auch Annahmen eine Rolle, über welche Mittel an Know-How, Finanzen und Hardware Angreifer wie die NSA mit ihrem Milliarden Dollar Etat verfügen.

Links
Faktorisierung von Mersenne-Primzahl mit SNFS 2006/2007

Am 21. Mai 2007 konnten Kazumaro Aoki, Jens Franke, Thorsten Kleinjung, Arjen K. Lenstra und Dag Arne Osvik die Faktorisierung der 307-stelligen Mersenne-Primzahl 21039 -1, die – von der Größe her – einer 1024-bit RSA Zahl vergleichbar ist, bekanntgeben.

Dazu mussten zuvor an der Universität von Bonn, der Ecole Polytechnique Fédérale de Lausanne und beim japanischen Konzern NTT elf Monate lang Berechnungen auf einzelnen Mehrkern-PCs im Leerlauf und Computer-Clustern durchgeführt werden, um mit dem Special Number Field Sieve (SNFS) Verfahren neben dem bereits bekannten 7-stelligen Faktor 5080711 die beiden anderen Primfaktoren mit 80 und 227 Stellen zu finden.

Das SNFS Verfahren kann im Gegensatz zum GNFS nur auf Primzahlen angelegt werden, die eine spezielle mathematische Form aufweisen, deren Primfaktoren relativ klein sind und unterschiedliche Größen aufweisen können, wie es bei der untersuchten Mersenne-Primzahl der Fall ist. Dadurch kommt man mit SNFS schneller zu Resultaten, es kann aber nicht zur Faktorisierung von RSA-Zahlen mit zwei großen Primfaktoren angewendet werden.

Dennoch haben Fortschritte bei der Weiterentwicklung von Techniken und Methoden für SNFS auch Auswirkungen auf GNFS, das vom SNFS abgeleitet wurde und damit auch auf die Faktorisierung von RSA-Zahlen.

Zu den Auswirkungen auf die Sicherheit bzw. Faktorisierung von RSA "Schlüsseln" mit 1024-bit schreiben die Wissenschafler in A kilobit special number field sieve factorization:

Factoring an RSA modulus of comparable size would be several orders of magnitude harder. Even factoring a 768-bit RSA modulus would be substantially harder than a 1024-bit 'special' one. Simply put, this is because RSA moduli require usage of the general number field sieve algorithm (NFS), which runs much slower than the SNFS on numbers of comparable size. Nevertheless, the aspects of our effort where we made most progress apply equally well to NFS as they apply to SNFS. They will therefore also have an effect on the assessment of feasibility of NFS-based factorizations such as those of RSA moduli.

Regular RSA moduli were ruled out, since in general they will not have the special form required for SNFS. Special form numbers, however, are not especially concocted to have two factors of approximately the same size, and have factors of a priori unknown sizes.

It must be stressed, and was already pointed out in the introduction, that our work does not imply that 1024-bit RSA moduli can now be factored by a comparable effort. Quite on the contrary, according to all information available to us, and as far as we know to anyone else in the open community, factoring a 1024-bit RSA modulus is still beyond the capabilities of anyone with resources a few orders of magnitude larger than ours. We estimate that the effort we spent would suffice to factor a 700-bit RSA modulus.

Until our work there were two major factoring milestones on our way to 1024-bit RSA moduli. One of these milestones, a kilobit SNFS factorization, is now behind us. The next one, and the only remaining major milestone before we would face 1024-bit RSA moduli, is the factorization of a 768-bit RSA modulus. We have no doubt that 768-bit RSA moduli are firmly within our reach, both as far as sieving effort and size of the matrix problem are concerned. If it would indeed be reached, as is now safe to predict, factoring a 1024-bit RSA modulus would begin to dawn on the horizon of what is practically possible for the open community.
Links
TWINKLE

Ausgehend von dieser Herangehensweise beschrieb Adi Shamir (das 'S' in RSA) 1999 das (theoretische) TWINKLE (Abkürzung für "The Weizmann Institute Key Locating Engine" - Adi Shamir lehrt und forscht am Weizmann Institut in Israel) Gerät, das aus einem LED-Array besteht, das mit einem Gallium-Arsenid (GaA) Chip-Wafer verbunden ist, mit einer sehr hohen Taktrate arbeitet und eine hohe Parallelisierung von Rechenschritten bietet, wodurch der Siebungsschritt drastisch beschleunigt würde. Allerdings sind GaA Chip-Wafer nur in kleinen Mengen herstellbar und setzen zur Funktionsfähigkeit absolute Fehlerfreiheit des Wafers voraus, d. h. ein TWINKLE Gerät wäre mit sehr hohen Kosten verbunden.

Bernstein

Im Jahr 2001 beschrieb E. Daniel J. Bernstein in seinem Papier E. Daniel J. Bernstein: Circuits for integer factorisation den Versuch, sich ebenfalls mit Hilfe von Spezialhardware, die auf den Einsatz von Spezialchips und der Parallelisierung von Rechenoperationen baut, zahlentheoretischer Probleme zu nähern, die - ähnlich dem TWINKLE Gerät - zu einer Verkürzung der Rechenzeit für die Faktorisierung von Zahlen um 2/3, vor allem für den Schritt der Matrix-Reduktion, führen würde. Daneben ergaben sich aufgrund von Bernsteins Untersuchungen Optimierungen für die bereits verwendeten Algorithmen.
Eine einfache Erläuterung des Papiers findet sich im Artikel Spezialhardware bedroht möglicherweise RSA-Sicherheit. Eine Betrachtung zu Bersteins Untersuchungen liefert der RSA Security Artikel Has the RSA algorithm been compromised as a result of Bernstein's Paper?
In Kryptografiekreisen entspannte sich eine Debatte über die Auswirkungen auf die Sicherheit heutiger Public-Key Kryptografie und es wurde zum Teil die Empfehlung ausgesprochen, RSA Schlüssel sollten mindestens 2048-Bit groß 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 und ging noch einmal im Artikel "Is 1024 Bits Enough?" des Crypto-Gram Newsletters vom 15.04.02 auf die Debatte ein:

"...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 Individual Corporation Government
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..."
TWIRL

Der "Hardware" Ansatz von Bernstein wurde u. a. auch von den Kryptologen A. Lenstra und A. Shamir im Jahr 2002 analysiert und von den Kryptologen Dr. Willi Geiselmann und Dr. Rainer Steinwandt in ihrem Papier "A dedicated Sieving Hardware" 2003 aufgegriffen.

Im Januar 2003 präsentierte Adi Shamir zusammen mit Eran Tromer Überlegungen zum (theoretischen) TWIRL (Abkürzung für "The Weizmann Institute Relation Locator") Gerät, die Ideen von Geiselmann und Steinwandt aufnahmen und verbesserten. Mit dem TWIRL Gerät als Überarbeitung des TWINKLE Designs von 1999, beschreiben Shamir und Tromer die Hardwareausstattung von Spezialcomputern, die ebenfalls über die kostengünstige Verwendung aktueller Hardwarebausteine, Paralellisierung von Rechenoperationen, besserer Ausnutzung von Speicherbausteinen und Speicherprozessen und optimierten Algorithmen zu einer drastischen Reduzierung des Rechen- und Kostenaufwandes für den Siebungsschritt und damit für die Faktorisierung von RSA-Moduli führen würden. Über die Bildung von TWIRL-Clustern, also dem parallelen Einsatz vieler TWIRL Geräte ließen sich bei höherem Einsatz an Geldern und Hardware die positiven Berechnungs-Effekte noch vervielfachen.

Dabei wird beim TWIRL Gerät nicht mehr von opto-elektronischen Komponenten auf GaA-Basis ausgegangen wie beim TWINKLE Gerät, sondern von Chips auf Silikon-Wafern, die in der sogenannten VLSI ("Very Large Scale Integration" Technologie gefertigt werden.
Für die Berechnung von 1024-Bit großen Schlüsseln würden 1423 mm2 große Cips ausreichen, wodurch mehr Chips pro Wafer untergebracht werden können. Weitere Komponenten sind hintereinandergeschaltete Digital-Addierer, DRAM mit einer Strukturgröße von 0.13µ, die heutzutage produziert werden können, Multiplexer und kleine Prozessoren.
Von einigen Kryptologen, Mathematikern und Informatikern wird das Hardwaredesign des TWIRL Geräts als realisierbar betrachtet.

Geht man von der Realisierbarkeit des theoretischen TWIRL Geräts aus, wären TWIRL-basierte Computer bei einem Kostenaufwand von 10 bis 50 Millionen Euro für die Hardware in der Lage, eine 1024-Bit Zahl in einem Jahr zu faktorisieren. Bei einem parallelen Einsatz mehrerer TWIRL Geräte und größerem Finazeinsatz würde sich dementsprechend der Zeitaufwand verringern lassen.

Bei der Betrachtung TWIRL basierter Computer muss man außerdem miteinbeziehen, dass z. B. für den Geheimdienst NSA der Etat auf mehrere Milliarden US$ geschätzt wird und die NSA selbst oder mit Auftragsvergaben an andere Firmen Hardware entwickelt, die dem "Markt" noch gar nicht bekannt ist.

Links

Die Vorstellung des Faktorisierungsproblems basieren auf der RSA FAQ 4.1 und des TWINKLE / TWIRL Geräts auf den Veröffentlichungen von Rüdiger Weis, Stefan Lucks und Andreas Bogk.

Elliptic Curve Cryptography (ECC)
Der NSA - CERTICOM Deal

Eine gute Möglichkeit zur Beurteilung des Anspruchs, den der U.S. Geheimdienst NSA an einzusetzende Kryptografie stellt, bietet das Geschäft, das die NSA im Oktober 2003 mit dem Unternehmen Certicom abschloß. Dieses Geschäft erregte deshalb große Aufmerksamkeit, weil die NSA selbst eine große Kryptografieabteilung unterhält und kryptographische Verfahren und Algorithmen im eigenen Haus entwickelt. Obgleich man hinzufügen muss, dass Certicom bereits in der Vergangenheit öfters im Auftrag der NSA an geheimen Projekten beteiligt war.
Nach einer Aussage des Certicom Präsidenten und CEO, Ian McKinnon, besitzt die NSA Lizenzen für 130 Certicom Patente.

Mit dem Deal erhielt die NSA für 25 Millionen US$ eine Lizenz für das MQV (Menezes-Qu-Vanstone, ein Schlüsseleinigungsverfahren zur Erzeugung eines gemeinsamen Sitzungsschlüssels) basierte Elliptic Curve Cryptography (ECC) System, das Certicom entwickelt und patentiert hatte. Die Lizenz umfasst Rechte an 14 Patentfamilien, die 26 Patente von Certicom beinhalten.
ECC sind Public-Key Kryptoalgorithmen, die aber, im Gegensatz zu RSA, Schlüssel von großer Sicherheit bei wesentlich kürzeren Schlüssellängen hervorbringen und als Zukunft der Public-Key Kryptografie betrachtet werden. Der Anwendungsbereich, den die Lizenz festlegt, bezieht sich auf Implementierungen durch die NSA, wo ECC größer als GF(2256) ist, d. h. auf arithemtische Verfahren mit Primzahlen größer 2256.

Wie u. a. das Magazin eWeek berichtete, will die NSA (und damit andere U.S. Geheimdienste) 512-bit ECC Schlüssel mit dem Certicom ECC Verfahren nutzen, um als Top-Secret eingestufte Dokumente zu schützen und Daten sicher zu übertragen. Ein 512-bit ECC Schlüssel entspricht, wie aus anderen Darstellungen auf dieser Seite hervorgeht, einem 15360-bit langen RSA- oder 256-bit langen AES Schlüssel.

Auf der 14. RSA Konferenz in San Francisco stellte Daniel G. Wolf, Leiter des Direktoriums für die Absicherung von Informationssystemen (IAD) der NSA, am 16.02.2005 die neue Strategie der NSA zur Absicherung der Kommunikation der U. S. Regierungsbehörden vor, die zum U. S. Standard der kryptografischen Absicherung für das nächste Jahrzehnt wird. U. a. dienen die ECC Algorithmen der Verschlüsselung der Kommunikation und des Datentransfers innerhalb des globalen Informationsnetzwerkes Global Information Grid (GIG) des U. S. Verteidigungsministeriums.

Die Strategie sieht vor, dass für die Absicherung nur noch bestimmte Algorithmen benutzt werden, die in einer als Suite B genannten Klasse zusammengefasst sind. Dazu gehören als Public-Key Algorithmen Elliptic Curve Menezes-Qu-Vanstone (ECMQV) und Elliptic Curve Diffie-Hellman (ECDH), Elliptic Curve Digital Signature Algorithm (ECDSA) für Signaturen, AES-128/256 für die symmetrischen Schlüssel und SHA-256/384 für das Hashing.
Die ECC Algorithmen der Suite B basieren auf den Certicom Entwicklungen.

Der Certicom Gründer Dr. Scott Vanstone deutete in der Pressemitteilung NSA Names ECC as the Exclusive Technology for Key Agreement and Digital Signature Standards for the U.S. Government zur Ankündigung der neuen NSA Kryptostrategie an, dass ECC in 75% der 1,3 Millionen Kryptogeräte, die zum Invetar der U. S. Behörden gehören, eingesetzt würden, die im nächsten Jahrzehnt im Zuge des U. S. Kryptografie Modernisierungsprogramms (CMP) ausgetauscht werden.

Im OpenPGP Standard ist ECC bereits für Public-Key Algorithmen reserviert, bis jetzt implementieren aber weder GnuPG noch PGP ECC. Der Einsatz von ECC mit GnuPG wird im Rahmen des ECCGnuPG Projekts erprobt. Zur Standardisierung von ECC für OpenPGP gibt es den IETF Internet Draft ECC in OpenPGP.

Links
ECRYPT
Yearly Report on Algorithms and Key Lengths (2004)
revision 1.1, 17 March 2005

Das ECRYPT (Europäisches Kompetenznetzwerk für Kryptografie) ist ein Programm der Europäischen Kommission, das von 2004 - 2008 läuft und an dem zahlreiche technische Universitäten und IT-Unternehmen aus ganz Europa beteiligt sind. Das Ziel des Programms besteht in der Intensivierung der Zusammenarbeit europäischer Wissenschaftler auf dem Gebiet der Kryptografie und des "Digital Watermarking".

In den ENCRYPT Jahresberichten wird eine ähnliche aber ausführlichere Abschätzung unter Einbeziehung aktueller Entwicklungen im Bereich der theoretischen und praktisch-technischen Kryptoanalyse vorgenommen wie auf dieser Seite. Einschätzungen zur Stärke und Sicherheit symmetrischer und Public-Key Schlüssel sind ebenfalls Bestandteil der Jahresberichte:

Tabelle 7.1: Minimale symmetrische Schlüsselgröße in Bits für verschiedene Angreifertypen
Angreifer Budget Hardware Min. Sicherheit
"Hacker" 0
< $400
0		 PC
PC(s)/FPGA
"Malware"		 51
56
59
Kleine Organisation $10000 PC(s)/FPGA 62
Mittelgroße Organisation $300000 FPGA/ASIC 66
Große Organisation $10000000 FPGA/ASIC 76
Geheimdienst $300000000 ASIC 81

Die minimale Sicherheit bezieht sich dabei auf die Zeitdauer, die eine Organisation mit entsprechenden finanziellen und technischen Ressourcen benötigt, um einen symmetrischen Schlüssel mit bestimmter Länge zu berechnen. In dem ENCRYPT Bericht auf Seite 25 heißt es dazu, dass im Jahr 2004 bei einem finanziellen Aufwand, den ein Geheimdienst betreibt, ein 81-bit Schlüssel in 73 Tagen zu berechnen wäre.

FPGAs und ASICs sind programmierbare Schaltkreise bzw. kunden- und anwendungsspezifische, integrierte Schaltungen. FPGA steht für Field Programmable Gate Array und ASIC für Application Specific Integrated Circuits.

Tabelle 7.2: Gleichwertige Schlüsselgrößen
Sicherheit (bits) RSA DLOG
field size		 DLOG
subfield		 EC
48
56
64
80
112
128
160
192
256		 480
640
816
1248
2432
3248
5312
7936
15424		 480
640
816
1248
2432
3248
5312
7936
15424		 96
112
128
160
224
256
320
384
512		 96
112
128
160
224
256
320
384
512

Die Sicherheit (bits) bezieht sich auf die Größen symmetrischer Schlüssel, DLOG bezieht sich auf Schlüssel, deren Algorithmen auf dem Discrete Logarithm Problem (DLP) beruhen wie z. B. die Elgamal Schlüssel bei GnuPG. EC steht für Schlüssel, die auf Elliptic Curve Cryptography (ECC) Algorithmen beruhen.

Tabelle 7.4: Sicherheitsniveaus
(bezogen auf die Größen symmetrischer Schlüssel).
Sicherheits-
Niveau		 Sicherheit (bits) Schutz Kommentar
1 32 gegen Angriffe von Individuen in "Realzeit" Only acceptable for auth. tag size
2 64 Sehr kurzzeitiger Schutz gegen kleine Organisationen Sollte nicht bei neuen Systemen zur Wahrung vertraulicher Informationen benutzt werden
3 72 Kurzzeitiger Schutz gegen mittelgroße Organisationen, mittelfristiger Schutz gegen kleine Organisationen
4 80 Sehr kurzzeitiger Schutz gegen Geheimdienste, langzeitiger Schutz gegen alle kleinen Organisationen Kleinstes, generelles Sicherheitsniveau, < 5 Jahre
5 112 Mittelfristiger Schutz
6 128 Langzeitschutz Gut, generelle, applikationsunabhängige Empfehlung, ≈ 30 Jahre
7 256 "Absehbare Zukunft" Guter Schutz gegen Quantencomputer

Der Bericht merkt hierzu an, dass es z. B. angesichts neuer oder zukünftiger Verfahren zur Kryptoanalsye, der Abhängigkeit der verwendeten Mthoden und von Entwicklungen im Hardwarebereich natürlich schwierig ist, allgemein gültige Empfehlungen auszusprechen.

Zum Gefährdungspotential und der Realisierbarkeit von Quantencomputern heißt es in dem Bericht auf Seite 31:

Both of the fundamental intractability assumptions on integer factoring and discrete logarithms break down if a (large) quantum computer could be built as demonstrated by Shor, [104]. For instance, integers N can be factored in only O(log3 N) "steps" on such a machine.
We are, however, quite far from realizing such a device. In [113], an experimental result for factoring the "toy" number N = 15 is reported with a run-time of just under one second.

For symmetric cryptography, the effect would also be dramatic, though not devastating.
By the generic search algorithm due to Grover, [38], key-sizes are in effect cut in half. Also this algorithm has been implemented on small toy examples, [22].

The recommendations in this report assumes (large) quantum computers do not become a reality in the near future.

[104] P. W. Shor, Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer, SIAM J. Sci. Statist. Comput., 26 (1997).
[113] L. M. K. Vandersypen, M. Steffen, G. Breyta, C. S. Yannoni, M. H. Sherwood, and I. L. Chuang, Experimental realization of Shor's quantum factoring algorithm using nuclear magnetic resonance, Nature 414 (2001), 883{887.
[38] L. K. Grover, A fast quantum mechanical algorithm for database search, Proceedings of the 28th ACM STOC, pp. 212-219, 1996.
[22] I. L. Chuang, N. Gershenfeld, and M. Kubinec, Experimental Implementation of Fast Quantum Searching, Physical Review Letters, 80:15 (1998), 3408-3411.
Die Größe des Hashalgorithmus SHA

Das NIST hatte im August 2002 den Secure Hash Signature (SHS) Standard FIPS-180-2 veröffentlicht, der neben SHA-1 die zusätzlichen Hashalgorithmen SHA-256, SHA-384 und SHA-512 spezifiziert. Algorithmen, die größere Message Digests erzeugen, sind Voraussetzung für das sichere Signieren von Daten bestimmter Größe und der Verwendung größerer DSA und RSA Signierschlüssel, bzw. muss die Größe des Hashalgorithmus und des Message Digest der Größe eines Schlüssels, der mit einem Public-Key Algorithmus erstellt wurde und die vergleichbare Sicherheit des Schlüssels eines symmetrischen Algorithmus bietet, entsprechen.

Das NIST schreibt dazu in der Einführung zu FIPS-180-2:

"The four algorithms differ most significantly in the number of bits of security that are provided for the data being hashed - this is directly related to the message digest length. When a secure hash algorithm is used in conjunction with another algorithm, there may be requirements specified elsewhere that require the use of a secure hash algorithm with a certain number of bits of security. For example, if a message is being signed with a digital signature algorithm that provides 128 bits of security, then that signature algorithm may require the use of a secure hash algorithm that also provides 128 bits of security (e.g., SHA-256). Additionally, the four algorithms differ in terms of the size of the blocks and words of data that are used during hashing. Figure 1 presents the basic properties of all four secure hash algorithms."
Figure 1: Secure Hash Algorithm Properties
Algorithm Message Size (bits) Block Size (bits) Word Size (bits) Message Digest Size (bits) Security2 (bits)
SHA-1 < 264 512 32 160 80
SHA-224* < 264 512 32 224 112
SHA-256 < 264 512 32 256 128
SHA-384 < 2128 1024 64 384 192
SHA-512 < 2128 1024 64 512 256

2 In this context, security refers to the fact that a birthday attack [HAC] on a message digest of size n produces a collision with a workfactor of approximately 2n/2.

* vom NIST in einer Veränderungsmitteilung zum FIPS-180-2 vom 01.12.2003 angekündigt.

Im Februar 2005 veröffentlichten die chinesischen Wissenschaftler Xiaoyun Wang, Yiqun Lisa Yin und Hongbo Yu ihre Forschungsergebnisse zu Angriffen auf den SHA-1 Hashalgorithmus im Dokument Collision Search Attacks on SHA1. Im August 2005 ergänzt durch Finding Collisions in the Full SHA-1 - Collision Search Attacks on SHA1.

Den Dokumenten zufolge ist es der Forschergruppe gelungen, ein Verfahren zu entwicklen, mit dem man SHA-1 Kollisionen - also zwei Daten mit demselben SHA-1 Hashwert - mit 269 statt 280 Operationen finden kann. Damit gilt der SHA-1 Algorithmus als geschwächt, der Rechenaufwand zur Erzeugung von Kollisionen ist aber immer noch enorm. Unter Kryptologen rechnet man jedoch damit, dass sich aus dem Verfahren der chinesischen Forschergruppe weitere, optimierte Verfahren ergeben werden, die in der nächsten Zeit den Rechenaufwand zur Erzeugung von Kollisionen weiter reduzieren werden, so daß SHA-1 mittelfristig als gebrochen eingestuft werden muss.

Im März hatte William Burr, Manager der Security Technology Group beim U. S. National Institute of Standards and Technology (NIST) in NIST brief comment on recent cryptanalytic attacks on SHA 1 and NIST plans angekündigt, die Nutzung von SHA-1 als Hashalgorithmus bis 2010 zu beenden und durch SHA-256 bis SHA-512 zu ersetzen. Außerdem hatte er in Interviews dazu geraten, die Nutzung von MD5 als Hashalgorithmus ganz einzustellen.

In der NIST Veröffentlichung SP-800-57 Recommendation for Key Management – Part 1: General ist dann auch auf Seite 64 in einer Fußnote zu lesen:

SHA-1 has recently been demonstrated to provide less than 80 bits of security for digital signatures; at the publication of this Recommendation, the security strength against collisions is assessed at 69 bits. The use of SHA-1 is not recommended for the generation of digital signatures in new systems; new systems should use one of the larger hash functions. For the present time, SHA-1 is included here to reflect its widespread use in existing systems, for which the reduced security strength may not be of great concern when only 80-bits of security are required.

Im Oktober 2008 wurde FIPS 186-3 vom NIST und dem US-Handelsministerium angenommen, der für den DSA drei Schlüssellängen mit korrespondierenden Hashgrößen definiert:

DSA Schlüssellängen und Hashgrößen in Bits nach FIPS-186-3
Schlüssel Hash
1024 160
2048 224
2048 256
3072 256

Für RSA Hauptsignierschlüssel definiert FIPS-186-3 folgende Schlüssellängen mit Hashgrößen (nach SP 800-57) und Hashalgorithmen nach FIPS 186-2:

Schlüssel Hash
1024 160 (SHA-1)
2048 224 (SHA-224)
3072 256 (SHA-256)

Im August 2005 ließ die chinesische Forschergruppe um Prof. Xiaoyun Wang durch Adi Shamir auf der Crypto 2005 Konferenz mitteilen (denn die chinesichen Wissenschaftler hatten von der U. S. Regierung kein Visa erhalten), man habe durch Optimierung der Verfahren gegen SHA-1 den Aufwand zur Erzeugung von Kollisionen auf 263 Aufrufe senken können.

Das NIST hatte Anfang November 2007 wie für den AES den offenen Wettbewerb für den Nachfolger "SHA-3" der jetzigen SHA Algorithmen ausgeschrieben, der laut Zeitplan bis 2012 festgestellt werden soll. Bis dahin hatte das NIST im März 2006 für Bundesbehörden die Richtlinie ausgegeben, SHA-1 so schnell wie möglich durch die SHA-2 Hashfunktionen zu ersetzen und spätestens ab 2010 mit ein paar Ausnahmen für SHA-1 ausschließlich SHA-2 Hashfunktionen zu nutzen.

Links

Auf der Webseite Cryptographic Key Length Recommendation von BlueKrypt werden nach Auswahl der "Methode" alle veröffentlichten Studien und ihre Empfehlungen zur Schlüssellänge im Überblick dargestellt.

Methodenauswahl
Eigenes Fazit

Wenn man Schlüssel zur Verschlüsselung und Signierung mit maximaler Stärke/Sicherheit einsetzen will, die, gemessen an den Informationen, die auf dieser Seite stehen, den Vermutungen über die technologischen Kapazitäten eines Geheimdienstes wie der NSA (eine Annahme geht von einem technischen Vorsprung von ca. 10 Jahren aus), den kryptografischen Anforderungen, die von ihm formuliert werden und den Möglichkeiten, die durch die OpenPGP Spezifikation definiert werden, zukunftssicher für die nächsten Jahrzente sein sollen:

  • Beträgt die Mindestgröße von Verschlüsselungs- und Signierschlüsseln um die 3100-bit.

    Bei GnuPG beträgt die Länge von RSA und Elgamal Unterschlüsseln zur Verschlüsselung maximal 4096-bit. DSA Hauptsignierschlüssel sind seit dem Standard FIPS 186-3 und GnuPG 1.4.4 bis zu einer Länge von 3072-bit möglich, bei RSA Hauptsignierschlüsseln beträgt die maximale Länge 4096-bit.
  • Beträgt die Mindestgröße des Schlüssels eines symmetrischen Kryptoalgorithmus 128-bit.

    Bei GnuPG kann auch Twofish, AES-256 mit 256-bit und AES-192 mit 192-bit verwendet werden.
  • Beträgt die Mindestgröße des verwendeten Hashalgorithmus 256-bit.

    GnuPG ab Version 1.4.4 bietet SHA224 bis SHA512. Mit dem neuen FIPS 186-3 Standard und GnuPG 1.4.4 sind auch bei DSA Schlüsseln größere Hashfunktionen als SHA-1 und RIPE-MD/160 möglich.

Die Kombination, die den Darstellungen nach maximale Sicherheit bei größten Performanceeinbußen bieten würde, wären RSA / Elgamal Schlüssel mit 15360-bit oder ECC-512, SHA512, AES-256 / Twofish. Keine GnuPG Version bietet diese Kombination an.

Abseits diese Fazits wird von einem großen Teil der Kryptografiexperten das Minimum, bestehend aus Hautpt- und Unterschlüssel mit einer Länge von 1024- bis 2048-bit, symmetrische Schlüssel mit 128-bit und SHA-1, als hinreichend sicher für den täglichen Gebrauch eingeschätzt.

[ GnuPG Startseite | Top ]