Re: E patches for review: ELoader, Scope.with, seedVat

Sorry to be slow replying. I have been out of town teaching and 
away from email.

On 5/20/10 at 8:15 AM, [email protected] (Mark Miller) wrote:

>On Thu, May 20, 2010 at 6:44 AM, Thomas Leonard <tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]> wrote:
>>For discussion:
>>
>>Can I remove ESecureRandom? "This class provides a cryptographically
>>strong random number generator based on user provided sources of entropy
>>and the MD5 hash algorithm." I'm guessing that the normal Java version
>>is pretty good these days - is there any reason why E needs its own
>>one?
>>
>>My particular reason for wanting to remove it is that the Java version
>>lets you request a lower-security configuration that's much faster for
>>testing, and I worry that the crypto stuff in E isn't actively
>>maintained.
>>
>
>I remember this came up at Electric Communities. Bill (cc'ed) did
>ESecureRandom. ESecureRandom wouldn't provide random bits until it could
>provide good ones. This led to longer startup times, which was frustrating
>during our rapid development cycle. Bill was repeatedly asked "We don't need
>high quality randomness during development. Can't you just give us a switch
>so that we can turn this off during development?" IIRC, Bill refused to
>provide a switch until we could build a development process that could
>ensure that this switch wouldn't accidentally be left on in the shipping
>product.
>
>Whether I remember this accurately or not (Bill?), it has become one of my
>favorite stories about the proper attitude to security during software
>development.

I don't remember the details, but I certainly would have been 
worried about development code in production releases.


>Are there any remaining vestiges of this switch? What was the means of
>ensuring that this switch was not left on in the shipping product? Although
>I love the story, I never did become familiar with the specifics.

As I remember, David Wagner has expertise in this space, so I 
have cced him.

Reading:
http://stackoverflow.com/questions/137212/how-to-solve-performance-problem-with-java-securerandom
I am now convinced that the Java secure random space is even 
more complex than it was when I was actively working on 
ESecureRandom. In those days, there was only one implementation.

The ESecureRandom implementation was designed for EC Habitats, a 
consumer application. As such, we wanted to deliver a system 
that was secure without any user-level choices. Hence we 
delivered only one implementation.

At that time, the Java SecureRandom implementation had a short 
internal state, and only seeded itself at startup. To improve 
security, we wanted a larger state and periodic reseeding. Since 
the attack on continuous reseeding with small amounts of random 
data had been published, we implemented a scheme which collected 
the short amounts of random data and then reseeded when "enough" 
of them had been collected.

The current implementation does not depend on external sources 
of randomness (e.g. dev/random), since they were not available 
on Windows 95. One way to speed up E startup, which IMHO would 
not compromise security would be to use one of them for seed 
material. If external sources are available on all our supported 
platforms, this is the way to go. In the edit-compile-test 
cycle, these sources should have had time to gather enough 
random data to be able to respond promptly. Making server 
startup fast is a different can of worms.

The whole area of seeding is fraught. The basic problem is that 
computers are designed to be specifically not random. (Actually 
unguessable is good enough for our purposes, but it is hard to 
see how to be unguessable without being random.) If we have a 
hardware source of random bits, as is present on some Intel 
chipsets, we are in luck. "All" we have to do if we are really 
paranoid is ensure that the hardware is still working correctly.

Since machines of the time did not have hardware random number 
sources, we attempted to use UI interactions for seeding 
ESecureRandom. (And anything else we could get our hands on.) 
The clock value when the event occurred was also included, since 
it would be very hard to guess the low-order bits. The more 
precision for the time the better.

Systems have also used disk timing, which is problamatic given 
solid state disks. Network event timing might be visible to an 
external observer. Etc. The whole area still gives me a headache.

I hope this babbling is useful.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Airline peanut bag: "Produced  | Periwinkle
(408)356-8506      | in a facility that processes   | 16345 
Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, 
CA 95032