Rusty Shield

The Inherited Surface

Rusty Shield — published as the crate rs_shield — inherits its hashing contract from the language itself rather than defining one. Each primitive it ships is, first, an ordinary hasher in Rust's standard sense: bytes go in through the same interface a HashMap already relies on, and the type stands in wherever code written against that interface expects one. A single addition extends it to return a full-width cryptographic digest. What a consumer gets is the guarantee every hashable value in the language already carries, extended rather than replaced by a bespoke API built for the occasion. Elsewhere in the ecosystem the pattern runs the other way: a purpose-built trait framework, generic cores assembled into concrete types through a macro, over a compression backend chosen at runtime by CPU-feature detection. The cost of rs_shield's choice is paid where it is visible — implementation effort, and a scope that grows one primitive at a time. What it buys is an audit boundary a reviewer can actually reach the bottom of.

Philosophy

Four Unix-derived principles constrain the design: Do One Thing Well, Avoid Dependency Breakage, Self-Support, and Clarity Over Efficiency. Each implementation carries one responsibility, and diverging responsibilities become a separate crate. rs_shield bundles a suite behind a single dependency for callers who want all of it or the CLI — a convenience, not the entrypoint.

no_std without allocation is therefore neither a portability concession paid for in speed nor a promise that allocation-free code runs faster: it is a boundary — requiring only what implementing the primitive requires, and leaving placement, allocation strategy and runtime policy to whoever actually knows the target.

Delivered Scope

Shipped in rs_shield 0.1.4: hashing, in depth. The SHA family (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256), the SHA-3 family (SHA3-224, SHA3-256, SHA3-384, SHA3-512), the extendable-output functions SHAKE128 and SHAKE256, generic Keccak variants, and HMAC composed over any of the above. Each implementation extends the Hash and Hasher traits of Rust's core library and is checked against the published NIST test vectors.

Coming next: symmetric ciphers and public-key primitives. Both are scoped under the same no-FFI, allocator-free constraints as the hashing work, and both are under active development. Neither is published yet — §05 states what that means for anyone evaluating the crate today.

Architecture

The dependency graph is shallow by design, and it has no mandatory root. Each primitive is published as its own crate and resolves directly against core — no intermediate FFI shim, no edge to a heap allocator. rs_shield sits above them as a bundle: it re-exports the primitive crates behind a single dependency and adds no hashing logic of its own — the CLI is the one thing that exists only there. Depending on it is a packaging convenience, not an architectural commitment: a consumer that needs SHA-256 alone depends on rs_sha256 and inherits nothing else — the same code, one edge shorter. The graph below is the whole of it — that is the claim the diagram is there to let a reviewer check.

flowchart LR
  Consumer["Consumer crate"]
  Bundle["rs_shield · bundle re-export + CLI"]
  subgraph Prims["Primitive crates · each published standalone"]
    Hash["SHA / SHA-3"]
    HMAC["HMAC"]
    SHAKE["SHAKE128 / 256"]
    Keccak["Keccak"]
  end
  Consumer --> Bundle
  Consumer -. "or any one crate, directly" .-> Prims
  Bundle --> Prims
  Hash --> Core(["core"])
  HMAC --> Core
  SHAKE --> Core
  Keccak --> Core
  Note["no FFI · no alloc"]:::note -.-> Bundle
  classDef note fill:transparent,stroke-dasharray: 3 3,color:#555,stroke:#999;

Status And Limitations

The hashing milestone is complete and published. Nothing has been released since rs_shield 0.1.4 in June 2023: the cipher and public-key work named in §03 is underway but unreleased, and no date is claimed for it. What crates.io serves today is the hashing scope alone.

Three constraints bear on anyone evaluating adoption. The library is licensed GPL-2.0-only, which governs what it can be linked into. That is the operative constraint today and the one to plan against: the intent is to relicense under MIT once the work named in §03 is delivered, but no relicensing has occurred and no date is claimed for it. It has had no third-party security audit; conformance to the NIST vectors demonstrates correctness against the published test cases, not resistance to side-channel attack. And Clarity Over Efficiency is a real trade — where throughput is the binding constraint, an optimised implementation will win.