PGP - 8192 bit Schlüssel

Du suchst ein Programm für einen bestimmten Zweck?
Antworten
Aaron
Beiträge: 29
Registriert: 25.12.2003 12:12:16
Kontaktdaten:

PGP - 8192 bit Schlüssel

Beitrag von Aaron » 07.01.2004 19:46:15

Hallo,

auf dem 20C3 lief vor kurzenen ein Vortrag über die Sicherheit von 1024bit RSA Schlüsseln. Diese Schlüssel sind nun langsam veraltet und können jetzt schon in aktzeptablen Zeiten mit Heim PC geknackt werden.(bzw. Spezial Hardware -> nich Teuere (optisches Rechnen))
Da ich im moment in meiner Sicherheitsphase bin und sowieso äußerst sensible Daten habe die unbedingt verschlüsselt werden müssen wollte ich mir eben ein Keyring erstellen und erschreckt festgestellt das ich mit

Code: Alles auswählen

pgp -kg
nur 4096 bit Keys erstellen kann.

FRAGE:

Wie kann ich Keyrings mit einer deutlich höheren Sicherheit erstellen?
Ich dachte da so an 8192bit Keys! Oder deutlich größere!

Benutzeravatar
pdreker
Beiträge: 8298
Registriert: 29.07.2002 21:53:30
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Nürnberg

Beitrag von pdreker » 07.01.2004 20:48:12

Das ist nicht nötig.. Ich denke Du sitzt einem Denkfehler auf... Ein 2048 Bit Schlüssel ist nicht doppelt so schwer zu knacken, wie ein 1024 Schlüssel, sondern 2^1024 mal so sicher. Nur zum Vergleich: wenn man einen 1024 Bit Schlüssel in einer Sekunde knacken kann, dann braucht man für einen 2048 Bit Schlüssel ca. 5,7e300 Jahre. Das Universum ist schätzungsweise 15e9 Jahre alt. Für einen 4096 Bit Schlüssel bräuchte man ca. 3,2e600 Jahre. Für den 2048 Bit Schlüssel bräuchte man also ca. (ganz grob) 10^290 (Das ist eine Eins mit 290 Nullen) 'mal so lange, wie das Universum existiert...

Patrick (Warum kann man hier eigentlich kein Superskript einstellen?)
Definitely not a bot...
Jabber: pdreker@debianforum.de

Aaron
Beiträge: 29
Registriert: 25.12.2003 12:12:16
Kontaktdaten:

Beitrag von Aaron » 07.01.2004 21:37:08

Nein das war mir klar aber das ist halt idealismus

tylerD
Beiträge: 4068
Registriert: 10.07.2002 17:34:13
Wohnort: Halle/Saale
Kontaktdaten:

Beitrag von tylerD » 07.01.2004 21:43:59

Hu, was für sensible Daten hast du denn? Und Sicherheit hängt nicht nur von der Schlüsselstärke ab. Ist der Rest in deinem Rechner auch so abgeschottet? Dann dürftest du hier ja gar nicht posten können, weil ins Internet gehen dürfte dann ein zu großes Sicherheitsrisiko sein.

cu

Muldini
Beiträge: 61
Registriert: 26.10.2003 02:18:17
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Muldini » 07.01.2004 21:45:12

pdreker hat geschrieben:Das ist nicht nötig.. Ich denke Du sitzt einem Denkfehler auf... Ein 2048 Bit Schlüssel ist nicht doppelt so schwer zu knacken, wie ein 1024 Schlüssel, sondern 2^1024 mal so sicher. Nur zum Vergleich: wenn man einen 1024 Bit Schlüssel in einer Sekunde knacken kann, dann braucht man für einen 2048 Bit Schlüssel ca. 5,7e300 Jahre. Das Universum ist schätzungsweise 15e9 Jahre alt. Für einen 4096 Bit Schlüssel bräuchte man ca. 3,2e600 Jahre. Für den 2048 Bit Schlüssel bräuchte man also ca. (ganz grob) 10^290 (Das ist eine Eins mit 290 Nullen) 'mal so lange, wie das Universum existiert...

Patrick (Warum kann man hier eigentlich kein Superskript einstellen?)
Alles klar *gg

Nur mal sone Frage (ich kenn mich ehrlich gesagt überhaupt nicht damit aus !) wie lange bräuchte man wirklich um einen 1024 bit Schlüssel zu entschlüsseln ? Gesetz dem Fall man hat das Passwort (Falls das darüber funktioniert ...) nicht.

Mfg
Muldini

P.S. falls wer gute Links zum Thema PGP hat, immer schön posten *gg ;)

Benutzeravatar
bollin
Beiträge: 482
Registriert: 01.11.2003 23:31:33
Wohnort: Berlin
Kontaktdaten:

Re: PGP - 8192 bit Schlüssel

Beitrag von bollin » 07.01.2004 22:38:14

Aaron hat geschrieben:Diese Schlüssel sind nun langsam veraltet und können jetzt schon in aktzeptablen Zeiten mit Heim PC geknackt werden.(bzw. Spezial Hardware -> nich Teuere (optisches Rechnen))
War bisher nicht von 10 Mio. Euro die Rede und das ganze ist 'nur' eine Vermutung? Die Vermutung lautet, dass man mit 10 Mio. Euro einen solchen Schlüssel in einem Jahr knacken kann.
Wie kann ich Keyrings mit einer deutlich höheren Sicherheit erstellen?
Ich dachte da so an 8192bit Keys! Oder deutlich größere!
2048 dürfte wohl erstmal reichen.

Torsten

LittleBoy
Beiträge: 718
Registriert: 30.04.2002 14:32:26

Beitrag von LittleBoy » 08.01.2004 09:46:19

Die Schlüssellänge ist idR völlig wurscht - ein Angreifer greift eigentlich niemals den eigentlichen Schlüssel an.

Wenn man trotzdem eine Aussage über die Sicherheit von Schlüssellängen machen möchte, so muss man den dahinterliegenden Algorithmus miteinbeziehen: Ein 1024bit Schlüssel für RSA ist wesentlich schneller "geknackt" als ein 1024bit Schlüssel für ein symmetrisches Verfahren - schlicht deshalb, weil man bei RSA eben nicht stupide alle Schlüssel durchprobieren muss, sondern die gesamte Operation ohne einen Zugriff auf das Verschlüsselungssystem erledigt.

Um es im Falle RSA mal anzureissen: Hier geht es darum, eine Zahl der Größenordnung Keylänge in ihre Primfaktoren zu zerlegen. Bislang wurde dafür kein effizienter Algorithmus gefunden - aber mit dem deterministischen Primzahltest und der Methode der elliptischen Kurven ist man in den letzten fünf Jahren weiter gekommen als sämtliche Mathematiker in den tausenden Jahren vorher. Das Problem selber ist schon seit dem antiken Griechenland "aktuell". Sollte also in Zukunft zufällig ein Algorithmus gefunden werden, der diese Aufgabe schnell erledigt, dann bringt auch ein 8192bit Schlüssel wenig bis garnichts. Davon abgesehen steht auch noch der Beweis aus, dass RSA mindestens so sicher ist, wie das Problem der Primfaktorzerlegung. Möglicherweise findet jemand noch einen Weg, RSA zu brechen, ohne die Primfaktorzerlegung zu lösen.
Auch in diesem Fall bringt der grosse Key gar nichts.
Gehen wir jetzt mal wirklich davon aus, jemand greift den Key auf eine bislang bekannte Methode an - da wird er ewig rechnen: Bislang ist der 576bit RSA-Schlüssel geknackt. RSA Labs. bietet ja ein fröhliches Wetthacken auf die Schlüssel an - und wenn jemand in der Lage ist, einen 1024bit Schlüssel in vertretbarem Aufwand zu knacken, dann gibt es zwei Möglichkeiten: Entweder ich verkaufe mein Wissen an kriminelle, oder ich räume als erstes mal die Preise von knapp $250000 ab. Aber mit Sicherheit schreibe ich kein Paper, indem ich meine Erkenntnisse ohne Gegenleistung bekannt mache...
Somit bewzeifle ich sehr stark die Glaubwürdigkeit dieses Papers, auch wenn ich es noch nicht gelesen habe...

Aber die realen Angriffe erfolgen auf einer anderen Ebene: Es geht schlicht darum, den Schlüssel in die Finger zu kriegen. Ein 1024bit Schlüssel kann sich kein Mensch merken - also liegt der im Homeverzeichnis eines jeden Benutzers. Das wiederum kann jeder mit dem root-PW lesen, und das wiederum hat wohl kaum eine Länge von 1024bit. Ergo: Ich suche mir einen Zugang zur Maschine (ggf. durch ein hübschen Exploit), danach kommt der passende root-Exploit, und dann lese ich mir fröhlich den PGP/GPG-Key von der Disk. Vielleicht installiere ich noch einen PW-Sniffer, der mir dann die Passphrase gleich aussnifft - aber die meisten User haben eh die Passphrase leer gesetzt.

Ein ebenfalls schöner Angriff ist, nach Fehlern in der Implementation der Protokolle zu suchen - kürzlich sind ja erst die Fehler im ElGamal-Protokoll aufgetaucht. Ähnliche Fehler können sich natürlich auch in anderen Implementationen und / oder Verfahren finden.

Wer also wirklich paranoid ist, der denkt nicht über eine höhere Schlüssellänge nach, sondern erstmal darüber, wie er seinen Schlüssel in Sicherheit bringen kann und eine sichere Implementation des ganzen findet. Spätestens dann kommt "trusted Computing" ins Spiel und die Diskussion wird sehr emotional ;) Eine andere Lösung sind Krypto-Smartcards, die den Schlüssel automatisch erzeugen, nicht rausgeben und die Verschlüsselung auch übernehmen. Da wiederum gibts Probleme mit der recht beschränkten Datenübertragung - weshalb ein deutscher Vorschlag in die Richtung geht, die beiden ungenutzten PINs auf den Karten für einen USB mit höherer Geschwindigkeit zu nutzen. Letztlich scheitert man aber auch schon an der doch eher bescheidenen Softwareunterstützung für solche Karten unter Linux...

Benutzeravatar
Hackmeck
Beiträge: 1397
Registriert: 22.10.2002 19:14:02
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Düsseldorf
Kontaktdaten:

Re: PGP - 8192 bit Schlüssel

Beitrag von Hackmeck » 08.01.2004 09:56:55

Aaron hat geschrieben:auf dem 20C3 lief vor kurzenen ein Vortrag über die Sicherheit von 1024bit RSA Schlüsseln. Diese Schlüssel sind nun langsam veraltet und können jetzt schon in aktzeptablen Zeiten mit Heim PC geknackt werden.(bzw. Spezial Hardware -> nich Teuere (optisches Rechnen))
Da ich im moment in meiner Sicherheitsphase bin und sowieso äußerst sensible Daten habe die unbedingt verschlüsselt werden müssen wollte ich mir eben ein Keyring erstellen und erschreckt festgestellt das ich mit

Code: Alles auswählen

