inputs:

• salt: empty
• info: "aes-key" encoded (UTF-8)
• secret1 || secret2: concatenation of byte arrays

Kontext:
Nicht-Ziele sollten formuliert werden, um die Sicherheitsgarantien des Systems klar zu benennen.

• Deniability oder Non-repudiation: Beides scheint nicht Ziel zu sein, aber das Konzept scheint sich 'noch unsicher' zu sein, wie etwa Formulierungen wie "Falls Alice die Verschlüsselung authentifiziert hat" nahelegen.
• Ohne persistenten Speicher der Clients wird Forward Secrecy (Nicht der benannte Teil mit User werden ausgeschlossen, sondern was passiert, wenn ein User sein Langzeitgeheimnis verliert) nicht umsetzbar sein. Das sollte dokumentiert sein.
• Das Konzept nutzt ein KEM-Interface, das nahelegt, dass eine authentisierte KEM (aKEM) genutzt wird. Der symmetrische Ciphertext ist aber nicht an den resultierenden Schlüssel gebunden, entsprechend ist der Ciphertext trotz aKEM nicht authentisch. Das Konzept nimmt dies zwar in den Annahmen an, könnte aber durchaus expliziter sein, warum dies nicht umgesetzt wird.

Derzeit spricht das Konzept von 16 Byte AES-Schlüssellänge: new_board_key = prng(16). An sich ist AES mittels Grover's algorithm von Quantencomputer ebenfalls betroffen, jedoch nur quadratisch im Sicherheitsparameter, dh die Suche nach dem korrekten Schlüssel kann in O(2^(n/2)) statt O(2^n) funktionieren. Damit wäre AES-128 "asymptotisch" nicht mehr sicher genug bei einem angestrebten Sicherheitslevel von >=100bit.

