Re: TRNGs and Firefox/TB

On Mon, Jan 2, 2017 at 12:34 PM, aweatherguy <[email protected]> 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?
>>
> 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
>>
>
>
>
>
> _______________________________________________
> dev-security mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security
>