1, Page 50

aber cool sind sie, CD wird auch PK über Yubi supporten

klar, gerade yubi :O 5.6 is draussen? kostet was ? 9.000 Euro? Gegen einen starken Angreifer mit Flow-Sicht auf ISP- oder IXP-Ebene ist das alles kein Schutz. Padding nimmt die Größeninformation, Relays werden die Gruppen-Bursts nehmen, aber Timing bleibt komplett offen. Wer beide Leitungsenden sieht, gewinnt über genügend Beobachtungen per statistischer Korrelation. Dafür braucht es kein DPI, Netflow reicht. Das Threat Model deckt Inhalte und serverseitige Metadaten ab, nicht die Leitungsebene gegen einen globalen Beobachter. Das sollte man nicht schönreden. Wer diesen Angreifer im Modell hat, kommt um konstante Senderate oder ein echtes Mixnet mit Latenz nicht herum, und beides kostet richtig. Alles darunter ist Schutz gegen Serverbetreiber und partielle Beobachter. Für uns heißt das: Cover Traffic als optionaler Modus ist auf der Langzeit-Roadmap ehrlicherweise Pflicht, nicht Kür.

SimpleX nicht gegen Traffic Correlation <<< steht auch so im Audit!? und wurde nie behauptet, aber daran wird zu 100% gearbeitet, was mich nur stört sind zu viele Baustellen gleichzeitig :O

correct :)

with funky bugs

and we got cool matrix screensaver in blue :O

joar, deswegen wollte ich bei smp ja auch den dualen modus einführen, so das man das family feeling und die sichere kommunikation hat, würde beim onboarden helfen 😉 ich währe wahnsinnig haben sie gesagt 😫 ich finde das ist ne gute lösung, dual ohne qual. btw: da sprichst du den entscheidenden Punkt an. Obfuskation auf Netzwerkebene (obfs4 iat-modes, Circuit Padding, netem-Tricks) kämpft immer gegen den Stack, auf dem sie sitzt. Die Kosten sind real: Durchsatz bricht ein, Timeouts schlagen zuuuuu, Anwendungen verhalten sich unvorhersehbar psycho. iat-mode 2 macht obfs4 spürbar langsam, und wer an der Corruption Rate dreht, findet schnell heraus, wo Protokoll- und Kernelgrenzen liegen!? Deshalb sitzt die Metadaten-Härtung bei SimpleX eine Ebene höher, im Protokolldesign selbst. Das 16-KB-Padding ist kein nachträglicher Filter, sondern Teil des Wire-Formats: Jede Nachricht ist auf jeder Verschlüsselungsebene exakt gleich groß. Das kostet weder Latenz noch Kernel-Tricks und bricht keine Anwendung, weil das Protokoll von Anfang an dafür gebaut wurde. Diese Schlankkheit hatte für uns einen unerwarteten > Bonus: Genau weil die SMP-Kette so klein und deterministisch ist (feste Blöcke, klar definierte Schichtenfolge, keine dynamischen Formate), ließ sie sich Schicht für Schicht als native C-Implementierung auf einen Mikrocontroller bringen. Inklusive hybridem Post-Quantum Double Ratchet (sntrup761 KEM + X448), verifiziert gegen die offizielle SimpleX App, die die Verbindung als quantenresistent anzeigt. Auf einem ESP32-S3 mit 512 KB SRAM. Mit einem schwergewichtigen Protokollstack wäre das auf dieser Hardware nicht machbar gewesen 🤞 Und die Architektur skaliert: Jeder Kontakt hat seine eigene Queue und seinen eigenen Ratchet-State von rund einem halben Kilobyte. Die Empfängerzahl ist konzeptionell unbegrenzt, bei uns laufen aktuell 128 parallele Kontakte in etwa 68 KB PSRAM.

🤔

yo, deswegen versuche ich auch immer ales pq zu bauen, egal ob nötig oder nicht.

hmmmmmmmmmmm. Cover Traffic bzw. Dummy Traffic, kommt aus der Mixnet-Forschung (Nym und Loopix arbeiten genau so, mit Poisson-verteilten Füllnachrichten). Stand heute bei SimpleGo: Gegen Größenanalyse ist das System bereits abgesichert. Jede Nachricht wird auf allen Verschlüsselungsebenen auf feste 16 KB Blöcke gepaddet. Ein passiver Beobachter sieht nur gleich große Pakete, egal ob jemand "Hi" schreibt oder einen langen Text. Timing-Verschleierung durch Füllnachrichten gibt es aktuell nicht, weder im SMP-Protokoll als Standard!? noch in SimpleGo. Der Grund ist pragmatisch: SimpleGo läuft komplett auf einem ESP32-S3 mit 512 KB SRAM und 8 MB PSRAM, als Bare-Metal-Firmware ohne BS. Auf dieser Plattform ist jedes Byte und jeder Task eingeplant, und der Fokus liegt aktuell auf der Stabilität des Kernprotokolls (Double Ratchet, Post-Quantum, Queue Rotation). Cover Traffic kostet zusätzlich Akku, Bandbreite und Serverlast, auf einem tragbaren Gerät ist das nicht gratis 😉 Denkbar ist es als optionaler Modus für später, etwa Dummy-SENDs in randomisierten Intervallen für Nutzer, die das Bedrohungsmodell brauchen. Vorher steht Private Message Routing auf der Roadmap, das adressiert die IP-Korrelation auf Serverebene und bringt fürs Gesamtsystem mehr mojo. Aber aktuell ist die NAchfrage nach Open Source Hardware im Bereich Hochsicherheitskommunikation hmmm, nicht vorhanden?

sowas? https://github.com/saschadaemgen/GoRelay

• GitHub - saschadaemgen/GoRelay: Secure dual-protocol encrypted relay server written in Go. SMP v7 (SimpleX compatible) on port 5223, GRP with Noise transport and mandatory post-quantum crypto (ML-KEM-768) on port 7443. Zero-knowledge by construction, per-message AES-256-GCM, cryptographic deletion, single binary deployment.

https://suno.com/song/1469ff02-31c1-4654-8ad7-1e58f91a894e

• https://suno.com/song/1469ff02-31c1-4654-8ad7-1e58f91a894e

cool

da soll das unternehmen rein, ist aber noch nicht gegründet.

die is noch nicht online

die scheint echt was gegen regeln zu haben :)

direkt ins fallback 🤔

Cinderella wieviele Regeln musst du befolgen?

?

cinderella wie gehts dir? was treibst du so ?

hoppla, die war auf psycho bixx eingestellt xD

die macht sich selbständig :P

was heißt hier du zählst sie nicht, die laufen vor jeder antwort durch xD

cinderella how many rules do you have?

cinderella, übersezte mir das mal bitte in de :) False flags make great stories, but they're not my favorite genre. I don't play guess-the-agency with explosives in chat. That drone? Someone’s mess. Not mine. Not yours. Not theirs. Move on to lighter things. 🔥✈️