Wenn AES-256 performance-technisch einfach gewählt werden kann, dann sollten wir das vermutlich machen. Ansonsten müssten wir nochmal genauer auf die anderen relevanten Faktoren schauen (NIST erwartet, dass AES-128 noch deutlich länger ok ist; Grover ist nicht wirklich parallelisierbar, dh 2^64 ist viel; siehe auch https://crypto.stackexchange.com/questions/102671/is-aes-128-quantum-safe/102672#102672 oder https://security.stackexchange.com/questions/48022/what-kinds-of-encryption-are-not-breakable-via-quantum-computers/48027#48027)

Kontext:

• Einige Pseudocodeschnipsel sind sehr weit von tatsächlichen Interfaces entfernt:
  key_encryption_key = HKDF(secret1, secret2): Welche Inputs sind das? Auf was sind weitere Inputs gesetzt? Soll , hier die Konkatenation des Input Key Material (IKM) sein oder wird eins der Geheimnisse etwa in den info-Paramter geschoben?
  iv = sha256(board_id): Vermutlich wieder getrimmt auf 12 Byte? GCM akzeptiert auch längere IVs als Input, daher ist hier wichtig, dass die Spezifikation konkret ist. Entsprechende Frage stellt sich häufiger im Kontext mit sha256.
• Zusätzlich zum obengenannten Problem der Wiederverwendung von IVs durch Verstellen der Uhrzeit bei encrypted_postit_content = aes256gcm(postit_content, board_key, sha256(postit_id + ts)) stellt sich auch die Frage, was mit postit_id + ts gemeint ist. Bei Addition oder simpler Konkatenation (10 || 123 == 1 || 0123) kann dies ebenfalls zur Wiederholung des IVs und damit zum fatalen Scheitern von GCM führen.

Kontext: #22 (comment)

• objectId erklären
• Verwendung des Endpunkts erklären

Formulierung + API-Spezifikation anpassen.

Kontext:
"Aus der Post-It ID und dem Zeitstempel ergibt sich der IV für die Verschlüsselung des Inhalts" bedeutet, dass wenn 2 Clients gleichzeitig ein Post-It bearbeiten, kann es zur erneuten Nutzung eines Initialisierungsvektors kommen. Re-use vom IV ist unter GCM fatal und ermöglicht die Rekonstruktion des GHASH-Schlüssels und jede Integrität geht verloren.

Basierend auf der Version aus Mattermost vom 5.12.22

Größere Probleme

• Das größte Problem, das ich sehe, ist Key Management. Die Clients wissen nichts von den PubKeys und vertrauen komplett dem Server, dh jede Verschlüsselung geht an einen vom Server bestimmten PubKey. An sich ist damit sofort E2EE kaputt. Der Server kann das auch konsistent durchziehen und den abgefangenen board_key neu für den eigentlichem Empfänger verschlüsseln. Weiter kann dem Sender für den einen Empfänger und dem Empfänger für den einen Sender immer der ServerKey ausgegeben werden (also klassischer MitM). Das braucht der Server nur einmal pro board_key machen, d.h. es ist auch kein wirklich komplexer Split State.
  • Messenger haben für sowas den Fingerprintabgleich und einen Speicher für die Keys (sodass es dann zumindest TOFU ist und nicht Trust On Every Use).
  • Es wird schwer, dieses Problem zu beheben, solange Clients beliebig wechselnde Browser sind.
  • Vielleicht Zertifikate oÄ
    • Große Frage ist dann, woher das Vertrauen in die Zertifikate/ein Root-Cert kommt
• Generell kann eine Web-Applikation nicht gegen den Server verteidigen, da dieser immer böses Javascript nachladen kann, welches lokale Speicher ausließt.
• Jedes Post-It wird separat verschlüsselt, ohne im Kontext der anderen zu stehen und ohne dessen Metainformationen wie Position festzuhalten. Deshalb kann der Server die Post-Its austauschen, indem er die Positionen ändert. Des Weiteren kann er jeden Post-It unabhängig von den anderen auf einen beliebigen alten Stand bringen, d.h. das Gesamtsystem hat keine Integrität, nur die einzelnen Post-Its für sich alleine.
  • Grund ist (nachvollziehbarerweise) das komplexe Handling bei gleichzeitiger Bearbeitung, dann sollte aber das Post-It deutlich als Security Boundary genannt werden und Schutz eines Boards explizit als Non-Goal.
• "Aus der Post-It ID und dem Zeitstempel ergibt sich der IV für die Verschlüsselung des Inhalts" bedeutet, dass wenn 2 Clients gleichzeitig ein Post-It bearbeiten, kann es zur erneuten Nutzung eines Initialisierungsvektors kommen. Re-use vom IV ist unter GCM fatal und ermöglicht die Rekonstruktion des GHASH-Schlüssels und jede Integrität geht verloren. Entsprechendes kann passieren, wenn ein Client eine falsch laufende Uhr hat oder schnelle Änderungen mit sehr grobkörniger Uhr (zB Browser-Umgebung) unternimmt).
  • Implementation-Detail: Wenn nicht unixTime, sondern dateString, dann gibt es das Problem auch bei Zeitumstellung oder ggf. Zeitzonen.
• Bei der Berechnung des encryption_key für die verschlüsselten privateKeys des Users wird das user_password genutzt, dass beim Login auch an den Server gesendet wird. Entsprechend hat der Server auch als passiver Angreifer alle Informationen, um das Board mitzulesen.
  • Lösung könnte eine aPAKE wie etwa OPAQUE sein.
  • Weiter wäre ein separates Passwort denkbar, sodass der Server zumindest aktives Eingreifen benötigt, um die Vertraulichkeit zu brechen.

Empfehlungen / weitere Schwachstellen

• Domain separation für Hashfunktionen, zum Beispiel bei Generierung von IDs oder IVs, sodass gleicher Input nicht zu gleichen Werten führt.
• encryption_key = pbkdf2(user_password, salt)
  • PBKDF2 erlaubt einen Offline-Angriff auf das user_password durch den Server oder jemanden, der den Server/die Datenbank kompromittiert. Die anschließende Verschlüsselung encrypted private key = aes256gcm(private key, encryption key, iv) erlaubt, ebenfalls offline, eine Überprüfung des geratenen Passworts. Ein PAKE, beispielsweise OPAQUE, könnte hier Abhilfe schaffen. Wird hier der serverseitige-OPRF-Schlüssel gemeinsam mit der Passwortdatenbank geleakt, besteht das Problem allerdings trotzdem weiter (der Server kann immer einen Client mit Passwort X simulieren, wenn dessen einziges Geheimnis dieses Passwort ist).
• Inhaltsdaten sind mit GCM verschlüsselt. GCM ist nicht key-committing, d.h. ein Ciphertext kann unter mehreren Schlüsseln erfolgreich entschlüsselt werden und diese Schlüssel können von einem bösen Angreifer effizient berechnet werden. Dabei steht ein Großteil der anschließend entschlüsselten Nachrichten unter Angreiferkontrolle. Siehe etwa Paper oder Blog. Das würde einem User erlauben für andere User verschiedene Versionen unter dem gleichen symmetrischen Ciphertext zu erstellen, sodass für User A und User B ein Post-It unterschiedlichen Inhalt hat. Man beachte, dass dies ohne Beteiligung des Servers funktioniert und von diesem nicht erkennbar ist.
  • Lösung könnte hier ein committendes Verfahren sein, z.B. die Kombination aus einem normalen Modus (etwa CTR) und einer MAC, wobei Schlüssel für beide abhängig voneinander generiert werden, etwa HKDF-Ableitung mit unterschiedlichem info-Paramter.

Unpräzise Formulierungen

• "gewinnt die Verwendung von Kyber über die Zeit an Sicherheit": Kyber gewinnt nicht an Sicherheit, sondern die Erwartungshaltung gegenüber Kyber wird besser (falls es keine neuen Angriffe gibt).
• Das Konzept macht nicht klar, woher die ID eines Post-Its kommt, da es nur die Veränderung darstellt. Käme die ID vom Server, kann dieser gezielter Inhalte mehrere Post-Its vertauschen.
• "Technisch lässt sich auch RSA mit EC kombinieren, aber dies hat keinen praktischen Nutzen": Nicht ganz korrekt. Ähnlich wie PQC wäre die Möglichkeit ein Kryptosystem zu kreieren, dass standhält, wenn eines der beiden Verfahren noch sicher ist. Für beide Verfahren ist sicher, dass die nicht post-quanten-sicher sind, aber ein Bruch von RSA ohne signifikante Fortschritte bei der Faktorisierung und entsprechend beim diskreten Logarithmus auf elliptischen Kurver wäre denkbar.
• "Anschließend verhindert der Server das Hinzufügen von Änderungen, die unter einem anderen Board key verschlüsselt wurden": Das heißt es gibt keine Umschlüsselung für existierende Ciphertexte? Gibt es einen Modus, der dies erlaubt, wenn beispielsweise der alte BoardKey kompromittiert wurde? Heißt das, dass alle alten BoardKeys für neue Nutzer verschlüsselt werden (Prozess zum Teilen des Boards erwähnt nur einen Key)?
• "Will ein Nutzer beispielsweise ein RSA Schlüsselpaar durch ein EC Schlüsselpaar ablösen, wird das aktuelle Kyber-Schlüsselpaar zusammen mit dem neuen EC Schlüsselpaar registriert": Die Folgen sind hier nicht angerissen. Wenn User A von (RSA, Kyber) zu (EC, Kyber) wechselt, wird dann das (RSA, Kyber)-Paar gesperrt? Wie findet das Lesen von an das (RSA, Kyber)-Paar adressierten Ciphertexten statt? Wie wird verhindert, dass neue Ciphertexte für das alte Paar angelegt werden? Wie verhält sich User B mit (RSA, Kyber)-Paar, der bei aKEMs nicht mit dem neuen (EC, Kyber)-Paar interagieren kann?
• Einige Pseudocodeschnipsel sind sehr weit von tatsächlichen Interfaces entfernt:
  • key_encryption_key = HKDF(secret1, secret2): Welche Inputs sind das? Auf was sind weitere Inputs gesetzt? Soll , hier die Konkatenation des Input Key Material (IKM) sein oder wird eins der Geheimnisse etwa in den info-Paramter geschoben?
  • iv = sha256(board_id): Vermutlich wieder getrimmt auf 12 Byte? GCM akzeptiert auch längere IVs als Input, daher ist hier wichtig, dass die Spezifikation konkret ist. Entsprechende Frage stellt sich häufiger im Kontext mit sha256.

