### Description of changes:
Adds Keccak-256 with the original Keccak submission's padding byte (0x01)
— the variant used by Ethereum, Solidity's `keccak256()`, and other
blockchain ecosystems. This is **not** FIPS 202 SHA3-256 (which uses
0x06 padding); rate (1088 bits) and digest length (256 bits) match, but
the padding byte differs, so outputs differ for every input.
### Approach:
The implementation lives inside the FIPS module
(`crypto/fipsmodule/sha/sha3.c`) so it shares the audited Keccak-f[1600]
permutation, FIPS202_Init/Update/Finalize buffering, and assembly
backends with the SHA-3 family. The only delta in the module's
algorithmic code path is one extra accepted padding byte:
 if (pad != SHA3_PAD_CHAR &&
 pad != SHAKE_PAD_CHAR &&
 pad != KECCAK_PAD_CHAR) { // 0x01
 return 0;
 }
The new public surface is exactly `EVP_keccak_256()` (plus the existing
`EVP_Digest*` machinery). This matches the BoringSSL/AWS-LC convention
established by SHA-3: the `EVP_MD` is the public API; direct C entry
points (`KECCAK_256_Init/Update/Final`, one-shot `KECCAK_256()`) live in
`crypto/fipsmodule/sha/internal.h` and are exported only for in-tree
consumers, mirroring `SHA3_256_*`.
### Call-outs:
- **NOT FIPS-approved.** `KECCAK_256_Final` and the `KECCAK_256()`
 one-shot intentionally omit `FIPS_service_indicator_update_state()`,
 so calling Keccak-256 leaves the per-thread approved-services counter
 unchanged. Verified by a new row in
 `service_indicator_test.cc::kDigestTestVectors` with
 `AWSLC_NOT_APPROVED`. The negative invariant is enforced both at
 runtime (the parameterized `EVPMDServiceIndicatorTest.EVP_Digests`
 catches accidental `_update_state` calls) and structurally (a future
 reviewer can grep the file and see only "Intentionally no" comments).
- **No NID, no OID.** The Ethereum-style 0x01-padding Keccak is not
 standardised and OpenSSL has not assigned an OID for it either. The
 EVP_MD's `type` is `NID_undef`, and the digest is registered in
 `nid_to_digest_mapping` by name only. As a consequence,
 `EVP_keccak_256()` cannot be used with `EVP_DigestSign*` /
 `EVP_DigestVerify*` for RSA-PKCS#1-v1_5 or ECDSA, and
 `EVP_marshal_digest_algorithm` will fail with
 `DIGEST_R_UNKNOWN_HASH`. `objects.txt`, `obj_dat.h`, and `nid.h` are
 intentionally untouched.
- **OpenSSL compatibility.** The registered EVP_MD name is `KECCAK-256`
 (uppercase, hyphenated), matching OpenSSL 3.2+'s default-provider
 registration in `providers/implementations/include/prov/names.h`.
 Portable code that does `EVP_MD_fetch(NULL, "KECCAK-256", NULL)` on
 OpenSSL works against AWS-LC via
 `EVP_get_digestbyname("KECCAK-256")`. A `keccak-256` lowercase alias
 is also registered.
- **FIPS module impact.** The audited Keccak-f[1600] permutation,
 absorb/squeeze code, and existing SHA-3 entry points are unchanged
 byte-for-byte. The only edit inside the module boundary is the
 3-line `FIPS202_Init` pad-byte check above plus the new
 `KECCAK_256_*` wrappers.
### Testing:
All Keccak-256 tests live in `crypto/digest_extra/digest_test.cc`
alongside the rest of the digest tests. New coverage:
- `kTestVectors[]` — 3 well-known Ethereum-ecosystem vectors (empty /
 "abc" / fox-pangram). These exercise the EVP one-shot, byte-at-a-time
 streaming, copy/move-on-context, and unaligned-input paths in
 `TestDigest()`.
- `DigestTest.Keccak256DiffersFromSHA3_256` — invariant: for the same
 input, Keccak-256 and SHA3-256 outputs must always differ. Guards
 against a future maintainer "fixing" the padding byte.
- `DigestTest.Keccak256KAT` — file-driven tests using 137 short-message
 vectors (0..1088 bits) and 100 long-message vectors (2184..110688
 bits), in the same `Len/Msg/MD` format used by SHA-3 KATs. Mirrors
 the `FileTestGTest` pattern from `sha3_test.cc::NISTTestVectors`.
- `DigestTest.Getters` — extended with `EVP_get_digestbyname("KECCAK-256")`,
 the lowercase alias, and an `EVP_MD_type == NID_undef` assertion.
- `service_indicator_test.cc::kDigestTestVectors` — one new row,
 parameterized as `EVP_Digests/13`, asserts `AWSLC_NOT_APPROVED`
 through Init / Update / Final.
KAT vectors are generated by `util/gen_keccak256_kat.py`, which uses
pycryptodome (an independent Keccak-256 implementation) as the
reference. The script sanity-checks pycryptodome against the well-known
Ethereum vectors before generating, so a misconfigured environment fails
loudly. Reference and implementation under test come from completely
different code, so the test asserts genuine cross-implementation
agreement.
`bssl speed -filter KECCAK-256` is wired up next to the SHA-3
benchmarks for performance regression tracking.
Verified end-to-end:
- Debug build: 2707/2707 active `crypto_test` cases pass, including
 `DigestTest.Keccak256*`, `SHA3Test.*` (no regression), and the full
 digest suite.
- FIPS build (`-DFIPS=1 -DBUILD_SHARED_LIBS=1`): 3719/3719 active cases
 pass, including all 14 rows of `EVPMDServiceIndicatorTest.EVP_Digests`
 (was 13).
- `bssl speed -filter KECCAK-256` produces sensible numbers across all
 default chunk sizes.

@manastasova manastasova left a comment •

edited

Loading