24 views

Skip to first unread message

Jun 16, 2022, 12:39:07 PMJun 16

to

Hertzbleed <https://www.hertzbleed.com/> attacks SIKE (a key exchange

mechanism) through a power side channel, by observing the resulting

frequency of a core (which goes down if per-cycle power goes up).

Different bit patterns in the keys consume different amounts of power

in a "constant-time" (i.e., state-of-the-art) implementation of SIKE

which apparently allows to get some info about the bits in the keys by

observing the frequency.

So I was wondering if one could mitigate this by performing a

complementary computation that results in constant total power.

Letting both the key and the ones-complement of the key run through

SIKE is probably too naive. In an OoO CPU where every computation

overwrites a different physical register (and the original contents is

almost unpredictable), I don't see how to do the complementary

approach, but then I don't see how the exploit works. I guess I

should read the paper in more depth.

- anton

--

'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'

Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

mechanism) through a power side channel, by observing the resulting

frequency of a core (which goes down if per-cycle power goes up).

Different bit patterns in the keys consume different amounts of power

in a "constant-time" (i.e., state-of-the-art) implementation of SIKE

which apparently allows to get some info about the bits in the keys by

observing the frequency.

So I was wondering if one could mitigate this by performing a

complementary computation that results in constant total power.

Letting both the key and the ones-complement of the key run through

SIKE is probably too naive. In an OoO CPU where every computation

overwrites a different physical register (and the original contents is

almost unpredictable), I don't see how to do the complementary

approach, but then I don't see how the exploit works. I guess I

should read the paper in more depth.

- anton

--

'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'

Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Jun 16, 2022, 1:15:43 PMJun 16

to

On Thursday, June 16, 2022 at 11:39:07 AM UTC-5, Anton Ertl wrote:

> Hertzbleed <https://www.hertzbleed.com/> attacks SIKE (a key exchange

> mechanism) through a power side channel, by observing the resulting

> frequency of a core (which goes down if per-cycle power goes up).

<

Sounds more like an argument to avoid using a frequency higher than can
> Hertzbleed <https://www.hertzbleed.com/> attacks SIKE (a key exchange

> mechanism) through a power side channel, by observing the resulting

> frequency of a core (which goes down if per-cycle power goes up).

<

be sustained long term.

>

> Different bit patterns in the keys consume different amounts of power

> in a "constant-time" (i.e., state-of-the-art) implementation of SIKE

> which apparently allows to get some info about the bits in the keys by

> observing the frequency.

<

There was a data pattern the CDC 7600 was sensitive to when performing
> Different bit patterns in the keys consume different amounts of power

> in a "constant-time" (i.e., state-of-the-art) implementation of SIKE

> which apparently allows to get some info about the bits in the keys by

> observing the frequency.

<

something like DGEMM. When this data pattern would show up it would

setup standing waves on the power supplies in the 7600 and after about

1 millisecond the machine would deadstop.

<

This is the reason the CRAY-1 provided a DC load to the power supplys.

No data pattern created any change in current demand--either long

term or instantaneous.

>

> So I was wondering if one could mitigate this by performing a

> complementary computation that results in constant total power.

<

Run sensitive code at frequencies where no frequency throttling will occur.
> So I was wondering if one could mitigate this by performing a

> complementary computation that results in constant total power.

<

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu