Retro-Fit LED-Birnen - typische Defekte...

[Volker Bartheld]

On Thu, 24 Mar 2022 08:59:02 +0100, Hans-Peter Diettrich wrote:

On 3/24/22 8:18 AM, Volker Bartheld wrote:
Ich finde das Attribut \"kryptographisch\" amüsant.
Ich auch, wenn auch aus anderem Grund: Wenn etwas mit echten
Zufallszahlen verschlüsselt ist, wie soll diese Information jemals
wieder zurückgewonen werden?

Das geht. Zufallszahlen spielen bei der Erzeugung des Schlüssels eine Rolle
und stellen sicher, daß es in den verschlüsselten Daten keine statistischen
Auffälligkeiten gibt. Natürlich will man auf gar keinen Fall, daß bei
wiederholter Verschlüsselung desselben Klartexts auch immer wieder derselbe
verschlüsselte Text herauskommt. Oder daß jemand identischen, dem Angreifer
bereits bekannten Klartext (bzw. Anteile desselben) wiederholt
verschlüsselt und überträgt. Dazu weiter unten noch mehr.

Die Sache gestaltet sich übrigens deutlich weniger einfach als man
gemeinhin denkt, aber ich wünsche Helmut, unserem Universalgenie natürlich
alles Gute und viel Erfolg. Hier ein bisserl Lesestoff:

https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html
https://www.synopsys.com/blogs/software-security/pseudorandom-number-generation/
https://blog.tjll.net/weak-random-seed-rack-exploit/

Etwas historischer:
https://cryptocellar.org/pubs/enigma-modern-breaking.pdf
https://www.youtube.com/watch?v=G2_Q9FoD-oQ&t=0s
https://www.youtube.com/watch?v=V4V2bpZlqx8

Oder, wenn es abendfüllende Unterhaltung sein darf:

https://www.imdb.com/title/tt2084970/

Den Streifen kann ich wirklich empfehlen. Benedict Cumberbatch in seiner
wohl besten Rolle.

Volker

 

[Rupert Haselbeck]

Thomas Prufer schrieb:

Rupert Haselbeck wrote:
Das ist Blödsinn. Es kann keinen Algorithmus geben, der so etwas leisten
kann, solange er nicht von einem echten Zufallselement abhängt. Dein
Algorithmus wird, abhängig vom Eingabewert, immer vorhersagbare
Ergebnisse liefern...

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

(Eine Wand Lavalampen, gefilmt, und den Zufallsanteil draus in Algorithmen
gefüttert. Wohl nicht das beste System, aber schön anzuschauen und auch aus
einem anderen Topf finanziert wie \"Kunst am Bau\".)

Nun ja, es gibt eine ganze Reihe von Ansätzen zur Generierung /guter/
Zufallszahlen für kryptografische Zwecke. Manche sind halt ein wenig
umständlich und/oder aufwändig umzusetzen, andere lassen sich leichter
handhaben. Und bei all diesen Ideen ist es vor einer
erfolgversprechenden praktischen Anwendung von grundlegender Bedeutung,
dass sowohl der theoretische Ansatz als auch die praktische Umsetzung
wirklich einen \"echten\" Zufall ermöglichen.
Eine auf welche Weise auch immer generierte \"Zufallszahl\" wird
jedenfalls nicht dadurch /besser/, dass man sie tausend- oder auch
millionenfach durch einen irgendwie gearteten Algorithmus jagt. Das
haben schon etliche schlaue Menschen schmerzhaft feststellen müssen,
welche gerne mal ihre eigenen völlig unknackbaren
Verschlüsselungssysteme gebastelt haben...

MfG
Rupert

 

[Helmut Schellong]

On 03/23/2022 21:47, Gerrit Heitsch wrote:

On 3/23/22 21:39, Helmut Schellong wrote:
On 03/23/2022 20:13, Marc Haber wrote:
Helmut Schellong <rip@schellong.biz> wrote:
Auf dem PC verwende ich einen kryptographischen Generator, der mit 256 Byte
durch mehrere physikalische Effekte erzeugten Inhalten (seed) gestartet wird.
Danach wird der Algorithmus mit dieser Injektion 1024-mal blind durchlaufen, um alle
Spuren der 256 Byte zu verwischen.
Der Algorithmus erzeugt bei nur einem geänderten Bit im seed(256) eine vollkommen
andere Sequenz von Zufallszahlen.
Eine beispielhafte Sequenz-Länge beträgt 2^68 Byte.

Lass mich raten, selbst entwickelt.

Oder irgend eine fertige, vom Experten gemachte Bibliothek?



Die Kern-Algorithmen sind nicht selbst entwickelt.
Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
Diese Algorithmen sind alle kryptographisch.

bish -c \"coder -C\"

Ich redete von folgendem Teil (Spritz):

         case 1:
                  seed.pid= getpid();
                  seed.tim= time(NULL);
                  if (b!=3)  i-=w;
                  w= wv[(ulong)seed.tim%sizeof(wv)];
                  for (a=0;  a<256;  ++a)  {
                     i= i+w;
                     j= k+s[j+s&255];
                     k= i+k+s[j] + ((byte*)&seed)[a];
                     t= s, s=s[j], s[j]=t;
                     z= s[j+s[i+s[z+k&255]&255]&255];
                  }
                  for (j=i,a=0;  a<1024;  ++a)  {
                     i= i+w;
                     j= k+s[j+s&255];
                     k= i+k+s[j];
                     t= s, s=s[j], s[j]=t;
                     z= s[j+s[i+s[z+k&255]&255]&255];
                  }
                  cnt=1600000; f=b; continue;

Pseudozufallsgenerator. Dafür gibts fertige Implementationen. Der Linux-Kernel hat einen solchen eingebaut.

Vorstehend ist nur der seed-Teil des Algorithmus dargestellt.
Das schrieb ich bereits.
Der gesamte Algorithmus ist etwa 5-fach größer.
Durch den seed-Teil ist es eben _nicht_ ein deterministischer Generator.

Unter FreeBSD, Windows, etc. habe ich _nicht_ einen Spritz-Generator zur Verfügung.
Also implementierte ich selbst einen.

https://de.wikipedia.org/wiki/RC4#Nachfolger
https://de.wikipedia.org/wiki/Liste_von_Zufallszahlengeneratoren
https://de.wikipedia.org/wiki/Kryptographisch_sicherer_Zufallszahlengenerator


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm

 

[Helmut Schellong]

On 03/24/2022 08:18, Volker Bartheld wrote:

On Wed, 23 Mar 2022 21:47:43 +0100, Gerrit Heitsch wrote:
On 3/23/22 21:39, Helmut Schellong wrote:
On 03/23/2022 20:13, Marc Haber wrote:
Helmut Schellong <rip@schellong.biz> wrote:
Auf dem PC verwende ich einen kryptographischen Generator
Lass mich raten, selbst entwickelt.
Die Kern-Algorithmen sind nicht selbst entwickelt.
Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
Diese Algorithmen sind alle kryptographisch.
Pseudozufallsgenerator. Dafür gibts fertige Implementationen. Der
Linux-Kernel hat einen solchen eingebaut.

Ich finde das Attribut \"kryptographisch\" amüsant. Ist das wie
\"professionell\"? Man möchte irgendwie sagen, man sei toll ohne daß man
genau weiß warum. Dann heißt es \"premium\" (bevorzugt), \"professionell\"
(berufsmäßig), \"Qualität\" (Beschaffenheit), \"agil\" (beweglich),
\"resilient\" (widerstandsfähig) oder eben \"kryptografisch\" (geheim).

Diese Koniferen können mich mit ihrer Syphilisarbeit aber gar nicht
imprägnieren.

https://de.wikipedia.org/wiki/Liste_von_Zufallszahlengeneratoren#Zuverl%C3%A4ssige_Generatoren

Kryptographische Generatoren haben ein besonderes Verhalten.
Amüsant ist da gar nichts!


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm

 

[Helmut Schellong]

On 03/24/2022 08:29, Thomas Prufer wrote:

On Wed, 23 Mar 2022 16:04:18 +0100, Helmut Schellong <rip@schellong.biz> wrote:

Es ist von zwei verschiedenen Fehler-Klassen \'ausfall\' und \'rücksendung\' die Rede.
Um so etwas auseinander-analysieren zu können, ist eine anspruchsvolle Datenmenge vonnöten.
Außerdem schrieb ich, daß das in der Praxis einen unvernünftig hohen Aufwand bedeuten würde.

Zu Anfang muß stets eine reale Fehler-Bilanz gezogen werden.
Fehler, die bereits bei der Produktion erkannt werden (Endprüfung), und Rückläufe wegen Fehlers.
Die jeweilige Art des Fehlers muß notiert werden.
Sobald so etwas vorliegt, können Berechnungen vorgenommen werden - vorher nicht.
Dies hat nichts mit einer Stichprobe zu tun, sondern ist eine 100%-Erhebung!

Also kannste an einer Stichprobe nix erkennen?

Interessante Anwendung von Statistik...

Das habe ich weder geschrieben noch angedeutet.

An einer Stichprobe mit Umfang 20 kann sehr wahrscheinlich nichts erkannt werden, wenn
in der Gesamtheit nur 1 von 600 defekt ist.
Die Wahrscheinlichkeit dafür beträgt 1/30.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm

 

[Axel Berger]

Rupert Haselbeck wrote:

Eine auf welche Weise auch immer generierte \"Zufallszahl\" wird
jedenfalls nicht dadurch /besser/, dass man sie

Bei einmaliger oder extrem seltener Anwendung ist das vollkommen egal.
Schwachstellen werden erst relevant, wenn man eine große Zahl von
Nachrichten zur Verfügung hat und auch dann nur mithilfe weiterer
Anhaltspunkte.

Natürlich ist genau das auch dann gegeben, wenn viele verschiedene
Menschen unabhängig voneinander genau dieselbe Verschlüsselung mit
derselben Schwachstelle verwenden. Insofern kann schlecht
selbstgebastelt oft sogar besser sein als gut professionell.


--
/¯\\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \\ Mail | -- No unannounced, large, binary attachments, please! --

 

[Gerrit Heitsch]

On 3/24/22 11:26, Helmut Schellong wrote:

On 03/23/2022 21:47, Gerrit Heitsch wrote:
On 3/23/22 21:39, Helmut Schellong wrote:
On 03/23/2022 20:13, Marc Haber wrote:
Helmut Schellong <rip@schellong.biz> wrote:
Auf dem PC verwende ich einen kryptographischen Generator, der mit
256 Byte
durch mehrere physikalische Effekte erzeugten Inhalten (seed)
gestartet wird.
Danach wird der Algorithmus mit dieser Injektion 1024-mal blind
durchlaufen, um alle
Spuren der 256 Byte zu verwischen.
Der Algorithmus erzeugt bei nur einem geänderten Bit im seed(256)
eine vollkommen
andere Sequenz von Zufallszahlen.
Eine beispielhafte Sequenz-Länge beträgt 2^68 Byte.

Lass mich raten, selbst entwickelt.

Oder irgend eine fertige, vom Experten gemachte Bibliothek?



Die Kern-Algorithmen sind nicht selbst entwickelt.
Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
Diese Algorithmen sind alle kryptographisch.

bish -c \"coder -C\"

Ich redete von folgendem Teil (Spritz):

         case 1:
                  seed.pid= getpid();
                  seed.tim= time(NULL);
                  if (b!=3)  i-=w;
                  w= wv[(ulong)seed.tim%sizeof(wv)];
                  for (a=0;  a<256;  ++a)  {
                     i= i+w;
                     j= k+s[j+s&255];
                     k= i+k+s[j] + ((byte*)&seed)[a];
                     t= s, s=s[j], s[j]=t;
                     z= s[j+s[i+s[z+k&255]&255]&255];
                  }
                  for (j=i,a=0;  a<1024;  ++a)  {
                     i= i+w;
                     j= k+s[j+s&255];
                     k= i+k+s[j];
                     t= s, s=s[j], s[j]=t;
                     z= s[j+s[i+s[z+k&255]&255]&255];
                  }
                  cnt=1600000; f=b; continue;

Pseudozufallsgenerator. Dafür gibts fertige Implementationen. Der
Linux-Kernel hat einen solchen eingebaut.



Vorstehend ist nur der seed-Teil des Algorithmus dargestellt.
Das schrieb ich bereits.
Der gesamte Algorithmus ist etwa 5-fach größer.
Durch den seed-Teil ist es eben _nicht_ ein deterministischer Generator.

Linux hat /dev/random, da bekommst du einen Seed wenn du willst.

Gerrit

 

[Volker Bartheld]

On Thu, 24 Mar 2022 11:51:33 +0100, Gerrit Heitsch wrote:

On 3/24/22 11:26, Helmut Schellong wrote:
On 03/23/2022 21:47, Gerrit Heitsch wrote:
On 3/23/22 21:39, Helmut Schellong wrote:
                  seed.pid= getpid();
                  seed.tim= time(NULL);
                  if (b!=3)  i-=w;
                  w= wv[(ulong)seed.tim%sizeof(wv)];
                  for (a=0;  a<256;  ++a)  {
                     i= i+w;
                     j= k+s[j+s&255];
                     k= i+k+s[j] + ((byte*)&seed)[a];
                     t= s, s=s[j], s[j]=t;
                     z= s[j+s[i+s[z+k&255]&255]&255];
                  }
                  for (j=i,a=0;  a<1024;  ++a)  {
                     i= i+w;
                     j= k+s[j+s&255];
                     k= i+k+s[j];
                     t= s, s=s[j], s[j]=t;
                     z= s[j+s[i+s[z+k&255]&255]&255];
                  }
                  cnt=1600000; f=b; continue;
Pseudozufallsgenerator. Dafür gibts fertige Implementationen. Der
Linux-Kernel hat einen solchen eingebaut.
Vorstehend ist nur der seed-Teil des Algorithmus dargestellt.
Der gesamte Algorithmus ist etwa 5-fach größer.
Durch den seed-Teil ist es eben _nicht_ ein deterministischer Generator.
Linux hat /dev/random, da bekommst du einen Seed wenn du willst.

Also erstens ist der Algorithmus _natürlich_ deterministisch. Für dieselben
Eingangsdaten (Process ID und Systemzeit) liefert er haargenau dieselben
Ausgangsdaten - in dem Fall wohl z. Codekommentare hat ein Universalgenie
ja nicht nötig. Fremdworte zukünftig vor der Benutzung bitte im Duden
nachschlagen.

Und zweitens kann man sich das lustige Obfuskierungsgehampel mit Schleifen,
Additionen, Indexlotto, Binäroperationen und dem nicht weiter typisierten
aber hoffentlich dennoch vor Überlauf geschützten Array s[] komplett
sparen. Anno 2022 gibts dafür die STL und Hashes, dann ist der Drops
funktionsidentisch in drei Zeilen selbsterklärendem Code gelutscht:

std:stringstream s;
s << _getpid() << time(NULL);
std::size_t seed = std::hash<std::string>()(s.str());

Mannomann. Gehts eigentlich noch mit NIHS und der selbstentblößenden
Theoriewichserei?

Volker

 

[Gerrit Heitsch]

On 3/24/22 13:51, Volker Bartheld wrote:

On Thu, 24 Mar 2022 11:51:33 +0100, Gerrit Heitsch wrote:
On 3/24/22 11:26, Helmut Schellong wrote:
On 03/23/2022 21:47, Gerrit Heitsch wrote:
On 3/23/22 21:39, Helmut Schellong wrote:
                  seed.pid= getpid();
                  seed.tim= time(NULL);
                  if (b!=3)  i-=w;
                  w= wv[(ulong)seed.tim%sizeof(wv)];
                  for (a=0;  a<256;  ++a)  {
                     i= i+w;
                     j= k+s[j+s&255];
                     k= i+k+s[j] + ((byte*)&seed)[a];
                     t= s, s=s[j], s[j]=t;
                     z= s[j+s[i+s[z+k&255]&255]&255];
                  }
                  for (j=i,a=0;  a<1024;  ++a)  {
                     i= i+w;
                     j= k+s[j+s&255];
                     k= i+k+s[j];
                     t= s, s=s[j], s[j]=t;
                     z= s[j+s[i+s[z+k&255]&255]&255];
                  }
                  cnt=1600000; f=b; continue;
Pseudozufallsgenerator. Dafür gibts fertige Implementationen. Der
Linux-Kernel hat einen solchen eingebaut.
Vorstehend ist nur der seed-Teil des Algorithmus dargestellt.
Der gesamte Algorithmus ist etwa 5-fach größer.
Durch den seed-Teil ist es eben _nicht_ ein deterministischer Generator.
Linux hat /dev/random, da bekommst du einen Seed wenn du willst.

Also erstens ist der Algorithmus _natürlich_ deterministisch. Für dieselben
Eingangsdaten (Process ID und Systemzeit) liefert er haargenau dieselben
Ausgangsdaten

Das gilt für alle programmierten Zufallsgeneratoren. Für echten Zufall
brauchst du spezielle Hardware.

Wenn man die nicht hat benutzt man Entropiequellen bei denen es extrem
unwahrscheinlich ist, daß alle mehr als einmal denselben Status haben
und die schwer zu beobachten sind. Wobei /dev/random mehr als nur
Systemzeit und Prozess-ID benutzt. Da kommen noch Zeiten zwischen IRQs
und zwischen Tastendrücken rein (wenn eine Tastatur angeschlossen ist
und benutzt wird).

Gerrit

 

[Volker Bartheld]

On Thu, 24 Mar 2022 14:02:50 +0100, Gerrit Heitsch wrote:

On 3/24/22 13:51, Volker Bartheld wrote:
On Thu, 24 Mar 2022 11:51:33 +0100, Gerrit Heitsch wrote:
On 3/24/22 11:26, Helmut Schellong wrote:
Vorstehend ist nur der seed-Teil des Algorithmus dargestellt.
Durch den seed-Teil ist es eben _nicht_ ein deterministischer Generator.
Linux hat /dev/random, da bekommst du einen Seed wenn du willst.
Also erstens ist der Algorithmus _natürlich_ deterministisch. Für dieselben
Eingangsdaten (Process ID und Systemzeit) liefert er haargenau dieselben
Ausgangsdaten
Das gilt für alle programmierten Zufallsgeneratoren. Für echten Zufall
brauchst du spezielle Hardware.

Bekannt. Schellongs PID-Vergabesystem benutzt freilich eine Rauschdiode.

Wenn man die nicht hat benutzt man Entropiequellen bei denen es extrem
unwahrscheinlich ist, daß alle mehr als einmal denselben Status haben
und die schwer zu beobachten sind.

Hatten sich die Buben bei...

https://en.wikipedia.org/wiki/Random_number_generator_attack#Prominent_examples

.... wohl auch gedacht. Einmal die falschen Bits rausmaskiert, einen zu
großen Teiler genommen, einen ungünstigen Variablentyp verwendet, schwache
Startwerte eingestellt und schon ist die Kacke am Dampfen. Was liegt da
näher, als selber noch einen weiteren Zufallszahlengenerator zu
programmieren, der natürlich besser ist als alles, was sich die
Kryptoexperten in den letzten 20 Jahren aus den Fingern gesaugt haben?

Unsere Hall-of-Shame hier @work ist voll von dem Scheiß. Eine Galerie des
Schreckens und des Elends.

Wobei /dev/random mehr als nur
Systemzeit und Prozess-ID benutzt. Da kommen noch Zeiten zwischen IRQs
und zwischen Tastendrücken rein (wenn eine Tastatur angeschlossen ist
und benutzt wird).

Bekannt.

Ich versuch(t)e nur zu illustrieren, warum ich kein ausgesprochener Fan von
NIHS und Security by Obscurity bin.

Volker

 

[Helmut Schellong]

On 03/24/2022 00:07, Rupert Haselbeck wrote:

Helmut Schellong schrieb:
Albrecht Mehl wrote:
Helmut Schellong:
Echte Zufallszahlen können mit einem Counter 1..49 10MHz mit Taster
_fast_ echte! Echte mithilfe von quantenmechanischer Apperatur.
generiert werden.

Soweit mir bekannt ist:
Alle _nichtdeterministischen_ Zufallszahlengeneratoren generieren echte Zufallszahlen.

_Ausschließlich_ nichtdeterministische Zufallszahlengeneratoren können \"echte\" Zufallszahlen generieren

Beispielsweise das Lotto-Ziehungsgerät.

Auf dem PC verwende ich einen kryptographischen Generator, der mit 256 Byte
durch mehrere physikalische Effekte erzeugten Inhalten (seed) gestartet wird.

Woher kommt der Zufall? Der \"echte\" Zufall?

Der seed enthält:
struct { pid_t pid; time_t tim; byte buf[256]; } seed;

seed.pid= getpid();
seed.tim= time(NULL);
if (b!=3) i-=w;
w= wv[(ulong)seed.tim%sizeof(wv)];
for (a=0; a<256; ++a) {
i= i+w;
j= k+s[j+s&255];
k= i+k+s[j] + ((byte*)&seed)[a];
t= s, s=s[j], s[j]=t;
z= s[j+s[i+s[z+k&255]&255]&255];
}

Der seed ist nicht durch ein Argument beeinflußbar.
Er basiert auf den Eingaben:
Prozeß-ID zufällig, unique
Zeit dauerhaft aufsteigend, in Sekunden
Array[Zeit] ungerade Zahlen <128 \'wv[]\'
Stack-Speicherinhalt buf[256], nicht vorhersagbar

Der seed wird automatisch wiederholt.
Durch diesen seed sind die gelieferten Zufallszahlen nichtdeterministisch.

Danach wird der Algorithmus mit dieser Injektion 1024-mal blind durchlaufen, um alle Spuren der 256 Byte zu verwischen.

Das ist Blödsinn. Es kann keinen Algorithmus geben, der so etwas leisten kann, solange er nicht von einem echten Zufallselement abhängt. Dein Algorithmus wird, abhängig vom Eingabewert, immer vorhersagbare Ergebnisse liefern...

Nein, niemals!
Leerdurchläufe sind weltweit üblich bei kryptographischen Algorithmen.
Und dies funktioniert in 100% aller Fälle.

Es werden also z.B. 1024 Zufallszahlen nach irgendwelchen Initialisierungen
weggeworfen, um in der Ausgabe fast alle Überbleibsel der Initialisierung zu entfernen.

Der Algorithmus erzeugt bei nur einem geänderten Bit im seed(256) eine vollkommen andere Sequenz von Zufallszahlen.
Eine beispielhafte Sequenz-Länge beträgt 2^68 Byte.

Es ist völlig egal, wie lange die Zahl ist, wenn sie nur durch, gerne beliebig viele, stets gleiche und somit wohldefinierte Rechenoperationen bestimmt wird.
Man merkt mal wieder, dass es dir an einer wissenschaftlichen Ausbildung vollständig mangelt

Es ist nicht egal, wie lang die Sequenz ist!
Die Länge ist proportional mit der Qualität.
Ist die Länge geringer, muß wahrscheinlich eine neue Initialisierung
mit anderen Inhalten erfolgen, um weiterarbeiten zu können.
Bei genügender Sequenzlänge kann dies eingespart werden.

Angesichts Deiner Antworten drängt es sich auf, daß ich hier der Wissende bin,
während Du zum Thema einfach kein Wissen hast - wie fast immer.
Deine Antworten scheinst Du zu \'erfinden\'.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm

 

[Wolfgang Allinger]

On 23 Mar 22 at group /de/sci/electronics in article t1fii7$e4l$1@news.bawue.net
<gerrit@laosinh.s.bawue.de> (Gerrit Heitsch) wrote:

On 3/23/22 15:21, Wolfgang Allinger wrote:

On 23 Mar 22 at group /de/sci/electronics in article
9y0vu7mvpk2l$.dlg@news.bartheld.net <news2022@bartheld.net> (Volker
Bartheld) wrote:

Jup. Wenn man sich die Hg-Linien so ansieht, kommt da echt nicht viel im
sichtbaren Bereich raus. Da ist wohl normales Glühobst noch effizienter.

MöööP! Ich hab hier noch 2 HQL E27 160W OSRAM (für Strassenbeleuchtung)
aus D. Locker 45a alt aus meiner Verkehrsteuerung-Zeit.

Die haben keine weisse Beschichtung sondern sind klar?

Nein, haben weisse Beschichtung.

Klare hamse hier in PY, mit starkem Gelbstich.


Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Gerrit Heitsch]

On 3/23/22 19:49, Wolfgang Allinger wrote:

On 23 Mar 22 at group /de/sci/electronics in article t1fii7$e4l$1@news.bawue.net
gerrit@laosinh.s.bawue.de> (Gerrit Heitsch) wrote:

On 3/23/22 15:21, Wolfgang Allinger wrote:

On 23 Mar 22 at group /de/sci/electronics in article
9y0vu7mvpk2l$.dlg@news.bartheld.net <news2022@bartheld.net> (Volker
Bartheld) wrote:

Jup. Wenn man sich die Hg-Linien so ansieht, kommt da echt nicht viel im
sichtbaren Bereich raus. Da ist wohl normales Glühobst noch effizienter.

MöööP! Ich hab hier noch 2 HQL E27 160W OSRAM (für Strassenbeleuchtung)
aus D. Locker 45a alt aus meiner Verkehrsteuerung-Zeit.

Die haben keine weisse Beschichtung sondern sind klar?

Nein, haben weisse Beschichtung.

Klare hamse hier in PY, mit starkem Gelbstich.

Straßenlampen mit starkem Gelbstich sind eigentlich Hochdruck-Natriumlampen.

Gerrit

 

[Helmut Schellong]

On 03/24/2022 13:51, Volker Bartheld wrote:

