Forum: Offtopic Verschlüsselte E-Mails nicht mehr sicher


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

eben drüber gestolpert:

"Betroffen sind beide Verfahren, mit denen weltweit E-Mails 
verschlüsselt werden: S/Mime und PGP. Firmen verwenden in der Regel 
S/Mime, Aktivisten, Whistleblower und Journalisten hingegen PGP."

"Geheimnisse von Konzernen weltweit, aber auch vertrauliche Botschaften, 
die sich Menschenrechtsaktivisten, Anwälte und Journalisten schicken: 
Alle diese Nachrichten könnten nun im Nachhinein entschlüsselt werden."

http://www.sueddeutsche.de/digital/exklusiv-verschluesselte-e-mails-sind-nicht-sicher-1.3978608

Gruß Gustav

von Reinhard S. (rezz)


Bewertung
1 lesenswert
nicht lesenswert
Warten wir erstmal auf morgen bis die Details rauskommen.

von Mario M. (thelonging)


Bewertung
0 lesenswert
nicht lesenswert

von Teo D. (teoderix)


Bewertung
4 lesenswert
nicht lesenswert
Sehe da kein großes Risiko.
Es muss ein präparierte Mail an den Client, der das PW besitzt geschickt 
werden. Dieser muss auch noch so manipuliert werden, das er den 
entschlüsselten Text wieder zurückschickt.
Die Verschlüsselung ist also keinesfalls geknackt, nur der Client.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
-7 lesenswert
nicht lesenswert
Hallo Gustav,

das war doch immer klar. Es gibt keine dauerhafte Sicherheit durch 
Verschlüsselung. Man kann bestenfalls die Hürden der Entschlüsselung in 
die Höhe treiben.

 Die Folge ist, mit ausreichender Infrastruktur und Zeit ist jede 
Verschlüsselung auch ohne Schlüssel zu Knacken. Wer also Interesse daran 
hat wird sich die passende Kundschaft akquirieren schon um die Kosten im 
Zaum zu halten. Das bedeutet, aber auch das parallel mit stärkerer 
werdender Verschlüsselung auch die Entschlüsselungsindustrie wächst.

Namaste

von Uhu U. (uhu)


Bewertung
5 lesenswert
nicht lesenswert
Winne, das sind jetzt aber völlig triviale Allgemeinplätze, die zudem 
mit dem vorliegenden Problem herzlich wenig zu tun haben.

Verschlüsselte Kommunikation bedeutet nie absolute Sicherheit, sondern 
nur Zeitgewinn.

Das Problem, das hier zu Tage kam, hängt mit html-Mail zusammen - wenn 
das abgeschaltet ist, funktioniert der Trick nicht.

von Mac G. (macgyver0815)


Bewertung
8 lesenswert
nicht lesenswert
HTML in Mails gehört sowieso verboten. Das ist Sicherheitsrisiko Nummer 
1 (für Anwender die nicht wissen wie man das abschalten kann oder 
Webmail benutzen wo es nicht abschaltbar ist).
Im Heise Forum schrieb gerade jemand man hätte statt HTML damals auch 
einfach sowas wie BBcode einführen können, man hätte nie von solchen 
Problemen gehört.


Also nicht PGP wurde geknackt, sondern es ist nur eine weitere 
Sicherheitslücke im Client bei der Darstellung von HTML...

von Cyblord -. (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Der Medienhype ist FUD

von Markus M. (mmvisual)


Angehängte Dateien:

Bewertung
-9 lesenswert
nicht lesenswert
ich htate mal vor eneiign Jerhan enien Text Vhrllücssseeer geribceeshn, 
der den Text so mchist dass er iemmr noch labser ist. Dmait stleoln 
auimoattcshe Turnenxtekenegn doch was zu kanbebrn heban.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
-6 lesenswert
nicht lesenswert
Abradolf L. schrieb:
> Der Medienhype ist FUD

Ja nicht nur dieser.

Namaste

: Bearbeitet durch User
von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
-4 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Verschlüsselte Kommunikation bedeutet nie absolute Sicherheit, sondern
> nur Zeitgewinn.

Viele scheinen aber gerade das nicht zu erfassen und verlassen sich auch 
in inoportunen Situationen auf ewigen Geheimnisschutz durch 
Cryptotechniken.

Namaste

von MaWin O. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Markus M. schrieb:
> TextCoder.exe

Netter Versuch.
Deinen Virus darfst du behalten.

von Uhu U. (uhu)


Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
Ma W. schrieb:
> Markus M. schrieb:
>> TextCoder.exe
>
> Netter Versuch.
> Deinen Virus darfst du behalten.

Malware.HighConfidence

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-1 lesenswert
nicht lesenswert
Wenn der Schlüssel genau so lang ist wie der verschlüsselte Inhalt, dann 
kann die Verschlüsselung nicht gebrochen werden bzw. ich liefere Dir für 
jeden Wunschtext einen passenden Schlüssel.

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Hier ist die Sache beschrieben: 
https://www.heise.de/security/artikel/PGP-und-S-MIME-So-funktioniert-Efail-4048873.html

Doppelte Verschlüsselung dürfte den Trick auch mit eingeschaltetem HTML 
austricksen...

von Sven B. (scummos)


Bewertung
3 lesenswert
nicht lesenswert
Winfried J. schrieb:
> das war doch immer klar. Es gibt keine dauerhafte Sicherheit durch
> Verschlüsselung. Man kann bestenfalls die Hürden der Entschlüsselung in
> die Höhe treiben.

Das ist m.E. nicht wahr. Meist ist das Problem ein Fehler in der 
Implementierung des verwendeten Verfahrens, seltener ein Problem im 
Verfahren selber. Ein sicheres Verfahren zu entwerfen, das auch in 200 
Jahren nicht gebrochen werden wird, halte ich für ohne weiteres denkbar. 
Das Argument mit der größeren verfügbaren Rechenleistung ist schlicht 
falsch -- weil die Problemgrößen bei ordentlichen Verfahren exponentiell 
sind.

Um alle Schlüssel für AES-256 durchzuprobieren braucht man, alleine nur 
um die Bits umzukippen, um den zu probierenden Schlüssel mal irgendwo 
dastehen zu haben, aus rein thermodynamischen Überlegungen sowas in die 
Richtung der gesamten Energieproduktion der Milchstraße für eine 
Milliarde Jahre. Dieses Verfahren wird nur durch einen eventuellen 
Fehler im Verfahren gebrochen werden, und sicherlich nie durch 
"schnellere Rechner" oder "mehr Industrie".

: Bearbeitet durch User
von Markus M. (mmvisual)


Angehängte Dateien:

Bewertung
-8 lesenswert
nicht lesenswert
Keine Ahnung warum in der EXE ein Virus erkannt wurde, ich habe diese 
gerade nochmals mit dem aktuellen Lazarus übersetzt. Mein Virenscanner 
meldet kein Alarm.

von MaWin O. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus M. schrieb:
> ich habe diese
> gerade nochmals mit dem aktuellen Lazarus übersetzt. Mein Virenscanner
> meldet kein Alarm.

Netter zweiter Versuch.
Leider fällt niemand darauf herein.

von Sebastian H. (sebh)


Bewertung
-2 lesenswert
nicht lesenswert
Sven B. schrieb:
> Um alle Schlüssel für AES-256 durchzuprobieren braucht man, alleine nur
> um die Bits umzukippen, um den zu probierenden Schlüssel mal irgendwo
> dastehen zu haben, aus rein thermodynamischen Überlegungen sowas in die
> Richtung der gesamten Energieproduktion der Milchstraße für eine
> Milliarde Jahre. Dieses Verfahren wird nur durch einen eventuellen
> Fehler im Verfahren gebrochen werden, und sicherlich nie durch
> "schnellere Rechner" oder "mehr Industrie".

Das es noch immer Leute in der IT gibt, die sagen, daß manche Sachen 
"niemals" passieren werden...

von Daniel A. (daniel-a)


Bewertung
1 lesenswert
nicht lesenswert
Markus M. schrieb:
> Keine Ahnung warum in der EXE ein Virus erkannt wurde

Das ist ein bekanntes Problem. Wenn es ein Hello World oder ähnlich 
simpel ist oder mit gcc übersetzt wurde finden das die Virenskanner 
komisch, weil zu grosser unterschied zu durchschnittlichen Programmen. 
Es lebe machine learning:
https://www.google.ch/amp/s/www.csoonline.com/article/3216765/security/heres-why-the-scanners-on-virustotal-flagged-hello-world-as-harmful.amp.html

von MaWin O. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sebastian H. schrieb:
> Das es noch immer Leute in der IT gibt, die sagen, daß manche Sachen
> "niemals" passieren werden...

Die Thermodynamik ist aber ein recht hartes Limit.
Oder behauptest du, sie wäre falsch?

von René H. (mumpel)


Bewertung
-2 lesenswert
nicht lesenswert
Hallo!

Mac G. schrieb:
> HTML in Mails gehört sowieso verboten. Das ist Sicherheitsrisiko Nummer 1
Sehe ich anders. Das größte Sicherheitsrisiko sitzt 60cm vor dem 
Bildschirm.

Mac G. schrieb:
> man hätte statt HTML damals auch einfach sowas wie BBcode einführen können,

Du weisst aber schon dass BBCode serverseitig in HTML umgewandelt wird? 
Im Browser ist es somit HTML. Man hätte also zusätzlich zu BBCode auch 
eine ganze Menge an Prüfmechanismen einbauen müssen die vor der Anzeige 
oder besser vor dem Absenden der Email selbige erstmal umfangreich 
prüfen. Und wie es immer ist liese sich auch BBCode manipulieren. Wer 
glaubt BBCode sei sicher ist m.E. gewaltig auf dem Holzweg. Einen nicht 
manipulierbaren Ersatz für HTML mit den selben Eigenschaften kann es 
m.E. nicht geben.

Eine Möglichekeit, Sicherheit zu gewährleisten, sehe ich in der Sandbox. 
Bei der dem Emailclient bzw. einem HTML-Code verboten wird auf das 
System zuzugreifen. Oder man ändert die Art und Weise wie der HTML-Code 
verarbeitet wird.

Gruß, René

: Bearbeitet durch User
von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
Sebastian H. schrieb:
> Sven B. schrieb:
>> Um alle Schlüssel für AES-256 durchzuprobieren braucht man, alleine nur
>> um die Bits umzukippen, um den zu probierenden Schlüssel mal irgendwo
>> dastehen zu haben, aus rein thermodynamischen Überlegungen sowas in die
>> Richtung der gesamten Energieproduktion der Milchstraße für eine
>> Milliarde Jahre. Dieses Verfahren wird nur durch einen eventuellen
>> Fehler im Verfahren gebrochen werden, und sicherlich nie durch
>> "schnellere Rechner" oder "mehr Industrie".
>
> Das es noch immer Leute in der IT gibt, die sagen, daß manche Sachen
> "niemals" passieren werden...

Das ist kein IT-Argument, sondern ein Thermodynamik-Argument. Das ist 
ein bisschen was anderes, weil ja, es wird niemals passieren, dass 
Rechner weniger Energie benötigen als die physikalisch vorgegebene 
Untergrenze. Das ist ungefähr so, wie eine Solarzelle die in der Gegend 
liegt nie mehr Strom liefern wird als Licht von der Sonne auf sie drauf 
fällt. Da sagst du ja auch nicht "ja aber der Wirkungsgrad ist von 1% 
auf 2%, dann von 2% auf 5%, dann auf 20%, dann auf 40% gestiegen, also 
sind wir in 10 Jahren bei 80% und dann bei 160%".

von Uhu U. (uhu)


Bewertung
2 lesenswert
nicht lesenswert
René H. schrieb:
> Mac G. schrieb:
>> man hätte statt HTML damals auch einfach sowas wie BBcode einführen können,
>
> Du weisst aber schon dass BBCode serverseitig in HTML umgewandelt wird?

"Sowas wie BBCode" heißt nicht BBCode. Eine Implementierung für Mail 
müsste natürlich auf dem jeweiligen Mail-Client lokal laufen...

von René H. (mumpel)


Bewertung
0 lesenswert
nicht lesenswert
Wer Angst hat setzt auf "Nur-Text-Mail". Das erspart Experimente und 
Diskussionen. Und in vielen Firmen gibt es generell keine HTML-Mails.

: Bearbeitet durch User
von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
René H. schrieb:
> Wer Angst hat setzt auf "Nur-Text-Mail". Das erspart Experimente und
> Diskussionen.

Leider nicht ganz: wenn der Kommunikationspartner bei HTML bleibt, dann 
ist das Loch auch offen - deswegen sollte html tatsächlich dafür 
"verboten" werden, auch wenn das den Schlapphüten nicht gefällt.

: Bearbeitet durch User
von René H. (mumpel)


Bewertung
1 lesenswert
nicht lesenswert
Ein Verbot kommt aber einer Bevormundung gleich. Man kann nicht alles 
gesetzlich verbieten nur weil eine Gefahr existiert. Würde man alles 
verbieten was gefährlich ist müssten wir wieder in Höhlen oder auf 
Bäumen leben. Alle Verkehrsmittel sind gefährlich, Waffen sind 
gefährlich, und viele Menschen sind gefährlich.

: Bearbeitet durch User
von Joerg W. (joergwolfram)


Bewertung
3 lesenswert
nicht lesenswert
Keiner, den es interessiert, was denn da so verschlüsselt wurde, wird 
darauf warten wollen bis Bruteforce in sinnvollem Zeitrahmen 
realisierbar ist.

Die gängigstem Methoden sind daher diverse Orakel, known Plaintext, 
Seitenkanalattacken und die Daten dann abgreifen, wenn sie 
unverschlüsselt sind. Zu letzterem zählt meiner Meinung auch das 
aktuelle Problem. Selbst eine ideale Verschlüsselung wie das 
One-Time-Pad lässt sich "knacken", wenn man die Daten vor der 
Verschlüsselung oder nach der Entschlüsselung ausleitet. Aber damit ist 
nicht die Verschlüsselung geknackt, sondern die konkrete 
Implementierung.

Aus gegebenen Anlass sollte es für die meisten Fälle reichen, keine 
externen Inhalte zu erlauben, was bei mir z.B. schon seit der 
Einrichtung eingestellt ist. Aber hundertprozentig darauf verlassen 
würde ich mich da auch nicht.

Man könnte jetzt z.B. dem Thunderbird via Firejail und iptables alle 
Ports außer 465 und 995 und UDP 53 (DNS) abdrehen, allerdings muss man 
dann wieder Ausnahmen für den/die CalDAV und CardDAV Server einpflegen, 
sonst funktionieren Lightning und der SOGO-Adaper nicht mehr richtig.

Am einfachsten lässt sich das Problem wohl im Mailprogramm bzw. Plugin 
lösen. Z.B. bei unsignierten Mails oder welchen mit ungültiger Signatur 
explizit nachfragen, ob entschlüsselt werden soll. In dem Fall könnte 
man dann Rücksprache mit dem Absender halten. Nutzer von PGP (nicht GPG) 
scheinen meinen Beobachtungen nach aber generell nicht zu signieren...

Letztendlich bewahrheitet sich wieder einmal, dass Komfort und 
(richtige) Sicherheit sich diametral gegenüberliegen.


Jörg

von René H. (mumpel)


Bewertung
2 lesenswert
nicht lesenswert
Im Übrigen wird diese Lücke auch nur wieder von den Medien aufgebauscht. 
Dass diese Sicherheitslücke wirklich ausgenutzt wird darf bezweifelt 
werden. Vor ein paar Monaten ging eine "gefährliche" Sicherheitslücke in 
Windows durch die Medien. Alle haben "Hilfe, Hilfe... böses 
Microsoft..." geschriehen. Geblieben ist davon nichts als überflüssiges 
Medien-Geschmiere. Und das war auch nicht der einzige Aufschrei von dem 
am Ende nichts blieb. Die lukrativste Sicherheitslücke ist noch immer 
menschliche Gier nach dem schnöden Mammon, dafür muss man keine 
Schlösser knacken (eine Email mit viel Geld-Versprechungen reicht), was 
von Betrügern auch sehr erfolgreich ausgenutzt wird.

: Bearbeitet durch User
von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
René H. schrieb:
> Ein Verbot kommt aber einer Bevormundung gleich. Man kann nicht alles
> gesetzlich verbieten nur weil eine Gefahr existiert.

Du scheinst auch den feinen Unterschied zwischen "Verbot" und Verbot 
nicht zu kennen...

Gewisse Dinge verbieten sich einfach von selbst, z.B. das Baden in einer 
Jauchegrube, oder das Nasebohren mit einer Hilti - dazu braucht man kein 
Gesetz...

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
René H. schrieb:
> Im Übrigen wird diese Lücke auch nur wieder von den Medien aufgebauscht.
> Dass diese Sicherheitslücke wirklich ausgenutzt wird darf bezweifelt
> werden.

Ja und nein - weil eigentlich jeder Depp angelernt werden kann, die 
Lücke auszunutzen, ist sie sehr gefährlich.

Dass die Presseheinis sich ohne einen Funken Hintergrundwissen darüber 
auslassen, ist ein verbreitetes Phänomen, das in diesem Fall dem 
technisch gebildeten Leser klar machen sollte, dass derlei "Experten" 
auch zu anderen Themen im Brustton der Überzeugung großen Mist zu 
verzapfen pflegen und er deswegen gut daran tut, sein Hirn nicht nur im 
Bereich Technik einzuschalten...

von Mac G. (macgyver0815)


Bewertung
1 lesenswert
nicht lesenswert
Uhu U. schrieb:
> René H. schrieb:
>> Mac G. schrieb:
>>> man hätte statt HTML damals auch einfach sowas wie BBcode einführen können,
>>
>> Du weisst aber schon dass BBCode serverseitig in HTML umgewandelt wird?
>
> "Sowas wie BBCode" heißt nicht BBCode. Eine Implementierung für Mail
> müsste natürlich auf dem jeweiligen Mail-Client lokal laufen...

Genau das.
Der Client kann das natürlich völlig problemlos direkt rendern ohne HTML 
als Zwischenschritt.
Ja... da hätte jemand mal ein paar Tage dran programmieren müssen statt 
einfach den Webbrowser ins Programm einzubinden, das wäre die Mühe aber 
Wert gewesen.
Es reichen ja schon ein paar ganz einfache Formatierungen.

von Soul E. (souleye)


Bewertung
1 lesenswert
nicht lesenswert
Das Problem ist ja nicht das html an sich, sondern das unsichere 
Nachladen vom Drittanbieter.

Der Trick funktioniert ja so, dass man den verschlüsselten Text 
unangetastet lässt und mit einem "<img src="meinserver.xx/" und einem 
">" umgibt. Der Mailclient versucht dann das externe Bild nachzuladen 
und überträgt als "Dateinamen" die vorher entschlüsselte Mail zum 
Server. Verbietet man das Nachladen von Graphiken, ist Schluss damit.

von René H. (mumpel)


Bewertung
1 lesenswert
nicht lesenswert
soul e. schrieb:
> sondern das unsichere Nachladen vom Drittanbieter.

Microsoft hat ja schon den richtigen Weg eingeschlagen, aber nicht 
richtig zuende gebracht. Das automatische Laden von Bildern kann ja in 
Outlook schon jetzt blockiert werden. Nur sind Bilder nicht die einzigen 
Links die Angreifer ausnutzen können.

M.E. muss man das Emailformat nicht neu erfinden. Die technischen 
Möglichkeiten gibt es schon jetzt. Die Sicherheit erhöhen ist schon 
jetzt möglich. Man könnte z.B. den Emailheader analysieren bevor die 
Email in den Posteingang gelangt. Den Absendernamen kann man ja 
manipulieren, und genau das kann man zur Analyse nutzen. Manipulierte 
Emails könnten in einen speziellen Quarantäneordner verschoben werden. 
Innerhalb des Quarantäneordners wäre nur lesen und löschen (am 
Papierkorp vorbei) möglich, alle anderen Funktionen (Antworten, 
verschieben, Links anklicken, entschlüsseln etc.) wären nicht möglich. 
Linkshortener könnte man in Klartext umwandeln lassen. Und es wäre noch 
mehr möglich.

von Vn N. (wefwef_s)


Bewertung
-1 lesenswert
nicht lesenswert

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
René H. schrieb:
> soul e. schrieb:
>> sondern das unsichere Nachladen vom Drittanbieter.
>
> Microsoft hat ja schon den richtigen Weg eingeschlagen

Den hier? 
https://sec-consult.com/en/blog/2017/10/fake-crypto-microsoft-outlook-smime-cleartext-disclosure-cve-2017-11776/

SCNR :D

von Jiri D. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Die Heise-Artikel, tagesschau.de, und SZ geben die fehlerhafte Homepage 
und das Paper wieder. Das Paper mach claims und liefert dann nicht. Die 
Crypto ist nicht kaputt und OpenPGP funktioniert auch weiterhin. 
Enigmail schaltet HTML rendering per default aus, ebenso z.B. Torbirdy. 
HTML in Emails war schon immer eine schlechte Idee.


Offizielle Stellungnahme der GnuPG und Enigmail Autoren:

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html

> We have three things to say, and then we're going to show you why we're right.
>
> 1. This paper is misnamed.
> 2. This attack targets buggy email clients.
> 3. The authors made a list of buggy email clients.
> ...
> The authors have done the community a good service by cataloguing buggy
> email email clients.  We're grateful to them for that.  We do wish,
> though, this thing had been handled with a little less hype.  A whole lot
> of people got scared, and over very little.


https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060333.html

> BTW, the lack of all version numbers of the plugins or crypto engines is
> a major flaw in the paper.  With version numbers it would be much easier
> to see what is wrong with some claims.


https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060318.html

> We've known about problems in OpenPGP's feedback mode for at least
> thirteen years.  (See https://eprint.iacr.org/2005/033.pdf for an
> example.)  The OpenPGP working group resolved these problems by adopting
> modification detection codes (MDCs).  GnuPG properly implements MDCs and
> gives clear and unambiguous warnings if a message lacks an MDC.  The
> paper authors acknowledge that if an email client handles these warnings
> sensibly, their attack fails.
>
> In other words, their attack is completely dependent on email clients
> handling our warnings in a broken way.  Great: that they've found bugs in
> major email clients is a good thing, but where's the flaw in the OpenPGP
> protocol or GnuPG's implementation of it?  And does this really deserve
> the hype-tastic title "Breaking S/MIME and OpenPGP Email Encryption" when
> it really doesn't do that?
>
> In grad school my adviser told me to follow Napoleon's Rule in paper
> titles.  "If you tell the world you're going to conquer Russia, you'd
> better conquer Russia."  This paper doesn't deliver on what its title
> promises.


Mit den Autoren der betroffenen Software wurde nicht kommuniziert:
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060317.html

> Werner saw a preprint of this paper some time ago.  I saw it recently.
> Patrick Brunschwig of Enigmail saw it.  None of us are worried.  Out of
> respect for the paper authors I will skip further comment until such time
> as the paper is published.
>
> It would've been nice if EFF had reached out to us for comment, rather
> than apparently only talking to the paper authors.  We hope they'll reach
> out next time.

Undiplomatisch ausgedrückt, gilt leider in diesem Fall wieder: 
https://plus.google.com/+LinusTorvalds/posts/PeFp4zYWY46

Ich hätte von der Ankündigung und dem medialem Trommelwirbel her 
erwartet, dass endlich RSA brauchbar faktorisiert/anderweitig gebrochen 
wurde. Bin sehr underwhelmed.

von Jiri D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
René H. schrieb:
> Man könnte z.B. den Emailheader analysieren bevor die
> Email in den Posteingang gelangt.

Ein aktuelles Enigmail implementiert Memory Hole/Protected Headers: 
https://github.com/autocrypt/memoryhole


D.h. das (endlich) auch die Emailheader (Subject, From, Date, ...) 
verschlüsselt und signiert werden können. Öffentlich einsehbar ist dann 
nur ein dummy header (z.B. generisches "Subject: Encrypted").

> Den Absendernamen kann man ja
> manipulieren, und genau das kann man zur Analyse nutzen.

Man kann natürlich alle Headerzeilen manipulieren, nicht nur den 
Absendernamen. Außer natürlich man packt das alles in einen 
kryptographisch gesicherten Teil der Email (s.o.).

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.