ext/gmp: Add GMP ECC test #18363
ext/gmp: Add GMP ECC test #18363
Conversation
|
Can you maybe rebase and force push on the latest master to see if it fixes the FreeBSD pipeline? As that is unrelated to this PR |
|
@Girgias The tests pass now (apparently just flaky). I've also added some documentation for the point decompression math, and a new output check to ensure the test does not pass for trivial calculation (e.g. all 0s). Anything should now either be documented or reference the spec now. If this is not the case, please mention it in your review. While asking around whether I've covered all fundamental operations of ECC, I was made aware of that Parings (as in Weil-Pairing) could be seen as another fundamental operation. For me, this would be another possible PR in the future; but out of scope for now (as I first have to get used to the exact math there). |
| public function isOnCurve(Point $point): bool | ||
| { | ||
| $left = gmp_pow($point->y, 2); | ||
| $right = gmp_add( | ||
| gmp_add( | ||
| gmp_pow($point->x, 3), | ||
| gmp_mul($this->curve->getA(), $point->x) |
There was a problem hiding this comment.
It might be interesting to have a class that reimplements this using the overloaded operators, to ensure the behaviour is consistent. :)
There was a problem hiding this comment.
Agreed!
However, to avoid duplicating this complicated & slow ECC code, to test the method operators I would probably go for a "kitchen-sink" kind of test. So something like, for reasonably big GMP $a and GMP $b:
var_dump(gmp_cmp(gmp_add($a, $b), $a + $b) === 0);
var_dump(gmp_cmp(gmp_sub($a, $b), $a - $b) === 0);
var_dump(gmp_cmp(gmp_mul($a, $b), $a * $b) === 0);What do you think / does that make sense?
There was a problem hiding this comment.
I think we might already have a kitchen sink test, so maybe it's better to just change this test to use operator overloading?
There was a problem hiding this comment.
Yes, the kitchen sink test is in ext/gmp/tests/gmp_cryptography.phpt. Thinking about it, I'd rather change the kitchen sink test to use the operators. This way, the gmp_cryptography_ecc.phpt test remains close to how this would likely be written in crypto libraries: My expectation would be that these try to absolutely minimize risk; hence using operator overloading where there is a risk that the wrong operator is applied due to type confusion seems like a no-go.
So I would:
- Extend
gmp_cryptography.phptto do all gmp operations with reasonably big numbers (around 15360 bits for operations in (integer) finite fields, around 512 bits for operations used in ECC; see NIST security strength 256). - Perform each operation once with the real function, and once with its operator overload.
What do you think about the proposal?
There was a problem hiding this comment.
MSTM, thanks for the insights :)
Co-authored-by: Gina Peter Banyard <[email protected]>
Add a test that executes GMP operations in the context of elliptic curve.
This work is motivated by a bug from a couple of months ago (see #16870), which showed this use-case is uncovered by tests in PHP. The bug was fixed quickly, and in #16896 a unit test already landed for finite field cryptography. The test for elliptic curve cryptography is more complicated (as seen in this PR), so this was decided to be done later: #16896 (comment)
This unit test is written based on code developed for https://github.com/famoser/elliptic, which has been tested extensively. However, the code is not ready to use for security-related applications, as it has not been hardened nor tested against possible side channels. Side channels could leak the secret values, and therefore compromise the security of the algorithms.