Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Hans-Peter Jansen <hpj@urpla.net>
Newsgroups: de.comp.lang.python
Subject: Re: [Python-de] Diskussion Python Module
Date: Sun, 18 Jun 2017 18:57:07 +0200
Lines: 143
Message-ID: <mailman.152.1497805036.10125.python-de@python.org>
References: <201A6877-3A8D-4949-AD74-924A3545731F@multi-matrix.de> <oi5ise$73k$1@blaine.gmane.org> <8188736.sURn0HKOny@xrated>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
User-Agent: KMail/4.14.10 (Linux/4.11.1-10-default; KDE/4.14.28; x86_64; ; )
In-Reply-To: <oi5ise$73k$1@blaine.gmane.org>
Precedence: list
Xref: csiph.com de.comp.lang.python:4808

On Sonntag, 18. Juni 2017 11:58:40 Peter Otten wrote:
> Erich Schnoor wrote:
> > Hallo, Pythonfreunde
> >=20
> > auf dieser maillist bin ich neu. Ich wundere mich, dass es
> > so wenig Diskussionen um Python Module gibt.
> > Liegt es daran, dass so wenig Module entwickelt werden
> > oder gibt es schon nichts Neues mehr, das noch diskutiert
> > werden kann?
>=20
> Im Gegenteil, es gibt so viele Module, dass den meisten Benutzern nic=
hts
> anderes =FCbrigbleibt, als fast alles zu ignorieren und sich nur das
> anzuschauen, was ihnen m=F6glicherweise die Arbeit erleichtert.
>=20
> > Meinen Beitrag zur Diskussion findet Ihr unter:
> >     http://www.telecypher.net/Telepython.pdf
>=20
> Was die Diskussion angeht -- diese Mailing List/Newsgroup ist nicht
> gerade =FCberlaufen, und viel mehr als die Reaktionen auf Ihren erste=
n Post
> ist nicht zu erwarten.
>=20
> Wie ich sehe haben Sie diesmal den Quellcode mitgeliefert -- wenn auc=
h in
> einem absolut un=FCblichen Format und mit mindestens einem Bug (zchn =
nirgendwo
> definiert, soll wahrscheinlich zeichen hei=DFen).

Die Ver=F6ffentlichung per PDF ist nicht nur absolut un=FCblich, sonder=
n auch=20
selbst f=FCr Diskussionen inakzeptabel.

> Ich k=F6nnte hier eine Stilkritik starten oder Tips geben, wie Sie Ih=
ren Code
> effizienter machen, aber bei einem Verschl=FCsselungsprogramm ist ein=
 sicherer
> Algorithmus das KO-Kriterium, und davon verstehe ich leider nicht gen=
ug.

Ich nehme den Ball mal auf, Peter.

Ich empfehle Ihnen, einen Account auf github.com zu erstellen, und Ihr =
Modul=20
dort in einer "=FCblichen" Form hochzuladen, also als Python Modul inkl=
.=20
setup.py, sodass es auch auf PyPi publizierbar und per pip installierba=
r wird:

=09http://github.com

Dies hat f=FCr Mitwirkende den Vorteil, kolaborieren zu k=F6nnen, Code-=
Abschnitte=20
zu diskutieren, weiter zu entwickeln, automatisiert Tests auszuf=FChren=
 und=20
dergleichen mehr.

N=E4chste Schritte:=20

 * auf PyPI eine getestete Release ver=F6ffentlichen

=09https://pypi.python.org/pypi

 * Auf Cryptoforum eine Diskussion suchen

=09https://crypto.stackexchange.com/
=20
> Auch wenn die Antworten auf Ihre Posts im Mai teils r=FCde ausfielen:=
 ohne
> vorangegangene Diskussion vor einem Kryptographie-Fachpublikum kann i=
ch
> niemandem empfehlen, Ihr Skript zu verwenden.

Zumal die reine Lehre in den letzten Jahren auch deutliche Fortschritte=
=20
gemacht hat, welche im Bereich der symmetrischen Verschl=FCsselungen Ar=
gon2=20
hervorgebracht hat, welches im Zusammenspiel mit AES GCM recht brauchba=
re
Sicherheit liefert, und auch f=FCr Normalsterbliche einigerma=DFen behe=
rrschbar=20
ist.

Hier sind meine bescheidenen Versuche (auf Basis von etablierten Verfah=
ren).=20
Damit m=F6chte ich Ihnen exemplarisch eine m=F6gliche Herangehensweise =
an das=20
Thema Symmetrische Verschl=FCsselung aus der Nutzerperspektive aufzeige=
n:

=09https://github.com/frispete/keyrings.cryptfile
=09
Der interessante Teil:

https://github.com/frispete/keyrings.cryptfile/blob/master/keyrings/cry=
ptfile/cryptfile.py

Dies ist eine Erweiterung f=FCr das Python-Modul keyring, dass eben Sol=
che in=20
brauchbarer Weise als normale Dateien ablegen kann, sich also bewusst n=
icht in=20
die Schl=FCsselbund-Verfahren der Desktop-Umgebungen integriert, und so=
mit=20
unabh=E4ngig vom Betriebssystem und der Desktop-Umgebung das Crypto-Ver=
fahren=20
selbst w=E4hlen kann (und hierbei =FCbrigens alle authentifizierten AES=
-Modi=20
unterst=FCtzt (CCM, EAX, GCM und OCB)). Die verwendeten Crypto-Biblioth=
eken sind=20
=FCbrigens argon2_cffi (https://github.com/hynek/argon2_cffi) und PyCry=
ptodome=20
(https://github.com/Legrandin/pycryptodome), welche aus PyCrypto=20
hervorgegangen ist.

Wenn der Ansatz auf https://crypto.stackexchange.com nicht komplett zer=
rissen=20
wird, sieht es schon ganz gut aus:

https://crypto.stackexchange.com/questions/44705/conforming-to-best-pra=
ctices-in-password-file-keyring-encryption

Auch ich bin kein Krypto-Experte. Aber f=FCr mich als potentiellem Nutz=
er Ihres=20
Algorithmus ist die dargebotene Form unzureichend. An Argon2 kann man g=
anz gut=20
sehen, wie Crypto-Verfahren heute in die Mangel genommen werden *m=FCss=
en*, um=20
Bedrohungen, wie der rasant steigenden Zunahme an Hashing-Power zu entg=
ehen,=20
die wir der Verbreitung von Crypto-W=E4hrungen zu verdanken haben, und =
viele=20
Verfahren einfach per "brute force" aushebeln.

Ihr Verfahren ist schwer durchschaubar, was einer eingehenden Analyse=20=

zus=E4tzlich entgegensteht. Ohne die Ver=F6ffentlichung in der vorgenan=
nten Form=20
wird daher das Interesse an Ihrem Verfahren gering bleiben (unabh=E4ngi=
g von der=20
der verwendeten Programmiersprache).

MfG,
Hans-Peter