We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
use m2crypto, pycryptodome, cryptography or some other native library to accelerate ECDSA and ECDHE operations
some mechanism similar to the one used for RSA keys should be used to select the backend implementing the actual crypto
this is continuation of work from #196
The text was updated successfully, but these errors were encountered:
Which algorithms should be abstracted? Or we can just implement ECDSAKey interface?
ECDSAKey
Sorry, something went wrong.
The whole ECDSAKey interface should be implemented.
You can look at examples with AES: https://github.com/tlsfuzzer/tlslite-ng/blob/master/tlslite/utils/openssl_aes.py and https://github.com/tlsfuzzer/tlslite-ng/blob/master/tlslite/utils/python_aes.py and with RSA: https://github.com/tlsfuzzer/tlslite-ng/blob/master/tlslite/utils/openssl_rsakey.py and https://github.com/tlsfuzzer/tlslite-ng/blob/master/tlslite/utils/python_rsakey.py
(slightly counter-intuitively, the openssl_ prefix is used for implementations that use M2Crypto)
openssl_
No branches or pull requests
use m2crypto, pycryptodome, cryptography or some other native library to accelerate ECDSA and ECDHE operations
some mechanism similar to the one used for RSA keys should be used to select the backend implementing the actual crypto
this is continuation of work from #196
The text was updated successfully, but these errors were encountered: