Viren, Spyware, Datenschutz 11.258 Themen, 94.807 Beiträge

Verfolgung starten Optionen

PGP sicher ? Hintergründe ...

hawkin / 15 Antworten / Baumansicht Nickles

Hallo,
ich habe Dateien (keine e-mails), die ich gerne mit PGP verschlüssen möchte, daß KEINER die Dateien lesen kann, außer mit meinem key.

Gilt PGP wirklich als absolut sicher, daß auch keine Hacker die Dateien entschlüsseln können?

Habe ein Gerücht gehört, daß PGP verboten wurde, da die Dateien nicht mal von Geheimdiensten entschlüsselt werden können. Ist das Blödsinn?

Wäre für eine Antwort dankbar.

bei Antwort benachrichtigen
fnmueller1 hawkin „PGP sicher ? Hintergründe ...“
Optionen

"Gilt PGP wirklich als absolut sicher, daß auch keine Hacker die Dateien entschlüsseln können?"
Nein, PGP ist nicht absolut sicher - gerade wenn jmd deinen secret key hat gar nicht mehr so sehr sicher. Ein Hacker müsste aber schon große Machinen haben (und viel Sportsgeist), wenn er da was erreichen will. Sinnvoller ist aber eher ein verschlüsseltesVoluem anzuulegen, was so gross ist, das dass runterladen für den "Hacker" einfach keinen Sinn macht.

"Habe ein Gerücht gehört, daß PGP verboten wurde, da die Dateien nicht mal von Geheimdiensten entschlüsselt werden können. Ist das Blödsinn?"
Ja, überleg doch mal , wie soll es verboten sein wenn es aktiv vertrieben wird?

bei Antwort benachrichtigen
hawkin Nachtrag zu: „PGP sicher ? Hintergründe ...“
Optionen

vielen dank für die beantwortung.

eine theoretische frage:

wenn jemand meinen secret key NICHT hat und ganz ganz große maschinen hat.
ist der code knackbar?

bei Antwort benachrichtigen
fnmueller1 hawkin „vielen dank für die beantwortung. eine theoretische frage: wenn jemand meinen...“
Optionen

ja, z.B. die NSA sollte das können. Ferner steigt die Rechengeschwindigkeit ja nicht gleichmässig an....

bei Antwort benachrichtigen
Tyrfing hawkin „vielen dank für die beantwortung. eine theoretische frage: wenn jemand meinen...“
Optionen

>>wenn jemand meinen secret key NICHT hat und ganz ganz große maschinen hat.
ist der code knackbar? Theoretisch? Ganz klar Ja, auch mit "brute force" ist man irgendwann am Ziel

Realistisch? Auch für die NSA/CSS sehr unwahrscheinlich, außer die haben halb Texas in ein Rechenzentrum verwandelt. Falls man ein sicheres Passwort (15+ Zeichen, die üblichen Regeln) verwendet, ist der benötigte Rechenaufwand für heutige Verhältnisse schlicht und ergreifend wahnsinnig

PS: Übrigens stimmt es, dass zumindest der Export von Kryptographietechniken in vielen Staaten unter Beschränkungen fällt, die Benutzung ist jedoch in demokratischen Staaten nicht illegal

bei Antwort benachrichtigen
fnmueller1 Tyrfing „ wenn jemand meinen secret key NICHT hat und ganz ganz große maschinen hat. ist...“
Optionen

@tyrfing:
du machst mutige aussagen. Niemand weiss wirklich wie wird die Quantencomputer sind. Manche sagen das braucht noch 50 Jahre, andere sagen in 10 Jahren könnte es soweit sein. Wenn also jmd seine Dateien bekommt könnte man die sehr wohl schon sehr bald knacken.
Noch schlimmer kommt es wenn er auf einem Dual-Core / HTT System arbeitet... da ist der PGP Schlüssel nämlich auslesbar - ohne vielen Rechenaufwand und in der Praxis erwiesen.
Ich wäre also schon vorsichtig

bei Antwort benachrichtigen
Tyrfing fnmueller1 „@tyrfing: du machst mutige aussagen. Niemand weiss wirklich wie wird die...“
Optionen

>>Manche sagen das braucht noch 50 Jahre, andere sagen in 10 Jahren könnte es soweit sein. Wenn also jmd seine Dateien bekommt könnte man die sehr wohl schon sehr bald knacken. Und auch wenn es nächsten Monat so weit wäre: "heutige Verhältnisse" sind heutige Verhältnisse und was irgendeine three-letter-agency theoretisch in 10 Jahren können wird ist eher irrelavant wenn es darum geht, daß auch keine Hacker die Dateien entschlüsseln können

>>Noch schlimmer kommt es wenn er auf einem Dual-Core / HTT System arbeitet... da ist der PGP Schlüssel nämlich auslesbar - ohne vielen Rechenaufwand und in der Praxis erwiesen. In manchen Szenarien und auch nur bei Mehrbenutzersystemen, wenn der Angreifer parallel mit dem Opfer an derselben Maschine arbeitet. Für den Privatbenutzer irrelevant

bei Antwort benachrichtigen
fnmueller1 Tyrfing „ Manche sagen das braucht noch 50 Jahre, andere sagen in 10 Jahren könnte es...“
Optionen

nicht wenn z.B. ein Trojaner läuft

bei Antwort benachrichtigen
Tyrfing fnmueller1 „nicht wenn z.B. ein Trojaner läuft“
Optionen

>>nicht wenn z.B. ein Trojaner läuft Der auch einfach das Passwort mitlesen könnte, aber warum einfach, wenn es auch kompliziert geht *gg*

bei Antwort benachrichtigen
xafford Tyrfing „ Manche sagen das braucht noch 50 Jahre, andere sagen in 10 Jahren könnte es...“
Optionen
In manchen Szenarien und auch nur bei Mehrbenutzersystemen, wenn der Angreifer parallel mit dem Opfer an derselben Maschine arbeitet. Für den Privatbenutzer irrelevant

Und auch nur bei HTT-Systemen, und zudem erhält man nur einen Teil des Schlüssels und den auch nur statistisch ermittelt und nicht ausgelesen und auch nurbei bestimten Verchlüsselungsalgorithmen, da andere gegen Side-Channel-Attacken gehärtet sind und außerdem, wenn man so weit auf dem System ist ist so eine Attacke ohnehin für diesen Zweck wie eine Reise von Köln nach Dortmund mit dem Umweg über Tokio.
Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
xafford fnmueller1 „@tyrfing: du machst mutige aussagen. Niemand weiss wirklich wie wird die...“
Optionen
Noch schlimmer kommt es wenn er auf einem Dual-Core / HTT System arbeitet... da ist der PGP Schlüssel nämlich auslesbar - ohne vielen Rechenaufwand und in der Praxis erwiesen.
Ich wäre also schon vorsichtig

Mehrfach falsch. Erstens ist unter einer Dual-Core CPU der Cache nicht per Side-Band-Attacke angreifbar, da jeder Core eigene und exklusive Caches hat und sie nicht teilt wie virtuelle CPUs bei HTT. Zweitens ist der Inhalt auch durch eine Side-Channel-Attacke nicht einfach auslesbar, man kann nur statistisch ungefähr die Hälfte des Schlüssels erraten womit das Knacken verkürzt wird, aber nicht erledigt ist. Drittens sind einige Algorithmen gegen Side-Channel-Attaken gehärtet, indem sie in jedem Fall beide Zweige einer Berechnung durchführen und nur ein Ergebnis auswählen und damit die Timings immer gleich sind. Viertens und letztens wäre es absoluter Stuß sich diese Mühe zu machen wenn man ohnehin schon einen bösartigen Prozessg auf einem Zielsystem am laufen hat, dann kann man auch gleich die Daten vor dem Verschlüsseln abgreifen.
Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
fnmueller1 xafford „Antwort“
Optionen

"Erstens ist unter einer Dual-Core CPU der Cache nicht per Side-Band-Attacke angreifbar, da jeder Core eigene und exklusive Caches hat und sie nicht teilt wie virtuelle CPUs bei HTT."
aha, und warum werden dann AMD CPUs auch als betroffen gelistet?

"Zweitens ist der Inhalt auch durch eine Side-Channel-Attacke nicht einfach auslesbar, man kann nur statistisch ungefähr die Hälfte des Schlüssels erraten womit das Knacken verkürzt wird, aber nicht erledigt ist."
Also ich hab mir das File vom "entwickler" recht genau durchgelesen und habe das anders verstanden. Wo steht diese Textstelle mit der du argumentierst?

"Drittens sind einige Algorithmen gegen Side-Channel-Attaken gehärtet, indem sie in jedem Fall beide Zweige einer Berechnung durchführen und nur ein Ergebnis auswählen und damit die Timings immer gleich sind."
Ich erinnere mal an diese Stelle was FreeBSD da gemacht hat....
Die Timings sind eben nicht genau gleich

"Viertens und letztens wäre es absoluter Stuß sich diese Mühe zu machen wenn man ohnehin schon einen bösartigen Prozessg auf einem Zielsystem am laufen hat, dann kann man auch gleich die Daten vor dem Verschlüsseln abgreifen."
Stimmt, ist ja auch nur ein Szenario. Auf Servern (wie bei unis oder grösseren Firmen) ist diese Variante aber absolut von Bedeutung.

bei Antwort benachrichtigen
xafford fnmueller1 „Antwort“
Optionen
aha, und warum werden dann AMD CPUs auch als betroffen gelistet?

Vielleicht weil zu der Zeit der Entdecker noch nicht wusste, daß die kommenden Dual-Core CPUs getrennte Caches haben werden?
"..."multi-core" processors should either avoid sharing caches between the processor cores or use thread-
aware cache eviction strategies...."
Mehr kann man Caches nicht mehr trennen als wenn jeder Core seinen eigenen besitzt (und zwar sowohl 1st Level, als auch 2nd Level, was sowohl Pentium D als auch AMD X2 und Opteron implementiert haben)

Außerdem schreibt der Entwickler nirgendwo, daß AMD-Dualcore-CPUs betroffen sind, er bezieht sich auf FreeBSD/AMD64 und FreeBSD/i386, welches die betroffenen Versionen dieses Betriebssystems sind und FreeBSD/AMD64 läuft auf 64-Bit XEONs von Intel mit Hyperthreading wodurch die Verletzlichkeit zustande kommt.

Also ich hab mir das File vom "entwickler" recht genau durchgelesen und habe das anders verstanden. Wo steht diese Textstelle mit der du argumentierst?

Wohl nicht genau genug gelesen:
"...To ensure that the two processes
run simultaneously, we start running the Spy process before we start
OpenSSL, and stop it after OpenSSL has nished, while minimizing the number of other processes running; without these steps, an attacker
might need to make several attempts before he successfully \spies"
upon OpenSSL..."
"...From the sequence of multiplications and squarings, we can typically
obtain about 200 bits out of each 512-bit exponent..."
"...This alone is not quite enough to make factoring the RSA modulus..."
"and even once the correct cache set has been identied, the multiplier
is often not uniquely determined; but in the case of OpenSSL we can
typically identify the multiplier to within two possibilities in 50% of
the modular multiplications. This provides us with an additional 110
bits from each exponent on average, for a total of 310 out of 512 bits,..."

Ich erinnere mal an diese Stelle was FreeBSD da gemacht hat....
Die Timings sind eben nicht genau gleich
Wie Dir vielleicht nicht entgangen ist geht es in dem Paper um die in OpenSSL implementierte Variante von AES, ich habe dagegen geschrieben, daß es einige Kryptoalgorithmen und Implementierungen von Kryptoalgorithmen gibt, welche gegen Side-Channel-Attacks gehärtet sind durch "constant time".
Lies Dir einfach einmal etwas ältere Literatur zu dem selben Problem (denn es ist ein altes Problem) durch, z.B. dieses. Hier geht es um den gleichen Angriff über Netzwerk. Lies Dir vor Allem Kapitel 8 durch:

"Suppose that we are given several implementations of AES. How do we tell which
implementations actually take constant time?
One answer is to collect timings and look for input-dependent patterns. For
example, one can repeatedly measure the time taken by AES for one (key; input)
pair, convert the distribution of timings into a small block of colors, and then
repeat for many keys and inputs. Constant-time AES software would have the
same block of colors for every key and input, as in Figure 8.1. A glance at
Figure 8.2 shows instantly that the AES implementation in OpenSSL does
not take constant time."
Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
fnmueller1 xafford „Antwort“
Optionen

aha, frage mich nur warum man heute nicht aes benutzt.

Naja, werde da erstmal weiter reinrecherchieren - zumindest dein mittelteil ist mir incht shclüssig.

bei Antwort benachrichtigen
xafford hawkin „PGP sicher ? Hintergründe ...“
Optionen
ich habe Dateien (keine e-mails), die ich gerne mit PGP verschlüssen möchte, daß KEINER die Dateien lesen kann, außer mit meinem key.

Das ist ja auch der eigentliche Sinn von Public-Key Verfahren wie PGP.

Gilt PGP wirklich als absolut sicher, daß auch keine Hacker die Dateien entschlüsseln können?

Nichts gilt als absolut sicher. Jede Verschlüsselung ist prizipiell mindestens per Brute Force zu knacken, so lange jedoch Brute Force der einzige oder schnellste Weg ist, so gilt zumindest der Algorithmus als sicher. Aber auch ein sicherer Algorithmus kann zu einer unsicheren Verschlüsselung aufgrund von Implementierungsfehlern oder zu kurzer Schlüssel führen. Nimm z.B. RC4: Der Algorithmus ist sicher, die meisten Implementierungen sind jedoch unsicher aufgrund von zu kurzer Schlüssl (früher durfte RC4 nur bis zu 40-Bit Schlüssellänge exportiert werden, was schnell geknackt werden konnte), oder aufgrund fehlerhafter Implemetierungen wie bei WEP oder der Verschlüsselung, welche Office mit RC4 implementiert.

PGP gilt jedoch bisher als hinreichend sicher und zudem als relativ schnell, da es das Public-Key Verfahren RSA mit dem Stromchiffre IDEA kombiniert und pro Nachricht mit Einwegschlüsseln arbeitet. So lange also dein Private-Key nicht in die falschen Hände kommt kann niemand mit hausmitteln deine Daten entschlüsseln.

Habe ein Gerücht gehört, daß PGP verboten wurde, da die Dateien nicht mal von Geheimdiensten entschlüsselt werden können. Ist das Blödsinn?

Ja.
Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
hawkin Nachtrag zu: „PGP sicher ? Hintergründe ...“
Optionen

vielen dank für die rege beantwortung. habe bißchen über "brute force" nachgelesen. und kam zu dem entschluß, daß meine daten "NIEMAND" lesen kann, solange der private key lang genug ist.

vielleicht wäre er zu knacken von Geheimdiensten mit SEHR großen Rechnerleistungen, aber es würde sich bestimmt niemand so große mühe machen.

Danke.

bei Antwort benachrichtigen