From: “Perry E. Metzger” <perry@piermont.com>
To: Tom Weinstein <tomw@netscape.com>
Message Hash: 26dfd7b946324f6163ad33dea09005a97e947184d436879187e992dd8e71bd21
Message ID: <199512120100.UAA00263@jekyll.piermont.com>
Reply To: <30CC9B8C.6201@netscape.com>
UTC Datetime: 1995-12-12 06:55:20 UTC
Raw Date: Tue, 12 Dec 1995 14:55:20 +0800
From: "Perry E. Metzger" <perry@piermont.com>
Date: Tue, 12 Dec 1995 14:55:20 +0800
To: Tom Weinstein <tomw@netscape.com>
Subject: Re: Timing Cryptanalysis Attack
In-Reply-To: <30CC9B8C.6201@netscape.com>
Message-ID: <199512120100.UAA00263@jekyll.piermont.com>
MIME-Version: 1.0
Content-Type: text/plain
Tom Weinstein writes:
> Perry E. Metzger wrote:
> > The trivial way to handle this is simply to check user time with the
> > right system calls and make sure it always comes out the same with an
> > apropriate number of sleeps.
>
> The problem with that approach is that if the system is heavily loaded,
> it can take an arbitrarily large amount of user time.
Totally untrue. The process can take an arbitrary amount of wall clock
time, not user time.
In the case of the heavily loaded machine, the problem is gone -- the
opponent can't precisely predict this. Provided you take the same
amount of process time no matter what, you are okay.
(To be technical, user time doesn't pass during sleeps, but that
doesn't matter -- the problem gets fixed anyway).
> Somewhat better is to sleep for a random amount of time after you're
> done.
I don't think so. First of all, you can still extract some
information. If you have been gone as long as the maximum computation
plus the maximum random fudge, you know that you had to have conducted
the maximum computation. This means that some bits are indeed
leaking. Your approach also has the disadvantage that it is hard to
produce good random numbers -- you are perhaps familiar with that problem?
Perry
Return to December 1995
Return to “Tom Weinstein <tomw@netscape.com>”