[e-lang] E patches for review: ELoader, Scope.with, seedVat
frantz at pwpconsult.com
Wed May 26 22:45:24 PDT 2010
Sorry to be slow replying. I have been out of town teaching and
away from email.
On 5/20/10 at 8:15 AM, erights at gmail.com (Mark Miller) wrote:
>On Thu, May 20, 2010 at 6:44 AM, Thomas Leonard <tal at it-innovation.soton.ac.uk> wrote:
>>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
>>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
>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
>Whether I remember this accurately or not (Bill?), it has become one of my
>favorite stories about the proper attitude to security during software
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.
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
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos,
More information about the e-lang