Schneller Verschlüsselungsalgorithmus für kleine Datenmengen

Hi allerseits,

ich suche einen schnellen Verschlüsselungsalgorithmus für sehr kleine Datenmengen.
Die Datenmengen werden wohl durchschnittlich um die 4 Byte groß sein.

Weil ich dafür jetzt nicht einfach irgendeinen Algorithmus von den wenigen mir bekannten Verschlüsselungsalgorithmen nutzen will, der dann wohlmöglich ein absoluter "Overkill" für die geringe Datenmenge ist, frage ich hier einfach mal nach Empfehlunungen

SeppJ

Um eine optimale Antwort geben zu können:
Was hast du mit den Daten vor?
Warum sind die Datenmengen so klein?
Warum fasst du nicht viele kleine Datenmengen zu einer großen zusammen?

Im Grunde soll das ein kleiner "Speicherschützer" sein um die Veränderung von Daten im Hauptspeicher z. B. durch Programme wie TSearch zu unterbinden oder wenigstens vorzubeugen. Daher kommt auch die kleine Datenmenge.

Das Prinzip ist relativ einfach: Es wird eine Kopie des eigentlichen Wertes angelegt und dieser verschlüsselt, sodass man beim Suchen mit TSearch nicht auch noch die Kopie findet. Regelmäßig prüft dann der Speicherschützer, ob der zu schützende Wert ohne Erlaubnis verändert wurde und stellt gegebenenfalls den ursprünglichen Wert durch die Kopie wieder her. Die Kopie wandert ausserdem im Hauptspeicher um das Auffinden zu erschweren.

Eine andere Idee war es, die Daten Seitenweise im Arbeitsspeicher abzulegen, aber das hatte sich beim Arbeiten mit Objekten als relativ unpraktisch erwiesen.

Egal wie unnütz die Idee sein mag, es ist immerhin eine nette Übung

SeppJ

Wenn der "Angreifer" sowieso schon im System ist, kann man sich nicht mehr sicher schützen. Etwas Obfuscation ist das beste was du erreichen kannst. Da würde es schon reichen zu jedem Wert einfach 1 zu addieren oder etwas ähnliches. Gegebenenfalls noch eine Prüfsumme errechnen, um einfache Manipulationen entdecken zu können.

Bisher hab ich die Kopien einfach invertiert (binär-not) um sie zu "verschlüsseln", dann werd ichs wohl so lassen.

donkong

xor

Mich würde auch eine sinnvolle Antwort zu der Frage interessieren und weniger Antworten darüber ob die Frage Sinn macht.

donkong

hab ich dir doch geschrieben. was schnelleres/besseres wirst kaum finden. wenn doch sag bescheid.

wiki schrieb:

If the key is random and is as long as the message (so it never repeats), the XOR cipher is more secure. When the keystream is generated by a pseudo-random number generator, the result is a stream cipher. With a key that is truly random, the result is a one-time pad, which is unbreakable even in theory.

Also das von "immernochfrage" war ich nicht, ich würde innerhalb eines Threads niemals meinen Nickname ändern.

Aber was genau meinst du jetzt mit "was schnelleres wirst kaum finden"?
Ist XOR schneller als NOT?

SeppJ

Subsurf schrieb:

Also das von "immernochfrage" war ich nicht, ich würde innerhalb eines Threads niemals meinen Nickname ändern.

Aber was genau meinst du jetzt mit "was schnelleres wirst kaum finden"?
Ist XOR schneller als NOT?

Nein, beides ist ungefähr gleich schnell. XOR bietet dir aber zusätzlich noch die weitere Obfuskationsmöglichkeit, einen beliebigen Schlüssel benutzen zu können, während du bei NOT gar keinen Schlüssel hast, was für dich wiederum einfacher zu programmieren ist.

XOR ist bloß im Vergleich zu echten Verschlüsselungsverfahren eine sehr schnelle Methode, hat dafür aber Probleme an anderer Stelle die hier nicht relevant sind.

SeppJ schrieb:

Subsurf schrieb:

Also das von "immernochfrage" war ich nicht, ich würde innerhalb eines Threads niemals meinen Nickname ändern.

Aber was genau meinst du jetzt mit "was schnelleres wirst kaum finden"?
Ist XOR schneller als NOT?

Nein, beides ist ungefähr gleich schnell. XOR bietet dir aber zusätzlich noch die weitere Obfuskationsmöglichkeit, einen beliebigen Schlüssel benutzen zu können, während du bei NOT gar keinen Schlüssel hast, was für dich wiederum einfacher zu programmieren ist.

XOR ist bloß im Vergleich zu echten Verschlüsselungsverfahren eine sehr schnelle Methode, hat dafür aber Probleme an anderer Stelle die hier nicht relevant sind.

Stimmt, das mit dem Schlüssel bei XOR hatte ich gar nicht bedacht. Eigentlich eine super Idee... werd das übernehmen!