Project

General

Profile

Actions

Bug #1358

closed

Random number generator

Added by robin.carey1 almost 15 years ago. Updated about 9 years ago.

Status:
Rejected
Priority:
Low
Assignee:
-
Category:
Crypto
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

---------- Forwarded message ----------
From: Robin Carey <>
Date: 2009/5/8
Subject: Random number generator
To:

I had an idea about how to improve the random number generator in
DragonFlyBSD which I would like to share.

There is a bootstrapping problem where it is difficult to get enough
"entropy" at boot to ensure the random number generator is fully seeded and
completely unpredictable immediately after the system has booted.

Currently the random number generator seeds itself from nanotime() and
nanouptime() which introduces a small degree of entropy, but probably not
enough to ensure the above requirement is met.

So a possible improvement could be made by introducing more "entropy" at
initialisation from a high resolution timer like the TSC - rdtsc() (which is
also used in the random number generator - NANOUP_EVENT() - courtesy of
Matthew Dillon). That is my suggestion: Use rdtsc() aswell as nanotime() and
nanouptime() to ensure the random number generator has enough "entropy" at
boot to ensure it is fully seeded and completely unpredictable. If this were
done (and true) then you would not need the current ability of the random
number generator being able to be seeded from a file - an ability which
Matthew Dillon implemented to solve the boot-seeding problem.

I am wondering if there are any other high resolution timers available .....


Files

unnamed (1.92 KB) unnamed robin.carey1, 05/08/2009 06:53 AM
Actions #1

Updated by sepherosa almost 15 years ago

On Fri, May 8, 2009 at 2:47 PM, Robin Carey <> wrote:

---------- Forwarded message ----------
From: Robin Carey <>
Date: 2009/5/8
Subject: Random number generator
To:

I had an idea about how to improve the random number generator in
DragonFlyBSD which I would like to share.

There is a bootstrapping problem where it is difficult to get enough
"entropy" at boot to ensure the random number generator is fully seeded and
completely unpredictable immediately after the system has booted.

Currently the random number generator seeds itself from nanotime() and
nanouptime() which introduces a small degree of entropy, but probably not
enough to ensure the above requirement is met.

So a possible improvement could be made by introducing more "entropy" at
initialisation from a high resolution timer like the TSC - rdtsc() (which is
also used in the random number generator - NANOUP_EVENT() - courtesy of
Matthew Dillon). That is my suggestion: Use rdtsc() aswell as nanotime() and
nanouptime() to ensure the random number generator has enough "entropy" at
boot to ensure it is fully seeded and completely unpredictable. If this were
done (and true) then you would not need the current ability of the random
number generator being able to be seeded from a file - an ability which
Matthew Dillon implemented to solve the boot-seeding problem.

I am wondering if there are any other high resolution timers available .....

tsc probably is the highest resolution timer; it should be available
on almost all of the modern system. HPET is a high frequency timer
(>10Mhz, but compared to tsc, it is quite low freq) and ACPI timer is
@~3Mhz. They depends on that acpi.ko is loaded, and they are
available relatively later than tsc.

Best Regards,
sephe

Actions #2

Updated by joerg almost 15 years ago

On Fri, May 08, 2009 at 07:47:46AM +0100, Robin Carey wrote:

So a possible improvement could be made by introducing more "entropy" at
initialisation from a high resolution timer like the TSC - rdtsc() (which is
also used in the random number generator - NANOUP_EVENT() - courtesy of
Matthew Dillon).

The high resolution timers are very likely already used and using
multiple time sources doesn't add much entropy as they are driven from
the same crystal in almost every system.

Joerg

Actions #3

Updated by dillon almost 15 years ago

We should already be doing it at system startup via
[/usr/src]/etc/rc.d/initrandom. In fact, we pipe the entire contents
of sysctl -a to /dev/random.

-Matt
Actions #4

Updated by tuxillo about 9 years ago

  • Description updated (diff)
  • Category set to Crypto
  • Status changed from New to Feedback
  • Assignee deleted (0)
  • Priority changed from Normal to Low
  • Target version set to 4.2

Hi Alex,

Do you know if this would this be still relevant?

Cheers,
Antonio Huete

Actions #5

Updated by alexh about 9 years ago

This has never been relevant. The only way to ensure the system starts up with (enough) entropy is to save some on shutdown. See ceccfc6bc7912b64fce4d4cd929eaf9346d00d53 for more details.

Actions #6

Updated by robin.carey1 about 9 years ago

Dear Alex & Antonio,

There is a way to provide enough "entropy" (unpredictable data) to the
in-Kernel CRNG, to ensure it has enough data to start producing
unpredictable random data.

When I say "enough" I am talking about a minimum of 128-bits.

On 15 January 2015 at 15:37, <> wrote:

Issue #1358 has been updated by alexh.

This has never been relevant. The only way to ensure the system starts up
with (enough) entropy is to save some on shutdown. See
ceccfc6bc7912b64fce4d4cd929eaf9346d00d53 for more details.

----------------------------------------
Bug #1358: Random number generator
http://bugs.dragonflybsd.org/issues/1358#change-12460

I had an idea about how to improve the random number generator in
DragonFlyBSD which I would like to share.

There is a bootstrapping problem where it is difficult to get enough
"entropy" at boot to ensure the random number generator is fully seeded and
completely unpredictable immediately after the system has booted.

Currently the random number generator seeds itself from nanotime() and
nanouptime() which introduces a small degree of entropy, but probably not
enough to ensure the above requirement is met.

So a possible improvement could be made by introducing more "entropy" at
initialisation from a high resolution timer like the TSC - rdtsc() (which
is
also used in the random number generator - NANOUP_EVENT() - courtesy of
Matthew Dillon). That is my suggestion: Use rdtsc() aswell as nanotime()
and
nanouptime() to ensure the random number generator has enough "entropy" at
boot to ensure it is fully seeded and completely unpredictable. If this
were
done (and true) then you would not need the current ability of the random
number generator being able to be seeded from a file - an ability which
Matthew Dillon implemented to solve the boot-seeding problem.

I am wondering if there are any other high resolution timers available
.....

---Files--------------------------------
unnamed (1.92 KB)

--
You have received this notification because you have either subscribed to
it, or are involved in it.
To change your notification preferences, please click here:
http://bugs.dragonflybsd.org/my/account

--
Sincerely,

Robin Carey BSc

Actions #7

Updated by robin.carey1 about 9 years ago

Dear Alex & Antonio,

I should qualify that last response by clarifying; without having to save
data to an "entropy file" on shutdown (or any other non-optimal solution).

I did exactly that, on FreeBSD, a long time ago. That code was the basis
for the CRNG that I submitted to Matthew Dillon, which he then ported to
DragonFlyBSD. Matthew did not like the method I was using, and so did not
use it. However, the rest of the code I submitted was used.

I think that was about 2006.

Since then I've considered my solution and refined it (on paper).

After all, the threshold for achieving unpredictable random operation
(CRNG) is only 128-bits (the size of data which makes a brute-force attack
untenable). Not a lot really.

On 15 January 2015 at 15:37, <> wrote:

Issue #1358 has been updated by alexh.

This has never been relevant. The only way to ensure the system starts up
with (enough) entropy is to save some on shutdown. See
ceccfc6bc7912b64fce4d4cd929eaf9346d00d53 for more details.

----------------------------------------
Bug #1358: Random number generator
http://bugs.dragonflybsd.org/issues/1358#change-12460

I had an idea about how to improve the random number generator in
DragonFlyBSD which I would like to share.

There is a bootstrapping problem where it is difficult to get enough
"entropy" at boot to ensure the random number generator is fully seeded and
completely unpredictable immediately after the system has booted.

Currently the random number generator seeds itself from nanotime() and
nanouptime() which introduces a small degree of entropy, but probably not
enough to ensure the above requirement is met.

So a possible improvement could be made by introducing more "entropy" at
initialisation from a high resolution timer like the TSC - rdtsc() (which
is
also used in the random number generator - NANOUP_EVENT() - courtesy of
Matthew Dillon). That is my suggestion: Use rdtsc() aswell as nanotime()
and
nanouptime() to ensure the random number generator has enough "entropy" at
boot to ensure it is fully seeded and completely unpredictable. If this
were
done (and true) then you would not need the current ability of the random
number generator being able to be seeded from a file - an ability which
Matthew Dillon implemented to solve the boot-seeding problem.

I am wondering if there are any other high resolution timers available
.....

---Files--------------------------------
unnamed (1.92 KB)

--
You have received this notification because you have either subscribed to
it, or are involved in it.
To change your notification preferences, please click here:
http://bugs.dragonflybsd.org/my/account

--
Sincerely,

Robin Carey BSc

Actions #8

Updated by alexh about 9 years ago

  • Status changed from Feedback to Rejected

The entropy file solution is absolutely standard (but was disabled for a long time on DragonFly), and one of the very few ways of ensuring enough entropy at boot time (without a hardware RNG, etc). It's rather sad that you think a high resolution timer is a valid way of achieving the same.

In any case, not really in the mood of arguing about this, so I'm closing this.

Actions

Also available in: Atom PDF