suche pure Python crypt Algo...

[lunar]

Generell würde ich gern was fertiges nehmen. Aber ich hab da folgende Anforderungen, wie ich oben schon mal geschrieben hab:
-Klein soll es sein
-pure Python

Klein ist Rijndael ebenso wie andere AES Kanditaten, aber pure python ist halt langsam. Das steht ja auch im docstring des TLSLite Moduls:

A pure python (slow) implementation of rijndael with a decent interface

Wäre natürlich gut, wenn installierte binäre Krypto Module genutzt werden, wenn vorhanden. Damit es auch schneller geht. Ich glaube das kann auch TLSLite. Ich denke mit dem Modul fahre ich am besten.

Naja, ich weiß nicht... Die Datei, die du genannt hast, sieht für mich so aus, als würde sie nur einzelne Blöcke verschlüsseln, d.h. du musst dich nicht nur ums padding kümmern, sondern auch noch um eine korrekte Umsetzung von CBC. Das wird sehr schnell sehr aufwändig und vor allem fehleranfällig...

Das Modul, was ich dir genannt habe, übernimmt wenigstens schon mal das CBC für dich. Ums padding musst du dich leider immer noch selbst kümmern
Außerdem ist wahrscheinlich wesentlich schneller, weil der Hauptteil der Arbeit in C implementiert ist und auch sicherer, weil man in C Speicherbereiche (z.B. den Key oder den IV) zuverlässig löschen kann. Python hat zwar den del Operator, aber es ist eben nicht garantiert, dass die Daten sofort aus dem Speicher verschwinden.

Allerdings ist das alles imo ein ziemliches Trauerspiel Es gibt offenbar keine einfache, schnelle Schnittstelle zum Ver- und Entschlüsseln von Daten mit AES Da ist .NET ein großes Stück weiter; Verschlüsseln ist dort kein großes Problem. Dinge wie padding oder CBC werden da selbstverständlich von der Bibliothek übernommen...

Edit: Gibt es irgendwo einen nopaste Service für dieses Forum? Ich habe mal versucht, ein padding mit dem von mir genannten Modul zu implementieren, dass kann ich dir gerne posten...

[Leonidas]

Edit: Gibt es irgendwo einen nopaste Service für dieses Forum? Ich habe mal versucht, ein padding mit dem von mir genannten Modul zu implementieren, dass kann ich dir gerne posten...

Ja, gibt es, das LodgeIt, welches von blackbird programmiert wurde und birkenfelds Pygments nutzt. Somit haben wir einen der besten Paste-Services im Internet

[lunar]

Ja, gibt es, das LodgeIt, welches von blackbird programmiert wurde und birkenfelds Pygments nutzt. Somit haben wir einen der besten Paste-Services im Internet

Das beste ist gerade gut genug für meinen Code
(wo wir gerade beim angeben sind)

Habe das Snippet jetzt gepostet:
http://paste.pocoo.org/show/271/

[birkenfeld]

Das

Code: Alles auswählen

    # remove unencrypted stuff and hope, that it really vanishes from memory
    del data
    del a
    del padval

ist unsinnig. Damit löschst du nur die Name -> Objekt-Zuordnungen aus dem locals-Dict der Funktion, was beim return sowieso passiert.

[lunar]

Das

Code: Alles auswählen

    # remove unencrypted stuff and hope, that it really vanishes from memory
    del data
    del a
    del padval

ist unsinnig. Damit löschst du nur die Name -> Objekt-Zuordnungen aus dem locals-Dict der Funktion, was beim return sowieso passiert.

Stimmt In dem Snippet sind sogar noch zwei andere, relativ nutzlose del Operationen. Naja, war eben quick n' dirty

[jens]

Klein ist Rijndael ebenso wie andere AES Kanditaten, aber pure python ist halt langsam. Das steht ja auch im docstring des TLSLite Moduls:

Ich weiß. Aber so ist es halt Meine bisherige XOR Variante braucht für 130KB Daten auch ca. 13Sek auf meinem Rechner
Deswegen wäre es halt nett, wenn die installierte Binäre Module nutzten könnten, ohne das man viel umstricken muß.
Das kann und macht IMHO TLSLite:

TLS Lite is pure Python, however it can access OpenSSL, cryptlib, pycrypto, and GMPY for faster crypto operations.

Außerdem ist wahrscheinlich wesentlich schneller, weil der Hauptteil der Arbeit in C implementiert ist

Logisch. Aber da sind wir jetzt wieder bei binären Modulen Für PyLucid in einer CGI Umgebung brauche ich aber pure Python.

Die Datei, die du genannt hast, sieht für mich so aus, als würde sie nur einzelne Blöcke verschlüsseln, d.h. du musst dich nicht nur ums padding kümmern, sondern auch noch um eine korrekte Umsetzung von CBC.

Mit dem padding hast du recht. Aber ein CBC muß ich nicht unbedingt haben... Das wäre ein wenig Übertrieben, denke ich...

Es gibt offenbar keine einfache, schnelle Schnittstelle zum Ver- und Entschlüsseln von Daten mit AES

Speziell AES weiß ich jetzt nicht, aber schau dir mal hier um:
http://cheeseshop.python.org/pypi?:action=browse&c=401

[lunar]

Außerdem ist wahrscheinlich wesentlich schneller, weil der Hauptteil der Arbeit in C implementiert ist

Logisch. Aber da sind wir jetzt wieder bei binären Modulen Für PyLucid in einer CGI Umgebung brauche ich aber pure Python.

Blöd
Kannst du da nicht was drehen? z.B. pycrypto in den Vorraussetzungen erwähnen? Obwohl, dass geht ja bei gemieteten Webservern auch nicht

