suche pure Python crypt Algo...

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

In PyLucid gibt es ein Problem mit dem eingebauten crypt Modul. Es ist ein XOR Verschlüsselung, die bekanntermaßen nicht wirklich sicher ist. Das ganze wird für den MD5-Login verwendet. Von daher reicht eigentlich die Sicherheit aus...

Aber nun ist es so, das Änderungen am crypt Modul dazu führen werden, das alle alten Passwörter ungültig werden, siehe auch:
http://pylucid.htfx.eu/phpBB2/viewtopic.php?p=327#327

Also bietet es sich an, das man den crypt Algorithmus komplett tauscht.

Nur was nehmen???

Ich würde nur eine pure Python Implementation nehmen, die möglichst klein ist (eine Datei) und ab Python 2.3 läuft.

Ich hab PyDES gefunden: http://cheeseshop.python.org/pypi/pyDes/ (DES und Triple DES)

Dann gibt es noch http://cheeseshop.python.org/pypi/asym (u.a. RSA implementation) aber der Download ist tot.

Besser wäre es vielleicht sich aus TLSlite http://trevp.net/tlslite gezielt ein Algorithmus zu extrahieren. Ich denke TLSlite ist besser getestet als pyDES?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Hab mit TLSlite näher angesehen... Ich denke da kann man sich nur DES bzw. Rijndael draus extrahieren und einzeln benutzten: http://tlslite.cvs.sourceforge.net/tlsl ... iew=markup

Ob da ein Unterschied zu pyDES besteht?

Der Nachteil ist allerdings, das der key und der Inhalt immer bestimmte länge (Blocksize) haben müssen.

Das ist unpraktisch :(

Kennt jemand alternativen???

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

jens hat geschrieben:Kennt jemand alternativen???
Die eine oder andere, ja, in der Tat.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Der zweite Linkt geht bei mir nicht...

Der erste scheint mir irgendwie nicht so super implementiert zu sein, oder? So wie der Quellentext z.Z. da ist (mit ein paar print Anweisungen) kann ich das nicht direkt verwenden... Außerdem verunsichert mich ein wenig die Aussage:
Not suitable for governmental or commerical purposes.

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

jens hat geschrieben:Der zweite Linkt geht bei mir nicht...
Google-Cache

Daneben noch Rijndael.py von Bram Cohen oder pyRijndael. Habe ich alle mit fünf Minuten suchen über eine in diesem Post bereits erwähnte Suchmaschine gefunden.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

OK, google hab ich nicht angeworfen ;) Ich hab nur im cheeseshop gesucht bzw. versucht zu suchen :)

Dort gibt es auch die Kategorie "Topic :: Security :: Cryptography":
http://cheeseshop.python.org/pypi?:action=browse&c=401

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Bei älteren Modulen auf jeden Fall daran denken, dass sich mit der "Quasi-Zusammenlegung" von `int` und `long` einiges geändert hat.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Ich kenne zwar diesen Zusammenhang nicht wirklich, aber gut das du das sagst :) Somit noch ein Argument ein möglichst verbreitetes Modul zu nehmen. Ich denke mit dem Rijndael aus dem TLSlite Paket würde ich ganz gut fahren...

Aber irgendwie raff ich das nicht, wie ich das mit dem Blöcken machen soll. Das Passwort und die Daten müssen bestimmte Längen haben...
Am einfachsten könnte ich mir vorstellen, die Daten mit Null-Bytes aufzufüllen und am Ende wieder abzuziehen... Dann müßte man auch Null-Bytes in den Daten selber maskieren, wenn man z.B. Binäre Dateien verschlüsseln will...

Ist alles wieder nicht so einfach :) Hat irgendwer etwas in dieser Richtung schon gemacht? Wobei, ich TLSlite selber wird wohl irgendwo dafür eine Lösung schon drin stecken, oder?

Ich hab auch festgestellt, das schon mein XOR Verfahren extrem langsam ist. Das macht bei kurzen Passwörtern überhaupt nichts aus... Aber ich hatte eigentlich gedacht, das ich damit auch gleich Dateien im FileStore-Plugin verschlüsseln könnte... Aber schon eine ca. 150KB große Datei dauert bei mit ca. 13Sek. Das ist viel zu viel :(

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

Ich verstehe nicht, was jetzt XOR mit einer MD5-"Verschlüsselung" zu tun hat. Was willst du dadurch erreichen?

Zum Problem mit der festen Blocklänge: hänge einfach ein Byte (oder Word), das die Länge angibt, vor die eigentlichen Daten und fülle dann mit Nullbytes auf, wenn du nicht direkt auf das Ende der Daten schließen kannst.
lunar

Joghurt hat geschrieben:Zum Problem mit der festen Blocklänge: hänge einfach ein Byte (oder Word), das die Länge angibt, vor die eigentlichen Daten und fülle dann mit Nullbytes auf, wenn du nicht direkt auf das Ende der Daten schließen kannst.
Wenn man Wert auf Sicherheit legt, dann sollte man da Zufallsbits nehmen...
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

lunar hat geschrieben:Wenn man Wert auf Sicherheit legt, dann sollte man da Zufallsbits nehmen...
Ja, das wäre vielleicht gut, aber wie dann die Nutzdaten von den Zufalls-Auffüll-Daten trennen??? Durch ein "Markierungs-Zeichen"? Oder die Nutzdatenlänge in den Block mit speichern???

Da muß es doch was fertiges geben...

EDIT: Für das Passwort, also den Verschlüsselungs-Key könnte man z.B. eine MD5 Summe nehmen, dann hat man eine Feste Länge...

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
lunar

jens hat geschrieben:
lunar hat geschrieben:Wenn man Wert auf Sicherheit legt, dann sollte man da Zufallsbits nehmen...
Ja, das wäre vielleicht gut, aber wie dann die Nutzdaten von den Zufalls-Auffüll-Daten trennen??? Durch ein "Markierungs-Zeichen"? Oder die Nutzdatenlänge in den Block mit speichern???
Ich würde ein Nullbyte zum Trennen von Text und Müll nehmen:
Text\x00Zufallsmüll
Ein Nullbyte kommt in normalem Text nicht vor und ist deswegen auch ideal. Du verwirfst einfach alles nach dem ersten Aufkommen eines Nullbytes im Text. Das funktioniert allerdings nur, wenn du Text verschlüsselst. Bei binären Nutzdaten wirst du um ein Längenprefix nicht herumkommen, es sei den, du speicherst die Daten als base64 String...
jens hat geschrieben:Da muß es doch was fertiges geben...

Code: Alles auswählen

!aptitude show python-crypto
Paket: python-crypto
Zustand: Installiert
Automatisch installiert: nein
Version: 2.0.1+dfsg1-1.2build1
Priorität: optional
Bereich: python
Verwalter: Ubuntu Core Developers <ubuntu-devel@lists.ubuntu.com>
Unkomprimierte Größe: 770k
Hängt ab von: python-central (>= 0.5), python (< 2.6), python (>= 2.4)
Kollidiert mit: python2.3-crypto, python2.4-crypto
Ersetzt: python2.3-crypto, python2.4-crypto
Liefert: python2.4-crypto, python2.5-crypto
Beschreibung: cryptographic algorithms and protocols for Python
 A collection of cryptographic algorithms and protocols, implemented for use from Python. Among the contents of the package:

 * Hash functions: MD2, MD4.
 * Block encryption algorithms: AES, ARC2, Blowfish, CAST, DES, Triple-DES.
 * Stream encryption algorithms: ARC4, simple XOR.
 * Public-key algorithms: RSA, DSA, ElGamal, qNEW.
 * Protocols: All-or-nothing transforms, chaffing/winnowing.
 * Miscellaneous: RFC1751 module for converting 128-key keys into a set of English words, primality testing.
Vielleicht wäre das ja was für dich?
Allerdings sind die Algorithmen selbst - wohl aus Gründen der Performance - nicht in python implementiert, sondern liegen als C Erweiterungen vor...
jens hat geschrieben:EDIT: Für das Passwort, also den Verschlüsselungs-Key könnte man z.B. eine MD5 Summe nehmen, dann hat man eine Feste Länge...
Man verwendet sowieso nie das Passwort selbst als Schlüssel für den Algorithmus. Zum einen müsste man das Passwort bei Blockchiffren ja auffüllen - wer verwendet schon 256 Bit Passwörter ;) - zum anderen sind Passwörter in den seltensten Fällen so zufällig, dass sie als Schlüssel für Algorithmen taugen würden.
Deswegen lässt man immer Hashing Operationen über Passwörter laufen, um Schlüssel zu erzeugen.
Es existieren ja auch Standards zum Ableiten eines Schlüssels aus einem Passwort. Empfehlenswert wäre PBKDF2 mit 2000 Hashing Iterationen, um vorrausberechnete Wörterbuchangriffe zu verhindern...
Eine Python Implementation gibt es hier
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

