Crypt zwischen 2 nicht wirklich synchronisierbaren Systemen.....

[fgordon]

Hmmm so langsam habe ich doch einiges an LoRa Sensoren - und aufgrund der hohen Reichweite bin ich nur aus Prinzip mal am überlegen dass ich den Datenverkehrn crypte, was ja wenn man damit Sachen steuert eigentlich eh sinnvoll ist xD

Wie aber oft hat man natürlich das Problem, man hat keinen gemeinsamen Zugriffspunkt von Server und Client, so dass man sich nicht synchronisieren kann - Echtzeituhr und Co fällt bei ESP auch letztendlich weg, auch wenn es Lösungen gibt die brauchen halt wertvolle Pins - und Speicherplatz ist natürlich auch endlich xD

Idee ist aktuell was weiss ich z.B. eine sehr hohe Anzahl an Random Passphrases als Basis für AES Crypt/Decrypt - Synchronisation ist halt dass der Server einfach dann alle Passphrases durchprobiert bis er den passenden hat und im Datenpaket dann der Client den nächsten Index mitschickt.

Da Pakete verlorengehen können kann der nächste Passphrase sicher nicht randommässig dynamisch erzeugt und verschlüsselt mitgeschickt werden - selbst wenn der Server ein OK zurückschickt müsste ja dann wieder überprüft werden dass das ok ankam und dann dass das ok für das ok ankam... etc xD hat man 1x einen dynamisch generierten Passphrase nicht empfangen wäre Schluss.

Oder gibt es da was Sinnvolleres?

Ich will halt a) verhindern dass einfach "Repeat" Messages geschickt werden und b) der Inhalt verändert werden kann.

 

[playerthreeone]

Du hast "Crypt" nicht verstanden?

 

[Maviapril2]

selbst wenn der Server ein OK zurückschickt müsste ja dann wieder überprüft werden dass das ok ankam und dann dass das ok für das ok ankam...

Dafür könnte man aber in einer Nachricht auch alles mit bestätigen was bisher ankam und noch nicht von der Gegenseite bestätigt wurde.

Z.B. kann dann eine Nachricht sein
190 bestätigt, 191 fehlt, 192 bestätigt, 193 bestätigt

Antwort
191, 194, 190 Ok, 192 Ok, 193 Ok

Antwort
191 bestätigt, 194 bestätigt

Und wenn da eine Nachricht auf einer Seite noch nicht angekommen ist, kann man eben alles noch nicht bestätigte mitsenden

Hoffe du verstehst was ich meine

Ich will halt a) verhindern dass einfach "Repeat" Messages geschickt werden und b) der Inhalt verändert werden kann.

Damit sollte a) abgedeckt sein.
B) dafür reichen Zertifikate mit private key and public key die die Nachricht signieren, da braucht man kein crypto

 

[fgordon]

Gerade mal ein bisschen angefangen zu testen.

Aus Performancegründen bin ich jetzt bei der Lösung ich erzeuge "Offline" auf dem PC Unique Keys als Quasi OneTimePad, speichere die ins PROGMEM der ESP32 und nutze dann einfach das einfachste Crypt was es gibt XOR um Herauszufinden ob das eine per "OneTimePad" verschlüsselte Nachricht für mich ist....
nach 3,5 Jahren ist das OTP halt durchgenudelt und beginnt von vorne, aber dafür ist das halt denke ich maximal schnell.

Dann reichen sogar 80 Mhz statt 240

Das mit Messages quittieren ist halt problematisch wenn man "Rolling Codes" will und der Sender wie bei ESP32 oft halt im Dauerschlaf sein soll.