[srpatcha]

Closes the verifier half of #98.

ed25519_verify() decoded the public key and never checked which subgroup it was
in. Ed25519 has eight low-order points, and for any of them every term of the
verification equation collapses regardless of the message — so a signature of all
zeros verifies against arbitrary content.

Not hypothetical. eos_pkg.c:94 ships

static const uint8_t eos_pkg_public_key[32] = {0};

and the all-zero encoding is one of the eight. Measured against the built
library, before this change:

all-zero key: 2 of 256 arbitrary signatures ACCEPTED

Package installation authenticated nothing. The SHA-256 check two lines above is
no help — it compares a hash of the payload against a field in the same
attacker-supplied file, which detects corruption, not origin.

The check

Multiply the key by L, require the identity. Chosen over comparing against a
table of the eight encodings because both are correct but this one cannot be
wrong in a way that silently rejects valid keys because a constant was
transcribed incorrectly.

Two things this took to get right, both found by testing rather than reasoning

The subgroup test alone is insufficient. The identity has order 1, which
divides L, so [L]identity = identity and it passes. My first version still
accepted an identity key. It is now rejected explicitly — which is why the helper
has two parts, and why eBoot#57 has both a point_is_identity() and a subgroup
check.

The regression test's first version passed against the unfixed code. The
all-zero key is order 4, so with S = 0 the equation reduces to [k](-A), and
whether that lands on R depends on k mod 4 — on the message:

untrusted firmware           -> rejected
malicious package payload    -> ACCEPTED
AB                           -> ACCEPTED
ABC                          -> rejected

The forgery succeeds for roughly one message in four, and an attacker simply
varies padding until one takes. My test asserted on a single message that
happened to be one of the three-in-four that do not verify. It looked like a
regression test and was not one — the exact defect I have been flagging on other
PRs this week.

It now sweeps messages verified to be accepted by the unfixed implementation:

unfixed   test_all_zero_key_is_rejected  [FAIL] at line 112
fixed     5/5 tests passed

Verified

0 build errors
ctest   28/29 -> 29/29 passed

The suite covers all 64 combinations of the eight low-order encodings used as key
and as R, plus RFC 8032 vector 1 — without which a check that rejected every
key would also pass every test above.

What this does not do

It does not make package signing work. A correct verifier with an all-zero trust
anchor now rejects everything instead of accepting everything: the safer failure,
still not a functioning signature check.

#98 covers the rest — supplying a real key, and whether eos_pkg should refuse
to run at all while its anchor is unset rather than appearing to verify. That is
the shape #84 uses for stub RSA/ECC (EOS_ALLOW_STUB_CRYPTO), and it is a policy
call rather than a bug fix, so it is deliberately not in this PR.

Base

Branches from #82, which repairs master's four compile breakages — on master
today CMake cannot generate a single test target, so none of the above could be
run there. Merge #82 first.

Related

eBoot#73 is the same missing check in eBoot's independent Ed25519
implementation, reached with the identity point. eBoot#57 fixes that one. Two
implementations in the organisation, the same gap in both.

[srpatcha]

Rebased onto current master, which is now green — the four compile breakages
this originally branched around have landed, so the base commits were dropped as
already-upstream. This is now a single commit on top of master.

The vulnerability is still live on master. Re-verified against a clean
git clone --depth 1 a moment ago:

subgroup checks in services/crypto/src/ed25519_verify.c: 0
all-zero key: 2 of 256 arbitrary signatures ACCEPTED

Worth noting when this became dangerous. master's ed25519_verify.c was last
touched by

feat: transition package verification from stubs to production-grade crypto (#57)

which added the real ed25519_fe.c / ed25519_ge.c / ed25519_sc.c
implementation — 1491 lines of field arithmetic — and left two things untouched:

services/pkg/eos_pkg.c:94
static const uint8_t eos_pkg_public_key[32] = {0};

and the absent subgroup check.

Before that PR, nobody would have relied on package verification: it was
self-evidently a stub. After it, the code reads as production crypto and is
described that way in the commit title, while accepting an all-zero signature for
roughly one message in four. The stub-to-real transition is exactly the point at
which this stops being a known gap and starts being a false assurance.

That is not a criticism of #57 — putting a real implementation in is the right
move and had to happen first. It does mean the trust anchor and the subgroup
check are now the two things standing between "production-grade" in the commit
message and production-grade in fact.

Re-verified after the rebase:

0 build errors
29/29 ctest passed
5/5 test_crypto_ed25519_loworder

I also dropped the two comment-only commits that were riding along here. They
were adopted from #93 and #94; those PRs are still open and should land their own
wording under their own authorship rather than having me carry it.