by Dave Jones

[permalink] [raw]

Subject: Re: API for true Random Number Generators to add entropy (2.6.11)

On Thu, Mar 24, 2005 at 08:18:35AM +0100, Jan Engelhardt wrote:
>
> >Would you suggest making /dev/random point to /dev/hw_random then ?
>
> No. I for example do not have a hardware RNG, so `modprobe hw_random` fails
> with No Such Device. Making it a symlink would make it a dangling one.

It shouldn't be a symlink. Something like rngd should read from it
and feed it into /dev/random's entropy pool.

Dave

2005-03-24 11:54:55

by Evgeniy Polyakov

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote:
> Hi all,
>
> Here is a small patch for 2.6.11 that adds a routine:
>
> add_true_randomness(__u32 *buf, int nwords);
>
> so that true random number generator device drivers can add a entropy
> to the system. Drivers that use this can be found in the latest release
> of ocf-linux, an asynchronous crypto implementation for linux based on
> the *BSD Cryptographic Framework.
>
> http://ocf-linux.sourceforge.net/
>
> Adding this can dramatically improve the performance of /dev/random on
> small embedded systems which do not generate much entropy.

People will not apply any kind of such changes.
Both OCF and acrypto already handle all RNG cases - no need for any kind
of userspace daemon or entropy (re)injection mechanism.
Anyone who want to use HW randomness may use OCF/acrypto mechanism.
For example here is patch to enable acrypto support for hw_random.c
It is very simple and support only upto 4 bytes request, of course it
is
not interested for anyone, but it is only 2-minutes example:

--- ./drivers/char/hw_random.c.orig 2005-03-24 13:36:05.000000000 +0300
+++ ./drivers/char/hw_random.c 2005-03-24 14:48:30.470407432 +0300
@@ -34,6 +34,10 @@
#include <linux/smp_lock.h>
#include <linux/mm.h>
#include <linux/delay.h>
+#include <linux/acrypto.h>
+#include <linux/crypto_def.h>
+#include <linux/crypto_stat.h>
+#include <linux/highmem.h>

#ifdef __i386__
#include <asm/msr.h>
@@ -73,6 +77,8 @@
#endif

#define RNG_MISCDEV_MINOR 183 /* official */
+
+static DEFINE_SPINLOCK(rng_lock);

