Schneier on Security

Clive Robinson • February 28, 2015 7:42 AM

@ Bruce,

As I read it you only realy cover the “weakening of standards” by the rather obvious “bull in a chins shop” method used over the Dual EC random generator.

There are more subtle methods that can be used.

For instance how can you “fix” an open standards process carried out almost entirely by others?

An example was the AES process / competition,

It is known that the NSA like side channels especially when the leak KeyMat in a non obvious way, the question for them is thus how do you put the fix in without it being obvious, thus giving plausible denialability?

Firstly know how to herd cats, that is get lots of mutually suspicious people to move in the desired direction by their own choice.

NIST used the NSA as advisors in setting up the competition, and thus allowed the NSA to put space between them and the competition. They then advised that it was about the algorithm security speed and efficiency, and ensured that the only implementation issues that were put in the specification were mainly if not totally irrelevant to their desired result.

The key thing to know is that to make an algorithm fast or efficient on any given practical implementation usually reducess considerably the “implementation security” not the “algorithm security”. This is because amongst other things it makes time based side channels considerably more likely than not. And where there are time based side channels in crypto, they are more likely to leak key data than they are plain text data.

Knowing this as the NSA most certainly did as one or two academic researchers did and said so at the time, should have raised / rung warning flags / bells with NIST. But for some reason did not, then or for some time afterwards even though a practical attack was demonstrated.

Worse part of the competition rules was the fact that all implementation code used for the entries must be made publicaly available.

The NSA must have been rolling around on the floor with laughter and glee in their offices when they got that one past NIST. Because they must have known that the code for the competition winner would be downloaded and “used as is” by any one and everyone either directly or indirectly through another entities code library, where they downloaded and “used as is” the competition code.

The result was the wide scale adoption of a theoreticaly secure algorithm but implemented through code that was optomised for speed or efficiency that was far from secure.

So whilst “data at rest” was secure, “data in transit” was only secure if further steps to remove or mittigate the resulting side channels from the competition code was taken.

As we know there are still quite a number of “finished products” out there which use insecure coded versions of AES directly to line without mittigation…

There is a reason they call this “finessing”, and one is, even though the information on this competition manipulation and it’s results has been known publicaly for some considerable time, the majority of people just don’t want to believe it for various quite human reasons.

This brings in another aspect to deniability, which is the difference between “proof” and “belief”. Whilst proof can be demonstrated people will call it “conspiracy theory” etc untill the level of proof is way way beyond that “which would hang a man”. We have seen this with the Ed Snowden revelations. There was considerably more than circumstantial evidence that the NSA et al were doing what they were doing long long before hand. However whenever it was brought up it would get at best skepticism and often “shouted down”. But worse, even though the meta evidence is there now for all to see many are in either denial or “head in the sand” mode due to the cognitive dissonance caused between belief and evidence. And for these people I doubt there will ever be enough evidence to convince them to overcome their beliefs.

This also raises another point about what level of evidence is required in security design. In law there are two commonly quoted burdens and the hurdles they must cross cleanly, the first for prosecution for a crime of “beyond reasonable doubt” the second when suing for damages of “reasonable probability”.

When designing a system it is wise to regard even circumstantial evedence as damming unless it can be proven otherwise, and thus take steps to prevent the cause or where not possible mitigate the effect. It’s the reason why “air-gapping” was –untill recently– held in high regard and the likes of TEMPEST / EmSec design rules are the way they are, even though the are usually ignored or avoided by commercial system designers.