Add SHA2-224 and establish the SHA-2 variant pattern - #3449
Open
geedo0 wants to merge 1 commit into
Open
Conversation
Contributor
|
🔒 Security Review — View Report Please review before merging. |
Codecov Report✅ All modified and coverable lines are covered by tests. 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. 🚀 New features to boost your workflow:
|
geedo0
marked this pull request as ready for review
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
force-pushed
the
feat/provider-sha224
branch
from
August 31, 2026 15:04
fc556e7 to
ceea01a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 algorithmrather 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. Itsfinalkeepsthe output-size check, because
SHA224_Finaltakes no size argument and would write past a shortbuffer.
Frontend, class level (new
frontend/operations/digests/digests.c). The gettable-params keys andthe
get_paramsbody are common toOSSL_OP_DIGEST, so they live here once.get_paramstakes blocksize, digest size, and flags; XOF and ALGID_ABSENT are flags a family supplies
(
AWSLC_PROV_SHA2_FLAGSfor SHA-2).Frontend, family level (
frontend/operations/digests/sha2.c). Shared behavior stays ordinary C atfamily 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_*_fntypedefs,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.4and reports size 28, blocksize 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=awslcrequired, so a fallthrough to the default providercannot 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 updatesbehind 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:
finalwith a short reported size returns 0, leaves the output buffer's canary intact, and leaves thecontext finalizable into a correctly sized buffer.
Two mutations confirm the rows bite: pointing SHA2-224's final slot at
awslc_prov_sha256_finalfailsthe 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.
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.