88847 - Implement buffered entropy collection and on-demand entropy feeding

Status: RESOLVED INVALID

(Core Graveyard :: Security: UI, defect, P3)

Description

[Stephane Saux]

From Nelson Bolyard:
What about the buffered entropy collector design?
We had it in PSM 1.x.
It took Mark Welch about a day (or less) to implement.
It decouples the cost of collection from the cost of processing and
reduces the cost of processing (N collections per processing event).

(see bug 82941)

Comment 1

[John Unruh]

Mass assigning QA to ckritzer.

Comment 2

[Stephane Saux]

Move to future. Won't have time to fix these for 2.1

Comment 3

[Kai Engert (:KaiE:)]

How would a buffered entropy collector work?

But
- who would keep the buffer, would that be PSM's job?
- what event would trigger transfering bytes from the buffer to NSS?

If the idea is that entropy should be available on demand, as the crypto
requires it, would be it a good idea, if NSS would itself do the buffering? It
could eat entropy bytes whenver it seems it is appropriate.

Comment 4

[Kai Engert (:KaiE:)]

I had a chat with Nelson, and I now understand better what he suggested.


Whenever entropy data is feeded to NSS, it takes CPU time.
If entropy gets feeded to NSS each time we obtain it, this results in a slow
application.
Because of that, we are not feeding any events, but only every 100th mouse event.

The idea of "buffering entropy" is to optimize performance, while collecting all
possible entropy:

PSM should collect entropy in its own simple data structure.
Whenever entropy data is obtained from the system (every mouse move, every
keyboard hit, etc.), it is given to PSM. Storing that data into a small data
structure should be a very cheap operation.

Feeding entropy from PSM to NSS should be done on demand when high level crypto
operations are about to begin. This is something NSS can not decide. PSM needs
to decide.

Examples for high crypto operations are:
- a new SSL session is about to start
- a new S/Mime message
- a new encrypted password
- a new private key

We would need to be careful to not overlook high level crypto operations being
done in PSM, and add the entropy forwarding whenever it is approriate.

The rationale behind this is:
- no noticeable performance drawback during entropy collection
- be able to use all entropy
- do the actual entropy processing at a time a crypto operation will be done,
when the user has to wait anyway


(While with bug 75947 we implemented a class that is called buffering entropy
collector, it is something different. The buffering done with 75947 was just a
pre-buffering, to enable entropy collection even if NSS did not yet start up.
The buffering will not be used as soon as NSS is loaded.)

Comment 5

[Lapo Luchini]

What about the Yarrow design by Bruce Schneier (or even better, Yarrow's
descendant: Fortuna)?

The basic idea is that entropy is not "buffered" but accumulated in a pool, by
hashing itin , something like "pool = SHA256(pool, new_value)".
This way no big buffer is needed and a single hash round is very fast: e.g. the
entropy gathering is a fast operation.

See full paper at http://www.schneier.com/yarrow.html
http://th.informatik.uni-mannheim.de/people/lucks/papers/Ferguson/Fortuna.pdf

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Mass reassign Javi's old PSM bugs to nobody

Comment 7

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

We removed the entropy collection system because we rely on the OS for randomness now.