On Thu, 2 Aug 2018 at 11:17, Leif Johansson <leifj at sunet.se> wrote:
On 2018-08-02 10:03, Steffen Klemer wrote:
Am Do, 02.08.2018 um 10:42 schrieb Ivan
<ivan.kanak at gmail.com>:
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?
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
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?
Relying on openssl isn't necessarily a sign of quality and goodness..
I agree on that.
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.
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
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.
Ivan c00kiemon5ter Kanakarakis >:3