cryptoanarchy.wiki

Arise, you have nothing to lose but your barbed wire fences!

1995-12-12 - Re: Timing Cryptanalysis Attack

Header Data

From: Adam Shostack <adam@lighthouse.homeport.org>
To: adam@lighthouse.homeport.org (Adam Shostack)
Message Hash: 5738d2f1336555ee5760a383e584203dd0d08f7ec9a5e4bf61827478b708e025
Message ID: <199512121759.MAA09353@homeport.org>
Reply To: <199512121525.KAA09078@homeport.org>
UTC Datetime: 1995-12-12 20:31:34 UTC
Raw Date: Wed, 13 Dec 1995 04:31:34 +0800

Raw message

From: Adam Shostack <adam@lighthouse.homeport.org>
Date: Wed, 13 Dec 1995 04:31:34 +0800
To: adam@lighthouse.homeport.org (Adam Shostack)
Subject: Re: Timing Cryptanalysis Attack
In-Reply-To: <199512121525.KAA09078@homeport.org>
Message-ID: <199512121759.MAA09353@homeport.org>
MIME-Version: 1.0
Content-Type: text



	Nope, I'm wrong, as Fred and Simon point out.  The noise makes
finding the times more difficult by some small factor, nothing more.
I'll stop writing these things in the morning. :)

I wrote:

| 	Does the delay have to be random, or does the total time for a
| transacation need to be unrelated to the bits in the secret key?
| Assume that the time added is pseudo-random (and confidential).
| Further, for any non-overlapping group of N transactions, the
| distribution of the times fits some predetermined curve, say a bell
| curve.
| 
| 	We've added a non random number, but since those numbers end
| up being a curve, it would be difficult to determine which transaction
| got which time added to it.  This resembles the 'make them all a
| constant time', but allows us to send out some in a shorter time than
| the maximum (although most transactions should probably take longer
| than the average.)

Thread