bp256+bp384: tracking issue for arithmetic feature

[tarcieri]

The bp256 and bp384 crates have a wip-arithmetic-do-not-use which enables a broken arithmetic backend.

It's unclear why it isn't working, but it's failing test vectors.

The field implementations were synthesized with fiat-crypto in the same way as the backends for many of the NIST P-curves (e.g. p192, p224, p384, p521), and the curve arithmetic implementation is from the primeorder crate.

[tarcieri]

We should review all constants that went into synthesizing the field implementations, as well as the PrimeCurveParams constants (curve equation, generator).

[janhesmert]

I'm very interested in making these curves work (predominantly bp256r1) and I have been implementing a range of tests to verify that the basic field operations (both for FieldElement and Scalar) are working as expected. So far, I have not been able to reproduce these issues myself. On top, I have checked that the test vectors given in RFC 7027 A.1 are calculated correctly, which is the case. Could you perhaps provide a MWE that shows where the arithmetic backend breaks? Thanks!

[tarcieri]

#879 was the commit that reverted the arithmetic feature.

It's been awhile but it says ECDH was failing.

It would be good to add test vectors similar to these: https://github.com/RustCrypto/elliptic-curves/blob/master/p256/src/test_vectors/group.rs