Happy New Year!

[aweatherguy]

Best wishes to all in 2017!

I'm new to the list and have a very narrow topic to inquire about. I've
been working on an inexpensive TRNG (True Random Number Generator) and
am interested in having Firefox/Thunderbird use this as a source for TLS
key generation, instead of the built-in PRNG (Pseudo-Random Number
Generator).

I seem to have custom builds of both Firefox and Thunderbird working
with the TRNG now. The changes were pretty small and easy. What I'm
wondering is if anyone on this list would be interested in integrating
this capability into these products. Or maybe this is beyond the scope
of your products?

I'm sure that one pre-requisite is cost. The TRNG is an off-the-shelf
Arduino Uno -- meaning the hardware is withing financial reach of most
folks. The Arduino firmware could be open-source (probably GPL). If
you're wondering, I'm not associated with Arduino in any way and would
not benefit financially were this idea to become popular.

I've avoided including much detail here as this is just an initial
inquiry to gauge your interest.

Cheers,

aweatherguy

[Martin Heaps]

On Sunday, 1 January 2017 01:29:33 UTC, aweatherguy wrote:
> Best wishes to all in 2017!
>
> I'm new to the list and have a very narrow topic to inquire about. I've
> been working on an inexpensive TRNG (True Random Number Generator) and
> am interested in having Firefox/Thunderbird use this as a source for TLS
> key generation, instead of the built-in PRNG (Pseudo-Random Number
> Generator).
>

My first reaction is that an inexpensive TRNG is a bit like building a cheap skyscrapper. Yes it can exist, but it will not be of great benefit due to the shortcoming required to make it "inexpensive".

1) How will you know the numbers generated are truly random?

2) There is a point of view that truly random numbers are impossible, as one a tiny subset of numbers are truly random and therefore they are more predictable than Pseudo-random. This is (if memory serves me) a basis of Chaos Theory (that chaos is predictable because it's not predictable).

> I seem to have custom builds of both Firefox and Thunderbird working
with the TRNG now. The changes were pretty small and easy

If changes were 'small and easy' have you considered if there's a reason why someone else has not already done this?

[iang]

The problem of random numbers is vexing and complicated because it is
intensely cross-domain. From the perspective of one domain (hardware?),
it seems easy. But there are other issues that bite in other domains,
rendering an "obvious" solution useless.

To OP's suggestion, a hardware solution is practically useless for
application software unless the OS is fixed. With FF/Tb etc, this isn't
the case.

The right place to solve the RN issue is in the OS. Linux, etc. As far
as the application (FF/Tb/etc) is concerned, the random numbers should
be sourced from the platform, and they should punt the entire problem to
the platform [1].

That's not to say it's uninteresting - it's an intensely interesting
problem. But the problem is so intricate that it is taking us a while
to figure out where to place the components. From the position of a
hardware supplier of RNG devices, what you want is to write the RNs into
/dev/random.

Going forward, it would be nice if there were a standard way for a RN to
pop up on the bus and announce its ability to deliver RNs. That would
make the path so much more obvious. But for that to happen we probably
have to go through a Cambrian explosion of generators.

iang

[1] http://iang.org/ssl/hard_truths_hard_random_numbers.html

On 31/12/2016 20:28, aweatherguy wrote:
> Best wishes to all in 2017!
>
> I'm new to the list and have a very narrow topic to inquire about.
> I've been working on an inexpensive TRNG (True Random Number
> Generator) and am interested in having Firefox/Thunderbird use this as
> a source for TLS key generation, instead of the built-in PRNG
> (Pseudo-Random Number Generator).
>

> I seem to have custom builds of both Firefox and Thunderbird working

> with the TRNG now. The changes were pretty small and easy. What I'm
> wondering is if anyone on this list would be interested in integrating
> this capability into these products. Or maybe this is beyond the scope
> of your products?
>
> I'm sure that one pre-requisite is cost. The TRNG is an off-the-shelf
> Arduino Uno -- meaning the hardware is withing financial reach of most
> folks. The Arduino firmware could be open-source (probably GPL). If
> you're wondering, I'm not associated with Arduino in any way and would
> not benefit financially were this idea to become popular.
>
> I've avoided including much detail here as this is just an initial
> inquiry to gauge your interest.
>
> Cheers,
>
> aweatherguy
>
>

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security

