Hi.
Ich möchte mehrere Mikrocontroller über einfache analoge RF Module
miteinander kommunizieren lassen.
Also solche einfachen Module wie man sie z.B. in billigen Funkkopfhörern
oder Funksteckdosen findet.
Ich verwende bewusst keine Funkmodule, wo man mit dem uC einfach per
UART daten hinein schiebt und das Modul dann den Rest übernimmt.
Der Grund ist, dass ich mit allem arbeiten können will, was in der Lage
ist, Audiofrequenzen zu übertragen. (konkret CB Funkgerät)
Es muss nicht sehr schnell sein, so dass ich mit AFSK bei 1200 Baud
arbeiten möchte, mit einer Modulation wie bei Packet Radio (1200 Hz /
2200 Hz)
Das ist jahrelang erprobt und ich kann ein herkömmliches Packet Radio
TNC nutzen um die Anlage zu testen.
Allerdings kann dann jeder, der irgendwie ein PR Equipment hat, alles
mitlesen oder sogar dazwischenfunken.
Das System ist für die Fernsteuerung und Messwerterfassung auch über
größere Entfernungen vorgesehen.
Deswegen wollte ich die Übertragung irgendwie verschlüsseln, und wenn
möglich auch ein bisschen Kompression mit rein bringen.
Es muss nicht absolut "High End" sein, also kein AES o.ä sein. Ich will
den kleinen Prozessor ja nicht nur deswegen gehen einen ausgewachsenen
Boldiden ersetzen müssen.
Ein bisschen mehr als ein festes "Zeichentauschen" (z.B. Bits bzw
Nibbles invertieren oder z.B. Caesar-Verschlüsselung) sollte es aber
schon sein.
Theoretisch würde es schon reichen, die Daten mit einem wechselnden Salt
zu "Scrambeln" und eine RLE Kompression zu nutzen.
Oder habt ihr eine Idee für mich wie man eine einfache Verschlüsselung
und kompression machen könnte?
Hallo!
Ein einfaches Verfahren wäre das hier:
-Denke dir einen 'Schlüssel' aus, der aus mehreren Bytes besteht und
nicht gerade ASCII Text ist. Sagen wir: 0x96, 0x3e, 0xb5, 0x81
- jetzt nimmst du den Klartext und verXORst den byteweise mit dem
Schlüssel, aus z.B. 'Hello World' wird dann 'H' XOR 0x96, 'e' XOR 0x3e,
'l' XOR 0xb5, 'l' XOR 0x81, 'o' XOR x96, ' ' XOR 0x3e, 'W' XOR 0xb5, 'o'
XOR 0x81, ...
- um zu entschlüssel machst du das gleiche mit dem verschlüsselten
Datenstrom. Also 1.Byte XOR 0x96, 2.Byte XOR 0x3e, usw.
Nachteil: Da der Schlüssel statisch ist, kann man immer mitlesen wenn
der Schlüssel einmal bekannt ist. Dynamische Schlüssel sind da besser
aber auch aufendiger.
Eine Kompression macht nur Sinn wenn es möglichst viele gleiche
Symbol-Anteile gibt. Nach einer Verschlüsselung ist das meistens nicht
mehr der Fall und der Kompressionsfaktor nimmt ab.
Außderdem mußt du dir überlegen was passiert wenn ein Byte in der
Übertragung verloren geht. Ein Header und eine Checksume können helfen
Übertragungsfehler zu erkennen.
Einfache Kompremierung:
Steuercoder = 0 für Kompremierung
Daten: 1 2 3 7 7 7 7 7 wird zu > 1 2 3 0 5 7 0= Kompremierung, 5
mal die 7.
1 2 3 0 8 wird zu 1 2 3 0 1 0 8 um auch Zahl 0 darstellen zu können.
Wir effektiv bei vielen gleichen Zeichen.
Dann die Daten mit einem Password XOR verknüpfen. PW ist Sender und
Empfänger bekannt.
>>>Nach einer Verschlüsselung ist das meistens nicht
mehr der Fall und der Kompressionsfaktor nimmt ab.
Deshalb erst kompremieren und dann verschlüsselen.
Weiterer Vorteil:
Sind viele gleiche Zeichen am Stück in den Daten enthalten und der
Schlüssel ist weentlich kürzer, dann kann der Schlüssel recht einfach
herausgefunden werden.
Welchen Sinn hat eine schwache Verschlüsselung? Wer deine Daten haben
will, knackt die. Wer sie nicht haben will, versucht's gar nicht erst.
Wenn du nur die Korrektheit der Daten sicherstellen willst, kannst du
sie mit Prüfsummen versehen und ggf. digital signieren (zB mit RSA).
AES auf 8Bit Mikrocontrollern. War überrascht, dass so etwas geht. Wenn
ich mich richtig erinnere, braucht die Library 30kByte und liefert
mehrere 1000 Bit/Sekunde.
Flo schrieb:> Dirk F schrieb:>> Deshalb erst kompremieren und dann verschlüsselen.>> Komprimieren und verschlüsseln bitte...>> Flo
Ein schönes Beispiel für eine schwache Verschlüsselung - Flo hatte sie
sofort geknackt.
Programmierer schrieb:> Welchen Sinn hat eine schwache Verschlüsselung?
Ich denke mal, der TO will da keine geheimen, sensiblen Daten
übertragen, sondern sich einfach nur gegen neugierige
"Zufallslauscher" schützen.
Ähnliches kennt man aus dem Freundes- oder Bekanntenkreis. Technisch
versierte Leute hacken ja sehr gerne die PCs ihrer Verwandschaft oder
Freunde. Dahinter steckt aber meist nur die pure Neugier, ohne den
Betroffenen irgendwie schaden zu wollen. :-)
Noch einer schrieb:> AES auf 8Bit Mikrocontrollern.
Muss es unbedingt 8bit sein? Die STM32F415 z.B. haben
Hardware-AES-Beschleunigung. Wenn es kein Massenprodukt ist machen die
paar Euros mehr im Preis auch nichts aus. Dafür hätte man eine
Verschlüsselung die auch den Namen verdient und nicht so nutzlos ist,
dass man sie auch weglassen könnte.
Crypto schrieb:> Nachteil: Da der Schlüssel statisch ist,
Na, den Schlüssel mit vereinbarter Anzahl durch einen Polynomgenerator
zu schicken sollte schon drin sein ...
Gruß
Jobst
Leute, macht doch nicht so einen Aufriß.
Wenn man den Datenverkehr bloß ein bissel verschleiern will - was ja
hier der Fall sein dürfte - dann sind alle Verfahren, die irgenwelche
tollen Schlüssel brauchen, außen vor, da viel zu aufgemotzt.
Erstmal kommt es drauf an, ob das Ganze blockweise passieren soll oder
einzelzeichenweise.
Variante 1, blockweise:
Feste Struktur des Blockanfanges, z.B. besonderes Zeichen oder deren
zwei, dann das häufigste Zeichen, dann der eigentliche Inhalt
- Einen Block zusammensammeln
- das am häufigsten vorkommende Zeichen suchen, merken.
- Adler32 Prüfsumme über den Block, merken.
- jetzt den ganzen Block zu einem Bitstream so komprimieren, daß immer
dann, wenn das häufigste Zeichen vorkommt, ein 1 Bit angefügt wird und
bei allen anderen Zeichen ein 0 Bit und dann das Zeichen.
- dann Prüfsumme anfügen und alles senden.
Bei diesem Verfahren stimmen die Zeichengrenzen des Quell-Blockes NICHT
mit den Bytegrenzen des gesendeten Streams überein. Ist unleserlich. Die
Kompression ist zwar eher lausig, hebt aber so lala die eingefügten
Steuerbits auf. Der Algorithmus ist sowohl senderseitig als auch
empfängerseitig sehr simpel zu realisieren, man braucht lediglich
Schiebeoperationen und keine echte Mathematik.
Ich hatte sowas schon mal vor Jahren hier gepostet, da ging es um
Landkartendarstellung auf µC, die bei OSM, Googlemaps und so weiter ja
als Kacheln im jpg oder png Format übertragen werden, was aber auf einem
kleinen µC erhebliche Schwierigkeiten beim Dekodieren macht.
Variante 2, einzelzeichenweise:
ganz einfach jedes Zeichen fortlaufend zyklisch rotieren, also ausgehend
von einem Startpunkt jedes Zeichen um eine Anzahl von Bits rotieren.
Aber mit 2 Ausnahmen: 0 und FF. Diese Zeichen dürfen erstmal im Nutzcode
nicht vorkommen. Mit 0 wird der Rotier-Zähler auf 1 oder 0
zurückgesetzt. Wenn 0 und FF im Nutzcode vorkommen, dann wird mit FF
angezeigt, daß das nachfolgende Byte das Originalbyte ist und kein
Sonderzeichen.
Dieses Verfahren ist noch viel simpler zu implementieren als das
Blockverfahren, es komprimiert aber nicht.
W.S.
Eine einfache Methode zur Verschlüsselung ist die Stream-Codierung
mittels linear rückgkoppeltem Schieberegister (LFSR)
https://de.wikipedia.org/wiki/Linear_r%C3%BCckgekoppeltes_Schieberegister#Zusammengesetzte_LFSR.
Ein LFSR von z.B. 16 Bit erzeugt eine Folge von Pseudo-Zufallsbits mit
einer Wiederholperiode von 65535, was für den genannten Zweck genügen
sollte. Die Berechnung erordert im Wesentlichen nur Schiebe- und
XOR-Operationen. Die Pseudo-Zufallszahlen werden dann mit dem
ausgehenden Bitstrom per XOR verknüpft. All dies ist auch auf einem
8Bit-Controller einfach und schnell zu machen. Mittels ROM-Tabelle
(256*16bit) köönen auch 8bit auf einen Schlag berechnet werden, was die
Saceh noch beschleunigt.
Verfügen Sender und Empfänger über eine einigermaßen synchrone Uhr? Dann
könnte man den XOR-Schlüssel von der Uhrzeit abhängig machen.
Bei geringer Un-Synchronität kann der Empfäger anhand einer Prüfsumme
notfalls den Code sogar variieren, bis er es lesen kann ...
Oder man versteckt in den Paketen irgendwo eine Kennung, die auf den
anzuwendenden Initialwert eines Pseudo-Zufallsgenerators verweist, oder
man nimmt die Prüfsumme direkt dafür ... da soll erstmal einer drauf
kommen. Es muss ja wohl nicht NSA-fest sein.
Mike schrieb:> Eine einfache Methode zur Verschlüsselung ist die Stream-Codierung> mittels linear rückgkoppeltem Schieberegister (LFSR)
Was ein Polynomgenerator ist. Und ich auch nicht für
W.S. schrieb:> so einen Aufriß
halte ...
Gruß
Jobst
Wie sehen denn deine Nutzdaten aus? Wenn das jetzt z.B. ASCII ist,
kannst du dir u.U. eine eigene Symboltabelle überlegen. Wenn du dich auf
Großbuchstaben und Ziffern beschränkst, kommst du mit 6 Bit pro Symbol
locker aus. Sind immerhin 25% gespart und ist super einfach realisiert.
Verschlüsselung: Die Enigma war eigentlich nicht so schlecht und lässt
sich als Programm einfach nachbilden.
Kompression ist doch wirklich aufwändig. Zumindest bei
AVRs o.ä. mit begrenztem SRAM. Da würde ich mir lieber
Gedanken machen, die Steuer-Codes, oder die Messwerte
in ihrer Bit-/Byte-weisen Darstellung zu optimieren.
Eine bewährte Praxis ist es:
1. Komprimieren
Damit werden schon mal Redundanzen in der Nachricht
minimiert, die einem Lauscher helfen könnten.
(Beschränkt man sich auf das Wesentliche, wird die
Wirkung geringer.)
2. Verwürfeln der Bytes / Nibbles
Wer einen Poly-Alphabetischen-Enschlüsselungs-Algorithmus
benutzt, kommt nicht auf "lesbaren Text".
3. XOR mit Pseudo- (oder echte!) Zufalls-Bitfolgen.
ECHTE Zufalls-Bitfolgen müssten vorher in ausreichender
Länge (!) verteilt werden.
Um Lauschern den Spaß zu verderben, gibt es sooo viele
Möglichkeiten mit LFSR's, dass es nur an deiner Phantasie
scheitert, wenn es mit Amateuraufwand schnell zu knacken
ist.
Bei Datenblöcken der Länge 2^n (inclusive Prüfsumme) ist
ein LFSR mit passender Länge n prima zum Verwürfeln der
Byte-Folge geeignet. Das (evtl. zusätzliche) XORen wurde ja
schon erwähnt.
Dabei kann man, je nach Messstelle einen Offset des LFSR-
Standes gegenüber der Vorgabe vom Master einführen....
Also, wenn es nichts HOCHSENSIBLES ist, kannst du mit
geringem Aufwand den Datenstrom minimieren UND privat
halten.
