Funktionen fgetc() unf fputc() nur fuer ASCII Zeichen ???

In einem DV-Praktika haben wir ein kleines Kyptogrphie-Programm geschrieben.
Dabei wurde von einer einzulesenden Datei byte-für-byte die Information(binäre Zahl) eingelesen, zu ihr eine Zahl addiert und die Information dann in eine zweite Datei gespeichert. Die Zahl, die auf die Information darufaddiert wurde, ist der Schlüssel.
Kern der Verschluesselungsfunktion ist dieser Abschnitt:
Quellcode:void plusconst(int richtung) /* richtung -> 1 = verschluesseln , -1 = entschluesseln */
{
  int schluessel,c,cneu;

  do
    {
    printf("Schluessel eingeben ( 0 - 255 )\n"); /* Eingabe des Schlussels mit Pruefung */
    scanf("%d",&schluessel);
    }
  while( schluessel <= 0 || schluessel >= 255 );

  while((c=fgetc(in)) != EOF ) /* in = Filepointer auf Einlesedatei */
    {
    cneu = (c+richtung*schluessel+256)%256; /* Verschluesselungs-Algorithmus */
    fputc(cneu,out); /* out = Filepointer auf Auslesedatei */
    }
} Nun wollte ich den recht einfachen Verschlüsselungs-Algorithmus etwas 'pimpen'.

Jedoch ergibt sich bei mir auf dem Rechner ein kleines Problem:
Die Ausgabedatei (die verschlüsselte) ist kleiner geworden.
Der Effekt wird besonders deutlich bei formatierten Textdokumenten (.doc oder .rtf) und bei Bilder (.jpg) ; hier sind Bilder nach dem verschlüsseln von 1,5 MB auf 135 Bytes geschrumpft.

Meine Vermutung ist deshalb, dass die Funktionen fgetc() unf fputc() nur fuer ASCII Zeichen, also Binärzahlen von 0 bis 255, funktioniernen. Die .doc , .rtf und .jpg - Dateien verwenden hoechstwahrscheinlich Binärzahlen von ueber 255, sodass die beiden Funktionen diese Bytes einfach weglässt.

Oder kann es auch etwas mit dem Betriebssystem zusammenhängen? Beim Praktika wurde irgendein Linux-BS verwendet, ich habe auf meinen Rechener XP drauf. Beim Praktika konnte ich zB problemlos Bitmapdateien (.bmp) codieren und decodieren; zu Hause gib es mit dem selben Programm aus dem Praktikum nicht mehr! (Könnte aber auch an dem .bmp Format zusammenhängen und wie es Linux speichert, habe nämlich nicht dieselbe Bitmap einmal unter Linux und einmal unter XP de/codiert.)

Hat hier jemand ne Idee, wo das Problem sein könnte?

Gruss Andre

.: Ist es krank, wenn ich es geil finde ? :.
.: Shoot me to the moon, Mr. President :.

Zitat:

[AR] HL-Mapper postete
Meine Vermutung ist deshalb, dass die Funktionen fgetc() unf fputc() nur fuer ASCII Zeichen, also Binärzahlen von 0 bis 255, funktioniernen. Die .doc , .rtf und .jpg - Dateien verwenden hoechstwahrscheinlich Binärzahlen von ueber 255, sodass die beiden Funktionen diese Bytes einfach weglässt.

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

1. es heisst praktikum im singular
2. bitmap ist auch unter linux nur bitmap

ansonsten, wenn du byte-weise liesst dann kriegst du auch nur n byte (zeig mir mal eins dass nen wert grösser als 255 hat)
lies mal binär

Quellcode:(c+richtung*schluessel+256)%256; Falls du dich fragen solltest, was theDon eigentlich meint... Der Wertebereich für signed char ist 0 bis 255 :)

Btw., wenn du dein Prog da pimpen willst, solltest du wissen, daß einige ASCII-Zeichen nur Steuerfunktion besitzen bzw. Whitespaces sind. In diesem Fall wäre es besser, wenn du CNs Vorschlag beherzigst und die Datei binär schreibst beim Verschlüsseln bzw. binär einliest beim Entschlüsseln.

EDIT: Ack, hat ja hier keinen [cpp] Tag o_O

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Zitat:

Kriz postete
Der Wertebereich für signed char ist 0 bis 255 :)

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

Abgesehen davon macht die Schluessel-Pruefung nicht das, was die Eingabezeile vermuten laesst.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Wtf, wo ist denn das un geblieben? Dolle Kartoffel...

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Zitat:

es heisst praktikum im singular

Zitat:

Ein Byte hat acht Bits. Demnach kann ein Byte nie groesser als 255 sein

Zitat:

Btw., wenn du dein Prog da pimpen willst, solltest du wissen, daß einige ASCII-Zeichen nur Steuerfunktion besitzen bzw. Whitespaces sind

Das gleiche hat auch mit einer beliebigen Bitmap funktioniert.
Also codiert -> man konnte sie nicht mehr betrachten -> dann wieder decodiert -> die Bitmap konnte wieder gelesen werden, der Inhalt der Bitmap war wieder erkennbar .

-----

