Schneier on Security

Clive Robinson • January 12, 2024 5:40 PM

@ Anonymous, ALL,

Re : Fault injection to the brain and the triggering of epilepsy.

“The future of cyberwar.”

I was involved with research decades ago that used to ultrasonic beams with a fractional frequency difference that were overlapped to form a pencil thin beam[1].

The two beams would use the nonlinearity of the human skin and dermis to demodulate the frequency and waveform difference (much like a mixer in a superhet receiver). The resulting wave was used to induce nerves to respond and overload. To say “You could stick a pig in a crowd at half a click” was unfortunately true. Like all radient energy weapons it had numerous disadvantages I’ve listed a few times before especially to the operators. However a significant number of people believe it may well be the basis for the device responsible for Havana Syndrome.

One issues is the narrow energy margin between effectivness and leathal.

Another is that like any insult to the head the effects are accumulative as the NFL has had to come to terms with. Unfortunately “Chronic traumatic encephalopathy” (CTE) can currently only fully be diagnosed after death with a carefull autopsy on the brain. However certain chronic symptoms are now recognised such as base personality change as being indicative.

The changes to the brain in CTE unfortunately make you more susceptable to the misfiring of neurons that can trigger epilepsy, as well as being more likely to develop epilepsy and the coresponding states.

The thing to remember is it realy does not matter what form of radiated energy is used, all that is required is it produces even quite minor but repetative shockwaves that if they cause resonance effects in the head are significantly multiplied in their detrimental effect.

As is known laser weapons are not very effective in continuous radiant mode. However optical feedback and pulsing the laser can be used to quickly find a resonance frequency that will quite literaly shake the target to pieces (look up destructive resonance and metal fatigue if you want details).

[1] This beam overlapping alows the edges of two much broader beams to become a very fine beam that is the product of both beams. Thus if one beam gives Dots spaced by Dashes and the other Dashes spaced by Dots and they are sychronized when in the overlap zone you get a continuous tone you can fly an aircraft down from a thousand miles away. This early radio navigation system was used during WWII to guide German Bombers to targets in England. The more accurate British system called G used a timed pulse system that was more immune to both jamming and “beam bending”.

Clive Robinson • January 12, 2024 7:36 PM

@ Winter, Bob, ALL,

Re : Compexity that can not be tested.

“The user cannot evaluate the safety and quality of a proprietary product as she is denied access to the necessary information.”

As complexity increases the same “unavailable information” logic applies to the developer.

All functional software has sub functions as distinct entities, these are linked together by external relationships.

The sub function distinct entities can be viewed as defined “state machines” that can only ever be in one state at a time, but can switch from state to state dependent on both forward (expected) and reverse (unexpectd) input, internal state and the internal relationship diagram that is assumed to be well defined and both synchronous and flow in the forward direction within the sub function.

The external relationships though are assumed to be asynchronous and bi-directional, and flow can be both forward and reverse such that exceptions and error correctian can “unroll” previous function.

It’s not hard to see how quickly the number of relationships rise as well as the number of asynchronous and potentially reversing states.

Even faily simple programs can excead the ability to test in any given time frame. Thus full testing of software of even moderate complexity is not possible.

Which is why information can be unavailable to the developer.

For some years now I’ve argued that the way we develop software should be changed and a more rigorous “engineering” aproach be taken. However whilst this can be done as I’ve indicated, it will drastically change not just the development cycle it will significantly change the development methodology and in many cases,increase development time. Thus software will become impossibly expensive to develop in anything other than a pure one size vanilla form. We know from the 1960’s through to the 1990’s what sort of “tied in” “big iron” perpetual licence business model this produces and how any inovation becomes either stolen or stagnates.

Clive Robinson • January 15, 2024 8:12 AM

@ cls,

Re : Imposability of 100%

“Software can not ever be defect free. Turing and the halting problem. Law of the universe.”

It’s a result of logic not a physical law of the universe that Church and Turing identified back in the early 1930’s.

But of more interest was work just a little earlier by Kurt Gödel that showed that outside of an overly simplified case, no system of logic could describe it’s self.

As for judges… In the UK a “Law Lord” pointed out in a case against British Gas for harasment that…

Managment could not use “the computer says” as an excuse…

Basically he pointed out the chain of facts,

1, Computers are designed/built by humans.
2, Software is designed/written by humans.
3, Therefor humans are responsable for the way the system behaves.
4, Therefor humans not the computer are responsible for any errors or omissions and thus managment should thus act in the same way as if it was a human system that had failed.
5, By not doing so mabagment were guilty of harasment.

This is kind of a bit of a stumbling block, one I suspect that the UK Post Office and various politicians do not want well known currently as it means Paula Vennells and her subordinates are guilty of criminal harassment. And as such the greviousness of what they did should result in maximal criminal sactions / tarrifs as perscribed by the legislation, and as they had “special status” the tarrifs should accordingly be raised.

Also that any compensation should be restorative. You might have heard that on 81year old man was awarded the pitiful sum of £330,000 and then the UK Government claimed £322,000 of it back for what is frankly spurious reasoning.

But moving on, you say,

“Software is not a physical system, like a bridge or dam or building, which can be designed to any desired reliability.”

No physical objects can not be “designed to any desired reliability”. For broadly the same reasoning that software can not be 100% fault free. That is there are “limits” that prevent it.

To see why look up “plastic limit” and “yield criterion” it describes a transition in behaviour from linear to non linear deformation under stress. That is fundemental to all physical objects and how they fail under load be it brittle, ductile, or both.

Thus as I’ve noted befor on this blog the only solution to both “intangible information objects” and “tangible physical object” failures is by putting in additional complexity thus load in the form of “mitigation”.

In the case of the overly generalised notion of the halting problem, an actual computational process may be subject to a transfinite limit. That is as a fully determanistic process either halts in a finite time, or it does not halt in a finite time. But if the entire system not just the process is not fully determanistic it may / may not halt at some point in a span beyond finite time[2].

As an example consider a fairly often occuring situation of a fully determanistic counter that will overflow / wrap around and a fully determanistic process that examines the counter. However the process of interest having started the counter repeatedly examines the counter value and compares it to a value. If the counter and value match the process halts, if they don’t ever match the process won’t halt even though the process is fully determanistic. To many programers their mental logic says that the examining process must halt. Reality however takes a different view and sometimes even though the counter and process value are the same, a match is not seen, or they may not match at the same point in time.

Such errors usually only cause a “miss” not an “out”, that is if the examining process misses the match on this count cycle it will catch it on a future cycle of the counter. But if they synchronize for some reason the match will never be caught.

Those trying to build “Real Time”(RT) processes on non RT systems such as standard multitasking systems –if they have any RT domain experience– know they have to mitigate this issue as best they can. However what ever the mitigation it reducess the efficiency thus limits the capability of the overall system.

[1] The notion of a transfinite limit is described as,

“As a limit cardinal, an infinite cardinal with no immediately smaller cardinal, i.e. it’s not the successor of another cardinal.”

Whilst it can be described in a sentence the implications are well almost a halting problem of their own 😉

[2] You can blaim stochastic processes for this. In the case of a simple counter of finite resolution we know it will reach a point in finite time where it either rolls over or stops at the end stop. However a random number generator with finite resolution in it’s output if “not fully determinate” may never output the end stop number. The probability of this reduces exponentially with the number of values output but it never reaches zero.