2:40 p.m.
Hey list,
is there a specific reason that pyXMLSecurity maintains forked,
crippled down and slightly changed versions of pycrypto (abandoned) and
PyASN1 (with security changes in the upstream since forking)? From a
quick look it seems that it might be quiet easy to port it over to
PyCryptodome(x) which is maintained and itself a fork of pycrypto and
would bring back some speed optimized parts in c (that were cut
away when forking) as well as ECC that might get relevant in the coming
years. My main concern is about the long term security impact of a
self-maintained crypto module; speed is just a nice addition ;).
pkcs11 wouldn't be impacted by it and has to be kept separately.
Would patches/PR be welcome or just a waste of time?
Steffen
--
DFN-Verein Steffen Klemer
Alexanderplatz 1 +49 30 884299 307
10178 Berlin klemer at dfn.de
Fax: 030 88 42 99 370
http://www.dfn.de
4:19 p.m.
Yes please PR!!!!!
Skickat från min iPhone
31 juli 2018 kl. 13:40 skrev Steffen Klemer <klemer
at dfn.de>:
Hey list,
is there a specific reason that pyXMLSecurity maintains forked,
crippled down and slightly changed versions of pycrypto (abandoned) and
PyASN1 (with security changes in the upstream since forking)? From a
quick look it seems that it might be quiet easy to port it over to
PyCryptodome(x) which is maintained and itself a fork of pycrypto and
would bring back some speed optimized parts in c (that were cut
away when forking) as well as ECC that might get relevant in the coming
years. My main concern is about the long term security impact of a
self-maintained crypto module; speed is just a nice addition ;).
pkcs11 wouldn't be impacted by it and has to be kept separately.
Would patches/PR be welcome or just a waste of time?
Steffen
--
DFN-Verein Steffen Klemer
Alexanderplatz 1 +49 30 884299 307
10178 Berlin klemer at dfn.de
Fax: 030 88 42 99 370
http://www.dfn.de
_______________________________________________
Idpy-discuss mailing list
Idpy-discuss at lists.sunet.se
https://lists.sunet.se/listinfo/idpy-discuss
11:28 p.m.
New subject: Forks of Forks of PyCrypto and PyASN1 in pyXMLSecurity
Would patches/PR be welcome or just a waste of time?
To be painfully clear: YES YES YES please!! (I'll buy you several drinks!)
The reason I have that fork is because pyXMLSecurity was started from
another project (with the approval of that author) who had included
the pyasn1 fork very early on.
I just kept it around because I've never had time to deal with it but
clearly you are right and we should switch to cryptodome.
I can't even begin tell you how much I'd appreciate your help here!
Cheers Leif
10:42 a.m.
On Wed, 1 Aug 2018 at 23:28, Leif Johansson <leifj at sunet.se> wrote:
I just kept it around because I've never had time
to deal with it but
clearly you are right and we should switch to cryptodome.
pysaml2 has switched to pyca/cyptography.
Should we try to use that for pyXMLSecurity too?
Has anyone gone into a comparison and evaluation?
--
Ivan c00kiemon5ter Kanakarakis >:3
10:58 a.m.
Skickat från min iPhone
2 aug. 2018 kl. 09:42 skrev Ivan Kanakarakis
<ivan.kanak at gmail.com>:
Pysaml2 should really use pyXMLSecurity to enable p11...
On Wed, 1 Aug 2018 at 23:28, Leif Johansson
<leifj at sunet.se> wrote:
I just kept it around because I've never had time to deal with it but
clearly you are right and we should switch to cryptodome.
pysaml2 has switched to pyca/cyptography.
Should we try to use that for pyXMLSecurity too?
Has anyone gone into a comparison and evaluation?
--
Ivan c00kiemon5ter Kanakarakis >:3
11:03 a.m.
New subject: Forks of Forks of PyCrypto and PyASN1 in pyXMLSecurity
Am Do, 02.08.2018 um 10:42 schrieb Ivan Kanakarakis
<ivan.kanak at gmail.com>:
On Wed, 1 Aug 2018 at 23:28, Leif Johansson <leifj
at sunet.se> wrote:
I was looking at it yesterday and while I like the idea (and its
not-home-grown crypto using openssl as its backend) of the cryptography
module better compared to cryptodome, it seemed to lack some features.
Notably I couldn't find any mentioning of a high-level function for
signing something else then certificates -- everything asymmetric above
the 'hazmat'-layer just seemed to be concerned with key handling.
That besides both projects seem to be vital. Crpytodome seems to rely
mostly on one person, cryptography on 3 or 4. The latter is Apache OR
BSD licensed, cryptodome mixed BSD+Public Domain (and one submodule
Apache).
Overall I tended to go a bit deeper into Cryptography and see how hard
a port would be. Cryptodome-porting should be more or less free as it's
also a fork of pycrypto.
Any ideas before I go on?
Steffen
--
DFN-Verein Steffen Klemer
Alexanderplatz 1 +49 30 884299 307
10178 Berlin klemer at dfn.de
Fax: 030 88 42 99 370
http://www.dfn.de
I just kept it around because I've never had
time to deal with it
but clearly you are right and we should switch to cryptodome.
pysaml2 has switched to pyca/cyptography.
Should we try to use that for pyXMLSecurity too?
Has anyone gone into a comparison and evaluation?
11:16 a.m.
New subject: Forks of Forks of PyCrypto and PyASN1 in pyXMLSecurity
On 2018-08-02 10:03, Steffen Klemer wrote:
Am Do, 02.08.2018 um 10:42 schrieb Ivan Kanakarakis
<ivan.kanak at gmail.com>:
Some observations:
Relying on openssl isn't necessarily a sign of quality and goodness..
One of the applications we have for SATOSA is eIDAS which will require
ECC and "non-standard" (eg OAEP) padding of RSA signatures.
As for maintainer size... I suspect whatever we choose we'll have to
take some responsability for ourselves
Cheers Leif
On Wed, 1 Aug 2018 at 23:28, Leif Johansson
<leifj at sunet.se> wrote:
I was looking at it yesterday and while I like the idea (and its
not-home-grown crypto using openssl as its backend) of the cryptography
module better compared to cryptodome, it seemed to lack some features.
Notably I couldn't find any mentioning of a high-level function for
signing something else then certificates -- everything asymmetric above
the 'hazmat'-layer just seemed to be concerned with key handling.
That besides both projects seem to be vital. Crpytodome seems to rely
mostly on one person, cryptography on 3 or 4. The latter is Apache OR
BSD licensed, cryptodome mixed BSD+Public Domain (and one submodule
Apache).
Overall I tended to go a bit deeper into Cryptography and see how hard
a port would be. Cryptodome-porting should be more or less free as it's
also a fork of pycrypto.
Any ideas before I go on? I just kept it around because I've never had
time to deal with it
but clearly you are right and we should switch to cryptodome.
pysaml2 has switched to pyca/cyptography.
Should we try to use that for pyXMLSecurity too?
Has anyone gone into a comparison and evaluation?
1:16 p.m.
On Thu, 2 Aug 2018 at 11:17, Leif Johansson <leifj at sunet.se> wrote:
On 2018-08-02 10:03, Steffen Klemer wrote:
I agree on that.
Am Do, 02.08.2018 um 10:42 schrieb Ivan
Kanakarakis
<ivan.kanak at gmail.com>:
Some observations:
Relying on openssl isn't necessarily a sign of quality and goodness..
On Wed, 1 Aug 2018 at 23:28, Leif Johansson
<leifj at sunet.se> wrote:
I was looking at it yesterday and while I like the idea (and its
not-home-grown crypto using openssl as its backend) of the cryptography
module better compared to cryptodome, it seemed to lack some features.
Notably I couldn't find any mentioning of a high-level function for
signing something else then certificates -- everything asymmetric above
the 'hazmat'-layer just seemed to be concerned with key handling.
That besides both projects seem to be vital. Crpytodome seems to rely
mostly on one person, cryptography on 3 or 4. The latter is Apache OR
BSD licensed, cryptodome mixed BSD+Public Domain (and one submodule
Apache).
Overall I tended to go a bit deeper into Cryptography and see how hard
a port would be. Cryptodome-porting should be more or less free as it's
also a fork of pycrypto.
Any ideas before I go on? I just kept it around because I've never had
time to deal with it
but clearly you are right and we should switch to cryptodome.
pysaml2 has switched to pyca/cyptography.
Should we try to use that for pyXMLSecurity too?
Has anyone gone into a comparison and evaluation? One of the applications we have for SATOSA is eIDAS
which will require
ECC and "non-standard" (eg OAEP) padding of RSA signatures.
Both support ECC and OAEP but pyca/cryptography is more complete.
https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/
https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#cryptog…
https://pycryptodome.readthedocs.io/en/latest/src/public_key/ecc.html
https://pycryptodome.readthedocs.io/en/latest/src/cipher/oaep.html
As for maintainer size... I suspect whatever we choose
we'll have to
take some responsability for ourselves
I agree that part of the responsibility is ours, as the users of the
library. That however does not mean that maintainer size is not
important. Without strong arguments, I really cannot recommend a
homegrown library compared to a library maintained by an organization
that focuses on cryptography and strives to be the authority on
cryptographic matters. Let me say that, pyca is for
python-cryptography what idpy strives to be for python-identity.
To be clear, my initial proposal for cryptography is not based on the
quality perspective of the library - I am probably not the right
person to do an evaluation on cryptographic methods. It is based more
on making a decision to use the same tools across all projects under
idpy.
Regardless of that decision, one should not couple tightly to a
dependency. Instead, the project should define the API it needs and
implement it with a dependency. That way one can move away from a
certain dependency easier when that is needed.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
12:49 p.m.
New subject: Forks of Forks of PyCrypto and PyASN1 in pyXMLSecurity
For pyoidc I moved from Cryptodome to Cryptography a while ago.
Working with the crypto experts at Google doing the new OIDC libraries Cryptography was
the only choice.
On 2 Aug 2018, at 10:03, Steffen Klemer <klemer at
dfn.de> wrote:
Am Do, 02.08.2018 um 10:42 schrieb Ivan Kanakarakis
<ivan.kanak at gmail.com>:
— Roland
The higher up you go, the more mistakes you are allowed. Right at the top, if you make
enough of them, it's considered to be your style.
-Fred Astaire, dancer, actor, singer, musician, and choreographer (10 May 1899-1987)
On Wed, 1 Aug 2018 at 23:28, Leif Johansson
<leifj at sunet.se> wrote:
I was looking at it yesterday and while I like the idea (and its
not-home-grown crypto using openssl as its backend) of the cryptography
module better compared to cryptodome, it seemed to lack some features.
Notably I couldn't find any mentioning of a high-level function for
signing something else then certificates -- everything asymmetric above
the 'hazmat'-layer just seemed to be concerned with key handling.
That besides both projects seem to be vital. Crpytodome seems to rely
mostly on one person, cryptography on 3 or 4. The latter is Apache OR
BSD licensed, cryptodome mixed BSD+Public Domain (and one submodule
Apache).
Overall I tended to go a bit deeper into Cryptography and see how hard
a port would be. Cryptodome-porting should be more or less free as it's
also a fork of pycrypto.
Any ideas before I go on?
Steffen
--
DFN-Verein Steffen Klemer
Alexanderplatz 1 +49 30 884299 307
10178 Berlin klemer at dfn.de
Fax: 030 88 42 99 370
http://www.dfn.de
_______________________________________________
Idpy-discuss mailing list
Idpy-discuss at lists.sunet.se
https://lists.sunet.se/listinfo/idpy-discuss I just kept it around because I've never had
time to deal with it
but clearly you are right and we should switch to cryptodome.
pysaml2 has switched to pyca/cyptography.
Should we try to use that for pyXMLSecurity too?
Has anyone gone into a comparison and evaluation?
2333
days inactive
2335
days old
8 comments
4 participants
participants (4)
-
ivan.kanak＠gmail.com -
klemer＠dfn.de -
leifj＠sunet.se -
roland＠catalogix.se