oreparaz / p256 Goto Github PK

maybe using a clever combination of gcc cross compiling and user-mode qemu emulation of MIPS or PowerPC...

@0adb kindly added test/nist_tests.txt and test_nist.cc. We could add all tests from test/nist_tests.txt into test_nist.cc. I think today test_nist.cc runs 5 test vectors out of the 15 in test/nist_tests.txt.

This shouldn't be too hard and can be a good first issue to get started.

@0adb reported in #3 that p256 doesn't compile cleanly in Windows 10 using MinGW. I don't have access right now to a Windows box so maybe we can debug with them. @0adb: could you please check if setting this environment variable in powershell helps compiling in windows?

$Env:CC="gcc"

Also: since I essentially ripped off the project structure from @charlesnicholson 's embedded libraries, and they compile in Windows, maybe we can just use their make recipe (it is using MSVC instaead of MinGW, tho): https://github.com/charlesnicholson/nanocobs/blob/main/make-win.bat

Coverage today is pretty minimal. We'd benefit from adding more known answer tests. Can steal the test vectors from other libraries or wycheproof.

The testing framework is already in place so this shouldn't take too long.

BearSSL does not ship with support for compressed public keys; we might want to add that.

Reference: §2.3.4 from https://www.secg.org/sec1-v2.pdf
https://cs.opensource.google/go/go/+/refs/tags/go1.20:src/crypto/elliptic/elliptic.go;l=175

We could explore adding support for signing in a separate file like p256-sign.c if there's interest. Signature verification is usually more relevant than signing in embedded land, so I think this has low priority, but it could be handy to have in certain contexts.

I imagine that would require pulling ecdsa_i31_sign_raw.c and dependencies, such as DRBG + HMAC since BearSSL uses deterministic ECDSA as per RFC 6979. Validation for this operation is non-trivial.

Since we're now using a fork of BearSSL, we should be running more tests. Add the ECDSA tests from https://github.com/google/wycheproof .

This library today does zero work to have an exclusive namespace for C identifiers. This means that this lib exports a bunch of functions that could (in theory) collide with existing symbols (also taken from BearSSL). This isn't really a problem for the current use cases, but documenting it here nevertheless.

To fix that, we could:

• static-ify stuff to restrict the scope to the translation unit
• (crude) replace every occurrence of br_ into br_p256_ (and BR_ as well). Since BearSSL is very well written and has consistent naming, this can do the trick.

Port tests to doctest. Currently it's hard to run catch tests in small computers... 🐌

https://github.com/doctest/doctest

BearSSL has br_ecdsa_i31_vrfy_asn1 so we should bubble this up in the future.

Useful comments from BearSSL:

  * The signature format is either "raw" or "asn1", depending on the
  * implementation; maximum length is predictable from the implemented
  * curve:
  *
  * | curve      | raw | asn1 |
  * | :--------- | --: | ---: |
  * | NIST P-256 |  64 |   72 |
  * | NIST P-384 |  96 |  104 |
  * | NIST P-521 | 132 |  139 |

test vector generation isn't deterministic, so vectors change every time they are generated. fix this.

We could easily add support for ECDSA over NIST P-384 (akan secp384r1) and the enormous curve NIST P-521 (secp521) since BearSSL supports them and we're already including the corresponding files in amalgamate.sh.

P-384 may be worth it since it seems supported by the yubikey's PIV applet.

We would need to write new functions similar to p256_verify, and think hard about a change to the projects name 🤔. Probably worth distributing different files (e.g. p384.c and p521.c)?

so that we can use p256 in a project that uses BearSSL for something else

Would be nice to provide some specific memory usage figures (for example using some cortex)

Documentation is pretty minimal as of now.

• The header file p256.h deserves some love
• Documentation in the README.md on public key format can be improved