Interessant! Verschlüsselung in Java, Charset in der JVM?

[guni]

Hallo,

ich habe ein externes Programm, dass über einen Algorithmus einen 32-Zeichen langen String erzeugt und damit Dateien mit einem bitwise xor verschlüsselt.
Das programm ist in C geschrieben.
Meine Aufgabe ist es nun, in Java ein Programm zu schreiben, dass diese Dateien wieder entschlüsselt...

Soweit, sogut.
Ich habe in meinem Programm den gleichen Algorithmus geschrieben, der auch in C den Schlüssel erzeugt, lese die verschlüßelte Datei blockweise ein, durchlaufe das erhaltene byte-Array und verknüpfe jedes Zeichen per XOR mit dem zugehörigen Zeichen aus dem Schlüssel.

das funktioniert auch soweit, solang mein Schlüssel keine besonderen Zeichen enthält.
erzeuge ich in C/Java allerdings einen komplexeren Schlüssel, kann mir java meine Dateien nicht mehr entschlüsseln.
die erzeugten Zahlen stimmen überein; sobald ich in java ein

(char)pwdint

mache, erhalte ich nicht immer die selben Zeichen, die ich in c mit dem gleichen befehl erhalte.
Während mein c-kompliertes Programm in der Kommandozeile nette Sonderzeichen wie Smileys oder mathematische Symbole im Key anzeigt, stellt mein Java einen großteil der Sonderzeichen nur als Fragezeichen da.

Jetzt hab ich mir gedacht, vielleicht läuft die JVM unter einem anderen Charset wie windows ...
kann das sein? Wie könnte ich da draufkommen?
Woran könnte es sonst liegen?
(Wie gesagt: die int-Werte sind noch die gleichen; d.h. mein Algorithmus ist gleich!)

mfg, guni

 

[guni]

hmm ... vielleicht muss ich mein problem ein bisschen konkretisieren um eine antwort zu bekommen.

im prinzip funktioniert die verschlüsselung ja so, dass ich einen key mit beliebiger zeichenlänger erzeuge und dann mit xor bitwise mit meinem text verschlüssle.
nehmen wir folgendes Beispiel:

Schlüssel: SCHLUESSEL123
Text: Franz jagt im komplett verwahrlosten Taxi quer durch Bayern

Verschlüsselung (XOR):
F XOR S -> (char)21
r XOR C -> (char)49
a XOR H -> (char)41
n XOR L -> (char)34
z XOR U -> (char)47
  XOR E -> (char)101
j XOR S -> (char)57
a XOR S -> (char)50
g XOR E -> (char)34
t XOR L -> (char)56
  XOR 1 -> (char)17
i XOR 2 -> (char)91
m XOR 3 -> (char)94
  XOR S -> (char)115
k XOR C -> (char)14
o XOR H -> (char)39
m XOR L -> (char)33
p XOR U -> (char)37
l XOR E -> (char)41
e XOR S -> (char)54
t XOR S -> (char)39
t XOR E -> (char)49
...

sehen wir uns die 1. Zeile genauer an:
der Buchstabe des Schluessels ist ein 'S', der Buchstabe des Textes ein 'F'. S hat in der ASCII-Tabelle einen Wert von 70, S hat 83. Diese beiden Werte weren per XOR verknüpft -> wir erhalten 21 (genaugenommen das Zeichen, das in der ASCII-Tabelle diesen Wert hat).
Das tolle ist, dass ich - sofern ich den Schlüssel kenne - aus meinem verschlüsselten Text per XOR auch wieder den Klartext ermitteln kann:
nehmen wir an, mein Programm stößt auf das Zeichen des Wertes 21. Verknüpfe ich es mit dem zugehörigen Buchstaben meines Schlüssels ('S' mit Wert 83), so erhalte ich wieder den ursprünglichen Wert ('F' mit Wert 70).
ich kann also mit der gleichen Methode, mit der ich VERSCHLÜSSELT habe auch wieder entschlüsseln.

so. und jetzt zum eigentlichen Problem:
mein Schlüssel wird natürlich über einen Algorithmus erzeugt; nehmen wir zum Beispiel folgende Funktion (ich schreibe hier jetzt irgendwas unsinniges für die Erzeugung des Buchstabens):

private String keygen() {
   StringBuffer key = new StringBuffer();
   for (int i=0; i<32;i++) {
      int k = i*2-4%8
      key.append((char)k)
   }
   return key.toString();
}

