[C++]Binäre Verschlüsselungsalgorythmen

[J!0X]

Hallo,
Habe letztens einen kleinen Algorithmus für ASCII Dateien gecodet. Es wird der ASCIIwert eines Buchstaben des Schlüssels genommen und zu dem Wert des Buchstaben des Klartexts addiert. Herraus kommen selbstverständlich seltsame Zeichen. Falls ich jetzt aber eine binäre Datei öffne, kann das ganze natürlich nicht funktionieren. Kann mir jemand erklären, wie ich binäre Dateien verschlüsseln soll?
MfG J!0X

[anda_skoa]

Das geht mit binären Dateien auch, du muß lediglich das Überlaufen, bzw Unterlaufen des Wertebereichs berücksichtigen

sagen wir der Schlüssel Wert ist 100

Verschlüsseln
Input 200 +100 -> 300 -255 -> 45

Entschlüsseln
Input 45 -100 -> -55 +255 -> 200

Während der Rechnung brauchst du natürlich einen Datentyp, der den größeren Wertebereich halten kann.

Ciao,
_

[Joghurt]

Einfach mit Modulo arbeiten:
coded = (zeichen+100)%256
decoded = (coded-100)%256

BTW: Es heißt "Algorithmus", hat nichts mit Rhythmus zu tun

[Pingu]

Ah, die klassische Caesar-Verschlüsselung.

Leider zuleicht knackbar.

Ich würde Dir anstatt einer Addition/Multiplikation besser die XOR-Verknüpfung empfehlen. Ist einfacher zu handhaben.

Pingu

PS: Ich lese gerade "Angewandte Kryptographie" von Bruce Schneider.

[Joghurt]

Leider zuleicht knackbar.

Ich denke, hier ging es eher um eine Programmierübung denn um eine sichere Verschlüsselung. Sowohl Addition als auch XOR sind gleich sicher, es kommt halt auf den Schlüssel an.
@J!0X: Falls du eine sichere Verschlüsselung haben willst, nimm AES oder so etwas. Es gibt genug Bibliotheken dafür.

[J!0X]

Leider zuleicht knackbar.

Also ich zeige hier mal kurz den Sourcecode:

void encrypt(std::ifstream& srcfile,std::ofstream& dstfile,char *key,bool log)
{
    
    int keypos = 0, strpos = 0;
    char buf, str[srcsize];
    
    while(!srcfile.eof())
    {
        str[strpos] = srcfile.get();
        strpos++;    
    }
    str[strpos] = '\0'; strpos = 0;
    srcfile.close();
    
    while(str[strpos + 1] != '\0')
    {
        if(key[keypos] == '\0') keypos = 0;
        buf = key[keypos];
        if(log){std::cout << "Encrypting character \"" << str[strpos] << "\" with key-character \"" << buf <<"\": ";}
        str[strpos] += (int)buf;
        if(log){std::cout << str[strpos] <<std::endl;}
        dstfile.put(str[strpos]);
        strpos++; keypos++; 
    }
}

Ich addiere folglich nicht immer einen gleichen Wert.
Ich denke, dass man da nur mit nem Bruteforcer ne Chance hat, und da das Passwort 25 Zeichen lang sein kann und man nicht weiß, wann der richtige Text rausgekommen ist, wird das wohl schwierig sein.

Es heißt "Algorithmus", hat nichts mit Rhythmus zu tun

thx, habe mal wieder zu schnell gelesen(C++ Buch^^).

[Joghurt]

Ich denke, dass man da nur mit nem Bruteforcer ne Chance hat, und da das Passwort 25 Zeichen lang sein kann und man nicht weiß, wann der richtige Text rausgekommen ist, wird das wohl schwierig sein.

Die Vermutung ist falsch. Wenn der Schlüssel 25 Zeichen lang ist, wird immer im Abstand von 25 Zeichen dieselbe Substitution benutzt. Nun muss man nur eine Häufigkeitsanalyse der Zeichen (im Abstand von z.B. 25) durchführen, und kann bald sagen, welches Zeichen für e steht[*] (z.B.), damit hat man dann u.U. schon einen Buchstaben des Schlüssels, etc.

