Implement RFC 3830 key derivation

[waxspin]

Closes #22.

@jcowgill was right on all three points in #22, and I confirmed each against the RFC text before changing anything.

What was wrong

The PRF was not RFC 3830 §4.1.2. It was a counter-mode KDF computing HMAC(key, label || 0x00 || i || len) per block. The RFC specifies a TLS-style feedback construction with input-key splitting:

P(s, label, m) = HMAC(s, A_1||label) || ... || HMAC(s, A_m||label)
    A_0 = label,  A_i = HMAC(s, A_(i-1))
PRF(inkey, label) = P(s_1,label,m) XOR ... XOR P(s_n,label,m)

Side by side on the same input, before the fix:

mykey PRF = d6bb06fe73a35dc5b2ba0ec64e78fd08
RFC   PRF = 437f424dae917437abd62a0443ac0100

The labels were ad-hoc ASCII ("TGK", "AUTH", "SRTP_KEY", …) instead of the RFC layouts, and csb_id was never mixed into any derived key.

The i as u8 counter wrapped, repeating the keystream every 5120 bytes — reachable only well beyond any caller's request (the largest is 32 bytes), and gone entirely now that the construction has no counter.

What changed

• mikey_prf implements §4.1.2, including the 256-bit input-key split and XOR combination.
• RFC §4.1.3 and §4.1.4 label layouts and all seven constants. The SRTP master key and salt are now the TEK (0x2AD01C64) and salting key (0x39A2C14B).
• csb_id is threaded from the MIKEY common header through derive_srtp_keys, derive_auth_key, and derive_enc_key.
• The PSK message authentication key derives from the pre-shared key per §4.1.4 rather than from the TGK. §4.1.4 is defined as derivation from the envelope/pre-shared key, so this follows from adopting the label; it also means the MAC key is no longer recoverable from a value that travels in the clear.
• An empty input key is rejected rather than silently yielding an all-zero key — with no blocks to iterate, the XOR accumulator would have stayed zero.

New tests lock the feedback construction against a reference written independently from the RFC text, plus the block splitting and XOR, both label layouts, the constants, and cs_id/csb_id reaching the output. The reference value above was computed before the implementation was written, and the new code reproduces it.

Documentation

New Deviations from RFC 3830 chapter recording every known departure, so this reasoning is written down rather than rediscovered: the non-RFC TGK derivation, X25519 on private-use DH-Group 255 rather than OAKLEY 5, the absent SIGN payload, and the PSK gaps below.

On the DH group specifically — switching to OAKLEY 5 would not buy interoperability. The RFC's DH method is signature-authenticated (SIGNi/SIGNr), and mykey emits no SIGN or CERT payload, so a conformant peer rejects the message regardless of group. OAKLEY 5 is also ~96-bit security against X25519's ~128. IANA reserves DH-Group 241–255 for private use, so 255 is a legitimate code point; no EC group has ever been registered for MIKEY.

The PSK chapter claimed "Mutual authentication: Yes" and "MITM protection: Yes". Neither holds, so I corrected the table and added a warning.

Not addressed here

PSK mode still builds its KEMAC with NULL encryption and puts the TGK in enc_data in the clear, so anyone who can read a PSK-Init recovers the SRTP master key without the PSK. No receive path verifies the KEMAC MAC either. Both need their own issue — the disclosure is exploitable in released 1.0.0, not merely non-interoperable, so it likely warrants a SECURITY.md advisory rather than being folded in here.

Breaking

Every derived key changes value, and derive_srtp_keys / derive_auth_key / derive_enc_key take new arguments. Wire-incompatible with 1.0.0 — both ends of an exchange must upgrade together. This warrants a 2.0.0 release. Cargo.toml is deliberately left at 1.0.0 for cargo-release to bump; the break is recorded in CHANGELOG.md under [Unreleased].

Downstream: rlac pins mykey = "1.0.0" and calls new_psk_init / complete_psk. Those call sites still compile unchanged, but it needs a coordinated bump once this releases.