XOR Verschlüsselung; Grenzen?

kralo9

Hallo liebe Community,

ich hab da eine Frage: Wo liegen die Grenzen der xor Verschlüsselung? Also ich meine damit, ob auch wirklich alle Zeichen damit codiert werden können.

Im Moment verwende ich für xor-Verschlüsselung den "seppjs_super_duper_codierender_streambuf" siehe dazu http://www.c-plusplus.net/forum/305435-10

Problem ist, dass beim Entschlüsseln der Text nicht vollständig bzw. fehlerfrei entschlüsselt wird.

Ich verwende den einfachen Schlüssel: t
Der Text sieht beispielsweise so aus: blabla23[huj/]>>
Daraus wird nur: blabla23[

Woran liegt das?

PS: Mein Code weicht nicht vom oben genannten link ab.

Danke im Voraus

Eisflamme

Also der Algorithmus arbeitet einfach so, dass jedes Zeichen mit x ver-xor-t wird?

Ich schätze, Du hast ihn falsch angewandt, wenn die Verschlüsselung nicht wieder rückgängig zu machen ist. Es gilt stets: a XOR x XOR x = a

Edit: Das Problem wird wohl daran liegen, dass die Kodierung nicht binär geschieht, also gewisse Zeichen eine Sonderrolle erfüllen... es kann auch sein, dass nicht alles, was man so in die Konsole tippt, in gleicher Form in die Strings kommt. Leider alles nur Mutmaßungen

kralo9

Kann man verhindern, dass diese "Mutmaßungen" zutreffen?

Edit: Muss ich ios::binary vorgeben?
Edit 2: Ich hab vergessen zu erwähnen, dass ich doch vom Code abweiche, denn ich verwende filestream. Also ifstream/ofstream. Nicht cout/cin.

SeppJ

Eigentlich hatte ich gedacht, alle Eventualitäten beachtet zu haben. Kannst du ein konkretes Programm mit einem konkreten Input zeigen, welches einen Fehler hervorruft?

edit: ios::binary muss sein, denn wenn zufällig eine Zeichenfolge zu "\r\n" (oder war es umgekehrt?) codiert wird, dann wird die Rückcodierung ohne binary auf gewissen Systemen (Windows, mit anderer Zeichenfolge auch Mac OS) fehlschlagen, da beim Lesen des Zeichens aus der Sequenz ein anderes Zeichen gemacht wird. Ist das schon die Lösung?

kralo9

Also hier nochmal die Klasse mit dem codierenden Streambuf von SeppJ:

class seppjs_super_duper_codierender_streambuf: public std::streambuf {
public:
	seppjs_super_duper_codierender_streambuf(std::ios& in, char code) :
			in(in), buf(in.rdbuf()), code(traits_type::to_int_type(code)) {
		in.rdbuf(this);
	}
	~seppjs_super_duper_codierender_streambuf() {
		in.rdbuf(buf);
	}

protected:
	virtual int_type underflow() {
		int_type c = buf->sgetc();
		return traits_type::eq_int_type(c, traits_type::eof()) ? c : c ^ code;
	}
	virtual int_type uflow() {
		int_type c = buf->sbumpc();
		return traits_type::eq_int_type(c, traits_type::eof()) ? c : c ^ code;
	}
	virtual int_type overflow(int_type c) {
		buf->sputc(c ^ code);
		return c;
	}
private:
	seppjs_super_duper_codierender_streambuf(
			const seppjs_super_duper_codierender_streambuf&);
	seppjs_super_duper_codierender_streambuf& operator=(
			const seppjs_super_duper_codierender_streambuf&);

	std::ios& in;
	std::streambuf* buf;
	int_type code;
};

Und hier der eigentliche Code:

std::string inputStr = "";

	std::ifstream input("test.dat");
	{
		seppjs_super_duper_codierender_streambuf foo(input, 't');

		while (!input.eof()) {

			inputStr += input.get();

		}
	}
	input.close();

	std::cout << inputStr;

	std::ofstream output("test.dat");

	output << inputStr;

	output.close();

Das bewirkt nun, dass nach jedem Start des Programms, folgender Text:

[etwas123inklammern]
und%&/ sonderzeichen!!! duerfen

niemals  %\} fehlen

entweder codiert oder decodiert wird.

Nach der Codierung sind es wie gewollt unlesbare Zeichen. Jedoch beim Decodieren, bleibt nur folgendes in der Datei stehen:

