In theory then, from what I can tell, interfering with IFF and instruction transmission in a very localized way would basically cause Yamataian forces to turn on themselves - since they'd drop below the trust margin of the system's referentia.
In addition, the whole thing (from the sounds of it) collapses under higherarchical systems if transmissions are interfered with so they can't make the higher-echelon report so situational judgement becomes entirely localized.
As secure as it is against people copying IFF, Wes, its rife for insane abuse from anyone who know how it works. You could trick any automated system into firing on any unit that fails the trust-scheme because of the jamming -- or if compensation is in place for the trust system, abuse the compensation and broadcast the signal of a 'damaged' IFF unit or jam anyway so they can't actually run the checks.
For the record, I'm kind of shocked you're not using
Remote Command Authorization Codes or
prefix codes -- to disable anything that's been taken.
In addition, why are you still using sequential codes (numbers in sequence, like the steps or instructions of a program) and not referential codes (numbers in reference, like neurons in the brain)?
Sequential data OTPs can be utterly
raped by any machine using a
low-abstraction single-purpose (not general purpose) processor.
There's absolutely nothing special about a quantum generated code. Its a code, just like any other. The math isn't any faster. Quantum Computers only come into their own when you're doing parallel processing and different sequences alongside eachother -- like a tactical simulation or cracking logic like OTPs. For standard logical operation and calculation (ie forming encryption instead of breaking it), they're
WORSE than general purpose processors, which are enormously worse than a single-purpose low abstraction processor -- which is why we have math-cores on processors to begin with -- because they can perform mathamatical ops faster than the broad face of the logic ops on the circuit (usually via opcodes to begin with).
The value is the encryption scheme, not the processor. And to be fair, OTP has the lowest holistic information survivability rate of any encryption scheme. If even one value is missing, the whole thing stops working. We actually stopped using them in the UK (outside of
number stations) because they're so easy to disrupt and jam -- which is why they're only used on analogue transmissions (which are much hardier but have a much lower bandwidth capacity and are entirely public by their very design).
There is a reason we don't use OTP on transmission equipment in the first place.
The issue then becomes is a referential OTP viable? Well, you also have to include the addressing information, so your file-sizes jump exponentially and you expose more information to your enemy with the One-Time Key that is tied to the pad, giving them huge insights into how your scheme works.
Flat out, OTP isn't viable for conventional encryption unless high signal loss is preferable to revealing the contents.
As for fractals, you're repeating patterns in your code. Because fractals ARE Repeating patterns and repeated patterns are predictable. Predictability is BAD for salt/peppering hash or any other element of any encryption scheme.
All you need to do is recognize one set of operations taking place and with fractal schemes, revealed unto you is the complete schema of the code without even having to decrypt the full thing. Worse, you can now do viability scopes and swots for the fastest area to unravel and BUILD a system around this to read these codes and decrypt them in close to realtime. Fractals sound cool (hence why Startreks writers used them) but they're suuuuper bad.
tl;dr: Quantum computers and OTPs don't work the way you seem to think they do.
