Threema Desktop Client - openMittsu

Stelle deine Frage öffentlich an die Threema-Forum-Community - über 4.600 Mitglieder helfen dir weiter. > Frage stellen <
  • Vermutlich wird die Absender-ID für den Server sichtbar übertragen (aber natürlich schon transportverschlüsselt, nur nicht E2E): der Empfänger sieht auf seinem Sperrbildschirm, falls der Absender keinen Nickname gesetzt hat, dass eine neue Nachricht von ID ABCDEFGH eingetroffen ist. Da diese Absender-ID auch unter iOS, das ja bekanntlich keine Hintergrundaktivitäten zum Entschlüsseln zulässt, im Sperrbildschirm angezeigt wird, muss die ID wohl nur transportverschlüsselt und damit für den Server sichtbar übertragen werden...

    Kann das jemand bestätigen/widerlegen, der das Threema-Protokoll besser kennt?


    - AndyG

    Einmal editiert, zuletzt von andyg (12. Juni 2016 um 10:38)

  • Das geht technisch kaum anders. Der Empfänger muss ja wissen, welches Schlüsselpaar er nutzen muss, um die Nachricht zu entschlüsseln. Er kann schlecht alle möglichen Kombinationen ausprobieren. Also, gehen würde das schon, aber die App würde schon mit wenigen Kontakten extrem langsam werden.

    (Um Verwirrung zu vermeiden: Ich arbeite bei Threema, spreche hier aber für mich.)

  • ...Braucht der Empfänger zum Entschlüsseln bei asymmetrischer Verschlüsselung nicht einfach nur seinen eigenen privaten Schlüssel? Entschlüsselung sollte doch eigentlich unabhängig vom Absender möglich sein, also ohne Schlüsseldurchprobieren etc., oder?

    Was anderes ist natürlich die Überprüfung der Signatur, dazu ist der öffentliche Schlüssel des Absenders erforderlich - aber die Signatur kann ja nach Entschlüsselung überprüft werden, d.h. die Absender-ID kann durchaus verschlüsselt sein.

    Oder funktioniert NaCl anders?

    AndyG

    Einmal editiert, zuletzt von andyg (12. Juni 2016 um 16:56)

  • Ja, die NaCl Public-Key Authenticated Encryption (ist also ein AE-Verfahren) benötigt zum Ver- und Entschlüsseln beide Schlüssel. Daraus wird das gemeinsame Shared Secret errechnet, was dann zur Ver- und Entschlüsselung genutzt wird.
    Außerdem: Ohne Information des Empfängers hat der Threema Server keine Ahnung, wem die Nachricht zugestellt werden soll.

    Das passt hier ehrlich gesagt aber nicht zum Thread. Wenn dich das Thema interessiert, schau doch mal ins Whitepaper von Threema.

    (Um Verwirrung zu vermeiden: Ich arbeite bei Threema, spreche hier aber für mich.)


  • Ja, die NaCl Public-Key Authenticated Encryption (ist also ein AE-Verfahren) benötigt zum Ver- und Entschlüsseln beide Schlüssel. Daraus wird das gemeinsame Shared Secret errechnet, was dann zur Ver- und Entschlüsselung genutzt wird.


    Danke! Werde mir das Whitepaper mal genauer ansehen.

    Zitat


    Außerdem: Ohne Information des Empfängers hat der Threema Server keine Ahnung, wem die Nachricht zugestellt werden soll.


    Das ist freilich klar - es ging aber um die Absender-ID [emoji6]


    - AndyG

  • OK, die ganze Verschlüsselungsgeschichte ist für mich auf dem Desktop unwichtig. Deshalb fand ich eure Diskussion dazu nicht nur zu "fachbegrifflich" sondern für mich auch unwichtig. Hab also den kleinen Abschnitt mit der SQL DB übersehen.
    Wie gesagt, mir würd es langen wenn einfach Textdateien je Kontakt zum speichern dienen würden.


  • OK, die ganze Verschlüsselungsgeschichte ist für mich auf dem Desktop unwichtig.

    Wie gesagt, mir würd es langen wenn einfach Textdateien je Kontakt zum speichern dienen würden.


    Kann ich nachvollziehen.

    Allerdings ist im Zeitalter allgegenwärtiger Malware/Trojaner/... gerade auf dem PC eine verschlüsselte Speicherung sehr sinnvoll. Meiner Meinung nach müsste es eigentlich so sein, das Daten grundsätzlich immer verschlüsselt abgelegt werden, also unverschlüsselte Daten nur in ganz wenigen Ausnahmefällen vorliegen. Also genau umgekehrt, wie es der gegenwärtige Zustand ist...


    - AndyG

  • Okay, ich denke ich kann hier mal eine kurze Übersicht über meine Pläne geben:

    Mein Ziel ist es, nur noch eine Datei zu haben, welche Privaten Schlüssel, ID, Kontakte, gesendete und empfangene Nachrichten sowie ausgetauschte Fotos/Files/Videos enthält.
    Eigentlich wollte ich hierfür eine Art SQLite Datenbank benutzen (soweit so einfach), welche verschlüsselt ist. D.h. beim Starten müsste der Benutzer ein Passwort eingeben, um die gesamten Daten zu entsperren/entschlüsseln.

    Leider gibt es wenige Implementierungen dieser Technik und die meisten sind nur kommerziell erhältlich. Solche, die auch kostenfrei erhältlich sind, scheinen mir extra so schlecht dokumentiert zu sein, als dass sich der Entwickler am Ende doch für kommerziellen Support entscheiden soll, anstatt genervt rum zu basteln.

    Da ich kein Geld für eine Lizenz habe, ist der mittelfristige Weg wohl, den Plan einfach minus der Verschlüsselung umzusetzen.
    Für die Speicherung des Nachrichtenverlaufs muss allerdings noch einiges angepasst werden und auch einiges im UI neu implementiert werden - dafür habe ich aktuell wenig Zeit. Von meiner Seite heißt das: Wenn es nicht jemand anderes tut, wird es irgendwann kommen, ich kann nur nicht sagen, wann.


  • wenn dein PC infiltriert ist, liegt eh Zugriff auf den Klartext vor

    Ich sage: Nein. Es geht nicht um die ultimative Sicherheit, sondern um Risikobegrenzung.

    Wenn die DB verschlüsselt ist, muss erstmal die Applikation laufen, dass auf die Daten zugegriffen werden kann. Das ist schon recht aufwendig und selbst dann werden wohl auch nicht alle Nachrichten im Arbeitsspeicher liegen. Selbst wenn der Schlüssel für die DB irgendwo daneben im Klartext liegen würde, ist das für den Angreifer aufwendiger. Ein Angriff müsste schon speziell auf das Problem zugeschnitten sein.

    Man muss einfach schauen, wie viel Aufwand gerechtfertigt ist. Bspw. ist es recht einfach SQLite mit AES-Encryption zum Laufen zu bekommen. In-Memory-Protection dahingegehen ist schon schwieriger.
    [hr]


    Okay, ich denke ich kann hier mal eine kurze Übersicht über meine Pläne geben:

    Mein Ziel ist es, nur noch eine Datei zu haben, welche Privaten Schlüssel, ID, Kontakte, gesendete und empfangene Nachrichten sowie ausgetauschte Fotos/Files/Videos enthält.
    Eigentlich wollte ich hierfür eine Art SQLite Datenbank benutzen (soweit so einfach), welche verschlüsselt ist. D.h. beim Starten müsste der Benutzer ein Passwort eingeben, um die gesamten Daten zu entsperren/entschlüsseln.

    Leider gibt es wenige Implementierungen dieser Technik und die meisten sind nur kommerziell erhältlich. Solche, die auch kostenfrei erhältlich sind, scheinen mir extra so schlecht dokumentiert zu sein, als dass sich der Entwickler am Ende doch für kommerziellen Support entscheiden soll, anstatt genervt rum zu basteln.

    Da ich kein Geld für eine Lizenz habe, ist der mittelfristige Weg wohl, den Plan einfach minus der Verschlüsselung umzusetzen.
    Für die Speicherung des Nachrichtenverlaufs muss allerdings noch einiges angepasst werden und auch einiges im UI neu implementiert werden - dafür habe ich aktuell wenig Zeit. Von meiner Seite heißt das: Wenn es nicht jemand anderes tut, wird es irgendwann kommen, ich kann nur nicht sagen, wann.

    Threema nutzt SQLCipher. Ich würde empfehlen, einfach die Threema Datenbank as is zu öffnen und die Daten daraus zu extrahieren. Das würde zwei Fliegen mit einer Klappe schlagen: Importieren von Daten aus der Threema App wäre möglich und du brauchst kein eigenes Datenbankformat entwickeln.

    (Um Verwirrung zu vermeiden: Ich arbeite bei Threema, spreche hier aber für mich.)

    Einmal editiert, zuletzt von f09fa681 (18. Juni 2016 um 13:36)

  • Threema nutzt SQLCipher. Ich würde empfehlen, einfach die Threema Datenbank as is zu öffnen und die Daten daraus zu extrahieren. Das würde zwei Fliegen mit einer Klappe schlagen: Importieren von Daten aus der Threema App wäre möglich und du brauchst kein eigenes Datenbankformat entwickeln.


    Ich versuche auch SQLCipher zu nutzen ;)
    Leider ist mein Smartphone aktuell nicht gerootet, ich vermute mal ich komme an die Datenbank nur mit Root-Rechten heran.

    Falls du eine Möglichkeit hast, mir ein Test-Exemplar zur Verfügung zu stellen, sehe ich mir das gerne an! Vielleicht einfach mit einer neuen ID plus ein paar Messages an EchoTest o.ä..
    Das Backup ist ja (leider) nur ein ZIP File mit Verschlüsselung.


  • Falls du eine Möglichkeit hast, mir ein Test-Exemplar zur Verfügung zu stellen, sehe ich mir das gerne an! Vielleicht einfach mit einer neuen ID plus ein paar Messages an EchoTest o.ä..
    Das Backup ist ja (leider) nur ein ZIP File mit Verschlüsselung.

    Das wird zeitlich bei mir momentan auch nichts. Aber wenn jemand Zeit hat: Mit dem default AVD Android Emulator müsste es doch gehen, an die Daten heranzukommen?

    (Um Verwirrung zu vermeiden: Ich arbeite bei Threema, spreche hier aber für mich.)