From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 border2.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
Newsgroups: comp.lang.ada
Subject: Re: Side-channel Attacks (Time)
Date: Fri, 25 Apr 2014 19:43:46 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <ljedti$vhg$1@dont-email.me>
References: <2wl6v.162063$kp1.28371@fx14.iad>
 <87lhuuuha3.fsf@kuiper.lan.informatimago.com>
 <Mvm6v.100857$Vl4.44401@fx10.iad>
Injection-Date: Fri, 25 Apr 2014 19:43:46 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="e458ff8b81bc0c159989eb0e36c6e372";
 logging-data="32304"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX1+6l02MB11V8Mw1aWQdtbzVwWS2xDdwP3A="
User-Agent: slrn/0.9.8.1 (VMS/Multinet)
Cancel-Lock: sha1:smTMUmobocgBv3pROf0JwfCMAtw=
X-Original-Bytes: 2683
Xref: number.nntp.dca.giganews.com comp.lang.ada:186087
Date: 2014-04-25T19:43:46+00:00
List-Id: <comp.lang.ada>

On 2014-04-25, Shark8 <OneWingedShark@gmail.com> wrote:
> On 24-Apr-14 23:09, Pascal J. Bourguignon wrote:
>> Shark8 <OneWingedShark@gmail.com> writes:
>>
>>> Considering the needs for a secure, verified security library [to
>>> replace OpenSSL] I was wondering about using the TASK construct in
>>> conjunction with DELAY UNTIL /OP_UPPERBOUND/* would be an acceptable
>>> countermeasure.
>>
>> It could help.
>>
>> Choosing an algorithm without branches, and with fixed count loops would
>> be better.
>
> Hm, there's a thought.
> I rather do like the DELAY UNTIL solution as it concisely states the 
> intention as a timing-attack countermeasure. (Though I've got pretty 
> much no experience in real-time systems, so I can't say if it's actually 
> appropriate.)
>

The problem is that you are making assumptions about the environment
your code is running in when you determine how long something is going
to take.

The static values you come up with for a 3GHz desktop processor will be
very different from the values you need for a 100MHz (or even less)
embedded system, which makes the values you choose fragile when they are
used in different environments.

If, OTOH, you try to calculate some dynamic values at program startup
time which reflect the system you are running on, then you are vulnerable
to bad values calculated due to varying system load.

I wonder if you could achieve what you want by introducing random
micro-delays into the calculations themselves ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world