The expanded experiments were run against the unchanged educational provider on the same OpenSSL 3.5.5 host as the baseline. Compilation completed with warnings treated as errors. The callback program reported 3,362 passing assertions, and the integration harness reported 37 passing cases. The original eight baseline checks also passed as part of the extended build script. This chapter interprets those observations without treating the counts as independent measures of cryptographic strength.
| Category | Cases or coverage | Result |
|---|---|---|
| Baseline integration | 8 checks | All passed |
| Deterministic message lengths | 28 lengths, 0 through 65,537 bytes | All matched reference |
| Mandatory properties | 3 requests | One selected; two rejected as expected |
| Activation values | 4 configurations | Two activated; two remained unavailable |
| Missing module | 1 invalid path | Request failed as expected |
| Independent processes | 16 executions grouped in 1 case | All matched reference |
| Direct callbacks | 3,362 assertions, including capacities 0–33 | All passed |
The results support the expected behavior of the wrapper’s selection and data path. They also provide a concrete example of evidence triangulation: algorithm output is tested through the command-line tool, while output-buffer handling is tested directly through the callback. A failure at either layer would require a different debugging approach even if both eventually affected the same digest request.
For insufficient capacities, the wrapper returned failure, set the output length to zero, and preserved all sentinel bytes. A subsequent sufficiently sized finalization succeeded. For capacities at least 32, the digest was written and bytes after the output remained unchanged. These observations are consistent with the source-level guard occurring before backend finalization.
The sweep also establishes that the interface is measured in bytes rather than in the length of a hexadecimal representation. A SHA-256 digest requires 32 binary output bytes, while its usual hexadecimal representation occupies 64 characters. Confusing these units is a realistic application error. The callback checks binary capacity; formatting belongs to a different layer.
The parameter tests returned the expected size, block size, and extendable-output flag. A string-typed size request was rejected. An unknown named parameter left its associated integer unchanged. These results demonstrate that the prototype is using typed setters rather than blindly writing through every caller-provided pointer.
They do not establish behavior for every malformed OSSL_PARAM array. The arrays in the harness are properly terminated and use valid allocated storage. Missing terminators, inaccessible pointers, and arbitrary corrupted structures are outside this experiment. This boundary is worth stating because successful type rejection can otherwise be exaggerated into a general parser-hardening claim.
The activation experiment agrees with the selected documentation version: true-like values activate the provider and false-like values do not. The distinction is especially useful when reading older discussions of provider configuration. The correct response to an historical finding is to identify the assessed version and retest the current version, not to assume either that the finding remains unchanged or that it is irrelevant.
The results do not identify which change introduced any historical behavior difference. Establishing that would require source-history analysis, release comparison, and possibly reproducing an older build. The paper therefore limits its statement to observed OpenSSL 3.5.5 behavior and the wording of the corresponding snapshot. This is a more defensible conclusion than inferring a complete maintenance history from one experiment.
The fips=yes request fails at outer selection because the educational algorithm does not advertise that property. This confirms an important boundary in the experiment: the module does not become available under that query simply because it delegates to a familiar digest algorithm. The test does not inspect a validated module and cannot establish compliance.
The successful provider=edu request remains compatible with the separate internal default-provider fetch. That nested selection is intentional but demonstrates why the outer provider identity is not a complete explanation of the cryptographic execution chain. An operational report that records only “provider=edu” would omit the backend used by the bridge. A production bridge should document or expose its backend policy in an appropriately controlled way.
The extended tests did not require a change to the provider’s implementation. This is useful evidence that the baseline code already handled the newly exercised boundary conditions. It is not evidence that no undiscovered defects remain. The test plan was derived partly from the source, so it naturally emphasizes behaviors the source makes visible. An independent reviewer might identify different risks or failure modes.
No performance claim is added. No security validation, device integration, or in-process multithreaded stress run is reported. The paper’s assurance remains deliberately scoped to the observed functional and boundary behavior. Subsequent chapters discuss how those remaining concerns could be investigated without relabeling a proposal as an experimental result.