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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx10.iad.POSTED!not-for-mail
From: Shark8 <OneWingedShark@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64;
 rv:31.0) Gecko/20100101 Thunderbird/31.0a1
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Side-channel Attacks (Time)
References: <2wl6v.162063$kp1.28371@fx14.iad>
 <87lhuuuha3.fsf@kuiper.lan.informatimago.com>
In-Reply-To: <87lhuuuha3.fsf@kuiper.lan.informatimago.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <Mvm6v.100857$Vl4.44401@fx10.iad>
X-Complaints-To: abuse@teranews.com
NNTP-Posting-Date: Fri, 25 Apr 2014 05:36:44 UTC
Organization: TeraNews.com
Date: Thu, 24 Apr 2014 23:36:43 -0600
X-Received-Bytes: 1825
X-Received-Body-CRC: 1745784420
Xref: news.eternal-september.org comp.lang.ada:19584
Date: 2014-04-24T23:36:43-06:00
List-Id: <comp.lang.ada>

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.)

> But even in that case, if physical access to the processor is available,
> physical side effects can be detected, and from them information about
> the data can be deduced.

I think physical security is well beyond the scope of a software library.

> Of course, it's as always a matter of risk and graduated counter-measures.

Certainly.