[Cryptography] Defeating timing attacks

[Tom Mitchell]

On Fri, Jul 14, 2017 at 9:21 AM, Henry Baker <hbaker1 at pipeline.com> wrote:
> [Follow-up on attackers always win.]
>
> Consider the following theoretical exercise:
>
> Suppose that a computer's instruction set was *purposely designed* to leak as much secret information through a timing side-channel as possible.  E.g., *asynchronous logic* from the 1960's/1970's might qualify, as the timing of essentially every operation is data-dependent!
>

Interesting...

Compiler authors are of a go fast mindset so there is little if any
intentional support.

Since it is unclear what the *purposely designed* hardware does the best trick
I can offer is an uncommon virtual machine or even a  Java, Python, FORTH,
Ruby, V8 (javascript), php, UCSD p-System's pcode VM and locally
fiddle with the
input to the VM and even the the VM itself.   Hack or strip out JIT
from V8, touch
garbage collection code so it triggers unpredictably.

On specific machines today other processes running on the same core can
abuse the shared logic of hyperthreaded cores or the shared cache to memory
logic of the CPU.  The parent process can fork a mix of short lived
work with a mix of data
to obfuscate the timing of the interesting task.

All the things system benchmark engineers try to control to get the
best possible
reproducible benchmark results gives hints for things to upset the system and
make timing locally and remotely difficult.

Lower level benchmarks like lmbench can be used as a touchstone to see if a
parallel system load sufficiently perturbs the machine and how.

The more cores the easier it gets, perhaps.



-- 
  T o m    M i t c h e l l
×