static int rng_dev_open (struct inode *inode, struct file *filp);
static ssize_t rng_dev_read (struct file *filp, char __user *buf, size_t size,
@@ -482,7 +488,6 @@
static ssize_t rng_dev_read (struct file *filp, char __user *buf, size_t size,
loff_t * offp)
{
- static DEFINE_SPINLOCK(rng_lock);
unsigned int have_data;
u32 data = 0;
ssize_t ret = 0;
@@ -526,7 +531,109 @@
return ret;
}

+#define CONFIG_ACRYPTO
+#ifdef CONFIG_ACRYPTO
+static struct crypto_device *hwr_cdev;
+static struct crypto_capability hwr_caps[] = {
+ {CRYPTO_OP_RNG, 0, 0, 100},
+};
+

+static void hwr_data_ready(struct crypto_device *dev)
+{
+ struct crypto_session *s, *n;
+ unsigned long flags;
+ u32 data = 0;
+ unsigned int have_data;
+ u8 *ptr, *optr;
+
+ local_irq_save(flags);
+ if (spin_trylock(&dev->session_lock)) {
+ local_irq_restore(flags);
+ return;
+ }
+
+ list_for_each_entry_safe(s, n, &dev->session_list, dev_queue_entry) {
+ if (!session_completed(s) && !session_is_processed(s)) {
+ start_process_session(s);
+ spin_lock(&rng_lock);
+ have_data = 0;
+ if (rng_ops->data_present()) {
+ data = rng_ops->data_read();
+ have_data = rng_ops->n_bytes;
+ }
+ spin_unlock (&rng_lock);
+
+ optr = ptr = kmap_atomic(s->data.sg_dst[0].page, KM_USER0) + s->data.sg_dst[0].offset;
+ while (s->data.sg_dst[0].length && have_data) {
+ *ptr++ = data & 0xff;
+ s->data.sg_dst[0].length--;
+ have_data--;
+ data >>= 8;
+ }
+ kunmap_atomic(optr, KM_USER0);
+
+ if (s->data.sg_dst[0].length)
+ broke_session(s); /* Need proper work deferring, see async_provider.c as example. */
+
+ crypto_stat_complete_inc(s);
+ crypto_session_dequeue_route(s);
+ complete_session(s);
+ stop_process_session(s);
+ }
+ }
+
+ spin_unlock(&dev->session_lock);
+ local_irq_restore(flags);
+}
+
+static int hwr_acrypto_init(struct rng_operations *ops)
+{
+ int err;
+
+ hwr_cdev = kmalloc(sizeof(*hwr_cdev), GFP_KERNEL);
+ if (!hwr_cdev) {
+ printk(KERN_ERR "Failed to allocate new crypto_device structure.\n");
+ return -ENOMEM;
+ }
+
+ memset(hwr_cdev, 0, sizeof(*hwr_cdev));
+
+ hwr_cdev->cap = hwr_caps;
+ hwr_cdev->cap_number = sizeof(hwr_caps)/sizeof(hwr_caps[0]);
+ hwr_cdev->priv = ops;
+ hwr_cdev->data_ready = &hwr_data_ready;
+ snprintf(hwr_cdev->name, sizeof(hwr_cdev->name), "%s", "hwr");
+
+ err = crypto_device_add(hwr_cdev);
+ if (err) {
+ kfree(hwr_cdev);
+ hwr_cdev = NULL;
+ return err;
+ }
+
+ printk(KERN_INFO "%s acrypto support is turned on.\n", hwr_cdev->name);
+
+ return err;
+}
+
+static void hwr_acrypto_fini(void)
+{
+ crypto_device_remove(hwr_cdev);
+ printk(KERN_INFO "%s acrypto support is turned off.\n", hwr_cdev->name);
+ kfree(hwr_cdev);
+ hwr_cdev = NULL;
+}
+#else
+static int hwr_acrypto_init(struct rng_operations *ops)
+{
+ return 0;
+}
+
+static void hwr_acrypto_fini(void)
+{
+}
+#endif

/*
* rng_init_one - look for and attempt to init a single RNG
@@ -549,9 +656,15 @@
goto err_out_cleanup_hw;
}

+ rc = hwr_acrypto_init(rng_ops);
+ if (rc)
+ goto err_out_misc_unregister;
+
DPRINTK ("EXIT, returning 0\n");
return 0;

+err_out_misc_unregister:
+ misc_deregister(&rng_miscdev);
err_out_cleanup_hw:
rng_ops->cleanup();
err_out:
@@ -617,6 +730,8 @@
{
DPRINTK ("ENTER\n");

+ hwr_acrypto_fini();
+
misc_deregister (&rng_miscdev);

if (rng_ops->cleanup)

So, one may use crypto_session_alloc(gimme_real_randomness) and that is
all
(either from userspace or kernelspace).
As far as I can see, OCF support is also very simple.

What I want to say, is that since OCF and acrypto already support
all RNG cases, it is better to port existing drivers to them, but
not the reverse.
That will allow to use both old hw_random.c driver and
any new one(HIFN, VIA, safenet, any other) without breaking any
interfaces from both userspace and kernelspace.

If one of the asynchronous crypto layers will be included,
/dev/random implementation can be changed to support it.

> Cheers,
> Davidm

--
Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2005-03-24 12:15:53

On Thu, 2005-03-24 at 07:48 -0500, Jeff Garzik wrote:
> Evgeniy Polyakov wrote:
> > On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote:
> >
> >>Hi all,
> >>
> >>Here is a small patch for 2.6.11 that adds a routine:
> >>
> >> add_true_randomness(__u32 *buf, int nwords);
> >>
> >>so that true random number generator device drivers can add a entropy
> >>to the system. Drivers that use this can be found in the latest release
> >>of ocf-linux, an asynchronous crypto implementation for linux based on
> >>the *BSD Cryptographic Framework.
> >>
> >> http://ocf-linux.sourceforge.net/
> >>
> >>Adding this can dramatically improve the performance of /dev/random on
> >>small embedded systems which do not generate much entropy.
> >
> >
> > People will not apply any kind of such changes.
> > Both OCF and acrypto already handle all RNG cases - no need for any kind
> > of userspace daemon or entropy (re)injection mechanism.
> > Anyone who want to use HW randomness may use OCF/acrypto mechanism.
> > For example here is patch to enable acrypto support for hw_random.c
> > It is very simple and support only upto 4 bytes request, of course it
> > is
> > not interested for anyone, but it is only 2-minutes example:
>
> If you want to add entropy to the kernel entropy pool from hardware RNG,
> you should use the userland daemon, which detects non-random (broken)
> hardware and provides throttling, so that RNG data collection does not
> consume 100% CPU.
>
> If you want to use the hardware RNG directly, it's simple: just open
> /dev/hw_random.
>
> Hardware RNG should not go kernel->kernel without adding FIPS tests and
> such.

hw_random can not and will not support HIFN, freescale, ixp and
great majority of the existing and future HW crypto devices.
I mean that userspace daemon(or any other one) which want to contribute
entropy
should use crypto framwork to obtain all it's data, but not different
access methods for each separate driver.

> Jeff

--
Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2005-03-24 13:24:10

by David McCullough

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Jivin Jeff Garzik lays it down ...
> Evgeniy Polyakov wrote:
> >On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote:
> >
> >>Hi all,
> >>
> >>Here is a small patch for 2.6.11 that adds a routine:
> >>
> >> add_true_randomness(__u32 *buf, int nwords);
> >>
> >>so that true random number generator device drivers can add a entropy
> >>to the system. Drivers that use this can be found in the latest release
> >>of ocf-linux, an asynchronous crypto implementation for linux based on
> >>the *BSD Cryptographic Framework.
> >>
> >> http://ocf-linux.sourceforge.net/
> >>
> >>Adding this can dramatically improve the performance of /dev/random on
> >>small embedded systems which do not generate much entropy.
> >
> >
> >People will not apply any kind of such changes.
> >Both OCF and acrypto already handle all RNG cases - no need for any kind
> >of userspace daemon or entropy (re)injection mechanism.
> >Anyone who want to use HW randomness may use OCF/acrypto mechanism.
> >For example here is patch to enable acrypto support for hw_random.c
> >It is very simple and support only upto 4 bytes request, of course it
> >is
> >not interested for anyone, but it is only 2-minutes example:
>
> If you want to add entropy to the kernel entropy pool from hardware RNG,
> you should use the userland daemon, which detects non-random (broken)
> hardware and provides throttling, so that RNG data collection does not
> consume 100% CPU.
>
> If you want to use the hardware RNG directly, it's simple: just open
> /dev/hw_random.
>
> Hardware RNG should not go kernel->kernel without adding FIPS tests and
> such.

For reference, the RNG on the Safenet I am using this with is
FIPS140 certified. I believe the HIFN part is also but I place the doc that
says so.

Cheers,
Davidm

--
David McCullough, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org

2005-03-24 13:40:54

On Thu, 2005-03-24 at 15:39 -0500, Jeff Garzik wrote:
> Evgeniy Polyakov wrote:
> > hw_random.c already does it using userspace daemons,
> > which is bad idea for very fast HW - like VIA xstore/xcrypt
> > instructions.
>
> This is incorrect, because it implies that a user would want to use the
> 'xstore' feature at full speed -- which would dominate the CPU,
> drastically slowing down the applications that are actually doing work.

If user want to get RNG data at full speed we do not want to allow it?
Something changed in the world...

User actually do not want to use xstore, but only read from /dev/random.

If kernelspace can assist and driver _knows_ in advance that data
produced is cryptographically strong, why not allow it directly
access pools?

> As I mentioned in another message, VIA xstore support should be removed
> from hw_random.c and moved completely to userspace rngd.
>
> Jeff
>
--
Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2005-03-25 04:28:13

On Thu, 2005-03-24 at 23:48 -0500, Jeff Garzik wrote:

> > And how HIFN driver can contribute entropy?
>
> Use the current chrdev->rngd method.

Why HIFN must be chardev?

> > You may say, that hardware can be broken and thus produces
> > wrong data, but if user want, it can turn it on or off.
>
> The user cannot know the data is bad unless it is constantly being
> validated.

The user can not use HW crypto processors, since he does not
know if HW is broken or not, and thus must validate each crypto
operation, i.e. reencrypt data in SW.

Not the point.

Validation can be performed in other HW
(like Xilinx which routes HW requests to the real devices),
or in driver (if it is not FIPS validation).

So I still insist on creating ability to contribute entropy directly,
without userspace validation.
It will be turned off by default.

> Jeff

--
Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2005-03-25 05:47:59

On Fri, 2005-03-25 at 00:58 -0500, Jeff Garzik wrote:
> Evgeniy Polyakov wrote:
> > So I still insist on creating ability to contribute entropy directly,
> > without userspace validation.
> > It will be turned off by default.
>
> If its disabled by default, then you and 2-3 other people will use this
> feature. Not enough justification for a kernel API at that point.

It is only because there are only couple of HW crypto devices
in the tree, with one crypto framework inclusion there will be
at least redouble.
Let's return to this discussion after it.

Thank you.

> Jeff
>
--
Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2005-03-25 06:29:08

by Evgeniy Polyakov

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

On Fri, 2005-03-25 at 17:13 +1100, Herbert Xu wrote:
> On Fri, Mar 25, 2005 at 09:16:01AM +0300, Evgeniy Polyakov wrote:
> > On Fri, 2005-03-25 at 00:58 -0500, Jeff Garzik wrote:
> >
> > > If its disabled by default, then you and 2-3 other people will use this
> > > feature. Not enough justification for a kernel API at that point.
> >
> > It is only because there are only couple of HW crypto devices
> > in the tree, with one crypto framework inclusion there will be
> > at least redouble.
>
> You missed the point. This has nothing to do with the crypto API.
> Jeff is saying that if this is disabled by default, then only a few
> users will enable it and therefore use this API.
>
> Since we can't afford to enable it by default as hardware RNG may
> fail which can lead to catastrophic consequences, there is no point
> for this API at all.

Currently implemented in-tree drivers(hw_random.c, do not have spec
about
VIA) do not perform any kind of validation, drivers created for
OCF/acrypto
have HW validated RNG.
Such hardware is used mostly in embedded world where SW crypto
processing
is too expensive, so users of such HW likely want to trust to
theirs hardware and likely will turn in on.
That would be even be a good idea to have two way of turning it on -
kernel config option and ioctl() one - to allow embedded systems
with too limited userspace not change it's applications.
Of course with big fat warning about possible dramatical consequences.

> Cheers,
--
Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachments:

by Evgeniy Polyakov

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

On Sat, 26 Mar 2005 10:47:45 +1100
Herbert Xu <[email protected]> wrote:

> On Fri, Mar 25, 2005 at 06:43:49PM -0500, Jeff Garzik wrote:
> >
> > In any case, it is the wrong solution to simply "turn on the tap" and
> > let the RNG spew data. There needs to be a limiting factor... typically
> > rngd should figure out when /dev/random needs more entropy, or simply
> > delay a little bit between entropy collection/stuffing runs.
>
> Completely agreed. Having it in rngd also allows the scheduler to
> do its job.

It looks like we all misunderstand each other -
why do you think that if there will be kernel <-> kernel
RNG dataflow, then system will continuously spent all
it's time to produce that data?
_Ability_ existence does not mean that only it must be used.
Userspace daemon should be able to turn it on or off,
but it is too expensive to allow it to be not only dataflow
controller, but the only random numbers dataflow initiator.

I can create following patch on top of rngd -
it will read from /dev/random, if read succeds too fast
(or even better just to check pool counts), then rngd
will turn HW RNG assist off and examine received data
to check if it is valid.
Later it can be turned on again.

> When applications need entropy from /dev/random and they can't get it,
> they'll simply block which allows rngd to run to refill the tank.

Such a blocking will be definitely a sign to turn
HW RNG assist on.

> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

2005-03-26 00:38:38

by Herbert Xu

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

On Sat, Mar 26, 2005 at 03:47:33AM +0300, Evgeniy Polyakov wrote:
>
> It looks like we all misunderstand each other -
> why do you think that if there will be kernel <-> kernel
> RNG dataflow, then system will continuously spent all
> it's time to produce that data?

It doesn't matter whether it's like that or not.

The point is if you do it in the kernel then either you'll have very
coarse controls over the rate of data coming out of the hardware RNG,
e.g., only on/off, or you'll have to put more code in to set the rate
appropriately.

Either way it's a loss compared to doing it in user-space.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2005-03-26 08:26:32

by Evgeniy Polyakov

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

On Sat, 26 Mar 2005 11:36:02 +1100
Herbert Xu <[email protected]> wrote:

> On Sat, Mar 26, 2005 at 03:47:33AM +0300, Evgeniy Polyakov wrote:
> >
> > It looks like we all misunderstand each other -
> > why do you think that if there will be kernel <-> kernel
> > RNG dataflow, then system will continuously spent all
> > it's time to produce that data?
>
> It doesn't matter whether it's like that or not.
>
> The point is if you do it in the kernel then either you'll have very
> coarse controls over the rate of data coming out of the hardware RNG,
> e.g., only on/off, or you'll have to put more code in to set the rate
> appropriately.

It is not the problem absolutely - just sleep if pool is full.
It will limit usage but this is better than nothing.

> Either way it's a loss compared to doing it in user-space.
>
>
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

2005-03-27 17:19:40

by Andi Kleen

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

> We -used- to need data from RNG directly into the kernel randomness

Are you sure? I dont think there was ever code to do this in
mainline. There might have been something in -ac*, but not mainline.

> pool. The consensus was that the FIPS testing should be moved to userspace.

Consensus from whom? And who says the FIPS testing is useful anyways?

I think you just need to trust the random generator, it is like
you need to trust any other piece of hardware in your machine. Or do you
check regularly if you mov instruction still works? @)

I think it is a trade off between easy to use and saving of
resources and overly paranoia. With an user space solution
which near nobody uses currently (I am not aware of
any distribution that runs that daemon)
it means most people wont have hardware supported randomness
in their ssh, and I think that is a big drawback.

Also I dont like the memory consumption of the daemon. It needs
at least 20+k for kernel stack, page tables etc. I know
a lot of people dont care about memory usage anymore, but I still
do. It is not a lot of memory, but bloat does usually not come in big
pieces but in small amounts of a time. And the code to do it
from kernel space is really simple.

And it would suddenly make a lot of peoples ssh/https etc. more secure,
which is a good thing. Probably would help Linux security a lot
more than all these crazy - "ABI, what ABI?" - buffer overflow
workarounds.

If you are really paranoid you can always turn off the sysctl
and do it from userspace.

-Andi

2005-03-27 18:55:30

On Tue, 2005-03-29 at 20:30 +1000, Herbert Xu wrote:
> On Tue, Mar 29, 2005 at 12:21:04PM +0200, Pavel Machek wrote:
> >
> > What catastrophic consequences? Noone is likely to even *notice*, and
> > it does not help practical attack at all. Unless hardware RNGs are
> > *very* flakey (like, more flakey than harddrives), this is not a problem.
>
> The reason some people use hardware RNGs in the first place is because
> they don't trust the software RNGs. When the hardware RNG fails but
> continues to send data to /dev/random, /dev/random essentially degenerates
> into a software RNG. Now granted /dev/random is a pretty good software
> RNG, however, for some purposes it just isn't good enough.

I think the most people use hardware accelerated devices to
speed up theirs calculations - embedded world is the best example -
applications that are written to use /dev/random
will work just too slow, so hardware vendors
place HW assistant chips to unload that very cpu-intencive work
from main CPU.
Without ability speed this up in kernel, we completely [ok, almost]
loose all RNG advantages.

--
Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2005-03-29 10:48:15

by Herbert Xu

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

On Tue, Mar 29, 2005 at 12:38:01PM +0200, Pavel Machek wrote:
>
> It seems to me that people wanting this level of assurance should do
> their own FIPS (or whatever) tests.

That's exactly what the current scheme of driver + rngd allows you
to do. For those that require high assurance, they can let rngd
do the checks. Otherwise they can disable the checks and just let
rngd feed data from /dev/hw_random into /dev/random.

It's not just about the quality checks. It's also about deciding the
rate at which data should be fed into /dev/random.

Feeding too much means that you might be wasting system resources
(CPU/PCI bus/etc.). Feeding too little means that /dev/random users
may block unnecessarily.

Doing the feeding in a process means that you can feed exactly the
right amount. You feed only when the /dev/random's pool is depleted
and you feed exactly the amount of data that is needed to replenish
the pool.

> Interrupts are not totally unpredictable, either, yet noone runs FIPS

I haven't looked at this but if that's the case we might want to
look at lowering the entropy count for that.

> > Someone else raised the example of Casinos using hardware RNGs. Some
> > of them are doing this to comply with government regulation. In that
> > case, using data from the software RNG when the hardware has failed
> > would be violating the law.
>
> Well, you are still using hardware RNG, but failed one. I do not see
> how you can break law with that... given that hardware RNG had proper
> certification in the first place.

Actually in the scheme proposed in this thread the hardware RNG could
be feeding a stream of zeros into /dev/random which means that the
/dev/random user will be using a software RNG.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2005-03-29 10:52:08

by Herbert Xu

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

On Tue, Mar 29, 2005 at 02:50:28PM +0400, Evgeniy Polyakov wrote:
>
> Without ability speed this up in kernel, we completely [ok, almost]
> loose all RNG advantages.

Well if you can demonstrate that you're getting a higher rate of
throughput from your RNG by doing this in kernel space vs. doing
it in user space please let me know.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2005-03-29 10:56:59

by Martin Mares

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Hello!

> We trust hardware, anyway. Like your disk *could* accidentaly turn on
> setuid bit on /bin/bash, and we do not insist on userspace
> disk-validator.

But there is a very important difference: the most likely (both in theory
and practice) failure of a disk is clearly visible, while failures of HW RNG's
are likely to be silent (the data are just less random than they should be).

Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Top ten reasons to procrastinate: 1.

2005-03-29 11:37:05

On Tue, 2005-03-29 at 21:39 +1000, Herbert Xu wrote:
> On Tue, Mar 29, 2005 at 03:42:05PM +0400, Evgeniy Polyakov wrote:
> > On Tue, 2005-03-29 at 20:46 +1000, Herbert Xu wrote:
>
> > > Well if you can demonstrate that you're getting a higher rate of
> > > throughput from your RNG by doing this in kernel space vs. doing
> > > it in user space please let me know.
> >
> > While raw bits reading from hw_random on the fastest
> > VIA boards can exceed 55mbits per second
> > [above quite was taken from VIA C3 Nehemiah analysis],
> > it is not evaluated in rngd and is not written
> > back to the /dev/random.
>
> Well when you get 55mb/s from /dev/random please get back to me.

I cant, noone writes 55mbit into it, but HW RNG drivers could. :)

--
Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2005-03-29 12:18:14

by Pavel Machek

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Hi!

> > > > Well if you can demonstrate that you're getting a higher rate of
> > > > throughput from your RNG by doing this in kernel space vs. doing
> > > > it in user space please let me know.
> > >
> > > While raw bits reading from hw_random on the fastest
> > > VIA boards can exceed 55mbits per second
> > > [above quite was taken from VIA C3 Nehemiah analysis],
> > > it is not evaluated in rngd and is not written
> > > back to the /dev/random.
> >
> > Well when you get 55mb/s from /dev/random please get back to me.
>
> I cant, noone writes 55mbit into it, but HW RNG drivers could. :)

Exactly, on via machines, it might be good idea to hook /dev/random
directly to hardware random generator... that should give you
55mbit/sec.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-29 12:46:05

by Herbert Xu

[permalink] [raw]

Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

On Tue, Mar 29, 2005 at 04:15:17PM +0400, Evgeniy Polyakov wrote:
> > > On Tue, 2005-03-29 at 20:46 +1000, Herbert Xu wrote:
> >
> > > > Well if you can demonstrate that you're getting a higher rate of
> > > > throughput from your RNG by doing this in kernel space vs. doing
> > > > it in user space please let me know.
>
> > Well when you get 55mb/s from /dev/random please get back to me.
>
> I cant, noone writes 55mbit into it, but HW RNG drivers could. :)

Are you intending to feed that into /dev/random at 55mb/s?

If not then how is this an argument against doing it in userspace
through rngd?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2005-03-29 13:06:15

[permalink] [raw]

Subject: Re: [PATCH] API for TRNG (2.6.11) [Fortuna]

Patch attached.

JLC

On Thu, Mar 31, 2005 at 08:58:22AM -0500, Jean-Luc Cooke wrote:
> On Thu, Mar 31, 2005 at 01:52:14PM +1000, David McCullough wrote:
> >
> > Jivin Jeff Garzik lays it down ...
> > ...
> > > >If kernelspace can assist and driver _knows_ in advance that data
> > > >produced is cryptographically strong, why not allow it directly
> > > >access pools?
> > >
> > > A kernel driver cannot know in advance that the data from a hardware RNG
> > > is truly random, unless the data itself is 100% validated beforehand.
> >
> > You can also say that it cannot know that data written to /dev/random
> > is truly random unless it is also validated ?
> >
> > For argument you could just run "cat < /dev/hwrandom > /dev/random"
> > instead of using rngd.
> >
> > If /dev/random demands a level of randomness, shouldn't it enforce it ?
> >
> > If the HW is using 2 random sources, a non-linear mixer and a FIPS140
> > post processor before handing you a random number it would be nice to
> > take advantage of that IMO.
>
>
> For those who are interested, my Fortuna patch to the Linux RNG (/dev/random,
> /dev/urandom) is available here (2.6.12-rc1, works on kernels as low as
> 2.6.11.4):
> http://jlcooke.ca/random/
>
> Fortuna is a Cryptographically Secure Random Number Generator (CSRNG)
> developed by Neils Ferguson and Bruce Schnier and published in their book
> Applied Cryptography.
>
> By most regards, it is the state of the art as far as software based CSRNGs
> go. The website gives an over view of the design, here is a summary:
> Fortuna uses a block cipher (AES128) in CTR mode to generate output.
> Fortuna uses a 32 hash states (SHA-256) which collect event data from
> sources of randomness (as usual in Linux).
> Once every 0.1sec or so, some of the hash states are finalised and the
> digests are collected.
> These digests are hashed together with with the current block cipher key to
> produce the new block cipher key.
>
> Ferguson goes into detail in Practical Cryptography as to why this design is
> superior to Yarrow based RNG (like the existing Linux RNG) and also delves
> into why entropy estimation is impossible and is infact a liability in RNG
> design.
>
> My patch keep the entropy estimation from the current Linux RNG since this is
> a very controversial issue with most people. Disabling entropy estimation
> and /dev/random blocking can be done by changing the RANDOM_NO_ENTROPY_COUNT
> macro to 1.
>
> I have not tested the syncookie code yet. But networking works smoothly
> after I echo "1" to /proc/sys/net/ipv4/tcp_syncookies. Any help on this
> would be great.
>
> JLC
> _______________________________________________
>
> Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi
> List archive: http://lists.logix.cz/pipermail/cryptoapi

Attachments:

(No filename) (2.77 kB)
fortuna-random-2.6.11.4.patch (63.77 kB)
Download all attachments