[iang]

Just to respond to some of these points because you raise good
questions, but thinking has moved on in the last decade or so.

On 02/01/2017 08:22, Martin Heaps wrote:
> On Sunday, 1 January 2017 01:29:33 UTC, aweatherguy wrote:

>> Best wishes to all in 2017!
>>
>> I'm new to the list and have a very narrow topic to inquire about. I've
>> been working on an inexpensive TRNG (True Random Number Generator) and
>> am interested in having Firefox/Thunderbird use this as a source for TLS
>> key generation, instead of the built-in PRNG (Pseudo-Random Number
>> Generator).
>>

> My first reaction is that an inexpensive TRNG is a bit like building a cheap skyscrapper. Yes it can exist, but it will not be of great benefit due to the shortcoming required to make it "inexpensive".
>
> 1) How will you know the numbers generated are truly random?
>
> 2) There is a point of view that truly random numbers are impossible, as one a tiny subset of numbers are truly random and therefore they are more predictable than Pseudo-random. This is (if memory serves me) a basis of Chaos Theory (that chaos is predictable because it's not predictable).

We don't (any more) think about random numbers. What we think about is
numbers that are unknown to the adversary. This solves a number of
issues due to the sort of rabbit holes you outline. It's a much more
practical engineering challenge to find numbers unknown to an adversary.

Now, perversely, given your above skyscraper comment, it turns out that
the go-to solution for numbers unknown to the adversary is several
cheap&dirty generators that are mixed then whitened. E.g., take 64 bytes
from 3 different independent crappy sources, concatenate them, feed them
as a key into a stream cipher. Done.

>> I seem to have custom builds of both Firefox and Thunderbird working

> with the TRNG now. The changes were pretty small and easy
>
> If changes were 'small and easy' have you considered if there's a reason why someone else has not already done this?

Yup - Mozilla's meme is not to resolve the RN issue but to put pressure
on the platforms to do so.

iang

[aweatherguy]

First of all, thanks for the replies. I was left out details about the
TRNG because I wanted to find out if there was any interest at all in
doing this. Sounds like there ***might*** be...if the TRNG is really a
good one.

There are really two topics here:

1) Presuming the TRNG is a good one, is there and interest and/or does
it make sense for FF/TB?

2) Is my TRNG idea any good?

I think iang hit the nail on the head with his point about
standardization. If TRNGs were to become cheap and widely available,
there would need to be some common, secure, cross-platform method to
integrate them into all OS's.

As a retired EE engineer, I think (2) is by far the more fascinating
topic and would enjoy discussing this here as long as it is within the
scope of this mailing list. However, I also realize that a great idea is
worthless if nobody want to use it. That's why I'm inquiring about
interest in using it.

I will send second e-mail describing why I think the TRNG might be good.

Notice I'm claiming that it might be good...not that it IS good ;-)

