[Cryptography] [FORGED] Attackers will always win, and it's getting worse!

[Arnold Reinhold]

> On Jul 11, 2017, at 8:16 PM, Tom Mitchell <mitch at niftyegg.com> wrote:
> 
> On Tue, Jul 11, 2017 at 5:04 AM, Arnold Reinhold <agr at me.com> wrote:
>> On Mon, 10 Jul 2017 04:40 Peter Gutmann wrote:
>> Henry Baker <hbaker1 at pipeline.com> writes:
>> 
>> User crypto software (the "attacked") has to run in such a way that:
>> a.  It produces the correct answer; and
>> b.  It does NOT LEAK SECRET INFORMATION through side-channels -- e.g.,
>>  timing/power/etc.
> .....
>> source and object code? Or maybe just configuration management tools that
>> insure compiler optimization levels are never turned on?
> 
> Having worked with compiler folk the need to disable optimizatons
> in and of itself exposes a design problem in the code.
> 
> It ignores that the code can be optimized and an attacker can
> attack faster than testing with "safe" side channel free code.
> How much faster is important to know!
> Constant time can be obtained with a constant time wrapper that
> can see a fast real time counter.
> Power requires physical access.
> 
> Testing mandates testing at all manner and levels of optimization.
> 
> Operational security mandates threat model understanding.
> 
> If optimizations reduce a large key space to fast and slow keys
> key selection is important except the rule for selection is telling
> an attacker about the key space itself.
> 
> This is important for both hardware and software.
> 

It may be of interest to know how much faster a maximally optimized version of my code runs or what optimization might do to key space, but I always have the option of doing those experiments during development and testing. (And any speed difference is likely dwarfed by the fact that an attacker can be running 100,000 pipeiined instances on 5GHz custom hardware cooled by liquid nitrogen, while my production code is running on an 8 MHz Atmel processor.) The code I ship only needs to be fast enough to keep up with the traffic I expect while allowing the processor to do its other work. I might prefer code 10X slower than optimized if it reduces side channel risks.

Almost all processors today have similar integer instructions: twos complement arithmetic, 8, 16, 32 and 64 bit words, shifts at bit resolution, and, or, xor, not, etc. A crypto designer could write code with expectations of what instructions will be executed and in what order. The compiler community, as I understand things, only is concerned about the final output and feels free to rearrange things or eliminate steps that don't affect the final result. As a minimum, I want configuration control over whether that happens or not.

Even better would be having the compiler suggest reordering and maybe additional computations that produce the same result with reduced possibility of leakage. And also make sure sensitive data is zeroed out as soon as it is no longer needed, and keep track of intermediate results and zero them out too; and make sure sensitive data and intermediate results are always stored in memory that is never swapped to mass storage. And I’m sure there are possibilities I haven’t thought of if the compiler community’s creativity were applied to our problems.

Regardless, from a security engineering perspective, we should have total control over what crypto object code we ship.  I don’t want my code altered just because someone elsewhere in the organization decides to up the optimization level to make the user interface snappier. 

Arnold Reinhold