Minimal no_std SHA-2 implementation crate for EriX.
Find a file
Erik Inkinen d1eb3312e3
All checks were successful
CI / test (push) Successful in 4s
CI / security (push) Successful in 1m28s
CI / minimal-versions (push) Successful in 10s
lib-sha2: drop unstable rustfmt options for stable toolchains
2026-03-23 10:19:55 +02:00
.github Refactor milestone terminology to "Component Milestone Tracking" across templates and documentation for consistency 2026-03-05 11:55:02 +02:00
src Implement SHA-256 support with incremental and one-shot hashing 2026-02-26 17:06:12 +02:00
.editorconfig Initial commit 2026-02-26 15:25:25 +01:00
.gitignore Initial commit 2026-02-26 15:25:25 +01:00
ARCHITECTURE.md Initialize lib-sha2 2026-02-26 16:48:04 +02:00
Cargo.toml Add initial implementation of no_std SHA-2 (SHA-512) crate 2026-02-26 16:51:34 +02:00
CODE_OF_CONDUCT.md Initial commit 2026-02-26 15:25:25 +01:00
CONTRIBUTING.md Refactor milestone terminology to "Component Milestone Tracking" across templates and documentation for consistency 2026-03-05 11:55:02 +02:00
LICENSE Initial commit 2026-02-26 15:25:25 +01:00
README.md Refactor milestone terminology to "Component Milestone Tracking" across templates and documentation for consistency 2026-03-05 11:55:02 +02:00
ROADMAP.md Update README and ROADMAP with current status and API implementation details 2026-02-28 04:53:39 +02:00
rustfmt.toml lib-sha2: drop unstable rustfmt options for stable toolchains 2026-03-23 10:19:55 +02:00
SECURITY.md docs: align security policy phase numbering 2026-03-11 05:28:13 +02:00

lib-sha2

Minimal no_std SHA-2 implementation crate for EriX.

This crate provides both:

  • SHA-256 (boot image hashing, section hashing)
  • SHA-512 (Ed25519 prehash requirements and related consumers)

UEFI + x86_64 are current primary targets, but this crate is explicitly portable and architecture-neutral.


Scope

This crate provides:

  • incremental and one-shot SHA-256 API
  • incremental and one-shot SHA-512 API
  • deterministic digest outputs in fixed-size arrays

This crate does not provide:

  • HMAC or HKDF
  • SHA-3/BLAKE variants
  • signature verification
  • key management or RNG

Why one crate for both algorithms

EriX needs both SHA-256 and SHA-512 in the secure boot chain:

  • SHA-256 for boot.img manifest and section verification
  • SHA-512 for Ed25519 verification support

Keeping both in one crate ensures:

  • shared implementation standards (no external deps, no_std)
  • consistent testing and review posture
  • less duplicated low-level logic

Design constraints

  • #![no_std]
  • zero external dependencies
  • deterministic behavior
  • explicit APIs and minimal unsafe (ideally none)

Intended consumers

  • lib-bootimg (SHA-256)
  • lib-ed25519 (SHA-512)
  • bootloader and future kernel/user-space verifiers

Status

Implemented baseline.

SHA-256 and SHA-512 one-shot/incremental APIs are available and covered by unit tests. Remaining work is hardening and expanded cross-repo regression coverage.

See ARCHITECTURE.md and ROADMAP.md.