Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for different cryptographic backends #12

Closed
onyb opened this issue Feb 11, 2020 · 2 comments
Closed

Add support for different cryptographic backends #12

onyb opened this issue Feb 11, 2020 · 2 comments

Comments

@onyb
Copy link

onyb commented Feb 11, 2020

The idea is to provide a common interface to do elliptic curve cryptography, and choose the "backend" at runtime based on how ecpy was installed.

This will allow us to centralise all cryptographic code in Python, used internally at Ledger, instead of having to maintain custom wrappers based on the use-case. Some examples are given below:

  • ledgerblue => uses libsecp256k1 if present, else falls back to ecpy.
  • ledgerctl => uses python-ecdsa for elliptic curve cryptography.
  • some internal Ledger package => uses openssl for elliptic curve cryptography.

I think this also adds value to the open source community, by providing a generic wrapper for all elliptic curve operations.

Here's how the installation would look like:

Using pure Python primitives
pip install ecpy
Using libsecp256k1 for the said curve, and pure Python for rest
pip install ecpy[libsecp256k1]
Using libsodium
pip install ecpy[nacl]
Using openssl
pip install ecpy[cryptography]

Let me know if this is outside the scope of ECPy, and not something that we want to do.

@cslashm
Copy link
Owner

cslashm commented Feb 11, 2020

The initial goal of ECPy is to provide pure python ECC.
Thus, adding various native dependencies is not really in the right way.

Also, note that ECPy is not a ledger dedicated library but a more general purpose lib.

Nonetheless we can discuss the needs of Ledger and why they needs libsodium/openssl.... and why dont use pure python everywhere.

I invite you to PM me in order to discuss

@onyb
Copy link
Author

onyb commented Feb 12, 2020

I agree with you. I realised that ecpy shows up as the first google search result for “pure python ecc library”, and therefore the original purpose of the package should not change. Additionally, ecpy supports more curves than most alternatives out there, so maybe the focus could be on readability and curve support.

Here are the curves supported by competing libraries:

Closing this issue.

@onyb onyb closed this as completed Feb 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants