-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simple, Non-DOS-resistent seed #126
Comments
We would like to have this as well, we compile with |
I don't see the issue with |
This can be done. See my comment here: #123 (comment)
compile-time-rng is a build time dependency only. So there should be no deployment cost.
This is already the case. The problem you are encountering is that the Builder does not implement |
Thanks for your replies @tkaitchuck !
What I would like is for One of the great things about My library could use |
@emilk Here's the solution I use in my own projects. struct HashMap<K, V> {
inner: hashbrown::HashMap<K, V, RandomState>,
}
impl<K, V> Default for HashMap<K, V> {
fn default() -> Self {
#[cfg(has_random)]
let inner = HashMap::with_hasher(RandomState::default());
#[cfg(not(has_random))]
let inner = HashMap::with_hasher(RandomState::generate_with(SEED1, SEED2, SEED3, SEED4));
Self { inner }
}
} I find it to be a robust solution that allows for a drop-in replacement. |
To add to this discussion: Sometimes you want to explicitly have deterministic behaviour. E.g. when writing tests. In particular, with property based tests it is really desirable that the same seed produces the same results. As far as I can see there is no straightforward way to get a fully deterministic ahash HashMap. Having that would be very useful. I got a case where I am using the |
On this issue, I have recently encountered a different problem. The core of the prob is: My crate would pull in Since cargo would merge features, I end up always having
|
Sorry if I am dense, but how do I generate a fully deterministic ahash hashtable using RandomState::with_seed? Got a bit lost... |
At this point you should probably expose
You should open a PR with these crates.
Use the |
So this is what I came up with to make a type of AHashMap that is always deterministic. Still feels a bit like walking a minefield since seemingly innocent methods like RandomState::with_seed are introducing nondeterminism... So pub struct DeterministicHasher(RandomState);
impl Default for DeterministicHasher {
fn default() -> Self {
Self(RandomState::with_seeds(0, 0, 0, 0))
}
}
impl BuildHasher for DeterministicHasher {
type Hasher = ahash::AHasher;
fn build_hasher(&self) -> Self::Hasher {
self.0.build_hasher()
}
}
type DetAHashMap<K, V> = ahash::AHashMap<K, V, DeterministicHasher>; |
Sorry I believe it is You can look into the source to see that it just takes the four numbers as the seed without any processing. I eventually expose an option to provide fixed seeds. |
Yes, I checked. Just found the difference a bit surprising. I would expect a method that is called with_seed to also be completely deterministic. That is usually what you want if you pass in an explicit seed.
Thanks a lot. Going with the solution above for now, I guess... |
Both
|
It is probably better to mention these in the documentation as it takes a while reading through the code to figure out. Especially the differences between Some form of table would be helpful, such as...
|
Summary
I want to be able to use
ahash
without enablingruntime-rng
norcompile-time-rng
.Background:
Currently users have a choice between
runtime-rng
andcompile-time-rng
. As I understand it, both these are designed to help against DOS attacks by having an unpredictable seed. There are many circumstances where DOS-attacks won't matter, e.g. wheneverahash
isn't used with user-generated keys, etc (related issue: #58).Why would one want to opt-out of these features?
runtime-rng
has the downside that, in order to useahash
in a web app (see emilk/egui#2009), users need to addcompile-time-rng
has the downside that it pulls in extra dependencies, and increase compile times.So, as a library author that do not care about DOS attacks, I would like to have to be able to use
ahash
without eitherruntime-rng
orcompile-time-rng
. However, this doesn't currently work:Solution
I would suggest that
ahash
can be used without bothruntime-rng
andcompile-time-rng
by just using a fixed seed.Either
--no-default-features --features std
should just work, or we add a new featurefixed-seed
(or similar) so that users opt-in to this (potentially DOS-vulnerable) behavior.In either case, this would be the fallback only if no dependency enables the
runtime-rng
orcompile-time-rng
features. That means me as a library author can leave it to my users to opt-in to DOS-resistant hash seeds.The text was updated successfully, but these errors were encountered: