sign jwt tokens with ed25519, ecdsa p-256 and rsa pkcs#1

[kacy]

summary

the runtime verified ed25519, ecdsa and rsa pkcs#1 signatures but could not produce them — a shape inherited from tls, which checks certificates constantly and signs almost never. jwt is the first caller that wants signing as a first-class operation, so this wires the three signers through. ring already had all of them; rsa pkcs#1 is the existing rsa helper with a different encoding constant, ed25519 is a ten-line kernel, and ecdsa p-256 signs with the fixed encoding so the signature comes out as the raw r-and-s form jws carries — the sign path needs none of the der translation the verify path does.

std.crypto.jwt gains sign_rs256, sign_es256 and sign_eddsa, and every algorithm in the module now both signs and verifies. std.crypto.signature exposes the three kernels for anything else that needs them. all signing keys are pkcs#8, which is what encoding.pem_decode yields from a BEGIN PRIVATE KEY file; the ed25519 parser is ring's maybe_unchecked variant because openssl writes pkcs#8 v1, which cannot carry the embedded public key the strict parser insists on.

docs and the crypto index no longer describe the sign/verify asymmetry, and instead say which algorithm to pick when.

what was tested

rsa pkcs#1 v1.5 and ed25519 are deterministic, so for a fixed key and claims there is exactly one valid token — the tests check sign_rs256 and sign_eddsa reproduce, byte for byte, the tokens openssl minted over the same key and claims. that pins the signing half to the same external standard the verifying half was already held to, where a round trip would only prove the module agrees with itself. es256 gets the opposite check: two signatures over the same input must differ (a repeated ecdsa nonce forfeits the private key), both must verify, and a wrong key must not. a garbage private key fails loudly.

make test, make bootstrap-verify (the bootstrap seed is regenerated — the checker and lowering tables changed), make run-examples, and make leak-check all clean.

notes

the per-signature ecdsa nonce is generated inside ring from the system rng; it is never chosen or seen by pith code, which is the property that keeps p-256 keys from leaking through nonce reuse. ed25519 needs no nonce at all, which is why it can be the deterministic one.