Proposal: Add EAP-NOOB KDF and Key Export Regression Tests

[Ratherrayees]

Proposal: Add EAP-NOOB KDF and Key Export Regression Tests

Background

During targeted mutation testing of services/eap-noob, I found several mutations that changed key derivation or export behavior without causing the existing test suite to fail.

I investigated these cases and prepared a test-only addition to improve regression coverage. The proposed tests cover deterministic expected outputs, published HKDF test vectors, non-empty export context, and label-length encoding.

This was targeted mutation testing of services/eap-noob, not a repository-wide mutation-testing run. The purpose of this discussion is to ask whether the maintainers would welcome a focused test-only PR and to confirm the protocol interpretation behind the expected values before I submit it.

Findings and evidence

I reproduced five surviving mutations in a disposable clone based on commit 85f523d3624cf1596bdda6e36c28eb8ad3969737. In each case, the full services/eap-noob test suite passed with the mutation applied.

1. KDF output loop condition: Changing len(out) < outLen to its logical opposite caused the derivation loop to be skipped, leaving zero-filled output instead of the expected key material.

2. KDF counter: Changing counter++ to counter-- altered the derived key material.

3. Export block counter: Changing i++ to i-- broke exports longer than one SHA-256 block, while a 32-byte output did not expose the problem.

4. Export salt condition: Changing if salt == nil to if salt != nil changed behavior for non-nil salt inputs. The production Export path uses a nil salt, so this mutation is not evidence of a failure on that path alone.

5. KDF output loop boundary: Changing len(out) < outLen to len(out) <= outLen did not change the returned output in the tested path because the extra derived bytes were truncated. I do not consider this a confirmed defect.

These results indicate that the existing tests did not detect several meaningful changes to KDF and export behavior. They also show why surviving mutations need individual investigation rather than automatically being treated as defects.

Proposed regression coverage

The local test-only addition in services/eap-noob/kdf_test.go covers the following:

1. One-step KDF golden test: Checks the complete 320-byte output against an expected value, covering the derived material rather than checking only determinism or output length.

2. HKDF known-answer tests: Checks the package's HKDF helper against the published SHA-256 test cases in RFC 5869 Appendix A. The test asserts the expected output keying material (OKM). A full-length OKM match checks the complete output of the helper, although it does not separately assert the intermediate pseudorandom key (PRK).

3. Export golden test with context: Checks a 100-byte export using a non-empty context. This exercises output spanning multiple SHA-256 blocks and verifies that context affects the expected result.

4. Long-label export test: Checks a 64-byte export with a 256-byte label. This exercises the high byte of the two-byte label-length encoding, which a short-label-only test would not cover.

The two export cases use fixed expected values:

• With context: label app, context bytes aa bb, output length 100, and a 32-byte Kz consisting of 0x42 repeated 32 times.
• 256-byte label: label a repeated 256 times, nil context, and output length 64.

The expected outputs were cross-checked through independent calculation paths using Go, Python HMAC, and the OpenSSL command-line tool. The supplied refinement report also records an additional oracle check with 14 of 14 expected-value comparisons matching. These are cross-checks of the calculations, not a substitute for an independently published EAP-NOOB known-answer vector.

The new tests also detected two additional mutation probes: removing the context from the export input and zeroing the high byte of the label-length encoding.

Protocol interpretation that needs confirmation

There is one point I would like to confirm before treating the EAP-NOOB KDF golden output as definitive.

My reading of RFC 9140, Section 3.5, together with NIST SP 800-56A Revision 3, Section 5.8.2.1.1, is that the FixedInfo input includes the one-byte length of SuppPrivInfo before the SuppPrivInfo data.

For the inputs used here, that gives:

"EAP-NOOB" || Np || Ns || 0x10 || Noob

Here, Np and Ns are each 32 bytes, Noob is 16 bytes, and 0x10 encodes the 16-byte length.

The implementation in services/eap-noob/kdf.go follows this interpretation. However, the reference C and Python implementations I examined appear to omit the length byte. I did not find a published full EAP-NOOB KDF known-answer vector that resolves this discrepancy.

I therefore do not want to present the calculated golden value as independently established proof of protocol conformance. The calculation has been cross-checked, but the interpretation itself needs maintainer or protocol-expert confirmation. If the reference implementations reflect the intended behavior, the expected value or implementation may need further investigation before a regression test is merged.

Relevant references:

• RFC 9140, EAP-NOOB: An EAP Method for Noob: https://www.rfc-editor.org/rfc/rfc9140.html
• RFC 5869, HMAC-based Extract-and-Expand Key Derivation Function (HKDF): https://www.rfc-editor.org/rfc/rfc5869.html
• NIST SP 800-56A Revision 3: https://csrc.nist.gov/pubs/sp/800/56/a/r3/final
• NIST SP 800-56C Revision 2: https://csrc.nist.gov/pubs/sp/800/56/c/r2/final

Verification performed

The supplied test report records the following checks:

• Focused EAP-NOOB tests passed.
• The full services/eap-noob module test suite passed.
• go vet passed for the targeted module.
• gofmt was applied and checked.
• The race-detector run passed.
• The additional mutation probes for non-empty context and the high byte of label length were detected by the new tests.

There were also two checks with unrelated repository-level limitations:

• make test-services failed at TestBrokerProxySetPortRebinds in services/tests/broker_supervision_test.go:554. The supplied report says the failure was reproduced without the new test file, so it appears unrelated to this proposed change.
• The SPDX scan reported no missing license headers but exited nonzero because of the pre-existing unclassified file desktop/tools/inference-dispatcher.

These results are from the supplied local reports. They are not a claim that every repository test or every repository-wide check passes.

Questions for maintainers

1. Does the FixedInfo construction described above match the intended EAP-NOOB implementation, particularly the SuppPrivInfo length byte?
2. Would a focused, test-only PR adding these regression tests be welcome?
3. Are there existing upstream test vectors, interoperability results, or project-specific conventions that should be used to validate or refine the expected values before submitting the PR?

Scope

The proposed change is limited to tests. It does not modify production behavior.

I would appreciate confirmation of the protocol interpretation and whether this test-only contribution fits the project's direction before opening a PR. If the interpretation needs adjustment, I would rather resolve that first than add golden values that accidentally lock in incorrect behavior.