Jitterentropy failing repetition count online health test

[PeterAdamson]

Hello,

I have a library in which I've linked jitterentropy to serve as the RNG. I noticed that over time (usually 1-3 hours), the library will start to report error codes of -2 when calling jent_read_entropy(). Can you think of a reason why the library might be failing this test after a certain period of time?

I have monitored the system entropy over the time period that the call fails in, and the system entropy stays at a consistently high value, so it does not seem that my system is lacking in entropy.

my failing implementation is roughly as follows (POC, not full production code):

unsigned char getbyte() {
  unsigned char u = 0;
  int n;

  struct rand_data *entropy_collector;
  entropy_collector = jent_entropy_collector_alloc(1, 0);
  n = jent_read_entropy_safe(entropy_collector, &u, sizeof(u));

  jent_entropy_collector_free(entropy_collector);
  return u;
}

when adding a check to make sure that n > 0, that is when I find that the value eventually returns -2.

[smuellerDD]

Am Donnerstag, 21. April 2022, 20:22:59 CEST schrieb PeterAdamson:

Hi PeterAdamson,

Hello,

I have a library in which I've linked jitterentropy to serve as the RNG. I noticed that over time (usually 1-3 hours), the library will start to report error codes of -2 when calling jent_read_entropy(). Can you think of a reason why the library might be failing this test after a certain period of time?

For starters, I recommend using jent_read_entropy_safe.

The error is returned when the RCT test is failing. This fails when too many back-to-back identical values are seen - this happens when the entropy source somehow degrades. When using the jent_read_entropy_safe, a higher oversampling rate and a larger memory buffer is used which should alleviate the problem, but slows down the entropy rate.

I have monitored the system entropy over the time period that the call fails in, and the system entropy stays at a consistently high value, so it does not seem that my system is lacking in entropy.

my failing implementation is roughly as follows (POC, not full production code):

unsigned char getbyte() {
  unsigned char u = 0;
  int n;

  struct rand_data *entropy_collector;
  entropy_collector = jent_entropy_collector_alloc(1, 0);
  n = jent_read_entropy_safe(entropy_collector, &u, sizeof(u));

  jent_entropy_collector_free(entropy_collector);
  return u;
}

when adding a check to make sure that n >= 0, that is when I find that the value eventually returns -2.

Can you run the tests in tests/raw-entropy/recording_userspace/ invoke_testing.sh

Send the generated data to me, please.

Ciao Stephan

[PeterAdamson]

I tried using jent_read_entropy_safe first actually, but I ended up getting repeated core dumps in my root folder, to the point that my system would run out of space after 5 minutes due to it being filled with core dumps. Switching to jent_read_entropy stopped the core dumps (but resulted in this error).

I'll run those tests and get you the data as soon as I can.

[PeterAdamson]

please see attached for results of the invoke_testing.sh script results-measurements.zip

[PeterAdamson]

I forgot to note that this is running in a FIPS enabled environment

[smuellerDD]

Am Donnerstag, 28. April 2022, 15:25:47 CEST schrieb PeterAdamson:

Hi PeterAdamson,

I forgot to note that this is running in a FIPS enabled environment

Sorry for the delay, ESDM and leancrypto kept me busy.

First, coredumps is not good. Have you detected why it fails?

Second, the data you provide looks very good. Ample entropy, more than 6 bits of entropy per time delta (the Jitter RNG requires only 0.333) using the SP800-90B analysis tool.

Can it be that your timer behaves differently at times? If so, have you tried the internal timer (JENT_FORCE_INTERNAL_TIMER flag during initialization)?

Ciao Stephan

[smuellerDD]

closing