Sicherheit von GPG bzw. PGP

[moR-pH-euS]

Magnum P.I.
Servus,
ich habe ein kleines Thema, das ich im Studium bearbeiten muss. Die Frage ist: "Welches Risiko besteht, wenn ich einer mir unbekannten Person eine verschlüsselte E-Mail schicke?".
Im endeffekt kann doch jemand, dem ich z.B. aus Versehen eine verschlüsselte E-Mail schicke, oder wenn jemand eine verschlüsselte E-Mail abfängt, nichts damit anfangen, da er zum Entschlüsseln ja den Privaten Key des eigentlichen Empfängers bräuchte (und die Passphrase mit dem dieser gesichert ist) und zur Verifizierung dann den öffentlichen Schlüssel des Absenders (den er sich natürlich ohne Probleme besorgen kann von einem Key-Server).
Aber ausser das im Header noch ein paar Informationen stehen, wie die Version von GnuPG bzw. PGP, das Charset und das OS auf dem es ausgeführt wurde (Linux, FreeBSD etc.) gibt es keine Informationen.
Brute-Force Attacken würden ja nix bringen, da ich den Privat-Key ja nicht habe, deswegen sehe ich jetzt keine Gefahr. Oder liege ich da jetzt auf dem Holzweg?
 
[moR-pH-euS] schrieb:
Servus,
ich habe ein kleines Thema, das ich im Studium bearbeiten muss. Die Frage ist: "Welches Risiko besteht, wenn ich einer mir unbekannten Person eine verschlüsselte E-Mail schicke?".
Im endeffekt kann doch jemand, dem ich z.B. aus Versehen eine verschlüsselte E-Mail schicke, oder wenn jemand eine verschlüsselte E-Mail abfängt, nichts damit anfangen, da er zum Entschlüsseln ja den Privaten Key des eigentlichen Empfängers bräuchte (und die Passphrase mit dem dieser gesichert ist)
Das ist richtig. Ohne den privaten Schlüssel kann er nichts machen.

Es sei den Du verschluesselt die Mail mit einem privaten Schlüssel ;)...aber sowas macht man ja nicht!

[moR-pH-euS] schrieb:
und zur Verifizierung dann den öffentlichen Schlüssel des Absenders (den er sich natürlich ohne Probleme besorgen kann von einem Key-Server).

Jetzt sprichst Du vom Signieren und nicht mehr vom Verschlüsseln

[moR-pH-euS] schrieb:
Aber ausser das im Header noch ein paar Informationen stehen, wie die Version von GnuPG bzw. PGP, das Charset und das OS auf dem es ausgeführt wurde (Linux, FreeBSD etc.) gibt es keine Informationen.
Brute-Force Attacken würden ja nix bringen, da ich den Privat-Key ja nicht habe, deswegen sehe ich jetzt keine Gefahr. Oder liege ich da jetzt auf dem Holzweg?

Du liegst quasi richtig.
 
[moR-pH-euS] schrieb:
Brute-Force Attacken würden ja nix bringen, da ich den Privat-Key ja nicht habe, deswegen sehe ich jetzt keine Gefahr. Oder liege ich da jetzt auf dem Holzweg?
Brute-Force führt 100% zum Entschlüsseln der Mail. Das ist mathematisch belegt. Du brauchst nur entsprechend starke Rechner und genügend Zeit, mehr nicht.

auf bald
oenone
 
oenone schrieb:
Brute-Force führt 100% zum Entschlüsseln der Mail. Das ist mathematisch belegt. Du brauchst nur entsprechend starke Rechner und genügend Zeit, mehr nicht.

auf bald
oenone

Das irgendwann Brute-Force zum Ergeniss führt ist klar, aber ohne Privaten Schlüssel, keine Brute-Force Attacke. Und ohne Privaten Schlüssel keine Möglichkeit um an die Daten ranzukommen, das meinte ich.
 
Wieso, kann man nicht den privaten Schlüsel per "probieren" rausbekommen, so in tausenden von Jahren :-)

I.MC
 
@I.MC: genau das ist Brute-Force doch...

und anders als durch BF gibt es AFAIK keine möglichkeit.

auf bald
oenone
 
[moR-pH-euS] schrieb:
Brute-Force Attacken würden ja nix bringen, da ich den Privat-Key ja nicht habe, deswegen sehe ich jetzt keine Gefahr. Oder liege ich da jetzt auf dem Holzweg?
Im allgemeinen versucht man aus dem Public-Key den Private-Key zu errechnen. Bei RSA zB gilt ja m^ed = m (mod p) und m^ed = m (mod q) wobei m die verschlüsselte Nachricht ist und pq = n wobei n und d den Public-Key bilden.

Wirf also deinen GNFS Cluster an, ermittle p und q, errechne d und nach etwa 24+ Monaten (grobe Schätzung) bei ausreichender Rechenleistung hast du den Private-Key und kannst die Mail lesen (24 Monate dürfte hinkommen für 1024bit RSA wenn man die ~5 Monate bedenkt, die jetzt für RSA-640 benötigt wurden).

OpenPGP verwendet aber i.A. DSA, ein auf diskreten Logarithmen basierendes Verfahren. Da is das errechnen des PrivKey nochmals ungleich unschöner.

Ansonsten, für wen soll Risiko bzgl was entstehen?

Für dich? Du benutzt seinen PubKey, also keines. Wenn du zusätzlich noch signierst und dein PGP-Client defekt ist, dann is evtl doof.
Für ihn? Jemand könnte die E-Mail abfangen, brechen und irgendwann lesen. Alternativ könnte er die Mail auch unverschlüsselt erhalten, dann könnte derjenige sie sofort lesen.
 
Also derzeit ist ein 1024 bit lnger Schlüssel wohl noch recht sicher, aber wehn juckt es, wenn man einfach einen 2048 oder gleich einen 4096 Bit Schlüssel nimmt? Dann ist man definitv auf der sicheren Seite. Und Mails sind nach sooooo einer langen Zeit informationtechnisch sicherlich "Schnee von gestern" :)
Langer Schlüssel + gutes Passwort = Lange Ruhe
 
die NSA hat ja bekanntlich nen supercomputer, mit dem sie die schlüssel in sehr viel kürzerer zeit knacken kann... fühlt euch also nicht zuu sicher.

auf bald
oenone
 
Elessar schrieb:
Wirf also deinen GNFS Cluster an, ermittle p und q, errechne d und nach etwa 24+ Monaten (grobe Schätzung) bei ausreichender Rechenleistung hast du den Private-Key und kannst die Mail lesen (24 Monate dürfte hinkommen für 1024bit RSA wenn man die ~5 Monate bedenkt, die jetzt für RSA-640 benötigt wurden).

Nein, der Aufwand steigt exponentiell, nicht linear.
 
marzl schrieb:
Also derzeit ist ein 1024 bit lnger Schlüssel wohl noch recht sicher, aber wehn juckt es, wenn man einfach einen 2048 oder gleich einen 4096 Bit Schlüssel nimmt?

Na dann ver- und vorallendingen endschlüssele mal einen längeren Text mit einem RSA 4096 bit Schlüssel, das istja dann ein übelster Rechenaufwand :D :D
 
Hubert schrieb:
Nein, der Aufwand steigt exponentiell, nicht linear.
Also zum einen:
640 Bits -> 5 Monate
1024 Bits -> 24 Monate
ist nicht linear.

Genau genommen erhalten wir aus x^640 = 5 <=> x = 1.0025179, woraus wir dann ausrechnen können: x^1024 = 13.13. Die 24 Monate von mir sind also nicht nur exponentiell zur Anzahl der Bits, sondern auch noch mit einer viel ungünstigeren Basis was den Aufwand pro Bit betrifft!
 
Zuletzt bearbeitet:
Kann die Rechnung nicht nachvollziehen...

Wenn man für 640 Bit 5 Monate benötigt, dann benötigt man für 1024 Bit doch 5^384 Monate. Das sind

2114951531096374352728353796525452955686349041417579651338383601032897248241082894943672857546486905191387159214792413205501726118703022252317255298063483148698930416446412555735549017223536505700794022650650592542818997678123127519541254078679533752923210461934407552

Jahre.

Mache ich da einen Denkfehler?

Edit: Die Rechnung gilt natürlich nur für identische Rechenleistung. Aber daß die Rechenleistung ebenfalls exponentiell steigt, bezweifle ich persönlich einfach mal ganz stark.
 
Zuletzt bearbeitet:
Hehe, Rechnenleistung steigt nun aber mal exponentiell (Moores Gesetz)

Aber zwischen 640 Bit und 1024 Bit liegt der Faktor 2^384, selbst wenn man 640Bit in 1s knacken koennte, braeuchte man da eine Ewigkeit.

Aber frueher oder spaeter sollte man eh auf Elliptic Curve Cryptography umsteigen, schon allein wegen der Aussicht auf Quantencomputer.

Und: Daten/Dokumente muessen auch mal 20, 50, 100 Jahre unter Verschluss bleiben...
 
@MrFixit:
Die Möglichkeit diese Chips mit Strom zu versorgen und/oder zu kühlen steigt aber nicht exponentiell.
Darum ist sehr bald Multicore und Multichip auch im x86/x64 - Bereich nötig.
Schau mal auf www.acmqueue.org.
 
Übrigens ist Moore's Law ziemlich ungenau definiert, siehe dazu:
http://en.wikipedia.org/wiki/Moore's_law

Und ewig steigt "die Rechenleistung" nicht exponentiell.

Sonst hätten wir schon 5GHz Pentium CPUs, haben wir aber nicht :-)
 
lars schrieb:
Sonst hätten wir schon 5GHz Pentium CPUs, haben wir aber nicht :-)
da gibt es ja auch die physikalische Grenze.. Das ist auch der Grund, warum die großen CPU-Hersteller nicht mehr viel schnellere CPUs herstellen, sondern auf Multi-Core-CPUs umsteigen.

Bei 5 GHz würde der Strom (angenommen mit Lichtgeschwindigkeit) länger brauchen um durch die CPU zu wandern als ein Takt lang ist. Bei kleineren CPUs geht es vielleicht noch ein bisschen höher, aber nicht mehr viel.

auf bald
oenone
 
Zurück
Oben