Description of problem: The python-ecdsa package tests itself against openssl. It implements the prime192v1 and secp224r1 curves which are not currently enabled in openssl. Can these be enabled please?
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
as bug #1019390 said you should reenable all ECC/ECDHE/EC/ECDSA/elliptic curves and not just some . I'd like have sect233k1 In [1]: import M2Crypto In [2]: ec_keypair = M2Crypto.EC.gen_params(M2Crypto.EC.NID_sect233k1) ValueError: Received a NULL pointer.
I would view enabling EC curves smaller than 256 bits as a security regression. So I am wontfixing this bug.
+1 to the WONTFIX They are too weak to support. And since most applications have no way to control which ones are enabled, we would need to enable them by default too, that would be serious security regression (even 256 bit curves have a shadow of doubt on them). Enabling them will bring serious security issues with little to no additional compatibility.
The work of Proos and Zalka show how a quantum computer for breaking 2048-bit RSA requires roughly 4096 qubits, while a quantum computer to break the equivalently secure 224-bit Elliptic Curve Cryptography requires between 1300 and 1600 qubits. Depending on the growth rate of quantum computers in the future, elliptic curve cryptosystems may become attackable by a quantum computer many years before an equivalently secure RSA scheme.[37] To avoid quantum computing concerns, an elliptic curve-based alternative to Elliptic Curve Diffie Hellman which is not susceptible to Shor's attack is the Supersingular Isogeny Diffie–Hellman Key Exchange of De Feo, Jao and Plut. It uses elliptic curve isogenies to create a drop-in replacement for the quantum attackable Diffie–Hellman and Elliptic curve Diffie–Hellman key exchanges. This key exchange uses the same elliptic curve computational primitives of existing elliptic curve cryptography and requires computational and transmission overhead similar to many currently used public key systems.[38] https://en.wikipedia.org/wiki/Elliptic_curve_cryptography So you concerned with quantum computing ? You shouldn't decide this by your own, you should open a ticket in fesco or something like that, the problem wasn't safety, was legal, some algorithms have patents and now you are not implement this because is not safe !?! The problem is: this ECC (that we are requesting here to enabled) are used in 3rd software like tribler or acestream or tor or others and won't run in Fedora because you are illuminated . I think you are confusing the key length with curve over a 233 bit prime field , 256 is 2^8 and 233 is prime number . Moreover openssl.spec [1] is a mess , you have patches over patches, a own implementation of ec_curve.c and this could have make sense when legal department decide remove ECC (by legal reasons) but not anymore. What I though was that by legal reasons we couldn't enable all ECC and we have to analyse them one by one, now invoke a security reason doesn't make sense . [1] https://pkgs.fedoraproject.org/cgit/openssl.git/tree/
AFAIK there is no blank approval for any elliptic curves by legal anyway. You need to explicitly ask for approval for each. If you dispute it, feel free opening tickets in FESCo.
Well, that was the original intent of this bug - to get approval for those curves.
Point is that even if there was approval for all curves from legal, we would be against enabling them. If you want curves smaller than 256 bit in Fedora, please open ticket in FESCo. If FESCo overrides our position, we can then ask legal.