summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/man/OpenSSL_add_all_algorithms.3
diff options
context:
space:
mode:
authorjsing <>2023-03-08 05:35:51 +0000
committerjsing <>2023-03-08 05:35:51 +0000
commit803622911687b70848ed5277f86819fe63f7c372 (patch)
treeafede466818a45660427347494e39a5c69a48c47 /src/lib/libcrypto/man/OpenSSL_add_all_algorithms.3
parent8d29cc48fbbf1116295d560fac3a0b9be6f4c15e (diff)
downloadopenbsd-803622911687b70848ed5277f86819fe63f7c372.tar.gz
openbsd-803622911687b70848ed5277f86819fe63f7c372.tar.bz2
openbsd-803622911687b70848ed5277f86819fe63f7c372.zip
Stop trying to use EC_GFp_nist_method().
Currently, if compiled without OPENSSL_BN_ASM_MONT, EC_GROUP_new_curve_GFp() tries to use EC_GFp_nist_method(), falling back to EC_GFp_mont_method() if it is not a NIST curve (if OPENSSL_BN_ASM_MONT is defined we use EC_GFp_mont_method() unconditionally). Now that we have a reasonable non-assembly Montgomery implementation, the performance of EC_GFp_nist_method() is either similar or slower than EC_GFp_mont_method() (the exception being P-521, however if you're using that you're not doing it for performance reasons anyway). The EC_GFp_nist_method() uses rather scary BN NIST code (which would probably already be removed, if not for the BN and EC public APIs), it uses code paths that are currently less constant time, and there is additional overhead in checking to see if the curve is actually supported. Stop trying to use EC_GFp_nist_method() and unconditionally use EC_GFp_mont_method() in all cases. While here, factor out the common setup code and call it from both EC_GROUP_new_curve_GFp() and EC_GROUP_new_curve_GF2m(). ok beck@ tb@
Diffstat (limited to 'src/lib/libcrypto/man/OpenSSL_add_all_algorithms.3')
0 files changed, 0 insertions, 0 deletions