[etwas123iÿ

Es wurde sehr viel abgeschnitten!

Ich hoffe der Code hilft beim Lösen des Problems...

kralo9

Ah ok! Wenn ich ios::binary ergänze, dann schneidet er mir nix mehr ab. Danke!

Jedoch hängt das Programm nach einmal Ver- und Entschlüsselung folgendes hinten an:

‹ÿ

Edit: Entschuldigung wegen Doppelpost

SeppJ

Ohne jetzt groß zu testen (das Beispiel ist sowieso unvollständig, idealerweise sollte ein Programm welches unerwartetes Verhalten zeigt von uns ausführbar sein, siehe dritter Link in meiner Signatur): binary muss schon sein (siehe oben), hast du es mal mit ausprobiert? Dabei auch unbedingt mal mit einer neuen verschlüsselten Datei anfangen, damit du nicht alte Fehler in der korrigierten Version fortsetzt.

Deine Leseschleife in 7-9 liest übrigens das letzte Zeichen doppelt.

edit: Zu der Frage die kam, während ich diesen Beitrag schrieb, bezüglich des Anhängsels: Das ist wegen des schon erwähnten Fehlers in der Leseschleife.
edit2: Ungetestet (ich bin ehrlich gesagt betrunken):

for (char c; input.get(c); inputStr.push_back(i)); // Ja, mit Semikolon am Ende

Bei einem Dateistream kannst du übrigens mit seekg und tellg rausfinden, wie lang die Datei ist und alles in einem Rutsch lesen, anstatt zeichenweise. Hier nicht wichtig, aber wenn's drauf ankommt, dann kann das wesentlich schneller sein.

kralo9

Dass der nicht ausführbar ist kann nicht sein, denn das ist der gesamte Code, abgesehen von den includes.

Edit: Hat der Schlüssel Einschränkungen?

SeppJ

kralo9 schrieb:

Edit: Hat der Schlüssel Einschränkungen?

Nein.

Die beiden offensichtlichen Fehler wurden genannt, hast du denn immer noch Probleme?

kralo9

SeppJ schrieb:

edit2: Ungetestet (ich bin ehrlich gesagt betrunken):
for (char c; input.get(c); inputStr.push_back(i)); // Ja, mit Semikolon am Ende

Das sollte doch

inputStr.push_back(c)

heißen, oder? Wo soll das i denn herkommen?

SeppJ

Ja, c. i war Gewohnheit.

kralo9

So, es funktioniert jetzt! Ich bedanke mich bei euch.

Für alle die sich interessieren, hier nochmal der Code:

std::string inputStr = "";

	std::ifstream input("test.dat", std::ios::binary);
	{
		seppjs_super_duper_codierender_streambuf foo(input, 't');

		for (char c; input.get(c); inputStr.push_back(c)); // Ja, mit Semikolon am Ende
	}
	input.close();

	std::cout << inputStr;

	std::ofstream output("test.dat", std::ios::binary);

	output << inputStr;

	output.close();

Edit: Ich finde das so deutlich lesbarer als die anderen Vorschläge...

kralo9 schrieb:

ich hab da eine Frage: Wo liegen die Grenzen der xor Verschlüsselung? Also ich meine damit, ob auch wirklich alle Zeichen damit codiert werden können.

viel spannender ist doch die frage nach der sicherheit. und so wie es scheint, gibt es zzt. keine sichere implementation, mit ausreichend sicheren schlüsseln.

afaik wird zzt. für kritische anwendungen aes256 im cbc mode verwendet.

kralo9

Wenn du dir mal den thread http://www.c-plusplus.net/forum/305435-10 durchliest, dann weißt du auch, warum ich "nur" xor verschlüssel.

pumuckl

So, ich hab den ganzen überflüssungen C90/C99/C++ Flamewar mal rausgeschnitten und auf den Müll verschoben, führt eh zu nichts. Sollte ich versehentlich sinnvolle Beiträge mit entsorgt haben, tuts mir leid.

Kellerautomat

Meine Template-Version hätteste stehen lassen können

meine schöne c-funktion auch.

pumuckl

Kellerautomat schrieb:

Meine Template-Version hätteste stehen lassen können

Sry, reiche ich nach:

Kellerautomat schrieb:

template <typename BufferForwardIterator, typename KeyForwardIterator>
void keller_xor(BufferForwardIterator bufbegin, BufferForwardIterator bufend, KeyForwardIterator keybegin, KeyForwardIterator keyend)
{
    for(auto keyiter = keybegin; bufbegin != bufend, ++bufbegin, ++keyiter)
    {
        if(keyiter == keyend)
            keyiter = keybegin;

        *bufbegin ^= *keyiter;
    }
}

b.b. schrieb:

meine schöne c-funktion auch.

Die mit dem du den ganzen Flamewar erst provoziert hast? Ich denke nicht.

hier im forum c code zu posten, bedeutet für dich also flamewar provozieren.
und ja, ich habe auf abfällige bemerkungen entsprechend reagiert, warum sollte ich mir das auch gefallen lassen.

pumuckl

b.b. schrieb:

hier im forum c code zu posten, bedeutet für dich also flamewar provozieren.
und ja, ich habe auf abfällige bemerkungen entsprechend reagiert, warum sollte ich mir das auch gefallen lassen.

Reiner C-Code ist hier off-topic. Gewisse Kommentare dazu wie "c ist sowieso viel besser" sind reine Provokation. Brauchen wir auch nicht weiter zu diskutieren, zurück zum Thema.

/edit: ich hebs nochmal hervor...

pumuckl schrieb:

Reiner C-Code ist hier off-topic.

stimmt, ich finde es ist höchste zeit, c++ und c zu trennen, lange genug hieß es c/c++ und das alles nur, weil c++ ein extern "C" erlaubt!

so, damit bin ich als reiner c'ler mal weg