You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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:
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
Using libsecp256k1 for the said curve, and pure Python for rest
Using libsodium
Using openssl
Let me know if this is outside the scope of ECPy, and not something that we want to do.
The text was updated successfully, but these errors were encountered: