Beste Verschlüsselung - so einfach?

[Krypter]

Hallo,
Ich habe folgenden Algorithmus zum verschlüsseln von Dateien geschrieben:

vector<BYTE> datei; //lese datei binär ein

vector<BYTE> key;
for(unsigned int a=0;a!=datei.size();++a)
    key.push_back( rand() );

vector<BYTE> encrypted(datei.size());

for(unsigned int a=0;a!=datei.size();++a)
    encrypted[a] = datei[a] ^ key[a];

Gibt es eine Verschlüsselung, die "Sicherer" ist?
Würde man die "Sicherheit" erhöhen, wenn man - anstatt einfach Xor zu nehmen - irgend einen wilden algorithmus mit Xor, Bitshift, Addition, Subtraktion usw einführt?
Hat die Qualität des PNG in Zeile 6 auswirkungen auf die Sicherheit?

[HighendCoder]

Krypter schrieb:

Hallo,
Ich habe folgenden Algorithmus zum verschlüsseln von Dateien geschrieben:

vector<BYTE> datei; //lese datei binär ein

vector<BYTE> key;
for(unsigned int a=0;a!=datei.size();++a)
    key.push_back( rand() );

vector<BYTE> encrypted(datei.size());

for(unsigned int a=0;a!=datei.size();++a)
    encrypted[a] = datei[a] ^ key[a];

Hat die Qualität des PNG in Zeile 6 auswirkungen auf die Sicherheit?

Vor allem Zeile 6.

Gibt es eine Verschlüsselung, die "Sicherer" ist?

Ja.

[Krypter]

Aber mit einem "perfekten" RNG wäre das der Sicherste Algorithmus zur Verschlüsselung? Oder gibt es noch weitere Konzepte, die vielleicht besser wären?

[Blue-Tiger]

Krypter schrieb:

Aber mit einem "perfekten" RNG wäre das der Sicherste Algorithmus zur Verschlüsselung? Oder gibt es noch weitere Konzepte, die vielleicht besser wären?

Mit einem "perfekten" RNG waer die Verschluesselung 100% sicher, das ganze nennt sich "One Time Pad" (siehe z. B Wikipedia). ABER:

1. "perfekte" RNGs sind schwer herzubekommen
2. du musst Schluessel uebermitteln/abspeichern, die gleich gross sind wie die eigentlichen Daten: z. B 100kb Daten musst du 100kb Schluessel sicher uebermitteln/speichern ==> wenn du das sicher schaffst, haettest du genau so gut gleich die echten Daten auf diesem Weg speichern koennen.

[Superlexx]

Blue-Tiger schrieb:

haettest du genau so gut gleich die echten Daten auf diesem Weg speichern koennen.

hätte er aber nicht zur selben Zeit machen müssen *g*. Der OTP wurde ja auch so verwendet: Agent nimmt sich lange Schlüssel mit und kommuniziert bis sie alle sind.

[tntnet]

@Krypter:

Du solltest Dich erst mal mit den Grundlagen der Verschlüsselung beschäftigen. Deine Verschlüsselung sieht auf den ersten Blick perfekt aus, wenn man der Schlüssel, der auf einem sicheren Weg übertragen werden muss, perfekte Zufallszahlen sind. Und schon die Erzeugung von Zufallszahlen ist schon eine Wissenschaft für sich. Die gängigen rand()-Implementierungen erzeugen mit einem Startwert immer die gleiche Folge. Damit ist die Schlüssellänge genau so lang, wie der Startwert, da ich den Rest ja daraus berechnen kann.

Und selbst dann haben Deine verschlüsselten Daten noch Informationen, die unverschlüsselt sind. Nämlich die Länge der Quelldaten. Also wenn Deine Ausgangsdatei beispielsweise 4711 Bytes hat, dann haben Deine verschlüsselten Daten auch 4711 Bytes. Der Angreifer erfährt also etwas über Deine Quelldaten. Offensichtlich ist Dein Algorithmus also doch nicht perfekt.

Die Länge erscheint auf den ersten Blick banal, aber nehmen wir beispielsweise eine Banküberweisung, die im Textformat vorliegt und verschlüsselt wird. Wenn es ungünstig gemacht wird, könnte es sein, dass ich aus der verschlüsselten Überweisung schliessen kann, wie viele Stellen der Betrag hat. Und das ist eine Information, die in einer verschlüsselten Banküberweisung mal wirklich nicht erkennbar sein sollte.

[Blue-Tiger]

Superlexx schrieb:

Blue-Tiger schrieb:

haettest du genau so gut gleich die echten Daten auf diesem Weg speichern koennen.

hätte er aber nicht zur selben Zeit machen müssen *g*. Der OTP wurde ja auch so verwendet: Agent nimmt sich lange Schlüssel mit und kommuniziert bis sie alle sind.

Word, aber der Threadersteller will ja vermutlich alle Details ueber den Algo wissen.

[SeppJ]

Um das nochmal auf den Punkt zu bringen: Diese One-Time-Pads(OTP) sind theoretisch unknackbar. Man handelt sich aber ein Problem ein: Der Schlüssel muss sicher übermittelt/gespeichert werden. Und das ist der eigentliche Knackpunkt, denn wenn man den Schlüssel sicher speichern/übermitteln kann, dann kann man auch gleich die Nachricht (die genauso lang ist) sicher speichern/übermitteln ansstelle des Schlüssels.

Normalerweise hat man aber keine absolut sicheren Kommunikationskanäle, daher wird OTP in der Praxis nur sehr selten benutzt (es gibt aber praktische Anwendungen in der Quantenkryptographie, da dort das Übertragungsproblem gelöst ist). In der Regel setzt man daher je nach Anwendungszweck andere Verfahren ein, oft auch Kombinationen aus mehreren Verfahren. Ein paar Beispielverfahren zum googeln: RSA, AES. Die sind dann aber nicht mehr so einfach zu verstehen.

[Krypter]

Das mit der Länge des Textes/der Datei ist ein guter Punkt.
Mir geht es eigentlich nur darum, einen "einfachen" Verschlüsselungsalgorithmus zu schreiben, nichts aufwändiges wie die gängigen Verfahren. Mich hat nur überrascht, dass mein erster Ansatz (siehe oben) schon eine (theoretisch) unknackbare Verschlüsselung darstellt.

[asdasd]

Krypter schrieb:

Würde man die "Sicherheit" erhöhen, wenn man - anstatt einfach Xor zu nehmen - irgend einen wilden algorithmus mit Xor, Bitshift, Addition, Subtraktion usw einführt?

Ja und Nein. Der Algorithmus kann dadurch schwerer zu rekonstruieren sein. Das ganze läuft dann unter dem Oberbegriff Security through obscurity.

Und ein solches Verfahren, das nur "sicher" ist, weil der Algorithmus nicht bekannt ist, ist insgesamt wieder unsicher.

Früher oder später wird man den Algorithmus rausbekommen und damit jede Nachricht entschlüsseln können!

[Moadal]

asdasd schrieb:

Früher oder später wird man den Algorithmus rausbekommen und damit jede Nachricht entschlüsseln können!

Nö, er hat ja immer noch das Passwortm was er ändern kann

[asdasd]

Moadal schrieb:

asdasd schrieb:

Früher oder später wird man den Algorithmus rausbekommen und damit jede Nachricht entschlüsseln können!

Nö, er hat ja immer noch das Passwortm was er ändern kann

Die Anzahl an Schlüsselmöglichkeiten sinkt dadurch aber so drastisch, dass man diesen schnell berechnen kann.

[;fricky]

Krypter schrieb:

Mich hat nur überrascht, dass mein erster Ansatz (siehe oben) schon eine (theoretisch) unknackbare Verschlüsselung darstellt.

das einfachste ist oft schon fast das beste. nimm z.b. einen PRNG, der aus einem passwort (also nicht aus seinem vorherigen zustand, wie rand()) eine pseudo-zufallsfolge, so lang wie deine datei, macht. das ist dann noch schöner.
z.b. 'nen sha1-hash aus dem passwort machen, daraus wieder einen sha1-hash, dahinterhängen, usw. bis die gewünschte länge erreicht ist.

[volkard]

;fricky schrieb:

Krypter schrieb:

Mich hat nur überrascht, dass mein erster Ansatz (siehe oben) schon eine (theoretisch) unknackbare Verschlüsselung darstellt.

das einfachste ist oft schon fast das beste. nimm z.b. einen PRNG, der aus einem passwort (also nicht aus seinem vorherigen zustand, wie rand()) eine pseudo-zufallsfolge, so lang wie deine datei, macht. das ist dann noch schöner.
z.b. 'nen sha1-hash aus dem passwort machen, daraus wieder einen sha1-hash, dahinterhängen, usw. bis die gewünschte länge erreicht ist.

Das kling sehr schlau. Ist es aber wie so oft nicht. Die sha1-Folge ist doch genau das Verwenden des vorherigen Zustands. Welche Aussagen gibt es nochmal über die Periodenlänge von sha1-Ketten? Und dann kannste deinen Pseudo-Zufallszahlengenerator, auch den mit sha1, so pfiffig machen, wie Du willst, bei einem Passwort aus drei Dezimalziffern gibt es nur 1000 Möglichkeiten. Ein zu kleiner Schlüsselraum läßt sich nicht korrigieren, indem man viel Rechenzeit für nichts verbrät.

[Verschüsselungsexperte]

Du solltest noch RC4 mit dem Hash verknüpfen um eine monoalphabetische Substitution auf Bitebene zu verhindern. Dann kannst du mit Public Key Cryptography einen RSA PRNG Codekey zur asymmetrischen Signatur hinzufügen und erzielst eine dem One-Time-Pad änhlich, aber mit hybrider Verfahrenssicherheit ohne dabei auf Hashkollisionen der PNG Tripel zu stoßen.

[;fricky]

volkard schrieb:

Das kling sehr schlau. Ist es aber wie so oft nicht. Die sha1-Folge ist doch genau das Verwenden des vorherigen Zustands.

klar, ist mir schon während des schreibens aufgefallen. aber das sollte trotzdem schwer zu knacken sein, weil jedes einzlne bit des passworts einfluss auf die ganze folge hat. ich hab so'ne ähnlich sha1-ketten-xor-verschlüsselung mal implementiert (allerding war der in input für sha1 vorheriger hash xor voheriger verschlüsselter datei-block), das ergebnis ist wirklich ein übler bitsalat, an dem sogar http://www.cryptool.org/ nix zu meckern hatte.

volkard schrieb:

Ein zu kleiner Schlüsselraum läßt sich nicht korrigieren, indem man viel Rechenzeit für nichts verbrät.

musste eben lange passwörter wählen, schön mit sonderzeichen, gross/kleinschreibung und ziffern drin.

[tntnet]

Verschüsselungsexperte schrieb:

Du solltest noch RC4 mit dem Hash verknüpfen um eine monoalphabetische Substitution auf Bitebene zu verhindern. Dann kannst du mit Public Key Cryptography einen RSA PRNG Codekey zur asymmetrischen Signatur hinzufügen und erzielst eine dem One-Time-Pad änhlich, aber mit hybrider Verfahrenssicherheit ohne dabei auf Hashkollisionen der PNG Tripel zu stoßen.

Daran habe ich auch gedacht. Oder ich hätte daran gedacht, wenn ich wenigstens mit der Hälfte Deiner Begriffe was anfangen könnte .
Immerhin weiß ich so viel über Verschlüsselung, dass ich weiß, dass ich das den richtigen Experten überlassen sollte.

Aber Du bringst es eigentlich trotzdem auf den Punkt. Verschlüsselung ist ein kompliziertes Thema und man sollte eher bewährte und getestete Algorithmen verwenden, als eigene erfinden. Eigene sind praktisch immer schlechter.

[;fricky]

tntnet schrieb:

Immerhin weiß ich so viel über Verschlüsselung, dass ich weiß, dass ich das den richtigen Experten überlassen sollte.

verdirb dem OP doch nicht den spass. wenn jeder so denken würde, dann wären wir heute immer noch bei der cäsar-chiffre *fg*

[loks]

Bei einer Verschlüsselung zählt nicht der Algo allein, sondern man muß immer das ganze System betrachten inklusive der Frage welche Art von Daten denn jetzt verschlüsselt werden sollen...

Beispiel... Mein Vorgänger hatte die Aufgabe ein Lizenzfile zu verschlüsseln. In dem Lizenzfile wurden Lizenzflags als Bitfeld gespeichert. (1 bit = 1 lizenzfeature). As Schlüsselalgo wählte der Kerl nen Stream-Cypher.

Alles was man tuen mußte war mittels Hex-Editor an der richtigen Stelle des Files ein Bit inverten um das zugehörige Lizenzflag an/ oder auszuschalten. Man brauchte ncihtmal das Passwort dazu. (Und die Geschäftsführung hat echt blöde geguckt...)

Krypter schrieb:

Das mit der Länge des Textes/der Datei ist ein guter Punkt.
Mir geht es eigentlich nur darum, einen "einfachen" Verschlüsselungsalgorithmus zu schreiben, nichts aufwändiges wie die gängigen Verfahren. Mich hat nur überrascht, dass mein erster Ansatz (siehe oben) schon eine (theoretisch) unknackbare Verschlüsselung darstellt.

I want to move to theorie, cause in theorie everything works...

[;fricky]

loks schrieb:

Bei einer Verschlüsselung zählt nicht der Algo allein, sondern man muß immer das ganze System betrachten inklusive der Frage welche Art von Daten denn jetzt verschlüsselt werden sollen...

Beispiel... Mein Vorgänger hatte die Aufgabe ein Lizenzfile zu verschlüsseln. In dem Lizenzfile wurden Lizenzflags als Bitfeld gespeichert. (1 bit = 1 lizenzfeature). As Schlüsselalgo wählte der Kerl nen Stream-Cypher.

Alles was man tuen mußte war mittels Hex-Editor an der richtigen Stelle des Files ein Bit inverten um das zugehörige Lizenzflag an/ oder auszuschalten. Man brauchte ncihtmal das Passwort dazu. (Und die Geschäftsführung hat echt blöde geguckt...)

^^muss aber trotzdem ein mieser algo gewesen sein. wenn man ein bit im cypher text flippt, sollte bei einer halbwegs guten verschlüsselung nach dem ent-crypteten einiges kaputt sein. nächstes mal häng das dran: http://www.javvin.com/networksecurity/MessageIntegrityCode.html
bzw. ein CRC, der tuts auch.