48258 - use NSPR to get random noise from machine

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect, P3)

Description

[Ian McGreer]

NSPR has incorporated the machine-specific code used by NSS to obtain random
noise.  NSS should remove the *rand.c files from lib/util and use NSPR calls.

Comment 1

[Ian McGreer]

moving to 3.2.

Comment 2

[Wan-Teh Chang]

Ian, do you not have time to work on this
in 3.1?

Comment 3

[Ian McGreer]

In looking at this bug, I found that I need to implement three functions:
1.  RNG_GetNoise
2.  RNG_SystemInfoForRNG
3.  RNG_FileForRNG

(1) has a corresponding function in NSPR that can be called (PR_GetRandomNoise),
and (3) can easily be written in a cross-platform manner using NSPR.  However,
there is no way to do (2) through NSPR.  I'm looking for suggestions on how to
proceed.  I see the following options:

1.  keep the *rand.c files in lib/util and their implementations of
RNG_SystemInfoForRNG, but remove implementations of RNG_GetNoise and
RNG_FileForRNG, and provide those two functions elsewhere in a cross-platform
manner using NSPR.

2.  Write all of the functions using NSPR, and have NSPR incorporate the
functionality of RNG_SystemInfoForRNG.

3.  Test the viability of PR_GetRandomNoise supplying all of the needed entropy,
and simply have RNG_SystemInfoForRNG call that function.  I personally have
found that RNG_SystemInfoForRNG does not always provide a great deal of entropy,
but then again every little bit counts.

Suggestions?

Comment 4

[Wan-Teh Chang]

I vote for option #1.

Comment 5

[Wan-Teh Chang]

#3 sounds like a good idea, but I don't know
what RNG_SystemInfoForRNG does so I can't decide
whether that function belongs in NSPR.  So I
suggest that we implement option #1 first.

Another problem that we should fix is that
sysrand.c #include's those *_rand.c files
but this dependency of sysrand.c on *_rand.c
is not known to the makefile.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I would ask Lord for input on this decision.  The decision to put 
the GetNoise functions into NSPR was his.  I don't understand why
he wanted to move only the GetNoise functions and not the others,
also.  So, if I were you, I'd ask him.

Comment 7

[Wan-Teh Chang]

Set target milestone 4.0.

Comment 8

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 9

[Wan-Teh Chang]

In bug 131171, I asked:
> By the way, I think it is a good idea to move ret_cr16.s
> to lib/freebl as well.  It is only used by unix_rand.c,
> which has been moved to lib/freebl.

Nelson responded:
> Once upon a time, we were directed to move all machine/platform dependent
> PRNG code into NSPR.  Since then, NSPR has contained a copy of code used
> to initialize the PRNG, but NSS retained its own copy also, and NSS has 
> never been switched to use NSPR's versions of these functions.  
>
> I think we ought to either use NSPR's versions of these, or remove them 
> from NSPR.  Because of our historical reluctance to use NSPR in PKCS#11
> modules, I'd guess we'll end up removing them from NSPR.

I can't remove NSPR's versions of these PRNG functions until the
next NSPR major release (5.0).

Bob, is the PRNG code only used in the softoken?  If so, NSS
should be able to use NSPR's PRNG functions.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Giving this bug to Neil, who's looking at this code right now.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

I guess we've decided it's better to continue to keep the code that gathers
entropy for the PKCS#11 softoken in NSS itself, because that keeps all the
code that must be FIPS evaluated in NSS.  

-> WONTFIX