Friday, February 18, 2022

Interrupt Entropy

NT Interrupt counter Entropy : A counter theory : RS


"more importantly, our
distribution is not 2-monotone like NT's, because in addition to the
cycle counter, we also include in those 4 words a register value, a
return address, and an inverted jiffies. (Whether capturing anything
beyond the cycle counter in the interrupt handler is even adding much of
value is a question for a different time.)"

NT Interrupt counter Entropy : A counter theory : RS

To be clear interrupts are old fashioned (NT & Bios) : Points

Network cards have offloading? Yes & why cannot we?

Offloaded does not mean that a time differential matrix HASH AES of 32Bit words,
Cross pollinated though MMX, AVX , SiMD is plausible!

Combined with even network latency timing & interrupt latency...

Various system differentials can alternate line in our table per clock sync!

In this reference Quartz clock instability is not only counter acted by NTP...
But also utilized as a variable co-modifier.

So why not also advantage ourselves of the clock frequency scaling effect to confuse odds again for Entropy (Random, Not Entropy)

SSD does also have a write counter & a cleared state, not so boring as one thinks if per 32KB segment is hashed in 4Bit, 8,Bit 32Bit float! (remember we have DOT3 DOT 4 & INT8 in ML)

We can utilize write cycle statistics & all hardware; Interrupts by themselves are rather Boring!

Computed timings on processes multiplexed over 3 Threads per group in competition is also a potential complexifier of Random

Rupert S

https://science.n-helix.com/2018/12/rng.html

https://science.n-helix.com/2022/02/rdseed.html

https://science.n-helix.com/2017/04/rng-and-random-web.html

https://science.n-helix.com/2022/02/interrupt-entropy.html

https://science.n-helix.com/2018/05/matrix-of-density.html

https://science.n-helix.com/2019/10/classic-physics.html

https://science.n-helix.com/2021/11/monticarlo-workload-selector.html

https://science.n-helix.com/2022/03/security-aspect-leaf-hash-identifiers.html

https://science.n-helix.com/2022/02/visual-acuity-of-eye-replacements.html

****

PreSEED Poly Elliptic SiMD RAND : RS


Preseed ; 3 Seeds with AES or Poly ChaCha or even 1 : 2 would be rather fast Init

Blending them would make a rather paranoid Kernel developer feel safe! :D

Like so List:

3 seeds 32Bit or 64Bit :
Examples :

1 Seed : Pre seeded from CPU IRQ & Net 16Bit values each & merged
2 & 3 from server https://pollinate.n-helix.com &or System TRNG

4 Seed mix 128Bit Value

Advantages :

AVX & SiMD Mixxer is fast 'Byte Swap & Maths etcetera" & MultiThreaded
AES Support is common :

*

HASH : RSA Source Cert C/TRNG : (c)RS


Elliptic RSA : Cert Mixer : RSA 4096/2048/1024Temporal : 384/256/192 ECC Temporal

Centric Entropy HASH: Butterfly Effects

ChaCha
SM4
SHA2
SHA3

Elliptic Encipher
AES
Poly ChaCha

Elliptic : Time Variance : Tick Count Variance : On & Off Variance : IRQ

*

Time & Crystal : Quartz as a diffraction point fractal differentiator : RS


RDTSC Variable bit differentiation & deviation of the quartz sub .0001 Value combined with complexity of unique interplay with Alternative clocks such as Network cards, Audio cards & USB Sticks & Bluetooth radio clocks & Ultimately the NTP Pools themselves when required.

(TIME Differential Float maths) TSC : RDTSC : RDTSCP : TCE supports single and half precision floating-point calculations

Security Relevant Extensions

SVM : Elliptic Curves & Polynomial graphs & function
AES : Advanced Encryption Standard Functions
AVX : 32Bit to 256Bit parallel Vector Mathematics
FPU : IEEE Float Maths
F16b : 16Bit to 32Bit Standards Floats
RDTSCP : Very high precision time & stamp

Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 htt pni ssse3 fma cx16 sse4_1 sse4_2 popcnt aes f16c syscall nx lm avx svm sse4a osvw ibs xop skinit wdt lwp fma4 tce tbm topx page1gb rdtscp bmi1

32Bit SiMD Operations Available on AVX Per Cycle (A Thought on why 32Bit operations are good!)
(8Cores)8*32Bit SiMD(AVX) * 6(times per cycle) * 3600Mhz = 1,382,400 Operations Per Second

*

For RDTSCP = TValue TV1=16.0685 TV2=16.1432 TV3=15.1871
When Processor Mzh = PV1 PV2 PV3
RAND Source = Es1 Es2 Es3

If Xt = 1.9 < then roll right

((TV1 - TV2) * (PV1 - PV2)) / ((TV1 - TV3) * (PV1 - PV3)) = FractorXt(Xt)

Es1 * Xt = Differential

Es2 Es3

(c) Rupert S

Quartz as a diffraction point fractal differentiator : RS

https://science.n-helix.com/2022/02/interrupt-entropy.html

https://tches.iacr.org/index.php/TCHES/article/download/7274/6452
https://perso.univ-rennes1.fr/david.lubicz/articles/gda.pdf
https://patents.google.com/patent/US9335971
*

"Taking spinlocks from IRQ context is problematic for PREEMPT_RT. That
is, in part, why we take trylocks instead. But apparently this still
trips up various lock dependency analysers. That seems like a bug in the
analyser's that should be fixed, rather than having to change things
here.

But maybe there's another reason to change things up: by deferring the
crng pre-init loading to the worker, we can use the cryptographic hash
function rather than xor, which is perhaps a meaningful difference when
considering this data has only been through the relatively weak
fast_mix() function.

The biggest downside of this approach is that the pre-init loading is
now deferred until later, which means things that need random numbers
after interrupts are enabled, but before work-queues are running -- or
before this particular worker manages to run -- are going to get into
trouble. Hopefully in the real world, this window is rather small,
especially since this code won't run until 64 interrupts have occurred."

https://lore.kernel.org/lkml/Yhc4LwK3biZFIqwQ@owl.dominikbrodowski.net/T/

Rupert S

*

Asymmetry dev/random:

Explain it & code it please :D We most certainly know what Asymmetry is in PCI Transactions for GPU & Audio!

The high precision clock source is a CPU feature, but what one forgets is that other processors & network cards have Clock Crystals & So do local networks though the Ethernet Time Sync protocol, PCI Cards with Fast Sync, Repeaters & Boosters..

We need Asymmetric T/T2 or (T * T2)/T3 Etcetera
The main feature is a Timer & The Synchronicity of that timer; Being Asymmetric on time is a feature!

We laugh but yes Asymmetry Is a feature!
But we utilize the Asymmetry to provide CHAOS or Random Patterns,Not Precisely with a single Digit; We may? But we do not have to.

RDTSC is a logical choice for a processor; However our timers can also simply be a tick,
Network Ethernet, PCI-E, Audio BUS, HDD & SSD, Timing Sync Events,
In the case (Example) Network PCI Cards; They do indeed have a precise & variable clock..
In addition they have Network Traffic & Chaotic Packet IRQ; Timed IRQ & Offloaded IRQ & Data,
Also TLS Cypher packets; (Events Sometimes Offloaded & Sometimes not).

In a single System Time Crystals & Sync Events are simply the beginning of "The EventFul Day - Crypto"

Rupert S

Elliptic Curve Erratic Time Diffraction:


Relatively Subtle Timers, Clock Timers from NIC's or Statistical packet flows, Timer offsets & data flow Engrams & Anagrams & Flow patterns, Timers & Interrupts!

But real Timing & Sync Crystals are a work of real logic & Therefor potent in their Patterns & Powerfully influential on the Dynamic Maximum System Potential,

However played or used, Timers & Sync are the heart of a well centered Kye!

So as to timers & statistics; We do have to flow charts though ECC Elliptic Anonymizers.

We frequent the waters of personal & business & We do know so little from that,

Elliptic Curve Erratic Time Diffraction!

Unique Precise clocks & How many? Depends on how Expensive Your Mainframe is! Asymmetry dev/random: Explain it & code it please :D We most certainly know what Asymmetry is in PCI Transactions for GPU & Audio!