Außerdem kann man davon ausgehen, dass die Nachricht korrekt ist, wenn der analysierte Schlüssel sowas wie "SupergeheimesWort" ist.

Erst wenn der Schlüssel so lang ist, wie die verschlüsselnde Nachricht, kommt man mit Buchstabenhäufigkeiten nicht weiter. Und erst, wenn der Schlüssel 100% Zufällig ist (also auch nicht mit einem Zufallszahlengenerator generiert) ist die Verschlüsselung absolut sicher.

PS: In deinem Code vermisse ich, dass du keypos wieder auf 0 setzt, wenn du am Ende des Schlüssels angekommen bist.

PPS: Falls du dich für Kryptographie interessierst, ist neben Applied Cryptographie auch "Entzifferte Geheimnisse" von F. Bauer zu empfehlen.
[*] "e" ist der häufigste Buchstabe im deutschen und englischen.

[J!0X]

Ich habe mir letztens erst ein Buch über Kryptografie aus der Bibleothek ausgeliehen, habe aber erst ein paar Seiten gelesen.

Erst wenn der Schlüssel so lang ist, wie die verschlüsselnde Nachricht, kommt man mit Buchstabenhäufigkeiten nicht weiter.

Hm und wie möchtest du das realisieren? Kann mir das nicht so ganz vorstellen^^

PS: In deinem Code vermisse ich, dass du keypos wieder auf 0 setzt, wenn du am Ende des Schlüssels angekommen bist.

Da steht doch

if(key[keypos] == '\0') keypos = 0;

B2T: Soll ich also die binären Werte wie ASCII Werte "behandeln"(also das mit dem addieren etc.), aber den Modulo-Operator hinzuziehen?

[Joghurt]

Hm und wie möchtest du das realisieren? Kann mir das nicht so ganz vorstellen^^

Du nimmst z.B. atmosphärisches Rauschen oder atomare Zerfälle auf und nimmst nur die untersten paar Bits der Messergebnisse. Das ganze lässt du dann 2 Tage lang laufen und brennst die Ergebnisse auf CD. Schon hast du 700MB Schlüsseldaten. Für jede neue Nachricht beginnst du nun dort auf der CD, wo du bei der alten aufgehört hast.

Das Problem ist, den Schlüssel sicher zu deinem Partner zu bekommen (deswegen gibt es ja überhaupt Publickey-Verfahren). Man kann es z.B. so machen, dass du 3 CDs machst, dessen Inhalt mittels XOR kombiniert werden müssen.

Die erste sendest du per Schiff, die zweite per Flugzeug und die dritte im Diplomatengepäck.

[Pingu]

Wie schon angesprochen, die Ceasarverschlüsselung ist mit einer einfachen Häufigkeitsanalyse knackbar. Für mich noch nicht, aber ich sag mal für einige sind das gerade mal Auflockerungsübungen.

Die sicherste Verschlüsselung ist heute noch das sog. One-Time-Pad. Leider ist sie nicht wirklich praktikabel.

Außerdem, wie hat Bruce so schön geschrieben (er haut auch nur zitiert, aber ich weiß nicht mehr wen): Eine sichere Verschlüsselung hängt nur von der Geheimhaltung des Schlüssels ab und nicht von dem eingesetzten Verfahren. Denn nur wenn das Verfahren offengelegt ist, haben qualifizierte Experten die Möglichkeit das Verfahren zu überprüfen. Alles andere ist Security by Obscurity.

Pingu

[J!0X]

Mal ne kurze Verständnisfrage: Die Häufigkeitsanalyse würde doch nur funktionieren, wenn der Klartext immer den gleichen Buchstaben beinhaltet. Der Text ist aber völlig "zufällig" (Wenn mans so nennen will).

[locus vivendi]

Mal ne kurze Verständnisfrage: Die Häufigkeitsanalyse würde doch nur funktionieren, wenn der Klartext immer den gleichen Buchstaben beinhaltet.

Häufigkeitsanalyse klappt immer wenn man einigermaßen zutreffend raten kann welche Art von Text unverschlüsselt rauskommen soll.

Der Text ist aber völlig "zufällig" (Wenn mans so nennen will).