On Thu, 24 Mar 2022 11:51:33 +0100, Gerrit Heitsch wrote:
On 3/24/22 11:26, Helmut Schellong wrote:
On 03/23/2022 21:47, Gerrit Heitsch wrote:
On 3/23/22 21:39, Helmut Schellong wrote:
                  seed.pid= getpid();
                  seed.tim= time(NULL);
                  if (b!=3)  i-=w;
                  w= wv[(ulong)seed.tim%sizeof(wv)];
                  for (a=0;  a<256;  ++a)  {
                     i= i+w;
                     j= k+s[j+s&255];
                     k= i+k+s[j] + ((byte*)&seed)[a];
                     t= s, s=s[j], s[j]=t;
                     z= s[j+s[i+s[z+k&255]&255]&255];
                  }
                  for (j=i,a=0;  a<1024;  ++a)  {
                     i= i+w;
                     j= k+s[j+s&255];
                     k= i+k+s[j];
                     t= s, s=s[j], s[j]=t;
                     z= s[j+s[i+s[z+k&255]&255]&255];
                  }
                  cnt=1600000; f=b; continue;
Pseudozufallsgenerator. Dafür gibts fertige Implementationen. Der
Linux-Kernel hat einen solchen eingebaut.
Vorstehend ist nur der seed-Teil des Algorithmus dargestellt.
Der gesamte Algorithmus ist etwa 5-fach größer.
Durch den seed-Teil ist es eben _nicht_ ein deterministischer Generator.
Linux hat /dev/random, da bekommst du einen Seed wenn du willst.

Also erstens ist der Algorithmus _natürlich_ deterministisch. Für dieselben
Eingangsdaten (Process ID und Systemzeit) liefert er haargenau dieselben
Ausgangsdaten

Der Kern-Algorithmus ist deterministisch, ja.
Die Funktion jedoch ist ein Zufallszahlen-Generator, der nichtdeterministisch
Zufallszahlen generiert.
Warum?
Weil die Eingangsdaten niemals gleich sind mit bisherigen Eingangsdaten!
Ich meine ALLE aufgeführten Eingangsdaten - nicht nur die beiden von Dir genannten!

- in dem Fall wohl z. Codekommentare hat ein Universalgenie
ja nicht nötig. Fremdworte zukünftig vor der Benutzung bitte im Duden
nachschlagen.

Und zweitens kann man sich das lustige Obfuskierungsgehampel mit Schleifen,
Additionen, Indexlotto, Binäroperationen und dem nicht weiter typisierten
aber hoffentlich dennoch vor Überlauf geschützten Array s[] komplett
sparen. Anno 2022 gibts dafür die STL und Hashes, dann ist der Drops
funktionsidentisch in drei Zeilen selbsterklärendem Code gelutscht:

Du scheinst Dich mit der Sprache C nicht auszukennen!
Ich habe offensichtlich nicht die komplette Funktion gepostet.

Es ging darum, ausdrücklich den Spritz-Algorithmus zu implementieren.
Nicht irgendwelche Hash-Funktionen mit unbekanntem Algorithmus aus der C++-Lib.

std:stringstream s;
s << _getpid() << time(NULL);
std::size_t seed = std::hash<std::string>()(s.str());

Mannomann. Gehts eigentlich noch mit NIHS und der selbstentblößenden
Theoriewichserei?

Die Funktion ist in C geschrieben - nicht in C++.



--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm

 

[Helmut Schellong]

On 03/24/2022 09:52, Volker Bartheld wrote:
[...]

Die Sache gestaltet sich übrigens deutlich weniger einfach als man
gemeinhin denkt, aber ich wünsche Helmut, unserem Universalgenie natürlich
alles Gute und viel Erfolg. Hier ein bisserl Lesestoff:

Ich habe einige der aufgelisteten Algorithmen schon vor über 10 Jahren implementiert
und entsprechend lange in erfolgreicher Benutzung.
Dieser volle Benutzungserfolg wird bis zu meinem Lebensende anhalten.

Lesestoff zum Thema habe ich ebenso seit entsprechend langer Zeit.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm

 

[Helmut Schellong]

On 03/24/2022 17:35, Helmut Schellong wrote:

On 03/24/2022 09:52, Volker Bartheld wrote:
[...]
Die Sache gestaltet sich übrigens deutlich weniger einfach als man
gemeinhin denkt, aber ich wünsche Helmut, unserem Universalgenie natürlich
alles Gute und viel Erfolg. Hier ein bisserl Lesestoff:



Ich habe einige der aufgelisteten Algorithmen schon vor über 10 Jahren implementiert
und entsprechend lange in erfolgreicher Benutzung.
Dieser volle Benutzungserfolg wird bis zu meinem Lebensende anhalten.

Lesestoff zum Thema habe ich ebenso seit entsprechend langer Zeit.

http://www.schellong.de/htm/rand.htm#spritz


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz

 

[Christian Weisgerber]

On 2022-03-22, Rolf Bombach <rolfnospambombach@invalid.invalid> wrote:

Es sollte keinen Unterschied zwischen Leuchtstofflampe und
\"Energiesparlampe\" AKA Kompaktleuchtstofflampe geben.

Tja. Trotzdem haben die hier im Haus verbauten Leuchtstoffröhren
und Energiesparlampen völlig verschiedene Spektren.

Möglicherweise ist es ein Generationenunterschied. Die Leuchtstoffröhren
werden schon Jahrzehnte alt sein. Mit Blick auf den von dir genannten
Artikel
https://www.licht-im-terrarium.de/roehre/funktion
vermute ich, dass die Leuchtstoffröhren vom Abschnitt
- \"Standard\" Leuchtstofflampen / Halophosphate
beschrieben werden, die Energiesparlampen von
- Dreibandenleuchtstoffe