On 1/2/2017 5:22 AM, Martin Heaps wrote:
> My first reaction is that an inexpensive TRNG is a bit like building a cheap skyscrapper. Yes it can exist, but it will not be of great benefit due to the shortcoming required to make it "inexpensive".
>
> 1) How will you know the numbers generated are truly random?
>
> 2) There is a point of view that truly random numbers are impossible, as one a tiny subset of numbers are truly random and therefore they are more predictable than Pseudo-random. This is (if memory serves me) a basis of Chaos Theory (that chaos is predictable because it's not predictable).
>

>> I seem to have custom builds of both Firefox and Thunderbird working

> with the TRNG now. The changes were pretty small and easy
>
> If changes were 'small and easy' have you considered if there's a reason why someone else has not already done this?

The changes only require a way to obtain numbers from the TRNG inside
FF/TB -- specifically I have modified the
RNG_GenerateGlobalRandomBytes() function in drbg.c file in the NSS
package to first attempt obtaining data from the TRNG before serving up
a PRNG from the default generator.

Currently, FF/TB are obtaining TRNG data from a TCPIP socket on
localhost (127.0.0.1) but that could be changed to a named pipe, direct
I/O or something else quite easily. I felt that a TCPIP socket was more
general purpose and allows multiple simultaneous clients to get data.
Obviously, there is also server process running on the computer which
obtains data from TRNG hardware and makes it available over a TCPIP socket.

I would think that the reason nobody has done this before is that cheap
TRNGs are not widely available. An option for TRNG in FF/TB is of little
interest to most if it requires an expensive/hard to get piece of hardware.

On 1/2/2017 8:20 AM, iang wrote:
> The problem of random numbers is vexing and complicated because it is
> intensely cross-domain. From the perspective of one domain
> (hardware?), it seems easy. But there are other issues that bite in
> other domains, rendering an "obvious" solution useless.
>
> To OP's suggestion, a hardware solution is practically useless for
> application software unless the OS is fixed. With FF/Tb etc, this
> isn't the case.

Not sure I get your point...why is it useless for most apps but not
FF/TB? Perhaps you're just saying that w/o a standardized interface,
most apps could not use a TRNG...not so w/open source apps?

>
> The right place to solve the RN issue is in the OS. Linux, etc. As
> far as the application (FF/Tb/etc) is concerned, the random numbers
> should be sourced from the platform, and they should punt the entire
> problem to the platform [1].

That's why I thought of using a TCPIP socket on localhost. That's a
cross-platform concept and it could be standardized. Most platforms
could support a TRNG on a mutually agreed-upon port number. It's just
like /dev/random but with sockets instead.

>
> That's not to say it's uninteresting - it's an intensely interesting
> problem. But the problem is so intricate that it is taking us a while
> to figure out where to place the components. From the position of a
> hardware supplier of RNG devices, what you want is to write the RNs
> into /dev/random.

The question with sockets is...is it safe? Data sent from localhost to
localhost should not appear on any wires outside the computer box...I
suspect...but don't know for sure. But perhaps one could still spy on
the data with Wireshark or some malware?

>
> Going forward, it would be nice if there were a standard way for a RN
> to pop up on the bus and announce its ability to deliver RNs. That
> would make the path so much more obvious. But for that to happen we
> probably have to go through a Cambrian explosion of generators.
>

So, what do you think about using TCPIP sockets? What other
communication facilities are cross-platform that could be used?
> iang

[aweatherguy]

Some of this matches what I have been thinking and working on:

On 1/2/2017 8:36 AM, iang wrote:
>
> We don't (any more) think about random numbers. What we think about
> is numbers that are unknown to the adversary. This solves a number of
> issues due to the sort of rabbit holes you outline. It's a much more
> practical engineering challenge to find numbers unknown to an adversary.

I ***think*** that's what I'm getting from my supposedly TRNG. A source
with true but polluted random content is the starting point.

>
> Now, perversely, given your above skyscraper comment, it turns out
> that the go-to solution for numbers unknown to the adversary is
> several cheap&dirty generators that are mixed then whitened. E.g.,
> take 64 bytes from 3 different independent crappy sources, concatenate
> them, feed them as a key into a stream cipher. Done.
>

Amazing coincidence (or maybe not). That's exactly what I'm doing in the
TRNG, using chacha20. The host computer (e.g. Windows in this case)
server process that serves data over TCPIP sockets is already written to
use any number of Uno's on input and it just merges the data as it comes
in. There's no fixed pattern to the merging and that's more randomness
because each Uno's clock runs at a different and unpredictable rate.

So there's your multiple crappy sources...except the merge happens on
the output of the cipher instead of input. This has the benefit that
none of the cipher state ever leaves the Atmel processor's RAM and is
pretty much impossible to spy on.

I have spent a fair amount of effort so far figuring out exactly what is
being measured to generate these so-called crappy random values being
fed into the stream cipher. It is easy to show that you would not want
to use that data directly.

While there is still a lot of work to do (mostly analysis), the results
so far are encouraging. If you are interested I can share some more
technical ramblings regarding the TRNG's operation.

To date, I have generated 5GB by merging the outputs from four Uno TRNGs
running for about 2 weeks. It passes all of the dieharder tests. I will
note that 5GB is not enough for all of those tests but suffices for the
majority of them.

>>> I seem to have custom builds of both Firefox and Thunderbird working

>> with the TRNG now. The changes were pretty small and easy
>>
>> If changes were 'small and easy' have you considered if there's a
>> reason why someone else has not already done this?
>

> Yup - Mozilla's meme is not to resolve the RN issue but to put
> pressure on the platforms to do so.

Sounds like a chicken/egg sort of thing....except the real egg I guess
is the TRNG vendor. W/o a supply of good/cheap TRNGs nobody has any
incentive to do anything. Any chance a widely accepted solution using an
Arduino for $35 bucks might be enough of an incentive...? But...then you
need at least one popular app to support it before people will buy an
Uno for that purpose...chicken/egg again.

[Eric Rescorla]

On Mon, Jan 2, 2017 at 12:34 PM, aweatherguy <ws...@osengr.org> wrote:

> First of all, thanks for the replies. I was left out details about the
> TRNG because I wanted to find out if there was any interest at all in doing
> this. Sounds like there ***might*** be...if the TRNG is really a good one.
>
> There are really two topics here:
>
> 1) Presuming the TRNG is a good one, is there and interest and/or does it
> make sense for FF/TB?
>