Rupert S

VMTGate2022:RS


What we are looking for essentially is 2 things:
Clock differential; As in speed & frequency shifts Electric signal variance,

The time shifting a number that does not guarantee forward (not obligatory),
For example a certificate ECC Elliptic that shifts 0.0005>6 to 4èéç=4 3fdé=5,

However a differential does Vary,

Still need system time to be precise (for Time NTP) & observations of differential are how we adjust..
Imprecision; Crystal Variance & imprecision is a core topic,
But we adapt imprecise results in NTP into precise ones.

Nanosecond TSC : RSTSCP
https://lkml.org/lkml/2022/4/25/57 

RS


[PATCH RFC v1 09/10] sparc: use sched_clock() for random_get_entro ... "Jason A. Donenfeld"
[PATCH RFC v1 08/10] um: use sched_clock() for random_get_entropy( ... "Jason A. Donenfeld"
[PATCH RFC v1 07/10] arm64: use sched_clock() for random_get_entro ... "Jason A. Donenfeld"
[PATCH RFC v1 06/10] x86: use sched_clock() for random_get_entropy ... "Jason A. Donenfeld"
[PATCH RFC v1 05/10] arm: use sched_clock() for random_get_entropy ... "Jason A. Donenfeld"
[PATCH RFC v1 04/10] mips: use sched_clock() for random_get_entrop ... "Jason A. Donenfeld"
[PATCH RFC v1 03/10] riscv: use sched_clock() for random_get_entro ... "Jason A. Donenfeld"
[PATCH RFC v1 02/10] m68k: use sched_clock() for random_get_entrop ... "Jason A. Donenfeld"
[PATCH RFC v1 01/10] random: use sched_clock() for random_get_entr ... "Jason A. Donenfeld"
[New] [PATCH RFC v1 00/10] archs/random: fallback to using sched_clock() ... "Jason A. Donenfeld"

https://lkml.org/lkml/2022/4/8/945
https://lkml.org/lkml/2022/4/8/946
https://lkml.org/lkml/2022/4/8/947
https://lkml.org/lkml/2022/4/8/948
https://lkml.org/lkml/2022/4/8/949
https://lkml.org/lkml/2022/4/8/950
https://lkml.org/lkml/2022/4/8/951
https://lkml.org/lkml/2022/4/8/952
https://lkml.org/lkml/2022/4/8/953
https://lkml.org/lkml/2022/4/8/954
https://lkml.org/lkml/2022/4/8/955

Timers
https://lkml.org/lkml/2022/4/9/459
https://lkml.org/lkml/2022/4/9/366

RDTSC
https://lkml.org/lkml/2022/4/9/482

Nanosecond TSC : RSTSCP
https://lkml.org/lkml/2022/4/25/57

*

Random : (Dynamic Elliptic Curve / T) * Factor Of T :

"Problems for Arm (32-bit), Motorola 68000 (M68k), Microblaze, SPARX32, Xtensa, and other niche architectures."

NoJitter - Initiating the dev/random ; Initiating Random with a SEED is the prospect I propose,
My personal Time Crystal RNG is based upon the variable clock rate principle of Quartz clock crystals & could potentially sound too regular.

However as we know very small variabilities in Super Stable Quartz crystals (Factory made) causes doubt,

However in the 0.005 or smaller range & Especially with variable frequencies & power input levels to controlled crystals; Creative Chaos Exists,

Particular market is motherboards that tweak frequencies to improve performance!

Clock rate variance is combined with a seed; As a Factoring agent & Again as a differentiator.

What Is a Factoring Differentiator ? a Math that shifts values subtly & therefor shifts our results from predictable to unpredictable; Well hard to!

The more effort we make; The harder it will be to see our Dynamic Elliptic Curve.

Rupert S

https://www.phoronix.com/scan.php?page=news_item&px=Linux-RNG-Opportunistic-urandom

*****

Serve C-TRNG QT Fractional Differentiator(c)RS


Server C/TRNG Quarts Time * Fractional differentiator : 8Bit, 16Bit, 32Bit, Float Int32 : Fractional Differentiator : fig-mantuary micro differentiator.


SipHash: a fast short-input PRF

Rotation Alignment : "The advantage of choosing such “aligned” rotation counts is that aligned rotation counts are much faster than unaligned rotation counts on many non-64-bit architectures."

http://cr.yp.to/siphash/siphash-20120918.pdf  

https://www.aumasson.jp/siphash/siphash.pdf

"Choice of rotation counts. Finding really bad rotation counts for ARX algorithms turns out to be difficult. For example, randomly setting all rotations in
BLAKE-512 or Skein to a value in {8, 16, 24, . . . , 56} may allow known attacks
to reach slightly more rounds, but no dramatic improvement is expected.
The advantage of choosing such “aligned” rotation counts is that aligned rotation counts are much faster than unaligned rotation counts on many non-64-bit
architectures. Many 8-bit microcontrollers have only 1-bit shifts of bytes, so
rotation by (e.g.) 3 bits is particularly expensive; implementing a rotation by
a mere permutation of bytes greatly speeds up ARX algorithms. Even 64-bit
systems can benefit from alignment, when a sequence of shift-shift-xor can be
replaced by SSSE3’s pshufb byte-shuffling instruction. For comparison, implementing BLAKE-256’s 16- and 8-bit rotations with pshufb led to a 20% speedup
on Intel’s Nehalem microarchitecture."

https://www.kernel.org/doc/html/latest/security/siphash.html

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

Code SIP-HASH
https://github.com/veorq/SipHash

Serve C-TRNG QT Fractional Differentiator(c)RS

Server C/TRNG Quarts Time * Fractional differentiator : 8Bit, 16Bit, 32Bit, Float Int32 : Fractional Differentiator : fig-mantuary micro differentiator.

As we see rotation may benefact from the addition of Quartz crystal alignment sync data from 4 cycles & aligning data blocks,

Obviously we can pre share 4 64Bit blocks use use a pre seed AES/ChaCha Quad!
Indeed we can have 16 64Bit pre Seeds & chose them by time sync for kernel


Rupert S https://science.n-helix.com

*RAND OP Ubuntu : https://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1.html

https://pollinate.n-helix.com

https://science.n-helix.com/2018/12/rng.html

https://science.n-helix.com/2022/02/rdseed.html

https://science.n-helix.com/2017/04/rng-and-random-web.html

https://science.n-helix.com/2021/11/monticarlo-workload-selector.html

https://science.n-helix.com/2022/02/visual-acuity-of-eye-replacements.html

https://science.n-helix.com/2022/02/interrupt-entropy.html

*

Encryption Methods:

https://tools.ietf.org/id/?doc=hash

https://tools.ietf.org/id/?doc=encrypt

HASH :


https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs

https://tools.ietf.org/id/draft-ribose-cfrg-sm4-10.html

https://tools.ietf.org/id/?doc=sha

https://tools.ietf.org/id/?doc=rsa

Encryption Common Support:


https://tools.ietf.org/id/?doc=chacha

https://tools.ietf.org/id/?doc=aes

SM4e does seem a good possibility for C/T/RNG CORE HASH Functions!


ARM Crypto Extensions Code (Maybe AES Extensions would work here)
https://lkml.org/lkml/2022/3/15/324

ARM Neon / SiMD / AVX Compatible (GPU is possible)
https://lkml.org/lkml/2022/3/15/323


*

197 FIPS NIST Standards Specification C/T/RNG https://science.n-helix.com/2022/02/interrupt-entropy.html


Only a Neanderthal would approve a non additive source combination that is injected into the HASH & Re-HASHED ,

One does not Procreate inadequate RANDOM from a simple bias KERNEL, Hardware RNG's added together may add around 450% Complexity!

Hardware RNG devices MUST be able to Re-HASH to their 197 NIST Standards Specification, That is FINAL 2022 DT

KEYS: trusted: allow use of kernel RNG for key material

https://lkml.org/lkml/2022/3/16/598

CAAM PRNG Reference : https://lkml.org/lkml/2022/3/16/649

No comments: