Im Grunde ist Ende-zu-Ende verschlüsselung witzlos, wenn sie in einem geschlossenen Code steckt. Hilft vielleicht gegen mithören von Anderen (aber das tut normale Verschlüsselung zum Server beispielsweise mittels TLS auch), aber man kann kaum sichergehen, dass auch der Anbieter wirklich nicht mitlesen kann.
Davon abgesehen, sind mir beim Lesen von Artikel und Kommentaren ein paar Fehler aufgefallen.
PGP bietet anders als im Artikel keine Perfect Forward Secrecy. Zum Verschlüsseln des symmetrischen Sitzungsschlüssel (der am Anfang der Nachricht steht) wird stets der öffentliche Schlüssel des Empfängers genutzt. Wird der dazugehörige private Schlüssel bekannt, so lässt sich sämtliche Konversation entschlüsseln. Anders gehts auch kaum, man kann ja vor dem Mailversand nicht erst Schlüsselaustauschmails versenden
Bei dem hier wohl eingesetzten Verfahren mit Perfect Forward Secrecy wird der öffentliche Schlüssel des Empfängers nicht zum Verschlüsseln verwendet, sondern einzig zum Überprüfen der Signatur, mit der die Diffie-Hellman-Token signiert sind.
Bei Textsecure läuft der Schlüsselaustausch im Grunde so ab:
Jeder Nutzer erstellt mehrere Paare der Form (K,K^a) in einer endlichen Gruppe, wobei K diese zyklisch erzeugt. Diese Paare werden mit dem privaten Schlüssel signiert (der Fingerabdruck des Schlüssels ist im Programm sichtbar, falls man dies möchte) und auf den Textsecure-Server geladen.
Möchte nun ein anderer Nutzer eine Nachricht senden, so holt er sich ein Paar vom Server und überprüft die Signatur. Ist diese korrekt, so bestimmt er einen Wert b, verschlüsselt den Sitzungsschlüssel mit K^(a*b) und hängt diesen zusammen mit dem Wert K^b an den Anfang der Nachricht.
Da der diskrete Logarithmus "schwer" zu lösen ist, ist einem Angreifer weder a noch b bekannt, der Empfänger kennt jedoch da von ihm erzeugte a und kann aus K^b K^(a*b) bestimmen und den Sitzungsschlüssel entschlüsseln.
Ist der Code der Clientapp überprüfbar (wie bei Textsecure, das Opensource ist)), so ist dieses Verfahren sicher (sofern der diskrete Logarithmus wirklich schwer ist).
Da die hier scheinbar implimentierte Verschlüsselung vom Textsecure-Entwickler kommt, wird sie wohl genauso funktionieren. Nur kann es wohl keiner überprüfen.
@übermir: Das ist Unsinn. Selbstverständlich ist das Verfahren sicher. Die Kenntnis des Algorithmus bringt dir nichts (und der ist wohl bekannt) und der ComServer weiß garnichts, daher ist ein Zugriff darauf völlig nutzlos.
Man-In-The-Middle Angriffe werden durch das Signieren der DH-Token erschwert und könnten wahrscheinlich nur vom ComServer durchgeführt werden (da sich dieser wahrscheinlich ebenfalls mit einem Zertifikat ausweist und somit kein weiterer "Man" in der Mitte sitzen kann).
Um auch dies zu verhindern, könnte man jedoch die Fingerabdrücke der Schlüssel vergleichen, Textsecure beispielsweise zeigt sie einem an. Damit wäre es dann völlig unmöglich.