ja die Idee mit dem NullByte hatte ich auch schon... Aber wenn, dann sollte alles auch mit Binärdaten gehen ;)
Zwei Möglichkeiten würden sich da anbieten:
1. Die länge der Nutzdaten stellt man diesen vorran. Bei entschlüsseln schneidet man dann einfach ab der Position die Daten ab
2. Man nimmt /x00 zu Trennung. Die anschließenden Auffüll-Daten dürfen entweder keinen NullBytes erhalten, oder diese werden Maskiert durch zwei NullBytes... Beim entschlüsseln suche ich von hinten an den ersten einzelnen NullByte und trenne...

Die erste Variante hört sich einfacher zu Implementieren an, oder?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
lunar

jens hat geschrieben:ja die Idee mit dem NullByte hatte ich auch schon... Aber wenn, dann sollte alles auch mit Binärdaten gehen ;)
Zwei Möglichkeiten würden sich da anbieten:
1. Die länge der Nutzdaten stellt man diesen vorran. Bei entschlüsseln schneidet man dann einfach ab der Position die Daten ab
2. Man nimmt /x00 zu Trennung. Die anschließenden Auffüll-Daten dürfen entweder keinen NullBytes erhalten, oder diese werden Maskiert durch zwei NullBytes... Beim entschlüsseln suche ich von hinten an den ersten einzelnen NullByte und trenne...

Die erste Variante hört sich einfacher zu Implementieren an, oder?
Was die Auffülldaten enthalten, ist doch egal. Du entschlüsselst alles, und dann splittest du beim ersten Nullbyte. Problematisch sind vielmehr eventuelle binäre Nutzdaten, die Nullbytes enthalten könnten...
Wenn solche Daten verschlüsselt werden sollen, würde ich persönlich die erste Methode wählen. Aber du solltest dir wirklich was Fertiges suchen...
Sowas korrekt und vor allem sicher zu implementieren, erfordert einiges an Wissen über dieses Fachgebiet. Im Zweifel macht man mehr Fehler als ein fertiges, getestetes Paket enthält...
Hast du dir mal das Paket angeschaut, welches ich dir genannt habe? Ich habe es jetzt mal selbst installiert. Die copyright Datei nennt diese URL als Quelle des Pakets. Vielleicht hilft es dir ja. Damit musst du dich um Dinge wie padding oder eine korrekte Implementierung von CBC nicht mehr kümmern.
Nur für PBKDF2 habe ich noch keine fertige Version in irgendeinem Modul gefunden...

Edit: :shock: Das von mir genannte Paket unterstützt ja nur Keys bis zu einer Länge von 32 Bit :shock: Also 256 sollten doch heute wohl drin sein, oder? Vielleicht ist dieses Paket doch keine gute Idee ...
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Also wenn, dann sollten auch Binärdaten unterstützt werden.

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

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.

Ich weiß nur noch nicht ob ich nur die eine Datei mir herraus picken sollte, oder mehr nehmen:
http://tlslite.cvs.sourceforge.net/tlsl ... iew=markup

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
lunar

jens hat geschrieben: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
jens hat geschrieben: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
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

lunar hat geschrieben: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 8)
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
lunar

Leonidas hat geschrieben:Ja, gibt es, das LodgeIt, welches von blackbird programmiert wurde und birkenfelds Pygments nutzt. Somit haben wir einen der besten Paste-Services im Internet 8)
Das beste ist gerade gut genug für meinen Code 8)
(wo wir gerade beim angeben sind)

Habe das Snippet jetzt gepostet:
http://paste.pocoo.org/show/271/
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

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.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
lunar

birkenfeld hat geschrieben: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 :oops:
Antworten