Firefox (which in this case NSS) uses a cryptographic PRNG which it seeds
from the operating
system. If we were to use something like this, we would do so as a source
of seed material
for the existing PRNG, and the easiest way for that to happen would be if
it were simply integrated
into the OS so that when we asked the OS for randomness, your entropy was
mixed in. It's
in principle possible to add a new NSS PKCS#11 token that would just
support your TRNG,
but I do not believe that that's something we would ship with Firefox [0].

The bottom line is that I don't think there's much to do here on the
Firefox side.

In terms of getting feedback on your design, this probably isn't the best
place for that as
this list is primarily dedicated to discussing Mozilla software.

-Ekr

[0] An OS vendor could choose to ship that token with their OS, but if they
did that, why not
just merge it into the OS randomness system.

2) Is my TRNG idea any good?
>
> I think iang hit the nail on the head with his point about
> standardization. If TRNGs were to become cheap and widely available, there
> would need to be some common, secure, cross-platform method to integrate
> them into all OS's.
>
> As a retired EE engineer, I think (2) is by far the more fascinating topic
> and would enjoy discussing this here as long as it is within the scope of
> this mailing list. However, I also realize that a great idea is worthless
> if nobody want to use it. That's why I'm inquiring about interest in using
> it.
>
> I will send second e-mail describing why I think the TRNG might be good.
>
> Notice I'm claiming that it might be good...not that it IS good ;-)
>
>
> On 1/2/2017 5:22 AM, Martin Heaps wrote:
>
>> My first reaction is that an inexpensive TRNG is a bit like building a
>> cheap skyscrapper. Yes it can exist, but it will not be of great benefit
>> due to the shortcoming required to make it "inexpensive".
>>
>> 1) How will you know the numbers generated are truly random?
>>
>> 2) There is a point of view that truly random numbers are impossible, as
>> one a tiny subset of numbers are truly random and therefore they are more
>> predictable than Pseudo-random. This is (if memory serves me) a basis of
>> Chaos Theory (that chaos is predictable because it's not predictable).
>>

>> I seem to have custom builds of both Firefox and Thunderbird working
>>>

>> with the TRNG now. The changes were pretty small and easy
>>
>> If changes were 'small and easy' have you considered if there's a reason
>> why someone else has not already done this?
>>

[aweatherguy]

Eric,

Thanks for the reply. This is what I was really trying to find out.

I just have one question out of curiosity:

Why wouldn't you use the TRNG stream for all of the random numbers,
instead of seeding a PRNG with it? My interest in this stems from
revelations of broken PRNGs deliberately inserted by government agencies
into widely accepted standards. The result is mistrust in PRNGs in
general and the TRNG would solve that problem.

Again -- just a question out of curiosity. Thanks for taking the time to
reply to my inquiries.

>>> I seem to have custom builds of both Firefox and Thunderbird working