--
Christian \"naddy\" Weisgerber naddy@mips.inka.de

 

[olaf]

Christian Weisgerber <naddy@mips.inka.de> wrote:

Möglicherweise ist es ein Generationenunterschied. Die Leuchtstoffröhren
werden schon Jahrzehnte alt sein. Mit Blick auf den von dir genannten

Es ist ein Geldproblem. Gut Leuchtstoffroehren kosten 1-2Euro mehr
und man muss sie bestellen. Es gibt sie nicht im Baumarkt.
Und aehnlich wie bei LEDs sinkt der Wirkungsgrad mit steigendem
CRI. Deshalb sehen dann Fabrikhallen mit sehr vielen solche Roehren
immer so schaurig aus.

Olaf

 

[Thomas Prufer]

On Sun, 27 Mar 2022 18:09:40 -0000 (UTC), Christian Weisgerber
<naddy@mips.inka.de> wrote:

Möglicherweise ist es ein Generationenunterschied. Die Leuchtstoffröhren
werden schon Jahrzehnte alt sein.

Ich vermute auch, die Röhren enthalten heute weniger Quecksilber als früher: die
neueren haben eine ungleichmäßige Lichtverteilung und flackern entlang der
Länge, bis die nicht \"eingelaufen\" sind. Sah ich an EVG und konventionell an
Drossel/Starter. Die Röhren starten IMO auch besser wenn sie eingelaufen sind.
Früher(tm) war das nicht so, oder erinnere ich mich nur falsch?

Hatte auch neulich welche in der Hand, auf denen stand sie wären dimmbar, aber
erst nach 100 Betriebsstunden...

Ich vermute erst eine gründlich erwärmte Röhre ist eine glückliche Röhre...
wegen Quecksilber aufheizen und verteilen, vielleicht?


Thomas Prufer

 

[Hanno Foest]

Am 28.03.22 um 09:44 schrieb Thomas Prufer:

Ich vermute erst eine gründlich erwärmte Röhre ist eine glückliche Röhre...
wegen Quecksilber aufheizen und verteilen, vielleicht?

Wenn ich mich recht erinnere, ist in neueren Röhren das Quecksilber als
Amalgam drin, damit es nicht so in der Umwelt rumsaut, wenn die Röhre
kaputtgeht. Wird erst bei Erwärmung ausgetrieben.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith