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?
Viginereverschlüsselung mit Pseudozufallszahlen vielleicht. Man müsste nur die Zufallsfolge synchronisieren.
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.
Dirk F schrieb: > Deshalb erst kompremieren und dann verschlüsselen. Komprimieren und verschlüsseln bitte... Flo
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.