One Time Pad - Verschlüsselungsprogramm (Programmabsturz unter Windows)
-
Hallo Zusammen!
Durch Zufall bin ich auf eine interessante Schaltung gestoßen mit der man echte Zufallszahlen generieren kann. (http://www.jtxp.org)
Nun habe ich einige zufallsdaten Dateien hergestellt um mit diesen eine Einwegverschlüsselung (One-Time-Pad) zu nutzen.
Programmiert habe ich das Programm mit C unter Linux, hier funktioniert auch alles wunderbar! Jedoch hängt sich das Programm bei Windows auf und ich weiss nicht wie ich das Problem am besten beheben kann. Da ja beim Kompilieren keine Fehlermeldung erscheint.
Die Fehlermeldung: Programm funktioniert nicht mehr.
Allerdings funktioniert es des öfteren wieder ohne Probleme.
Fehler titt meist beim ent und verschlüsseln auf!PS: Bin noch kein Profiprogrammierer!, das ist erst mein zweites Programm
-
Beschreibe, was unter welchen Umständen genau passiert.
(Dass One Time Pads eher Unsinn sind, ist dir bekannt, oder?)
-
xcatpc schrieb:
Jedoch hängt sich das Programm bei Windows auf
Sehr, sehr schlechte Fehlerbeschreibung.
Was passiert noch, was nicht mehr?
Gibt es irgendwelche Meldungen von Windows?
Welchen Compiler unter Windows und welchen unter Linux nimmst du?Hast du schon den Debugger benutzt?
-
Warum Unsinn?
Fehler:
Wenn ich unter Windows die eine Datei entschlüsseln oder manchmal auch verschlüsseln möchte, dann kommt nur die Meldung von Windows, Programm funktioniert nicht mehr. Manchmal bzw des öfteren Funktioniert aber wiederum alles.Unter Linux habe ich überhaupt keine Probleme.
-
xcatpc schrieb:
char *vevn_extraktion(char *datei) { char *vevn = malloc(sizeof(char) * 3); char *schluessel_vvv_signatur = sig_extraktion(datei); vevn[2] = schluessel_vvv_signatur[strlen(schluessel_vvv_signatur)-6]; vevn[1] = schluessel_vvv_signatur[strlen(schluessel_vvv_signatur)-7]; vevn[0] = schluessel_vvv_signatur[strlen(schluessel_vvv_signatur)-8]; vevn[3] = '\0'; //printf("%s\n", vevn); return vevn; }
Hier greifst du auf undefinierten Speicher zu, d.h. undefiniertes Verhalten, d.h. Programm ist Müll, du greifst auf 4 Bytes zu, hast aber nur 3 Bytes definiert
Außerdem ist hier eine potentielle Quelle von Speicherlecks.
- globale Variablen sind auch Müll
- C99 Features ohne Notwendigkeit benutzt
- scanf("%200s"... muss scanf("%199s"... heißen
- ...
-
Was mit erstmal aufgefallen ist:
- du nutz malloc (mehrmals), hast aber kein free (kann schon der Grund der Abstürze sein)
- schlechter Einrückungsstil
(Gut angefangen, aber leider nicht durchgezogen)
- Du hast leere if-Blöckeif(modus == 1 || modus == 2 || modus == 3) {} else
da negiert man dei Bedingung:
if(!(modus == 1 || modus == 2 || modus == 3)) { der Code aus dem else-Zweig
-
[quote="Wutz"]
xcatpc schrieb:
[cpp]
Hier greifst du auf undefinierten Speicher zu, d.h. undefiniertes Verhalten, d.h. Programm ist Müll, du greifst auf 4 Bytes zu, hast aber nur 3 Bytes definiert
Außerdem ist hier eine potentielle Quelle von Speicherlecks.
- globale Variablen sind auch Müll
- C99 Features ohne Notwendigkeit benutzt
- scanf("%200s"... muss scanf("%199s"... heißen
- ...Müll? Danke
Warum sind globale Variablen Müll?
Ansonsten erstmal Danke, werde ich überarbeiten!
-
DirkB schrieb:
Was mit erstmal aufgefallen ist:
- du nutz malloc (mehrmals), hast aber kein free (kann schon der Grund der Abstürze sein)Aber ich brauche den Inhalt bis des speichers oft bis zum Schluss. Soll ich am ende des Programmes den Speicher wieder freigeben?
-
xcatpc schrieb:
Müll? Danke
Warum sind globale Variablen Müll?Ist die Frage ernst oder entgeht mir die Ironie?
Da ich nicht selber die tausendfach gebrachten Argumente noch einmal tippen möchte:
Wikipedia schrieb:
They [ = global variables] are usually considered bad practice precisely because of their non-locality: a global variable can potentially be modified from anywhere (unless they reside in protected memory or are otherwise rendered read-only), and any part of the program may depend on it.[1] A global variable therefore has an unlimited potential for creating mutual dependencies, and adding mutual dependencies increases complexity. See action at a distance.
[One time pads]
Warum Unsinn?Wieder so eine Frage, wo ich nicht sicher bin, ob du sie ernst meinst. Ich hätte gedacht, dass du dich wenigstens grundlegend mal mit dem Thema befasst hättest. OTP ist zwar theoretisch ganz interessant, praktisch jedoch völlig unbrauchbar und ein sicheres Zeichen für Schlangenölverkäufer, wenn jemand damit wirbt. Man tauscht nämlich ein sehr gut verstandenes Problem (Nachrichtenaustausch über unsicher Kanäle) gegen ein sehr schwieriges (sicheren Schlüsselaustausch). Lass dich davon aber nicht von deinem Programm abhalten, du machst das ja sicher nur zur Übung. Und da ist OTP ganz nett.
-
xcatpc schrieb:
Aber ich brauche den Inhalt bis des speichers oft bis zum Schluss. Soll ich am ende des Programmes den Speicher wieder freigeben?
Ja klar.
Aber kannst du das überhaupt?
if(strcmp(vevn_extraktion(buffer), "VVV") == 0 )
ruftvevn_extraktion
das ruftsig_extraktion
und das dann malloc.
Irgendwo auf dem Weg geht aber der Zeiger verloren.
Also brauchst du ihn nicht bis zum Schluss.Bist du dir sicher, das du bei den Schleifen richtig zählst?
Beifor(x=0; x<=z_datei; x++)
hast du (z_datei+1) Durchläufe, da du bei 0 anfängst.
Ind C ist es üblich den Vergleich auf < zu machen, wenn du nur z_datei Durchläufe möchtest.for(x=0; x<z_datei; x++)
Erst recht wenn du
for(x=0; x<=z_datei-1; x++)
hast.
-
xcatpc schrieb:
Warum Unsinn?
Stell dir mal vor du willst einen HD film von 10GB sicher deinem freund schicken. Wenn du jetzt dazu OTP benutzt verschlüsselt du die 10GB mit einem 10GB schlüssel, schickst den HD film deinem freund und bringst ihm den schlüssel auf einem USB stick.
Warum hast du ihm den Film nicht direkt auf dem USB stick gebracht?
xcatpc schrieb:
DirkB schrieb:
Was mit erstmal aufgefallen ist:
- du nutz malloc (mehrmals), hast aber kein free (kann schon der Grund der Abstürze sein)Aber ich brauche den Inhalt bis des speichers oft bis zum Schluss. Soll ich am ende des Programmes den Speicher wieder freigeben?
Immer dann wenn du ihn nichtmehr brauchst. Ich glaub nicht dass du alles bis zum Schluss brauchst und wenn du es bis zum schluss brauchst gib es dann dort frei, bringt zwar meistens dann nichts aber macht man so, weil man dann leichter die wirklichen memory leaks suchen kann.
Auch allgemein zu der Fehlersuche in einem Programm. Wenn das Programm abstürzt ist es nicht ratsam sich einfach den gesamten quellcode anzugucken und einen fehler zu suchen. Das geht vllt. wenn der code ein paar zeilen lang ist. Aber stell dir mal ein Programm mit mehreren zehntausend Zeilen code vor, es ist ziemlich sicher dass das nicht nachdem ersten compilieren funktioniert wie gewünscht, und dann einfach den gesamten quellcode zu durchsuchen würde viel zu lange dauern. Deshalb musst du erst einmal herausfinden wo denn das problem im code liegt. Dazu nimmst dir einfach einen debugger startest das programm in ihm und er müsste dir dann anzeigen wo dein programm absturzt und dann weist du wo du suchen musst und kannst das programm zeilenweise durchlaufen lassen und überprüfen ob die zeile auch wirklich das macht was du von ihr erwartest.
mfg tobZel