XOR Verschlüsselung; Grenzen?

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