Ensure that all crates are `#![no_std]`

[ounsworth]

Might be a duplicate of #14

The work here is to circle back to the earlier crates:

• sha2
• sha3
• hmac
• hkdf
• rng

and add #![no_std] to the top of their lib.rs, see what breaks.

I suspect the things that will break will be of the flavour:

fn do something(..) -> Vec<u8>;

some of those will be able to convert to -> [u8; LEN] for some obvious choice of parametrized constant LEN (like the size of the hash function), but some of them might really need to be -> Vec<u8> in which case we should leave them but establish a pattern for guarding them with a cargo feature so that they compile out when building in no_std

Something like:

#[cfg(feature = "alloc")]
fn do something(..) -> Vec<u8>;

or maybe we want all crates to have a feature "std" as suggested here

#![no_std]

#[cfg(feature = "std")]
fn do something(..) -> Vec<u8>;

and add [features] std = [] (probably default = ["std"]) to Cargo.toml for all crates that use it.

[officialfrancismendoza]

@ounsworth One thing I'd add to the acceptance criteria: let's explicitly establish the workspace convention for no_std/alloc/std while we're here. Otherwise each crate may end up making slightly different feature-gating decisions. This seems like the right PR to define the pattern that the rest of the crypto crates should follow.

We should decide:

• whether the convention is default = ["std"] with an optional alloc feature (my preferred, to give developers optionality), or some other feature model;
• what the policy is for allocation-based APIs (e.g. Vec, String, Box): are they alloc-gated, std-gated, or considered out of scope for no_std;
• that the core cryptographic primitives remain allocation-free, with allocation only in convenience APIs where unavoidable.

It would also be good to add CI coverage for cargo check --workspace --no-default-features so we don't regress. Otherwise we risk each crate converging on slightly different no_std conventions over time.

[ounsworth]

Also as part of this: once we figure out a pattern for feature-gating on the presence / absence of STD, we should think about refactoring some of the internal algorithms (ML-DSA and ML-KEM for example) so that the big intermediate values (like the public matrix A) are allocated on the heap when building in STD mode.

[ounsworth]

Yes, I agree that we'll need some sort of tests (either local or CI) that make sure the no_std build is not broken and that all unit tests pass in both std and no_std builds.