Minimal no_std SHA-2 implementation crate for EriX.
- Rust 100%
| .github | ||
| src | ||
| .editorconfig | ||
| .gitignore | ||
| ARCHITECTURE.md | ||
| Cargo.toml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
| ROADMAP.md | ||
| rustfmt.toml | ||
| SECURITY.md | ||
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.imgmanifest 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.