Kommentare zu folgendem Beitrag: Verschlüsselungs-Umgehung: EU-Zusammenarbeit mit Five Eyes
In einem Leserkommentar auf Heise.de stand, dass es angeblich End-to-End Verschlüsselung mit mehreren Schlüsseln geben soll. In der Wikipedia habe ich dazu nichts gefunden. Da ist immer nur von einem einzigen Schlüsselpaar die Rede, einem privaten und einem öffentlichen. Gibt es diese E2E Verschlüsselung mit zusätzlichem Generalschlüssel wirklich, und hat da jemand einen Link wo erklärt wird, wie das funktioniert?
Jedes asymetrische Verschlüsselungsverfahren (im Gegensatz zum symetrischen Verschlüsselungsverfahren) benutzt ZWEI Schlüssel – aufgeteilt in:
- öffentlicher Schlüssel
- privater Schlüssel
Bei der erwähnten symetrischen Verschlüsselung wird nuer ein einziger Schlüssel genutzt, der von beiden Seiten genutzt wird!
Bin durch ein bisschen Nachdenken selber drauf gekommen, wie es geht. Alice generiert einen zufälligen symmetrischen Schlüssel S und verschlüsselt damit die Nachricht an Bob. Zusätzlich verschlüsselt sie S einmal mit dem öffentlichen Schlüssel von Bob, und ein zweites mal mit dem öffentlichen Schlüssel des Staates. Die Nachricht (1) und die beiden verschlüsselten S (2 und 3) schickt sie dann an Bob. Bob entschlüsselt (2) mit seinem privaten Schlüssel und erhält S. Damit entschlüsselt er dann die Nachricht. Der Staat entachlüsselt stattdessen (3) mit seinem privaten Schlüssel und erhält ebenfalls S. Alle anderen müssen draußen bleiben. Eigentlich ganz einfach.
Si Senor! 
So einfach ist das nicht. Da der öffentliche Schlüssel nicht an alle Daten herankommt. Sondern er nur genauso begrenzten Zugang dazu hat. Zum Beispiel ich gewähre dir einen ssh Key schlüssel wo du auf meinen Server kommst, das heißt du darfst da arbeiten, doch kommst du nicht an alle Daten oder Rohmaterial heran. Das heißt, Sie müssten einen Hauptschlüssel bekommen um an alle Daten herankommen zu dürfen. Damit du es noch besser verstehst, schaue dir das mal an. Daher muss das weg und darf nicht kommen. „Diese Forderungen nach einem Generalschlüssel zeugen von der Unbedarftheit der Behörden. Technisch sei das gar nicht möglich. „Wir haben gar keinen Generalschlüssel, den wir hinterlegen könnten. Die Verschlüsselung wird von den Nutzern vorgenommen und nicht von uns.“ https://youtu.be/QxCx6fSCHis
Ein Schlüssel kommt schon mal gar nicht an irgendwelche Daten ran…wenn überhaupt, dann kommt nur der User, der den Schlüssel bedienen kann, an diese Daten heran!
Das ist das Prinzip, wie VPS-Anbieter arbeiten, wenn sie dir einen beschränkten Root-Zugriff, auf einen gewissen Teil des dedizierten Servers geben. Das hat aber irgendwie nichts mit einer echten End-2-End Verschlüsselung zu tun, die bei Messengern eingesetzt wird!
Die Ende-zu-Ende-Verschlüsselung ermöglicht einen sicheren Informationsaustausch zwischen zwei Kommunikationspartnern. Sämtliche übertragenen Informationen werden vom Sender verschlüsselt und erst wieder beim Empfänger entschlüsselt. Über die komplette Übertragungsstrecke liegen die Daten nur in verschlüsselter Form vor. Dritte wie Zwischenstationen oder Serviceprovider können nicht auf die Inhalte zugreifen. Für sie sind nur Steuerinformationen verfügbar, mit denen die Weiterleitung oder das Routing der verschlüsselten Informationen möglich ist.
In der Regel nutzt die End-to-End-Encryption symmetrische oder asymmetrische Verschlüsselungsverfahren. Bei symmetrischen Verfahren sind die beiden Kommunikationspartner im Besitz eines geheimen Schlüssels, mit dem sie die Daten ver- und entschlüsseln. Gerät der geheime Schlüssel in den Besitz eines Unbefugten, kann dieser ebenfalls sämtlich Daten ver- und entschlüsseln. Damit zwei Kommunikationspartner mit dem symmetrischen Verfahren Daten Ende-zu-Ende-verschlüsselt austauschen können, müssen sie zuvor den geheimen Schlüssel vereinbart und ausgetauscht haben.
Die asymmetrische Verschlüsselung nutzt öffentliche und private Schlüssel. Der öffentliche Schlüssel eines Kommunikationspartners A ist für jedermann zugänglich. Mit einem öffentlichen Schlüssel verschlüsselte Daten sind jedoch nur mit dem zugehörigen privaten Schlüssel wieder zu entschlüsseln. Der private Schlüssel ist nur dem Kommunikationspartner A bekannt. Man nennt dieses Verfahren auch Public Key Encryption. Es bietet den Vorteil, dass die geheimen Schlüssel vor der Kommunikation nicht ausgetauscht werden müssen und private Schlüssel immer lokal bei einem Kommunikationspartner bleiben. Es ist bei der Methode zu vermeiden, dass ein falscher öffentlicher Schlüssel untergeschoben werden kann. Dies stellen die Public-Key-Infrastruktur (PKI), Zertifizierungsstellen (CA) und digitale Zertifikate sicher.
Dankeschön für eine kleine Verbesserung. Ich nutze dieses Verfahren und nutze auf meinem Server Public Key Encryption den du beschrieben, hast. Daher kenne ich etwas mich damit aus, doch nur nicht so gut wie du. Wenn, ich du, schreiben sagen darf bei mir liegt der Grund meiner Grammatik oder das ich was vergesse dabei zu schreiben ist das ich einen Tag später denselben Unfall hatte wie Schumacher bei mir mit dem Fahrrad. Das stimmt. Das einzige, was du machen kannst, wenn du über den Master Rekord auf meine ssh Key Ordner der selbst noch mal mit 256 Bit verschlüsselt ist. Trotzdem hast du sonst recht daher die Verschlüsselung des Ordners noch mal extra und auf dem Server ist alles nochmal höher verschlüsselt. Danke für deine Antwort dazu. Bleibe gesund. Ach ich nutze zu Hause nur Linux Debian und kein Windows und auf dem Handy auch nur Linux und kein Android oder Apple. Bist du Programmiere oder woher hast du dein Wissen gesammelt, wenn ich dich fragen darf. Also nochmal bleib gesund.
Vielen Dank und dito natürlich!
Gott bewahre…NEIN. Mein Nachbar ist ein Coder und ich sehe jeden Tag, was er für ne verpeilte Type ist… 
Ich komme da wohl eher aus der Netzwerktechnik und dort ist Verschlüsselung und die Prinzipien dahinter natürlich das A und O in vielen Teilen. Und übrigens ist ein „du“ in Foren weitaus lieber gesehen, als so ein förmliches „sie“! Das mit dem Unfall tut mir leid - allerdings kann man von dir, im Gegensatz zu Schumi, hier etwas von dir lesen…und das ist ja wohl schon einiges wert! 
1 „Gefällt mir“
Du bist Lady Carneval?
Ich hab mich halt gewundert weil der Threema CEO gesagt hat, das ginge technisch gar nicht. Muss ja nicht heißen, dass unsere Politiker das hinbekommen, sich auf einen Generalschlüssel zu einigen. Oder den in Software implementieren statt als Hardwaretoken, so dass der kopiert werden kann. Oder vom Hardwaretokenhersteller veräppelt werden wie die Schweizer Geheimdienste neulich. Naja, der Threema CEO wird schon seine Gründe haben, wenn er so ein Statement rausposaunt, obwohl er es eigentlich besser wissen müsste.
Damit hat er doch eigentlich recht!
Zu der Ver- und Entschlüsselung der Nachrichten kommt es direkt auf den Geräten der kommunizierenden Subjekte. Threema nutzt die asymmetrischen Chiffren ECC von 256 Bits. Für die Kommunikation setzt sie die Verschlüsselung XSalsa20 ein. Für den Schlüsselaustausch dann ECDH mit Curve 25519. Neben der Datenübertragung müssen auch die in dem Handy gespeicherten Daten abgesichert werden. Dieses erreicht Threema mit abgesicherten Datenbanken und einem Sandbox, der den Zugang von anderen Anwendungen zu den Daten unmöglich macht. Selbstverständlich ist auch die sog. Forward secrecy-Funktion, die das zukünftige Durchbrechen der eingetragenen Netzkommunikation verhindert. Während der Serververbindung verlässt sich Threema nur auf zeitweilige Schlüssel, die in RAM gespeichert sind und die sich bei jedem Neustart der App ändern.
Wie sollte dann also ein ständiger Generalschlüssel technisch machbar sein, der explizit für jeden User und jede Nachricht gültig wäre?? Insofern hat der Threema CEO doch völlig recht, wenn er das verneint!
P.S.
Wer weiß das schon so genau!
Laut Wikipedia ist XSalsa20 ein symmetrisches Verschlüsselungsverfahren mit 256 Bit Schlüssellänge. Threema müsste also diesen 256 Bit Schlüssel bei jeder Kommunikation mit dem öffentlichen Schlüssel der EU verschlüsseln, das gibt einen Overhead von mindestens 256 Bit pro Kommunikation. Ein Geheimdienst oder wer auch immer ein EU Hardwaretoken ergattert hat, würde dann diese 256 Bit in das Hardwaretoken einfüttern und dieses würde den XSalsa20 Schlüssel ausgeben. Damit ließe sich dann diese eine Kommunikation mitlesen. Also technisch sehe ich da kein Problem. Wenn der Threema CEO das nicht einbauen will, dann ist das natürlich seine Sache, weil ihm dann vielleicht die Klientel davonlaufen würde.