Die Datei, die du genannt hast, sieht für mich so aus, als würde sie nur einzelne Blöcke verschlüsseln, d.h. du musst dich nicht nur ums padding kümmern, sondern auch noch um eine korrekte Umsetzung von CBC.

Mit dem padding hast du recht. Aber ein CBC muß ich nicht unbedingt haben... Das wäre ein wenig Übertrieben, denke ich...

Sicherer ist CBC allemal, und so schwierig sollte das Implementieren auch nicht sein: Du musst einfach den aktuellen Klartextblock mit dem letzten Chiffreblock XOR verknüpfen. Als ersten Chiffreblock nimmst du den IV.
Zum Entschlüsseln fängst du wieder von vorne an: Den Block entschlüsseln, und den "Klartext" mit dem letzten Chiffreblock verknüpfen, um den richtigen Klartext zu erhalten...

Gruß
lunar

[lunar]

Ich habe mir jetzt mal die Mühe gemacht AES mit CBC und padding zu implementieren. Als Basis habe ich das rijndael Modul von TLS Lite genommen. Das Ganze ist hier zu finden:
http://paste.pocoo.org/show/276/

Die Anwendung ist einfach:

Code: Alles auswählen

key = os.urandom(32)
iv = os.urandom(16)
encrypted = new rijndael(key,iv).encrypt('hallo')
decrypted = new rijndael(key,iv).decrypt(encrypted)

Es sollte funktionieren (hoffe ich )
Verbesserungsvorschläge willkommen, der Code ist wie das andere snippet auch typisch q&d...

gruß
lunar

[sape]

Sieht beeindruckend aus dein Code.

Aber verstehen tue ich da nichts von

lg

[jens]

Hab den Thread über Sinn oder Unsinn des PyLucids JS-MD5-Login... mal abgetrennt...

[jens]

Ich glaube ich bleibe doch beim einfachen XOR. Allerdings nutzte ich nicht, wie früher random. Somit gehe ich dem Ursprünglichen Problem aus dem Weg, das random auf verschiedenen Rechnern, verschiedene Zahlenfolgen ausspuckt

Ich setzte voraus, das Klartext und Schlüssel genau gleich lang sein müssen, so wie es das one-time-pad Verfahren vorschlägt.

Das ganze ist sehr einfach:

Code: Alles auswählen

def crypt(txt, key):
    assert len(txt)==len(key), "Error: txt and key must have the same length!"

    crypted = [unichr(ord(t) ^ ord(k)) for t,k in zip(txt, key)]
    return u"".join(crypted)

Das ganze kann man mit x-beliebigen unicode Zeichen füttern und es kommt unicode zurück.

Das Ver- und Entschlüsseln nutzt genau die selbe Methode, wie es bei XOR üblich ist. Ich hab allerdings auch noch eine Methode drum herrum gebaut, die eine SHA Checksumme beim verschlüsseln einfügt und bei entschlüsseln vergleicht:
http://pylucid.net:8080/pylucid/browser ... y?rev=1167

[nkoehring]

Hi jens...

ich weiß nicht, ob es jetzt noch relevant ist, aber hast du schonmal vom Tiny Ecryption Algorithm (TEA) gehoert?

Schau einfach auf http://de.wikipedia.org/wiki/Tiny_Encryption_Algorithm.

So und jetzt wuensche ich eine gute Nacht.

[Joghurt]

Sonst kann man auch RC4 recht einfach in Python implementieren.

[lunar]

Sonst kann man auch RC4 recht einfach in Python implementieren.

Wobei man hier recht vorsichtig sein sollte, was den Einsatzzweck des Algorithmus angeht. RC4 ist in manchen Systemen (v.a. WEP) erwiesenermaßen unsicher. Die Entdecker der Schwachstelle in WEP empfehlen in ihrem Paper übrigens, RC4 nicht mehr für neue Kryptosysteme einzusetzen

[jens]

http://de.wikipedia.org/wiki/Tiny_Encryption_Algorithm

Hm! Das ist ja interessant! Zumal es auch Implementierungen in JavaScript gibt.
Von daher ergibt sich für mein JS-SHA-Login vielleicht neue Möglichkeiten, mal sehen...

[Joghurt]

Wobei man hier recht vorsichtig sein sollte, was den Einsatzzweck des Algorithmus angeht. RC4 ist in manchen Systemen (v.a. WEP) erwiesenermaßen unsicher. Die Entdecker der Schwachstelle in WEP empfehlen in ihrem Paper übrigens, RC4 nicht mehr für neue Kryptosysteme einzusetzen

Ich glaube nicht, dass es sich hier um ein sehr sicherheitsrelevates System handelt. Außerdem ist der Hauptschwachpunkt von RC4, IIRC, dass die ersten erzeugten Bytes eine für den Schlüssel charakteristische Verteilung haben. Man kann es daher etwas sicher machen, wenn man die ersten 5000 Bytes (oder mehr) wegschmeisst.

Das ganze dürfte dann auch nicht unsicherer sein als TEA

TEA hat einige Schwächen. Die meisten rühren daher, dass es zu jedem Schlüssel drei äquivalente Schlüssel gibt. Deswegen ist die effektive Schlüssellänge nur 126-bit (Kelsey et. al., 1996, und Vikram Andem, 2003). Diese Schwäche wurde beim Hacken von Microsofts Spielekonsole Xbox ausgentzt, da diese TEA als Hash-Funktion verwendete. TEA ist auch anfällig für eine verwandte Schlüssel-Attacke, die 223 gewählte Klartexte bei verwandten Schlüsseln braucht.