Skip to content

Add SHA2-224 and establish the SHA-2 variant pattern - #3449

Open
geedo0 wants to merge 1 commit into
provider-readmefrom
feat/provider-sha224
Open

Add SHA2-224 and establish the SHA-2 variant pattern#3449
geedo0 wants to merge 1 commit into
provider-readmefrom
feat/provider-sha224

Conversation

@geedo0

@geedo0 geedo0 commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

Context and motivation

SHA2-256 is the provider's only algorithm today, and its front side was written as one algorithm's
file: the gettable-params array, the reported flag values, and every slot body name SHA-256 directly.
Adding another variant in that shape means copying the file.

The point of this change is the pattern, with SHA2-224 as its first application: what belongs to an
operation class, what belongs to an algorithm family, and what an individual algorithm owns. After
it, a SHA-2 variant is a set of AWS-LC bindings, a set of thin typed slots, a registry row, and one
row in each test suite.

Description of changes

Backend (backend/operations/digests/sha2.c). SHA-224's bindings are written out per algorithm
rather than generated, so each AWS-LC type, constant, and function stays visible to review:
SHA256_CTX, SHA224_Init/Update/Final, SHA224_DIGEST_LENGTH, SHA224_CBLOCK. Its final keeps
the output-size check, because SHA224_Final takes no size argument and would write past a short
buffer.

Frontend, class level (new frontend/operations/digests/digests.c). The gettable-params keys and
the get_params body are common to OSSL_OP_DIGEST, so they live here once. get_params takes block
size, digest size, and flags; XOF and ALGID_ABSENT are flags a family supplies
(AWSLC_PROV_SHA2_FLAGS for SHA-2).

Frontend, family level (frontend/operations/digests/sha2.c). Shared behavior stays ordinary C at
family scope, taking the context size and the backend function pointers as arguments. Each
algorithm's slots are thin typed wrappers naming their own backend entry points and sizes.

Macros are limited to declarations and dispatch-table initialization. No algorithm behavior or
control flow is inside one. Slot declarations still go through the OSSL_FUNC_digest_*_fn typedefs,
so a slot that drifts to a neighbouring slot's signature fails to compile instead of being erased by
the dispatch table's (void (*)(void)) cast.

SHA2-224 registers as SHA2-224:SHA-224:SHA224:2.16.840.1.101.3.4.2.4 and reports size 28, block
size 64, XOF 0, ALGID_ABSENT 1. SHA2-256's slots, reported values, and registration are unchanged.

Testing

Both suites are parameterized, so SHA2-224 is one data row in each rather than a copy of the bodies.
CI passes.

The frontend row fetches with provider=awslc required, so a fallthrough to the default provider
cannot pass as success. It covers resolution under every advertised spelling including the OID, the
four algorithm parameters, and the "abc" answer through one-shot, byte-at-a-time updates
behind a zero-length update, DUPCTX into an empty destination, and COPYCTX over a destination holding
unrelated state. The backend row covers the same answer plus the bounds contract EVP cannot reach:
final with a short reported size returns 0, leaves the output buffer's canary intact, and leaves the
context finalizable into a correctly sized buffer.

Two mutations confirm the rows bite: pointing SHA2-224's final slot at awslc_prov_sha256_final fails
the known answer, and deleting the backend's short-output guard fails the bounds test.

Review considerations

This is the last cheap opportunity to change the structure an algorithm takes, so the structure is
what I want reviewed rather than SHA-224 itself.

  • Is the balance between maintainability, reusability, and extensibility right?
  • Does the class / family / algorithm split generalize to other digest families and to other
    operation types, or is it fitted to fixed-length hashes?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache
2.0 license and the ISC license.

@github-actions

Copy link
Copy Markdown
Contributor

🔒 Security ReviewView Report

Please review before merging.

@codecov-commenter

codecov-commenter commented Aug 25, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.06%. Comparing base (cbf7ffb) to head (ceea01a).

Additional details and impacted files
@@                 Coverage Diff                 @@
##           provider-readme    #3449      +/-   ##
===================================================
- Coverage            78.08%   78.06%   -0.02%     
===================================================
  Files                  700      700              
  Lines               124704   124704              
  Branches             17326    17323       -3     
===================================================
- Hits                 97371    97349      -22     
- Misses               26467    26488      +21     
- Partials               866      867       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@geedo0
geedo0 marked this pull request as ready for review August 26, 2026 12:58
@geedo0
geedo0 requested a review from a team as a code owner August 26, 2026 12:58
Add SHA2-224 with explicit backend bindings, ordinary-C family helpers, and thin per-algorithm frontend slots. Consolidate digest-class declarations and extend the parameterized frontend and backend suites.
@geedo0
geedo0 force-pushed the feat/provider-sha224 branch from fc556e7 to ceea01a Compare August 31, 2026 15:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants