19. Proposed Validation Strategy

This chapter proposes the tests that would establish the design works. It is a plan, not a log: no tests were executed in this study, and the chapter is written so that an implementation phase can be checked against it. The governing principle is from §6.4 — a check that has never been observed to fail has not been tested — so every requirement that can be violated has a test that violates it.

19.1 Levels

Level	Establishes	Independent of
L1 Algorithm	Each algorithm computes correct values	OpenSSL
L2 Provider	Algorithms are reachable through the provider interface	TLS
L3 Key schedule	Derivations match independently computed values	The network
L4 Handshake	A connection is established using the algorithms	—
L5 Interoperability	A different implementation agrees	The implementation under test

The levels are ordered by cost and by diagnostic value. A failure at L4 with L1–L3 passing localises the problem to integration; a failure at L4 with L3 untested localises it nowhere.

19.2 L1: algorithm correctness

Known-answer tests against published vectors, for each algorithm, including:

every input length from zero through at least two block boundaries, for the hash — the boundary cases are where streaming bugs live (§9.4);
the standard AEAD vectors, plus a case with empty plaintext and a case with empty AAD;
key exchange against fixed key pairs with known shared secrets;
a test that the transcript-style usage — many small updates — agrees with a single-shot computation over the concatenation.

19.3 L2: provider integration

The provider loads and appears in openssl list -providers.
Each algorithm is listed under the expected name with the expected properties.
Fetching with the required property succeeds; fetching with a property the provider does not satisfy fails (requirement F10).
Context duplication produces independent state: duplicate a partially updated hash context, finalise the copy, continue the original, and confirm both results are correct. This is the test for §9.2 and it fails loudly on a shallow copy.
The provider coexists with the default provider without displacing it (F9): fetch a standard algorithm and confirm it still resolves.
Teardown frees all state, verified under a leak checker.

19.4 L3: key schedule

Required by §15.6 and the most valuable single test in the plan, because it catches the silent-weakening failure of §15.3.

Derive each secret in the schedule from fixed inputs and compare against values computed by an independent implementation of HKDF with the same hash.
Confirm every derived secret has the length the hash reports.
Negative test: a deliberately misreported output length must cause a detectable failure, not a silently shorter secret.

19.5 L4: handshake

A TLS 1.3 handshake completes using the custom suite and group, between a client and server both configured for them.
The negotiated suite and group, as reported by both endpoints, are the intended ones — not merely that a connection was established (§14.2).
Data transfers correctly in both directions, including records at the maximum size and records of one byte.
Key update completes and traffic continues.
Session resumption either works or fails cleanly, with the hash recorded per §15.5.

19.5.1 Required negative tests

These establish that the mechanisms discriminate, and they are not optional:

Test	Expected	Guards
Deactivate the provider, retry with the custom suite required	Handshake fails	F10, silent fallback (§14.2)
Corrupt one byte of a record	Connection torn down with `bad_record_mac`	§8.6 tag verification
Present a peer key share that is not on the curve	Share rejected before any private-key operation	§10.4 invalid-curve
Present a small-subgroup point	Rejected	§10.4
Offer the suite to a peer without it	Clean `handshake_failure`, no fallback	§12.3
Configure the provider in a different library context	Algorithms unavailable, diagnosable	C6, §13.3

The second and third rows are the tests that distinguish a working security mechanism from one that has merely never been challenged. A test suite omitting them can pass completely against an implementation with no integrity protection and a recoverable private key.

19.6 L5: interoperability

Against an independent implementation, per §16.5. Where none exists, the chapter's recommendation is to say so rather than to substitute same-source testing and describe the result as interoperability.

19.7 Reporting

Results should record, for every case, what was executed and what was observed, with the environment. Following the companion paper's practice, counts of assertions should not be presented as counts of scenarios: three thousand bytewise comparisons within one test are one test, and reporting them as thousands of passing checks overstates coverage.

A results chapter should also record what was not tested. The absence of an interoperability result, of a constant-time verification (§17.5), or of a validated-module claim (§17.7) should appear in the report, because a reader cannot distinguish an untested property from a passing one by its absence.