der Schlüssel besteht natürlich nicht nur aus "schönen" Zeichen, er hat irgendwelche abgefahrenen Sonderzeichen dabei.
den Algorithmus kann ich natürlich nicht ändern, weil es ihn ja auch im C-Programm schon gibt! mein Problem ist, dass JAVA mit der Entschlüsselung nicht ganz zurechtkommt. Manche Zeichen sind anders. Der int-Wert k ist aber natürlich gleich; ich habe ja den gleichen Algorithmus.
Jetzt verstehe ich nicht ganz, womit das zusammenhängen kann.
Ich könnte mir vorstellen, dass unterschiedliche char-sets vielleicht manche Sonderzeichen anders belegen -> ?.
dann wäre die Lösung, die ich mir irgendwie vorstellen könnte, das charset der JVM mit dem charset meines C-Programmes gleichzusetzen.
Keine Ahnung ob das geht / ob das Problem überhaupt daran liegt.

Hätte irgendwer da eine Idee?! Wenn ihr keine Lösung habt wäre ich auch schon über einen Ansatz dankbar, mit dem ich das Problem finden / beweisen kann ;-)

danke!
guni

 

[faetzminator]

Ich gehe davon aus, dass es einfach die Konsole (warscheinlich in Eclipse oä?) anders ausgibt. Mach es mal im Systemterminal, und du solltest die gleiche Ausgabe bekommen.

 

[guni]

... ja. das hab ich mir auch schon gedacht. aber die konsole gibt mir auch etwas anderes aus :-(

 

[faetzminator]

machst du denn System.out.print(char) ? Oder wie gibst du es aus?

 

[guni]

nein ... ich erzeuge meinen Key mit einem StringBuffer.
dann returned die Funktion ein stringbuf.toString();

das gibt ich dann mit System.out.println aus ...

 

[guni]

weiß da wirklich keiner weiter?!

 

[ice-breaker]

Java verwendet für die Chars UTF-16 also 2 Byte, du solltest abklären was das C-Programm nutzt.
Ich vermute mal ASCII oder UTF-8

 

[Spacerat]

Warscheinlich liegt der Hund darin begraben, wie der Key in der eigentlichen Anwendung erstellt wird. Verwendet man dort "new String(bytes[] array, int offset, int length)" oder "somestring.getBytes()" hat man ein Problem (...eben dieses hier). Bei den internen Umwandlungen wird die Klasse "StringCoding" verwendet. Will man den Umstand umgehen (sprich: unabhängig Wandeln), muss man selbst implementieren:[highlight=java]byte[] binarystringToBytes(String binarystring)
{
// ACHTUNG: äusserste Vorsicht!! Strings welche Zeichen oberhalb von UTF-8
// beinhalten werden "verfälscht"!
byte[] rc = new byte[text.length()];
for(int c = 0; c < text.length(); c++) rc[c] = (byte) (text.charAt(c) & 0xFF);
return rc;
}

String bytesToBinaryString(byte[] buffer)
{
StringBuffer() rc = new StringBuffer();
for(int c = 0; c < buffer.length; c++) rc.append((char) (buffer[c] & 0xFF));
return rc.toString();
}[/highlight]

 

[guni]

@spacerat.
habe deine funktionen jetzt mal in meine funktionen "eingeflochten" ...
tja: kaum macht man's richtig gehts ;-)
danke für eure tipps *gg*

 

[ice-breaker]

Hmm, gerade so als Gedanke:
Könnte man nicht auch die getBytes(Charset c) verwenden? Man müsste ja nur sagen, dass er UTF-8 nutzen soll.
Dann würden auch UTF-16 Zeichen in der UTF-8 Notation funktionieren.

 

[Spacerat]

War mir bisher schlicht zu blöd, damit viel rumzuexperimentieren. Daher weis ich das nicht. Ich kann mir jedoch auch gut vorstellen, das beim Wandeln der utf-16 nach utf-8 auch irgend etwas verfälscht wird z.B. aus zwei Bytes nur eines wird.

 

[ice-breaker]

neija nen UTF-16 Zeichen in UTF-8 wird zu 2 Bytes, jup, aber die werden eben durch spezielle UTF-Sequenzen verbunden, das jeder der UTF-8 parsen kann, weiß, dass die 2 Byte eigentlich 1 Zeichen ist.

 

[Spacerat]

...Mit anderen Worten: Da wird in der Byte-Sequenz (den Binärdaten) etwas verändert. Deswegen steht dort auch das "ACHTUNG" im gepostetem Text. Ein mit "bytesToBinaryString()" codierter String wird definitiv auch wieder genau das Bytearray welches es vorher war. Anders siehts mit Strings aus, die UTF-16 enthalten.

 

[ice-breaker]

Ja ich meinte nur wenn man es zu nem UTF-8 Byte Array macht, kann man ganz normal die Verschlüsselung nutzen.
Unser String mit 8 Zeichen ist dann eben nicht mehr 8 Byte lang sondern 8 - 16 Byte, aber die Operationen funktionieren alle dadrauf, da wir ein UTF-16 korrekt zu UTF-8 umgeformt haben.