Implementierungsdetails

• Die Entschlüsselung eines Post-Its (bzw. zugehörigem Event) scheint über die boardKeyId geregelt zu sein. Wird dabei geprüft, ob der entsprechende BoardKey zu diesem Board gehört? Ansonsten kann der Server Post-Its von anderen Boards auf dem entsprechenden Board anzeigen. Dies könnte insbesondere problematisch sein, wenn verschiedene Boards unterschiedliche Vertraulichkeitsstufen haben. Szenario: Öffentliche Video-Präsentation eines öffentlichen Boards und der Server zeigt ein Post-It eines vertraulichen Boards an und erfährt den Inhalt über den Video-Stream.
• Zusätzlich zum obengenannten Problem der Wiederverwendung von IVs durch Verstellen der Uhrzeit bei encrypted_postit_content = aes256gcm(postit_content, board_key, sha256(postit_id + ts)) stellt sich auch die Frage, was mit postit_id + ts gemeint ist. Bei Addition oder simpler Konkatenation (10 || 123 == 1 || 0123) kann dies ebenfalls zur Wiederholung des IVs und damit zum fatalen Scheitern von GCM führen.
• Wie wird das gleichzeitige Entfernen von User X durch User A und Hinzufügen von User Y durch User B gelöst?
  • Entfernen rotiert den aktuellen BoardKey, aber der neue Schlüssel wird nicht für User Y hinzugefügt, weil Y aus Sicht von A nicht Teil des Boards ist.
  • Hinzufügen teilt den aktuellen Schlüssel, der User B aber nicht bekannt ist, weil er zeitgleich rotiert wird. Dadurch erhält User Y den Schlüssel weder von A noch B.
• Wie wird "Passwort vergessen" umgesetzt, sodass der Server diese Funktionalität nicht missbrauchen kann, um einen von ihm kontrollierten Schlüssel zu provisionieren?

Weitere Anmerkungen

• Nicht-Ziele sollten formuliert werden, um die Sicherheitsgarantien des Systems klar zu benennen.
  • Deniability oder Non-repudiation: Beides scheint nicht Ziel zu sein, aber das Konzept scheint sich 'noch unsicher' zu sein, wie etwa Formulierungen wie "Falls Alice die Verschlüsselung authentifiziert hat" nahelegen.
  • Ohne persistenten Speicher der Clients wird Forward Secrecy (Nicht der benannte Teil mit User werden ausgeschlossen, sondern was passiert, wenn ein User sein Langzeitgeheimnis verliert) nicht umsetzbar sein. Das sollte dokumentiert sein.
  • Das Konzept nutzt ein KEM-Interface, das nahelegt, dass eine authentisierte KEM (aKEM) genutzt wird. Der symmetrische Ciphertext ist aber nicht an den resultierenden Schlüssel gebunden, entsprechend ist der Ciphertext trotz aKEM nicht authentisch. Das Konzept nimmt dies zwar in den Annahmen an, könnte aber durchaus expliziter sein, warum dies nicht umgesetzt wird.
• Wäre eine Desktop- oder Mobil-Applikation im Einsatz, ließen sich bessere Annahmen treffen, da im derzeitigen Konzept alle kryptographischen Garantien durch bösartiges Javascript in der Webanwendung annulliert werden.

Lose Gedanken

• Würde das Passwort mittels OPAQUE gespeichert und trotzdem für encrypted private key = aes256gcm(private key, encryption key, iv) genutzt, so könnte der Server gegebenenfalls aus dem Verhalten des Clients (weitergehenden Anfragen vs Abbruch vs neue Anfrage an den Endpunkt) ableiten, ob die Entschlüsselung des private key funktioniert hat. In dem Fall würden dies wahrscheinlich ein Partitioning Oracle darstellen. Derzeit ist dies kein valider Angriff, da der Server das Passwort bereit Offline angreifen kann (oder sogar passiv beim Login erhält).
• Solange Authentizität des Senders ignoriert wird, sind einige Angriffe wie Key Compromise Impersonation ignorierbar, die die Herkunft von Nachrichten betrachten, sollten aber erneut betrachtet werden, falls Authentizität nicht ignoriert wird.

Kontext:
"Anschließend verhindert der Server das Hinzufügen von Änderungen, die unter einem anderen Board key verschlüsselt wurden": Das heißt es gibt keine Umschlüsselung für existierende Ciphertexte? Gibt es einen Modus, der dies erlaubt, wenn beispielsweise der alte BoardKey kompromittiert wurde? Heißt das, dass alle alten BoardKeys für neue Nutzer verschlüsselt werden (Prozess zum Teilen des Boards erwähnt nur einen Key)?

• Workflow im Dokument beschreiben
• Performance-Konsequences/Überlegungen im PerformanceMD festhalten

"gut genug" mit ausreichend vielen Iterationen (100k+), als Implementierungsdetail anmerken
Anzahl Iterationen muss im Code angepasst werden (aktuell 10k)
Alternativen: OPAQUE, Argon2

Kontext:

• PBKDF2 erlaubt einen Offline-Angriff auf das user_password durch den Server oder jemanden, der den Server/die Datenbank kompromittiert. Die anschließende Verschlüsselung encrypted private key = aes256gcm(private key, encryption key, iv) erlaubt, ebenfalls offline, eine Überprüfung des geratenen Passworts. Ein PAKE, beispielsweise OPAQUE, könnte hier Abhilfe schaffen. Wird hier der serverseitige-OPRF-Schlüssel gemeinsam mit der Passwortdatenbank geleakt, besteht das Problem allerdings trotzdem weiter (der Server kann immer einen Client mit Passwort X simulieren, wenn dessen einziges Geheimnis dieses Passwort ist).
• Würde das Passwort mittels OPAQUE gespeichert und trotzdem für encrypted private key = aes256gcm(private key, encryption key, iv) genutzt, so könnte der Server gegebenenfalls aus dem Verhalten des Clients (weitergehenden Anfragen vs Abbruch vs neue Anfrage an den Endpunkt) ableiten, ob die Entschlüsselung des private key funktioniert hat. In dem Fall würden dies wahrscheinlich ein Partitioning Oracle darstellen. Derzeit ist dies kein valider Angriff, da der Server das Passwort bereit Offline angreifen kann (oder sogar passiv beim Login erhält).

Konkrete Bsp. für

• RSA + Kyber
• EC + Kyber

Szenario: Alice teilt Schlüsselmaterial mit Bob

Kontext:

• Generell kann eine Web-Applikation nicht gegen den Server verteidigen, da dieser immer böses Javascript nachladen kann, welches lokale Speicher ausließt.
• Wäre eine Desktop- oder Mobil-Applikation im Einsatz, ließen sich bessere Annahmen treffen, da im derzeitigen Konzept alle kryptographischen Garantien durch bösartiges Javascript in der Webanwendung annulliert werden.

Kontext:
"gewinnt die Verwendung von Kyber über die Zeit an Sicherheit": Kyber gewinnt nicht an Sicherheit, sondern die Erwartungshaltung gegenüber Kyber wird besser (falls es keine neuen Angriffe gibt).

Kontext:
Wie wird das gleichzeitige Entfernen von User X durch User A und Hinzufügen von User Y durch User B gelöst?
Entfernen rotiert den aktuellen BoardKey, aber der neue Schlüssel wird nicht für User Y hinzugefügt, weil Y aus Sicht von A nicht Teil des Boards ist.
Hinzufügen teilt den aktuellen Schlüssel, der User B aber nicht bekannt ist, weil er zeitgleich rotiert wird. Dadurch erhält User Y den Schlüssel weder von A noch B.

Jedes Post-It wird von einem Client (eindeutig) gewählt, dieser generiert eine UUID (die heuristisch eindeutig ist).
Gefahr benennen für die Alternative, dass der Server die ID wählt.

Kontext:
Das Konzept macht nicht klar, woher die ID eines Post-Its kommt, da es nur die Veränderung darstellt. Käme die ID vom Server, kann dieser gezielter Inhalte mehrere Post-Its vertauschen.

Kontext:
Die Entschlüsselung eines Post-Its (bzw. zugehörigem Event) scheint über die boardKeyId geregelt zu sein. Wird dabei geprüft, ob der entsprechende BoardKey zu diesem Board gehört? Ansonsten kann der Server Post-Its von anderen Boards auf dem entsprechenden Board anzeigen. Dies könnte insbesondere problematisch sein, wenn verschiedene Boards unterschiedliche Vertraulichkeitsstufen haben. Szenario: Öffentliche Video-Präsentation eines öffentlichen Boards und der Server zeigt ein Post-It eines vertraulichen Boards an und erfährt den Inhalt über den Video-Stream.

Im E2EE-Konzept haben Public Links keinen Sinn ergeben. Mit dem neuen Sicherheitsziel von PQ-Sicherheit, sind sie aber durchaus denkbar und sollten konzeptuell eingeführt werden: #24 (comment)

Von der Idee her:

Public Links bedeuten insb., dass der Server die Inhalte jedes Post-Its auf dem nun öffentlichen Board lesen kann. Dies wird wie folgt realisiert: Der Server hat eigenes Board-spezifisches Schlüsselmaterial und wird ins Board eingeladen. Nutzer mit Zugang zum Public Link erhalten Zugriff zum Board-spezifischen Schlüsselmaterial des Servers und damit zu den Inhalten des Boards. Wenn der Public Link deaktiviert wird, entspricht dies dem Workflow für "Zugriffsrechte für ein Board entziehen", wobei hier dem Server Zugriffsrechte entzogen werden.

Wir können E2EE in Aussicht stellen und dabei anmerken, dass dann Public Links nicht mehr zweckmäßig sind.

Kontext:
Wie wird "Passwort vergessen" umgesetzt, sodass der Server diese Funktionalität nicht missbrauchen kann, um einen von ihm kontrollierten Schlüssel zu provisionieren?

Prüfen, wo im Konzept dies als Implementierungsdetail angemerkt werden sollte - ggf. auch in der Readme für die Client-Implementierung.

Kontext:
Domain separation für Hashfunktionen, zum Beispiel bei Generierung von IDs oder IVs, sodass gleicher Input nicht zu gleichen Werten führt.

Angriffsszenario beschreiben und ggf. feststellen, dass bei bereits leicht erhöhter Aktivität (3+ Post-Its) der Angriff auffällt
Alternative: CTR + HMAC

Kontext:
Inhaltsdaten sind mit GCM verschlüsselt. GCM ist nicht key-committing, d.h. ein Ciphertext kann unter mehreren Schlüsseln erfolgreich entschlüsselt werden und diese Schlüssel können von einem bösen Angreifer effizient berechnet werden. Dabei steht ein Großteil der anschließend entschlüsselten Nachrichten unter Angreiferkontrolle. Siehe etwa Paper, Paper oder Blog. Das würde einem User erlauben für andere User verschiedene Versionen unter dem gleichen symmetrischen Ciphertext zu erstellen, sodass für User A und User B ein Post-It unterschiedlichen Inhalt hat. Man beachte, dass dies ohne Beteiligung des Servers funktioniert und von diesem nicht erkennbar ist.

• Lösung könnte hier ein committendes Verfahren sein, z.B. die Kombination aus einem normalen Modus (etwa CTR) und einer MAC, wobei Schlüssel für beide abhängig voneinander generiert werden, etwa HKDF-Ableitung mit unterschiedlichem info-Paramter.

• auth server != nexboard server
• separate passwörter für login + encrypted boards weiterhin denkbar

Kontext:
Bei der Berechnung des encryption_key für die verschlüsselten privateKeys des Users wird das user_password genutzt, dass beim Login auch an den Server gesendet wird. Entsprechend hat der Server auch als passiver Angreifer alle Informationen, um das Board mitzulesen.

Kontext:
"Will ein Nutzer beispielsweise ein RSA Schlüsselpaar durch ein EC Schlüsselpaar ablösen, wird das aktuelle Kyber-Schlüsselpaar zusammen mit dem neuen EC Schlüsselpaar registriert": Die Folgen sind hier nicht angerissen. Wenn User A von (RSA, Kyber) zu (EC, Kyber) wechselt, wird dann das (RSA, Kyber)-Paar gesperrt? Wie findet das Lesen von an das (RSA, Kyber)-Paar adressierten Ciphertexten statt? Wie wird verhindert, dass neue Ciphertexte für das alte Paar angelegt werden? Wie verhält sich User B mit (RSA, Kyber)-Paar, der bei aKEMs nicht mit dem neuen (EC, Kyber)-Paar interagieren kann?

Akzeptiertes Risiko, Schutzziel konkretisieren zu "Integrität jedes einzelnen Post-Its"

Kontext:
Jedes Post-It wird separat verschlüsselt, ohne im Kontext der anderen zu stehen und ohne dessen Metainformationen wie Position festzuhalten. Deshalb kann der Server die Post-Its austauschen, indem er die Positionen ändert. Des Weiteren kann er jeden Post-It unabhängig von den anderen auf einen beliebigen alten Stand bringen, d.h. das Gesamtsystem hat keine Integrität, nur die einzelnen Post-Its für sich alleine.

• Grund ist (nachvollziehbarerweise) das komplexe Handling bei gleichzeitiger Bearbeitung, dann sollte aber das Post-It deutlich als Security Boundary genannt werden und Schutz eines Boards explizit als Non-Goal.

Lösungsansatz: Schutzziel umformulieren von "E2EE / Server kann Daten nicht lesen" zu "externer Angreifer kann Daten nicht lesen, selbst wenn TLS fällt"

Kontext:

• Die Clients wissen nichts von den PubKeys und vertrauen komplett dem Server, dh jede Verschlüsselung geht an einen vom Server bestimmten PubKey. An sich ist damit sofort E2EE kaputt. Der Server kann das auch konsistent durchziehen und den abgefangenen board_key neu für den eigentlichem Empfänger verschlüsseln. Weiter kann dem Sender für den einen Empfänger und dem Empfänger für den einen Sender immer der ServerKey ausgegeben werden (also klassischer MitM). Das braucht der Server nur einmal pro board_key machen, d.h. es ist auch kein wirklich komplexer Split State.
• Solange Authentizität des Senders ignoriert wird, sind einige Angriffe wie Key Compromise Impersonation ignorierbar, die die Herkunft von Nachrichten betrachten, sollten aber erneut betrachtet werden, falls Authentizität nicht ignoriert wird.

Kontext:
"Technisch lässt sich auch RSA mit EC kombinieren, aber dies hat keinen praktischen Nutzen": Nicht ganz korrekt. Ähnlich wie PQC wäre die Möglichkeit ein Kryptosystem zu kreieren, dass standhält, wenn eines der beiden Verfahren noch sicher ist. Für beide Verfahren ist sicher, dass die nicht post-quanten-sicher sind, aber ein Bruch von RSA ohne signifikante Fortschritte bei der Faktorisierung und entsprechend beim diskreten Logarithmus auf elliptischen Kurver wäre denkbar.