Du willst es wahrscheinlich nicht so nennen. Wenn der Text zufällig wäre, dann könntest du dir Verschlüsselung gleich ganz sparen.

[bischi]

Außerdem, wie hat Bruce so schön geschrieben (er haut auch nur zitiert, aber ich weiß nicht mehr wen): Eine sichere Verschlüsselung hängt nur von der Geheimhaltung des Schlüssels ab und nicht von dem eingesetzten Verfahren. Denn nur wenn das Verfahren offengelegt ist, haben qualifizierte Experten die Möglichkeit das Verfahren zu überprüfen. Alles andere ist Security by Obscurity.

Da hat Bruce aber ausnahmsweise mal nicht recht (mit Ausnahme von der One-Time-Pad-Verschlüsselung - und auch da nur dann, wenn du den Schlüssel nur einmal verwendest):

Denn ob beispielsweise RSA oder AES (oder was du auch sonst immer als aktuellen state-of-the-art nehmen willst - sind beides "offene" Verfahren), hängt es nicht nur davon ab, ob du deinen Schlüssel vor mir geheimhalten kannst, sondern massgeblich auch davon, wieviel Rechenleistung und "Glück" ich zur Verfügung habe. Denn mit Ausnahme der One-Time-Pads (mit atmosphärischem Rauschen und nur einfacher Verwendung, codiert von Hand in einem unüberwachten Büro) kannst du jede heutige Verschlüsselung knacken (brauchst unter Umständen einfach einen schnelleren PC als den, den du bei dir zu Hause stehen hast - mal bei der NSA nachfragen gehen, die haben glaub ich noch so ein paar Supercomputer, die sie aufgrund von Strommangel (stand zumindest mal auf heise.de) nicht benutzen können).

In diesem Umstand sehe ich denn auch ein grosses Problem heutiger Verschlüsselung: Nehmen wir an, ich verschlüssle ein sensitives Dokument mit heute üblicher Schlüssellänge (die zumindest für Normalverbraucher nicht knackbar ist) und schicke dieses Dokument übers Internet. Wer garantiert mir dann, dass nicht jemand das File abfängt und zehn Jahre später mit seinem Heimcomputer entschlüsselt? Die Daten sind vielleicht dann immer noch vertraulich...

MfG Bischi (der wieder mal etwas viel geschrieben hat )

[Joghurt]

Wer garantiert mir dann, dass nicht jemand das File abfängt und zehn Jahre später mit seinem Heimcomputer entschlüsselt? Die Daten sind vielleicht dann immer noch vertraulich...

Niemand, und deshalb sendet man verschlüsselte Dokumente nur, wenn die Informationen darin irgendwann nutzlos geworden ist. Z.B. ist es egal, wenn ein Dokument in dem Pläne für das nächste Geschäftsjahr gespeichert sind, nach 2 Jahren entschlüsselt wird.

Außerdem halten viele Verfahren der "Gartenschlauch-Methode" nicht stand, diese besteht darin, denjenigen, der das Kennwort kennt, solang mit einem Gartenschlauch auf die Füße zu schlagen, bis er das Kennwort freigibt. Oder wie es ein NSA (oder was es FBI?)-Mitarbeiter mal zu jemanden sagte, der sich mit seiner verschlüsselten Festplatte brüstete: "Ich bin man gespannt, wie sicher deine Daten sind, wenn dir jemand eine 9mm an die Schläfe hält"

"Sicherheit" ist immer ein relativer Begriff. Absolute Sicherheit gibt es nicht.

[J!0X]

"Sicherheit" ist immer ein relativer Begriff. Absolute Sicherheit gibt es nicht.

Ja, da stimme ich dir zu
Noch mal zu meiner obigen These, dass der Text zufällig ist:
Ich meine damit, dass nicht immer die gleichen Buchstaben in der gleichen Reihenfolge auftreten. Es hängt natürlich immer vom User ab, was geschrieben wird .

Außerdem halten viele Verfahren der "Gartenschlauch-Methode" nicht stand, diese besteht darin, denjenigen, der das Kennwort kennt, solang mit einem Gartenschlauch auf die Füße zu schlagen, bis er das Kennwort freigibt.

HEHEHE