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

kdbrand: elektraRandGetInitSeed behavior #1598

Closed
KurtMi opened this Issue Sep 6, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@KurtMi

KurtMi commented Sep 6, 2017

For the opmphm (a randomized hash map algorithm), a good and fast initialization seed is needed.
I investigated a little bit and found the following solution, but I am not sure if this is a good one and possible for all platforms (we support).

  1. If /dev/urandom can be opened use it.
  2. else use the following information to generate a seed:
  • time
  • pid
  • hostid

@markus2330 whats your opinion?

@markus2330

This comment has been minimized.

Show comment
Hide comment
@markus2330

markus2330 Sep 6, 2017

Contributor

Opening /dev/urandom seems to be heavyweight within every key set. For an efficient solution using /dev/urandom we would need something like kdbksNew (similar to the idea with kdbKeyNew to use identity of the key name instead of hashing the string; kdb could then pool a bit of random data and give it to the next key sets).

But random(3) or the platform-specific arc4random (BSD specific) or getrandom (linux specific) might be better suited anyway.

For non-POSIX systems it is quite difficult. We could do a best-effort mixing of the sources available. time(0) seems to be the only info standardized in C99. In C11 timespec_get would be available. Then you could get two timestamps for and after some calculation which would also incorporate some random noise caused by the scheduler.

Maybe you can elaborate on how good the seed should be. Is it really a problem if different key sets get the same seed?

Contributor

markus2330 commented Sep 6, 2017

Opening /dev/urandom seems to be heavyweight within every key set. For an efficient solution using /dev/urandom we would need something like kdbksNew (similar to the idea with kdbKeyNew to use identity of the key name instead of hashing the string; kdb could then pool a bit of random data and give it to the next key sets).

But random(3) or the platform-specific arc4random (BSD specific) or getrandom (linux specific) might be better suited anyway.

For non-POSIX systems it is quite difficult. We could do a best-effort mixing of the sources available. time(0) seems to be the only info standardized in C99. In C11 timespec_get would be available. Then you could get two timestamps for and after some calculation which would also incorporate some random noise caused by the scheduler.

Maybe you can elaborate on how good the seed should be. Is it really a problem if different key sets get the same seed?

@markus2330

This comment has been minimized.

Show comment
Hide comment
@markus2330

markus2330 Sep 6, 2017

Contributor

For non-POSIX there is also clock (3). Maybe clock+time together is already enough as workaround for these platforms?

Contributor

markus2330 commented Sep 6, 2017

For non-POSIX there is also clock (3). Maybe clock+time together is already enough as workaround for these platforms?

@KurtMi

This comment has been minimized.

Show comment
Hide comment
@KurtMi

KurtMi Feb 7, 2018

As long as elektraRandGetInitSeed (void) is used only by the OPMPHM, time(0) is a platform independent and good choice.

KurtMi commented Feb 7, 2018

As long as elektraRandGetInitSeed (void) is used only by the OPMPHM, time(0) is a platform independent and good choice.

@KurtMi KurtMi closed this Feb 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment