aHash
aHash copied to clipboard
tkaitchuck
feature gate random state
This is especially useful for no_std development, where we don't want to introduce the getrandom dependency.
After this change, one can choose to disable random-state feature and implement their own version of RandomState using whatever random source they choose. This also somewhat addresses #94 and avoids the need of using compile-time-rng in restricted platforms.
Issue #94 asside, getrandom is no_std. So why would you want to avoid it in a no_std env?
getrandom is no_std
getrandom is not truly no_std. It works by invoking system call through libc. Moreover, it is designed in such a way that it is impossible to overwrite the random source. As a result, it will break in certain no_std environment, where we don’t want to link to any system library, such as sgx.
The PR would give the crate user more flexibility, where we can choose whether we want a default random source, i.e. getrandom, or choose to implement a custom one.
@xu-cheng getrandom explicitly supports SGX environments through RDRAND. It seems like that would be the ideal solution there. But if you really want to disable all randomness, I don't see any way to do this with cargo's feature rules and keep things in one crate. Because it doesn't allow mutually exclusive features or forced choices in feature flags.
From a build perspective this makes sense. If you have multiple libraries getting linked together and one requires randomization and the other absolutely cannot have it, there is no way to resolve it without one of them breaking the other. I think the solution will have to involve multiple crates.
There are a couple of ways to go about this, one would be to re-factor the hashing algo out into its own crate independent of its invocation and then have different crates for invoking it. However I think it may make sense for them to diverge in their implementation. For example for SGX etc it probably makes sense to limit the instructions, and if randomness is not being used anyway the hashing algorithm can be significantly weaker as the data is being trusted already.
Barring some clever way to combine this with #94, I think the solution is to open an issue, or maybe just a comment on issue #58 and then I can create a new crate with a low-quality non-randomized hash.