pgp -kg
nur 4096 bit Keys erstellen kann.
Also ich war auch bei diesem Vortrag "1024-bit RSA ist unsicher" (siehe http://www.ccc.de/congress/2003/fahrpla ... 46.de.html ): Es wurde gesagt, dass Adi Shamir (das 'S' in RSA) die Vermutung geäußert hatte, dass es eventuell möglich wäre mit 10 Millionen Euro teuerer Hardware innerhalb eines Jahres einen 1024-Bit-Schlüssel zu knacken. Fakt ist aber, dass dies bisher noch niemandem dokumentiert gelungen ist. Natürlich kann man aber davon ausgehen, dass es beispielsweise der NSA (nicht aber z.B. deutschen Strafverfolgungsbehörden oder europäischen Geheimdiensten) mit sehr großem Aufwand in absehbarer Zeit möglich wäre, einen 1024-Bit-Key zu knacken.
Was du wahrscheinlich damit verwechselt hast, ist nur ein kleiner Teil der Kryptoanalyse bei RSA, nämlich die Matrixredukton (wenn ich das richtig im Kopfe habe), die früher oft noch als zusätzliche Hürde zur Entschlüsselung genannt wurde aber spätestens heute diese Funktion nicht mehr erfüllen kann, da schon kleine Großrechner in wenigen Tagen diese Aufgabe erledigen.
Wenn dir übrigens wirklich viel an der Sicherheit deiner verschlüsselten Daten gelegen ist, solltest du am besten GnuPG einsetzen. In Volker Grassmucks "Freie Sofware" (siehe http://freie-software.bpb.de/) steht einiges zu den Vorteilen von GnuPG gegenüber PGP:
PGP weist zwei Probleme auf. Erstens steht es nicht unter der GPL. Das heißt, der Source Code ist zwar verfügbar, aber es ist nicht erlaubt, Modifikationen daran vorzunehmen und zu vertreiben, also zusätzliche Features einzubauen, Teile aus PGP zu entfernen, die man für Sicherheitsrisiken hält und Software bereitzustellen, die auf PGP basiert. Zweitens wurde PGP von Network Associates gekauft. Als kommerzielles amerikanisches Produkt unterliegtes den Exportbeschränkungen. Starkes PGP ab einer bestimmten Schlüssellänge darf nicht ausgeführt werden. Außerdem war Network Associates Mitglied der Key Recovery Alliance, einem Zusammenschluss von US-Firmen, der es ermöglichen soll, eine Key Recovery Infrastruktur nach den Vorstellungen der US-Regierung zu betreiben, die nur dann an eine Firma Aufträge vergibt, wenn sie Mitglied in der Key Recovery Alliance ist. Dann sind Network Associates wieder ausgetreten und wieder eingetreten. Phil Zimmerman behauptetzwar, es gäbe eine klare Position gegen Key Recovery, aber die Firma, der diese Software gehört, hat offensichtlich eine andere Meinung. In der jüngsten Entwicklung von PGP sind Features hinzugekommen, die sicherheitstechnisch bedenklich sind und die Rückwärtskompatibilität einschränken. Einerder Kritikpunkte betrifft das Corporate Message Recovery (CMR). Anders als beim firmenexternen Key Recovery, das die NSA anstrebt, wird dabei jede Mail an einen Angestellten einer Firma nicht nur mit dessen persönlichem öffentlichem Schlüssel, sondern auch mit dem seines Unternehmens verschlüsselt. Ziel ist, dass die Firma auch dann noch aufdie Korrespondenz dieses Mitarbeiters zugreifen kann, wenn er selbst nicht mehr zur Verfügung steht. Andreas Bogk (CCC) sieht darin die Unterscheidung zwischen der Lagerung und der Übertragung von Informationen verletzt.

"Eigentlich viel sinnvoller wäre es, einen Mechanismus einzubauen, der einensogenannten Storage Key verwendet. Das heißt, wenn etwas an mich geschickt wird, lege ich das mit einem Storage Key ab, auf den die ganze Abteilung Zugriff hat. Essind auch Verfahren denkbar, bei denen Abteilungsschlüssel existieren, mit denen jeweils zwei Personen aus der Abteilung zusammen die Mail eines dritten lesen können usw. Also, die Art, wie diese Corporate Message Recovery angewendet werden soll, ist nicht wirklich nachvollziehbar. Aber sie ist natürlich hervorragend dafür verwendbar, zu einem späteren Zeitpunkt eine Überwachung einzurichten, indem man einfach bestimmten Firmen vorschreibt, eine solche Corporate Message Recovery mit einem Schlüssel zu verwenden, der bei staatlichen Stellen hinterlegt ist."
Eine weitere bedenkliche Neuerung ist die Message-ID, die seit PGP-Version 5.0 unverschlüsselt im Header steht. Offiziell soll sie dazu dienen, eine Mail, die in mehreren Teilen verschlüsselt ist, wieder zusammenzusetzten, doch existiert für diese Aufgabe der technische Standard Multipart-MIME. Vollkommen unbegründet ist diese Message-ID in einer PGP-Message, die nur aus einem Teil besteht. Andreas Bogk (CCC) sieht darin einen weiteren Weg, über den eine PGP-Nachricht angegriffen werden kann.

"PGP ist ja ein Hybridverfahren, d.h., ich habe einmal ein Public Key-Verfahren, mitdem ein Session Key verschlüsselt wird. Mit diesem Session Key wird dann in einem klassischen symmetrischen Verfahren der Rest der Mail verschlüsselt. Die beiden Punkte, die ich angreifen kann, sind einmal das Public Key-Verfahren. Wenn ich es schaffe, aus dem Public Key den Secrete Key zu generieren, kann ich die Message lesen. Der zweite Punkt, den ich angreifen kann, ist der Session Key, der für den symmetrischen Schlüssel verwendet wird. Wenn ich den knacke, kann ich die Message auch lesen. Und diese Message-ID bringt nun einen dritten Angriffsweg mit. Der Session Key wird nämlich aus einem Entropie-Pool generiert. Da werden also Random-Informationen gesammelt, miteinander verhasht, und daraus wird der Session Key gewonnen. Und direkt nachdem der Session Key generiert wurde, wird diese Message-ID aus demselben Pool generiert. Da ist zwar ein Prozess dazwischen, der sich Whitening nennt und der mit Hilfe eines Hashing-Algorithmus verhindern soll, dass man daraus den Zustand des Pools zurückrechnet, aber erstens ist die Forschung auf dem Gebiet noch ein bißchen dünn und zweitens wird hier grundlosein weiterer Angriffsweg eingeführt."
Die oben angesprochenen Exportbeschränkungen gelten AFAIK nicht mehr, trotzdem bleibt vor allem das Argument mit den Message-IDs. Darüber hinaus ist es in der aktuellen PGP-Versin zwar AFAIK erlaubt in den Sourcecode zu sehen aber nicht daraus selbst das Programm zu kompilieren. Somit ist es nicht sicher, ob das erhaltene Binary auch wirklich aus dem vorliegendem Quelltext kompiliert wurde.
Ich benutze einen 4096-Bit und GnuPG und halte das für völlig ausreichend. Einige Freund evon mir benutzen paranoide Keys mit einer Schlüssellänge von 8192 Bit aber dann ein Windows-Betriebssystem, was ich für völlig widersinnig halte.

Georgy
Beiträge: 97
Registriert: 07.01.2004 17:35:19
Kontaktdaten:

Beitrag von Georgy » 09.01.2004 13:08:51

kleine frage eines dummen, unwissenden linux-anfängers,
wie verschlüsselt mann überhaupt dateien mit pgp-key!?

geht das auch über losetup?
wenn ja, wieder mit ner anderen loop-version als loop-aes!?

oder mit cryptoloop von kernel 2.6???

oder wei oder was!?

ich würde nämlich auch gern ne partition auf meinem notebook verschlüsseln (siehe anderer thread im notebook-forum)
und hab damit eh genug probleme, aber wenns denn mal läuft, könnt ich ja theoretisch auch nen pgp-key statt AES nehmen, oder?
ist der erstere sicherer?

ein wenig offtopic, sorry...aber es interessiert mich grad!

grüßchen
Geo

Benutzeravatar
eagle
Beiträge: 2282
Registriert: 05.11.2002 11:20:53
Wohnort: Berlin

Beitrag von eagle » 09.01.2004 13:22:25

Georgy hat geschrieben:kleine frage eines dummen, unwissenden linux-anfängers,
wie verschlüsselt mann überhaupt dateien mit pgp-key!?
man gpg oder den Link [1].

Das ganze hat mit losetup und cryptoapi / cryptoloop im Kernel nichts zu tun.

eagle

[1] http://www.gnupg.org/(en)/howtos/de/index.html
"I love deadlines. I love the whooshing sound they make as they fly by." -- Douglas Adams

Georgy
Beiträge: 97
Registriert: 07.01.2004 17:35:19
Kontaktdaten:

Beitrag von Georgy » 09.01.2004 13:24:55

selbst wenn man platten damit verschlüsselt? 8O
das wundert mich nu bissi...dachte immer der einzige weg auf block-devices zuzugreifen, ginge über kernel-routinen, und wenn dies nicht können eben über nen loop....

aber ok....ich schlucks mal und lese die manpage...


Geo

Benutzeravatar
eagle
Beiträge: 2282
Registriert: 05.11.2002 11:20:53
Wohnort: Berlin

Beitrag von eagle » 09.01.2004 13:31:00

Georgy hat geschrieben:selbst wenn man platten damit verschlüsselt? 8O
das wundert mich nu bissi...dachte immer der einzige weg auf block-devices zuzugreifen, ginge über kernel-routinen, und wenn dies nicht können eben über nen loop....
Du wirfst hier ein paar Dinge durcheinander. Du kannst mit gpg Texte, emails und einzelne Dateien verschluesseln, aber keine gesamte Partition. Auch einen Container (wie bei pgpdisk oder bestcrypt) kannst du mit gpg nicht anlegen oder benutzen. Dazu brauchst du die cryptoloop / cryptoapi des Kernels.

eagle
"I love deadlines. I love the whooshing sound they make as they fly by." -- Douglas Adams

Georgy
Beiträge: 97
Registriert: 07.01.2004 17:35:19
Kontaktdaten:

Beitrag von Georgy » 09.01.2004 13:36:22

und die unterstützt kein gpg...ok...damit weiss ich schon bescheid!
nun muss ich nur noch rausfinden, warum das mit dem plattenverschlüsseln bei mir nicht klappt!
kann man ne aussage machen, wie sicher aes 256 in etwa ist?
(im vergleich zu dem oben gesagten!)

gruß
Geo

Benutzeravatar
eagle
Beiträge: 2282
Registriert: 05.11.2002 11:20:53
Wohnort: Berlin

Beitrag von eagle » 09.01.2004 13:53:44

Georgy hat geschrieben:und die unterstützt kein gpg...ok...damit weiss ich schon bescheid!
nun muss ich nur noch rausfinden, warum das mit dem plattenverschlüsseln bei mir nicht klappt!
kann man ne aussage machen, wie sicher aes 256 in etwa ist?
(im vergleich zu dem oben gesagten!)
Das eine ist ein asynchroner (RSA) und das andere ein synchroner Schluessel. Synchrone Schluessel sind immer deutlich kuerzer als asynchrone.

Ein 256 bit langer AES solle mit Sicherheit ausreichen. Bei der cryptoapi werden 128, 192, 256 bit Schluessel angeboten.

eagle
"I love deadlines. I love the whooshing sound they make as they fly by." -- Douglas Adams

Georgy
Beiträge: 97
Registriert: 07.01.2004 17:35:19
Kontaktdaten:

Beitrag von Georgy » 09.01.2004 13:56:41

ok, dann wirds wohl n 256er aes werden...sofern ich den fehler find...

danke!!!

gruß
Geo

Antworten