andere Sicht

Der Artikel stammt von 2021 - schon allein aufgrund Multi-Device - was bald für alle Betriebssysteme kommt - sollte sich einiges geändert haben?

Siehe hier von damals:

Beitrag

RE: Berichte über andere Messenger

Das ist zwar nicht wirklich ein Artikel, aber im Signal Forum gibt es einen Post von einem User über Threema (in Englisch), der erklären will, warum Threema's Verschlüsselung trotz des neuen IBEX Protokolls und die Sicherheit von Gruppenchats im Vergleich mit Signal's Implementierung unterlegen ist (ich habe den Text mal hier her kopiert):

[…]

JonnyDee

16. Dezember 2022 um 07:12

Zitat von jnL

Siehe hier von damals:

Das ist aber nicht exakt das gleiche Thema.

Der Stand ist folgender:

• No Forward Security: Gibt's mittlerweile.
• Threema IDs Aren't Scalable: Praktisch nicht relevant, da man die Threema ID mit einer validen Lizenz registrieren muss und die Anzahl IDs limitiert ist, welche man mit einer Lizenz erstellen kann. Sogar ein reines Rate Limit würde ausreichen, um das zu mitigieren. Selbst wenn man jede Millisekunde eine ID registrieren könnte, bräuchte man mehrere Jahrzehnte, um alle IDs aufgebraucht zu haben. Bevor das ein Problem wird, hat Threema genug Zeit den Code zu erweitern, sodass z.B. längere IDs möglich sind.
• Peer Fingerprints Aren't Collision-Resistant: Hat Soatok selbst mit Impact: None markiert. Wird womöglich bei Gelegenheit mal geändert, dass einfach der vollständige Public Key im QR Code angezeigt wird. Gibt heute eigentlich keinen Grund mehr das so zu machen. Vor 10 Jahren waren Smartphonekameras aber noch Mist.
• No Broadcrump for Cryptography Migrations: Hat Sotak selbst mit Severity: None markiert, sprich kryptografisch nicht relevant. Das Forward Security Protokoll hat zudem gezeigt, dass das geht und wie man mit Downgrades umgehen kann. Ich teile zwar durchaus die Frustration an einigen altlastigen Ecken des Protokolls (man kann nicht einfach wie bei TLS die Krypto anheben), allerdings sind das alles keine realen Blocker.
• Inconsistency with Cryptographic Randomness: Hat Sotak selbst mit Severity: None markiert. Ich bin mir nicht sicher, wie das damals im Whitepaper gelandet ist, denn wenn ich im Code nachschaue, wird unter iOS seit 12 Jahren /dev/urandom referenziert. Es wurden meines Wissens jedenfalls schon immer ausschliesslich CSPRNGs für kryptografische Anwendungen verwendet. (Fehler sind natürlich trotzdem möglich.)
• Invisible Salamanders with Group Messaging: Wie im anderen Thread erwähnt, ist das derzeit nicht Teil des Threat Models. Die Zeit wird zeigen, ob die Infosec-Community das als "must have" sieht. (Worum geht es hier: Man kann z.B. an alle TeilnehmerInnen einer Gruppe eine Nachricht senden und diese hat überall einen anderen Inhalt.)
• Weak Encryption with Master Key (LocalCrypto): Ein besserer KDF für den Master Key auf Android wurde bereits Anfang 2021 eingeführt. Wann genau der Code released wurde, müsste ich selbst nachforschen. Zur Einordnung: KDFs müssen immer wieder mal geupdated werden, sodass sie auch auf aktuellen Systemen genügend Ressourcen beanspruchen, um das Passwort ausreichend zu schützen. Man kann definitiv bemängeln, dass sich Threema hier etwas viel Zeit gelassen hat, die Parameter anzupassen. Die alten Verfahren existieren im Code nur noch zwecks Migration. Der Obfuscation Key wurde damals noch im Code entsprechend zwecks Einordnung kommentiert, Zitat: Introduced in really old app versions (long before APIs like the Android keystore system existed) back when the app was closed source and retained for compatibility; of course pretty pointless in an open source app, but does no harm either). Der Obfuscation Key war auch nie als Encryption gedacht, sondern sollte nur extrem simple Scraping-Angriffe mitigieren.
• File Encryption Uses Unauthenticated CBC Mode: Nicht schön aber auch nicht problematisch, weil nur lokal. Den Punkt bzgl. inkonsequenter Nutzung von SecureRandom nehme ich nochmal auf. Ist damals wohl vergessen worden. (Die Fussnote im Whitepaper ist unnötig, da ab Android 5 irrelevant, was derzeit eh Threema's Minimalanforderung ist.)
• Cache-Timing Leaks with Hex-Encoding: Die gezeigte Stelle ist praktisch nicht relevant, weil es nicht für Secrets verwendet wird. Und selbst wenn, wie Soatok selbst schrieb: This isn’t a meaningfully practical risk. Sollte bei Gelegenheit aber dennoch angepasst werden. (Hab ich auch nochmal aufgenommen.)
• Insecure Password-Based Key Derivation: Valide Kritik und wurde damals anschliessend auch direkt angepasst. (Die API `Uint8Array.from(password, 'utf-8')` existiert übrigens nicht im Web. Soatok verwechselt DOM mit Node APIs.)

Danke für den Reminder, da nochmal drüberzugehen.