Problem mit XOR Verschlüsselung??

12/05/2009 - 18:37 von Florian Lindner | Report spam
Hallo,

ich habe ein Programm welches Daten von einer anderen Quelle bekommt.
Diese Daten sind mit einem statischen Schlüssel über xor verknüft.
Seit den Update von Debian Etch auf Lenny (Python 2.4 auf 2.5.2)
treten dabei sporadisch Probleme auf. Ich bin noch nicht sicher, wo
das Problem liegt, habe aber den Algorithmus zur Entschlüsselung im
Verdacht.

Dieser schaut im Prinzip so aus:

payload ist ein String in Hex. Also wirklich ein normaler String, der
die übliche Hex-Repràsentation enthàlt, z.B. "fcff" heißt 0xfcff.
Deshalb das decode("hex"). Entschlüsselt werden soll nur payload[2:]

def handleEncipheredData(self, payload):
KEY = "ABCDEFGHIJK"
for k in range(6):
KEY += KEY # Create a key that is long enough for XOR
operation
recordNum = payload[0:2] # Soll nicht entschlüsselt werden
origLength = len(payload)
intKey = map(ord, KEY)
dataBlock = map(ord, payload[2:].decode("hex"))
deciphered = ""
for i, d in enumerate(dataBlock):
deciphered += chr(operator.xor(d, intKey[i]))

return recordNum + deciphered[:origLength-2].encode("hex")


Die Lànge von payload ist immer ziemlich kurz, die Lànge von KEY
sollte also ausreichen.
Kann es sein, dass dieser Algorithmus bei einigen Werten für payload
falsche Ergebnisse liefert? Evtl. abhàngig von der Einstellung des
Locales? (Zeichensatz).

Ich bin natürlich auch offen für alle anderen Verbesserungsvorschlàge.

Danke!

Florian
 

Lesen sie die antworten

#1 Stefan Behnel
12/05/2009 - 19:19 | Warnen spam
Florian Lindner schrieb:
ich habe ein Programm welches Daten von einer anderen Quelle bekommt.
Diese Daten sind mit einem statischen Schlüssel über xor verknüft.
Seit den Update von Debian Etch auf Lenny (Python 2.4 auf 2.5.2)
treten dabei sporadisch Probleme auf. Ich bin noch nicht sicher, wo
das Problem liegt, habe aber den Algorithmus zur Entschlüsselung im
Verdacht.

Dieser schaut im Prinzip so aus:

payload ist ein String in Hex. Also wirklich ein normaler String, der
die übliche Hex-Repràsentation enthàlt, z.B. "fcff" heißt 0xfcff.
Deshalb das decode("hex"). Entschlüsselt werden soll nur payload[2:]

def handleEncipheredData(self, payload):
KEY = "ABCDEFGHIJK"
for k in range(6):
KEY += KEY # Create a key that is long enough for XOR
operation



Schreib doch einfach

KEY = "ABCDEFGHIJK" * (2**6)

recordNum = payload[0:2] # Soll nicht entschlüsselt werden
origLength = len(payload)
intKey = map(ord, KEY)



bzw.
intKey = map(ord, orig_short_KEY) * (2**6)

dataBlock = map(ord, payload[2:].decode("hex"))
deciphered = ""
for i, d in enumerate(dataBlock):
deciphered += chr(operator.xor(d, intKey[i]))



Wie wàre es mit dem ^ Operator ?

Oder damit:

from itertools import izip, imap, cycle

deciphered = ''.join(chr(d ^ k)
for d,k in izip(imap(ord, decoded_payload),
cycle(imap(ord, KEY))))

return recordNum + deciphered[:origLength-2].encode("hex")



Was macht das "[:origLength-2]" Slicing hier am Ende? Und wieso kodierst du
das Ganze danach wieder nach Hex?

Die Lànge von payload ist immer ziemlich kurz, die Lànge von KEY
sollte also ausreichen.
Kann es sein, dass dieser Algorithmus bei einigen Werten für payload
falsche Ergebnisse liefert? Evtl. abhàngig von der Einstellung des
Locales? (Zeichensatz).



Nicht auf den ersten Blick, zumindest solange du nur Byte-Strings
einfütterst. Solltest du versehentlich einen Unicode-String erwischt haben,
wir dir der Algorithmus allerdings was husten.

Hast du mal versucht, auf beiden Seiten der Verbindung eine MD5-Summe vom
chiffrierten Text zu nehmen, damit du siehst, ob die Daten die geschrieben
wurden identisch sind mit denen, die gelesen wurden? Da kann eine ganze
Menge schief gehen, z.B. bei FTP-Übertragungen die Zeilenumbrüche
korrigieren, oder sowas.


Ich bin natürlich auch offen für alle anderen Verbesserungsvorschlàge.



Vielleicht kein XOR zur Verschlüsselung benutzen? Ist sehr anfàllig gegen
Klartextattacken.

Stefan

Ähnliche fragen