From: Shark8 <OneWingedShark@gmail.com>
Subject: Re: Side-channel Attacks (Time)
Date: Thu, 24 Apr 2014 23:36:43 -0600
Date: 2014-04-24T23:36:43-06:00 [thread overview]
Message-ID: <Mvm6v.100857$Vl4.44401@fx10.iad> (raw)
In-Reply-To: <87lhuuuha3.fsf@kuiper.lan.informatimago.com>
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.
next prev parent reply other threads:[~2014-04-25 5:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-25 4:28 Side-channel Attacks (Time) Shark8
2014-04-25 5:09 ` Pascal J. Bourguignon
2014-04-25 5:36 ` Shark8 [this message]
2014-04-25 5:51 ` Pascal J. Bourguignon
2014-04-25 6:26 ` Shark8
2014-04-25 19:43 ` Simon Clubley
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox