# "Verschlüsselung" mit Passwort (XOR bzw. Modulo)



## Bizarrus (25. Mrz 2011)

Hallöchen.
ich möchte gerne eine kleine Verschlüsselung visualisieren.
Sieht auch schon recht gut aus, funktioniert leider aber noch nicht ganz so, wie ich will.

Ich möchte, dass diese Methode um einen String mit einem Passwort zu "verschlüsseln" bzw. "entschlüsseln" zuverlässig funktioniert, was allerdings nicht der Fall ist.


```
private static int CryptKey(int count, String hash) {
		int size = hash.length();
		count = count % size;
		char[] sKeys = hash.toCharArray();
		return sKeys[count];
	}

	
	public static String CryptE(boolean method, String string, String hash) {
		String returned = "";
		int char_new = 0, count = 0;
		
		for(int i = 0; i < string.length(); i++) {
			if(method) {
				char_new = string.charAt(i) + CryptKey(count, hash);
			} else {
				char_new = string.charAt(i) - CryptKey(count, hash);
			}
			
			char_new = char_new % 256;
			if(char_new < 0) { char_new += 256; }
			
			returned += new Character((char) char_new);
			count += 1;
		}
		
		return returned;
	}
```

Wie wird die Methode genuzt?
Eigendlich Relativ einfach. Man hat ein String, der "verschlüsselt" werden soll, gibt an, ob Ver- oder Entschlüsselt werden soll (true bzw false) und gibt noch ein Passwort an:


```
System.out.println("\"Hello World\" verschlüsselt: " + CryptE(true, "Hello World", "mein Passwort"));
```

Wozu benutze ich diese Methode?
Ich bin derzeit dabei ein Chat zu entwickeln und möchte nicht, dass die "Kommunikation" zwischen Client & Server in Klartext geschieht.
Bei einem handshake des Clienten mit dem Server generiert der Chatserver ein Passwort.
Dieses Passwort ist solange gültig, bis der Client sich vom Server aus irgendwelchen Gründen verabschiedet (Beispielsweise timeout oder beenden des Clienten). Das Passwort wird verwendet um die Kommunikation zwischen Client & Server ein wenig zu sichern (Siehe obige Methoden).

Leider gibt es nun folgendes Problem: Nicht alle Zeichen werden wieder richtig "umgewandelt". Es werden ja schließlich mit der obigen Methode nur die Zeichen "versezt" sodass diese unleserlich erscheinen.

Hier gebe ich mal kurz ein Beispiel:


> Passwort: v2fnauQc4y
> 
> Versendet: Hello
> Verschlüsselt: ¾—ÒÚÐ
> ...



Wie kann ich die obigen Methoden so optimieren, dass auch tatsächlich *immer* das selbe ergebnis rauskommt? Ich möchte halt, wenn ich "Hello World" versende und dies mit einem Passwort verschlüsselt wird auch bei der entschlüsselung wieder "Hello World" herauskommt.

Hat jemand einen Tipp/Ideen und kann mir ggf. bei den Problem behilflich sein?


----------



## Gast2 (25. Mrz 2011)

Erm, deine Bemühungen in Ehre - aber warum nicht einfach die Verbindung über SSL absichern?


----------



## Bizarrus (25. Mrz 2011)

Klar, dann muss ich die Jar-file signieren, benoetige dann dafuer ein zertifikat was wiederrum Geld kostet da ansonsten beim laden immer eine vertrauens-dingsbums-meldung erscheint.

Ich moechte die verbindung selbst nicht verschluesseln, sondern den text, der versendet wird.


----------



## Gast2 (25. Mrz 2011)

Bizarrus hat gesagt.:


> Ich moechte die verbindung selbst nicht verschluesseln, sondern den text, der versendet wird.



Versteh ich schon. Das ist aber normalerweise konzeptionell der falsche Ansatz. Hast du dir mal gängige Verschlüsselungsalgorithmen angesehn?

Und nebenbei würd ich wenn schon dann den übertragenen Text in base64 encodieren. Macht es meiner Meinung nach leichter zu debuggen.


----------



## Bizarrus (25. Mrz 2011)

ja, hatte mir schon so einiges angeschaut gehabt (cypher & co). Probleme hierbei hatte ich bei grossen texten (man sollte bedenken, es ist ein chat - es kommt also vor, dass man auch mal Romane schreibt).

Gut base64 waere zwar eine moeglichkeit, spricht mich aber nicht so direkt an, zumal man des auf einfacher art en- und decoden kann (ohne irgendwelche "passwortangaben").


----------



## Gast2 (25. Mrz 2011)

Bizarrus hat gesagt.:


> Gut base64 waere zwar eine moeglichkeit, spricht mich aber nicht so direkt an, zumal man des auf einfacher art en- und decoden kann (ohne irgendwelche "passwortangaben").



Ich würde den *verschlüsselten* Text in base64 encodieren. Dann bekommst du keine unleserlichen Zeichen übermittelt und es macht das debuggen einfacher.

Hier mal ein link der dir helfen könnte die Verschlüsselung richtig zu machen: https://wiki.imise.uni-leipzig.de/Themen/JavaSecurity

Bleibt halt immer noch die Frage wie du initial das Passwort übermittelst. Das ist der schwächste Punkt deiner Kette.


----------



## musiKk (25. Mrz 2011)

Für einen Chat zwischen zwei Parteien eignet sich auch ein Stream-Cipher wie RC4. Den initialen Austausch der Codewörter kann man über Diffie-Hellman erledigen. Das Setup ist ähnlich der BitTorrent Protocol Encryption. Da ist man zwar nicht vor MITM gefeit, aber das geht ohnehin schlecht ohne "ein zertifikat was wiederrum Geld kostet".



fassy hat gesagt.:


> Hier mal ein link der dir helfen könnte die Verschlüsselung richtig zu machen: https://wiki.imise.uni-leipzig.de/Themen/JavaSecurity



Richtiger wäre natürlich, nicht ECB zu nutzen.


----------



## despikyxd (27. Mrz 2011)

Bizarrus hat gesagt.:


> da ansonsten beim laden immer eine vertrauens-dingsbums-meldung erscheint



ich muss dich leider enttäuschen : auch wenn du ein gültiges zertifikat hast *was also von einer bekannten CA wie THWATE oder VeriSign signiert wurde kommt diese meldung um dem user mitzuteilen das das applet OHNE die sandbox ausgeführt wird ...
der einzige unterschied ist nur das bei einem gültigen zertifikat unten drunter steht das es halt gültig is und bei einem ungültigen ein text angezeigt wird das hier i-was nicht stimmt ... ansonsten aber wird das fenster IMMER angezeigt um halt besagte meldung zu machen


----------