Das Thema finde ich sehr interesant, also nach dem Praktikum mir den Quellcode auf den USB-Stick gepackt und wollte das Prog zu Hause auf dem Rechner ausprobieren und erweitern.
Jedoch, wie beschrieben, lässt das Prog ( wenn es mit Dev-C++ und unter XP compilert wurde ) einige Byte 'unter den Tisch fallen'.

Bei einer einfachen Unicode-Textdatei nur ~ ein dutzend,
bei einem Bitmap fast alle und von den vorher 1,5 MB bleiben 135 Bytes übrig.

Kann die Formatierung einer Festplatte irdendwelche Auswirkungen darauf haben, sperrt sich Windows/Virenscanner/... gegen das beschreiben von Dateien mit 'seltsamen Byte-Folgen' ??

Ich geh das Programm zu Hause noch mal Zeile für Zeile durch, vielleicht hat sich ja da ein Fehler eingschlichen

MfG

.: Ist es krank, wenn ich es geil finde ? :.
.: Shoot me to the moon, Mr. President :.

Zitat:

CN postete
lies mal binär

Zitat:

man 3 fopen
The mode string can also include the letter ``b'' either as a last character or as a character between the characters in any of the two-character strings described above. This is strictly for compatibility with ANSI X3.159-1989 (``ANSI C'') and has no effect; the ``b'' is ignored on all POSIX conforming systems, including Linux. (Other systems may treat text files and binary files differently, and adding the ``b'' may be a good idea if you do I/O to a binary file and expect that your program may be ported to non-Unix environments.)

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

[AR] HL-Mapper
ich bezweilfe dass du irgendeinen der posts hier vollständig gelesen hast, ausser den ersten von thedon

1. fputc() & Co. lassen definitiv keine Bytes unter den Tisch fallen
2. Es gibt keine seltsamen Bytefolgen
3. Ein char in C/C++ kann als Zeichen _oder_ Byte interpretiert werden (Java z.B. dagegen hat die Trennung vollzogen), sprich es kommt drauf an, wie man die Werte verarbeitet
4. Wo ist nun dein Problem?

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Quick & Dirty... praktisch identischer Code, geht.
Quellcode:#include <stdio.h>
#include <stdlib.h>

void do_crypt(int dir, FILE *in, FILE *out)
{
    int key, c;
    
    do {
        printf("Schluessel eingeben (0-255)\n");
        scanf("%d", &key);
    } while (key < 0 || key > 255);
    
    while ((c = fgetc(in)) != EOF) {
        c += (dir * key + 256) % 256;
        fputc(c, out);
    }
}


int main(int argc, char** argv)
{
    FILE *in, *out;
    int dir;
    
    if (argc != 4)
        return -1;
    
    dir = atoi(argv[1]);
    in = fopen(argv[2], "r");
    out = fopen(argv[3], "w");
    
    if (!(in && out))
        return -1;
    
    do_crypt(dir, in, out);
    return 0;
}

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Hey, ich hab auch ne Kryptographiefrage!

Und zwar hab ich mal vor nem Jahr was in ner Klausur zum RSA-Verfahren geschrieben, das ich jetzt nicht mehr verstehe ^^

Quellcode:p = 13;
q = 17;
e = 7;
{
x = (((p - 1) * (q - 1)) * i + 1) mod e;
i++;
}
while (x != 0)
d = (((p - 1) * (q - 1)) * i + 1) / e;
p und q sind die beiden Primzahlen, e ist ein Schlüssel (z.B. der private) des Schlüsselpaares. Es geht nun darum ein passendes d zu diesem bereits bestimmten e zu finden.

x ist der Rest der überbleibt wenn die Division von dem was da in Klammern steht mit e nicht sauber aufgeht, solange das nicht aufgeht wird (p - 1) * (q - 1) immer mit einem pro Durchlauf um 1 angestiegendem i multipliziert. Geht die Rechnung ohne Rest auf, so wird abschließend d ausgegeben.

Was ich jetzt nicht zahlentheoretisch kapiere ist: (Wieso) darf ich einfach (p - 1) * (q - 1) immer mit nem ansteigendem Faktor multiplizieren? Ist das ein korrektes Verfahren um ein d zu bestimmen? Bin wohl zu müde -_o

dazu guckst du dir vielleicht besser eine beschreibung des rsa verfahrens an denn dann musst du so ne frage nicht stellen
ausserdem "disagreen bei dir code and comments" (dank an ttt) ;)
der block wo dein i hochgezählt wird, wird nur ein mal wiederholt, das einzige was wiederholt wird solang x != 0 ist ist die zeile mit d = ...

Öhm... nicht ganz, der Block mitm i wird garnicht wiederholt, nur ein einziges mal ausgeführt, cool was so nen vergessenes "do" ausmacht wa? Btw. woher willste das eigentlich wissen, hab ja garnicht die Programmiersprache genannt, könnt doch auch was ganz anderes sein als Java... :P
Danke für den Wikipedia-Link, DA hatte ich noch nicht nachgesehen...

wer sagt denn dass ich von java ausgegangen bin, wer sagt dass ich von irgendwas ausser logik ausgegangen bin?
zu dem ersten wiederholt: meinte ausgeführt
ausserdem fehlt da noch einiges mehr als nur ein do, rein logisch

Logik ist relativ.