Schneier on Security

Clive Robinson • February 28, 2023 11:08 AM

@ Bruce, ALL,

“The algorithm is not “broken” or “cracked”—despite headlines to the contrary—this is just a side-channel attack.”

The problem is not many understand the difference between,

1, Broken algorithm.
2, Broken implementation.

Or the implication of the latter.

As I’ve indicated in the past side channels appear in many ways, and they can leak many things.

What would be fair to say is that outside certain “Tripple Fence” organisations, not much research has been done.

Trying to deal with each type of side channel is not something many can do, and like “rolling your own crypto” is something where your success will be doubtful, without knowledge you may find difficult to aquire.

Thus the safe rule of thumb to mitigate side channels is not to use any crypto algorithm you need to rely on in an “On-Line” mode.

So encrypt your secrets on an “energy gapped” machine where neither side channeles or other communications can carry secret information out into the world for the third party ears of Eve and friends to pick up.

Clive Robinson • February 28, 2023 5:46 PM

@ Ted, ALL,

Re : Side channel protection gives slow algorithms.

“Moody adds that Kyber may be about twice as slow when lots of countermeasures are added.”

And those measures will probably not be enough…

But before anyone goes “but but but.
..” The AES finalist suffers from this very issue quite badly as well. And the NSA darn well knew about side channel issues before they pursuaded NIST to rig the contest to not just ignore them but select for probably worat case algorithms… Which ment that the “fastness” of the AES finalist pushed out other better algorithms that did not have anywhere near as bad side channel leakage.

I’ve said for years on this blog, there is a trade off of “Security v Efficiency” in general the more efficient you make an algorithm or implementation the worse the side channel leakage will be in a practical implementation.

I’ve even said how you minimise some side channel issues.

One of those old English idioms os pertinent,

“There’s many a slip twixt the cup and lip”

As well as the more general,

“Don’t count your chickens till they’ve hatched”

That apply to information security.

The enemy of privacy and security when it comes to information has always been statistics, that lift apparent noise into being a signal.

When all is said and done about “Machine Learning”(ML), the reality is it’s in effect statistics on steroids. I’m only surprised that it’s taken so long for it to be shown as such against a “black box output”.

The flip side of this by the way, is it will enable us to get more information through a Shannon Channel, especially when time/distance precludes the use of feedback error correction.

So I expect to see some papers about ML applied to “Feedforward Error Correction”(FEC) to come out of this.

Which will actually be a better use of it from society and mankinds perspective, than cracking codes.

Clive Robinson • March 3, 2023 1:10 AM

@ bobthebuilder,

“because some smart young lad had devised a way to get a miniature hall effect sensor within a few microns of an encryption chip surface”

It was not a “hall effect sensor” but a “pico-probe” made from a microwave inductor. He was in communications with Ross J. Anderson back when Ross was trying to solve Power Analysis by using non synchronized clocks.

I’d pointed out to Ross that the logic could be forced into synchronisation by the use of what we now call an EM Fault Injection Attack (basically a CW RF signal sufficient to cause “injection locking”).

Ross put me incontact with the researcher who sent me a pre-publish of his paper, which I still have somewhere in my “Dead Tree Cave”.

Others went on later to use even magnetostrictive “barber-pole” sensors and even SQUID.

Basically anything that works as an H-Field sensor as generally this gives tighter sensor imaging than an E-Field sensor.

With regards,

“Makes me believe there is no data security without physical security and more to the point the limitation of data security is inherent human limitations of physical security.”

There are two “information objects” that need to be protected,

1, The “plaintext”.
3, The “root of trust”.

Currently we have no general practical ways to use them unless they are in their unprotected or not secure state. However it is something that is being worked on.

For instance consider the XOR or ADD -MOD used as the mixer in a stream cipher. You can thus have the information encrypted by stream cipher but perform a limited number of actions on it as though it were not encrypted. One such is in a database where a field contains an integer number, you can add a value to that field without knowing what it contains, however you can not do a compare to find or sort a record.

It’s a form of David Chaum’s “Dining Cryptographers” problem from the 1980’s,

https://en.wikipedia.org/wiki/Dining_cryptographers_problem

Another variation allegedly thought up by a cryptograpers daughter is how to find the average income of the cryptographers without any revealing directly what they earn.

She said get the waiter to write a number down and give it to the first cryptographer who adds his income to it writes the result on another piece of paper and hands that to the second cryptograper who does the same. The final piece of paper is given to the waiter who subtracts his number, then divides the result by the number of cryptographers to get the result and then tells the table what it is.