64-Bit Integer Beschleunigung

@ Jordy: Das ist schon mal nix mit "mal eben durch die HLS kloppen". Ob 
sich das so elegant manuell in V*HDL umsetzen laesst, ist schwer zu 
beurteilen, ungut ist schon mal eine Abbruchbedingung in der obigen Art, 
das bewirkt auch auf einer CPU einen teuren Pipeline-Flush. Sonst ist 
sowas

1

      aRollingValue = (aRollingValue >> 1u) ^ ((aRollingValue & 1u) ? aPolynomial : 0u);

2

3

      const crc_t aNewAccumulator = aRollingValue ^ pAccumulator;

auch m.o.w. trivial in einem Cycle zu schaffen. Frage waere, ob sich die 
Abbruchbedingung anders verarzten laesst (wenn ein Wort-Stack in der 
Groessenordnung um 64 reicht). Ist noch nicht klar, wie sich obiges mit 
'populationCount()' pipelinen liesse. Die Rekursion muesste man schon 
mal aufloesen und in Hardwareschleifen umstricken.

Ansonsten ist das eine interessante Anwendung. Nehme mal an, dass auf 
hoeherer Ebene bereits Reduktion stattfindet? (Kenne besagten C-Algo 
nicht).

Mit einem Stack man man strukturell schon komplett verloren und mit der 
Nutzung von XI HLS bekommt man eine ausgerollte Version einer 
CPU-action-pipe, wie ich das gerne nenne: Es wird das in VHDL gegossen, 
was eine CPU machen müsste, um den Rechenschritt zu lösen.

Um das effektiv zu machen, muss man aber angepasste Schaltungen 
erfinden!

Jordy schrieb:
> Das hier ist die innerste Schleife inklusive Rekursion (maximale
> Rekursionstiefe ist 64, wenn ich mich recht erinnere).
Bei dynamischen Rekursionstiefen muss selbige virtuell verwaltet werden, 
d.h. alle möglichen Prozessschritte müssen mit ALLEN Parametern 
übergeben werden und dann jeweils ein Rekursionsschritt durchgeführt 
werden. Das kann man in einem FPGA in einer linearen pipeline machen. 
Man MUSS es auch so machen, wenn man keine Annahmen über die Dimension 
des Problems machen kann.

Wenn man das kann, ist eine Rekursion als n-dimensionale pipeline zu 
entwerfen und auch gut zu optimieren, wenn man die Produktsumme der 
Dimensionen in die Nähe einer 2hochN-Zahl kommt. Als Beispiel verwende 
ich in meinem Synthesizer eine interative Filterstruktur, welche die 
16000:16384 realisiert und irgendwo dafür von 125 auf 128 übersetzt. 
Dazu braucht man die Dimension 5*5*5. Die füllen die 128 sehr gut. So 
eine Struktur kann man statisch bauen.

Für das Problem wie es sich hier darstellt, muss eine Rekursion in eine 
Iteration übersetzt werden und bei jedem Schritt eine Verwaltung hinein, 
die prüft, ob ein neues Element oder ein altes mit Interationsprogress 
in die pipeline geworfen werden soll.

Als Rechentempo bekommt man bei einen durchschnittlichen FPGA dann 100 
bis 200 MHz, je nachdem wie breit die MUL / ADD sind. Der Rest der 
Dimension wird in die pipeline gedrängt. Damit ergibt sich u.a. die 
Forderung, dass je Iterationsschritt = Rekursion mit Ergebnissen solange 
gewartet werden muss, bis diese aus der pipeline kommen. Die Anzahl der 
"Kanäle" = "Szenarien" = "unterschiedliche Ansätze" KANN / MUSS groß 
genug sein.

Konkret dürften solche Rechnungen wie bei dir mal locker 50-100 pipeline 
steps verbraten. DAS wird dann der limitierende Faktor. Wird durch die 
Zahl der Kanäle oder der unabhängigen Ansätze diese Zahl nicht 
ausgelastet, wird es weniger effektiv und man bekommt Zeitlücken.

Das gleiche gilt, wenn man die Zahl der unabhängigen Ansätze nicht so 
hoch bekommt, wie man die pipeline- Strukturen parallelisieren kann. 
Idealerweise ist die Zahl der parallelen Pfade genau so groß und minimal 
kleiner, als die pipeline Länge, damit immer dann, wenn ein Datum fertig 
ist, es entweder vorne in die eigene oder in eine andere freie 
reingeworfen werden kann. Damit ist es dann EGAL, wie sich die Länge der 
Rekursionen verteilt, also ob es mal wenige lange oder viele kurze gibt 
und es ist egal, wieviele man davon parallel nutzt. Ansonsten gibt es 
wieder viele leere time slots.

Für ein solches Problem habe ich eine Architektur entworfen, welche die 
pipelines verwalten kann. Sie wird in einer industriellen Anwendung 
sowie in meinem Synthi eingesetzt.

Um sie zu portieren, braucht es aber die Randbedingungen des Problems, 
weil die Verwaltungsstrukturen eingestellt werden müssen, also die 
Signale, welche die MUX an den pipe-Eingängen bedienen. Zudem müssen 
dann FFs ausgegossen werden und ein sinnvolles Gesamttiming gefunden 
werden. Das ist meistens der Killer, die ganzen Daten, die mitgeschleppt 
werden müssen, in  REGs zu halten, um sie schlagartig in die neue pipe 
kopieren zu können. Da muss man u.U. auch händisch mitdenken und eine 
partielle optimierung finden, also festlegen, wie dicht man das drängen 
will und wieviel Verwaltung und Ausgleichs-FF man hat. In meinem Synth 
ist das so gelöst, dass die rechnenden Einheiten, immer ein bestimmtes 
Vielfaches ihre Sub-Kanalzahl an Latenz generieren, damit man FFs sparen 
kann.

Ich sehe bisher keine Möglichkeit, das irgendwie zu automatisieren, 
daher bräuchte man wirklich die step-Analyse der Formel, als einen 
Graphen, der timing-genau angibt, was wann womit verrechnet werden soll 
und wie die Querabhängigkeiten sind. Davon hängt ab, wie viele 
unabhängige pipes man nebeneinander bekommt. Ideal sind Rechnungen mit 
Enscheidungen im JA/NEIN-Muster, weil man die Folger schon als 2 
Szenarien in die Folge-pipe werfen kann und sich dann das richtige 
schnappt, sobald das Ergebnis da ist.

Was man generell sagen kann: Die Struktur lohnt sich bei sehr breiten 
Daten und vielen Kanälen, die unabhänig laufen. "Breite Daten" sind 
solche, die mal wenigstens im Produkt 100x50 Bit haben, damit der 
Verwaltungsaufwand drum herum klein bleibt.

Jordy schrieb:
> Mein Ziel ist ein kleines C-Programm für Forschungszwecke möglichst
> günstig auf Hardware zu beschleunigen.

Jordy schrieb:
> Es handelt sich um einen Algorithmus zur Bestimmung der Performance von
> CRC Polynomen. Also NICHT die Berechnung von CRCs, das ist trivial,
> sondern die Bewertung aller möglichen Polynome.

Da du alle Polynome durchrechnen willst, braucht man deine Arbeit ja nur 
ein mal zu machen, danach weiss man ja dann alles. Darum finde ich es 
etwas übertrieben, dafür extra Hardware zu bauen/zu kaufen die danach in 
den Keller wandert.

So wie du den Algorithmus beschreibst (parallelisierbar ohne 
gegenseitige Abhängigkeit, kleine Ein-/Ausgabedatenmengen, wissenschaft) 
klingt das für mich nach der perfekten Anwendung für BOINC:
https://boinc.berkeley.edu/

oder vielleicht einfacher sich an ein Meta-Project zu wenden wie z. B. 
Yoyo:
https://www.rechenkraft.net/yoyo/

Jürgen S. schrieb:
> Mit einem Stack man man strukturell schon komplett verloren

Nicht zwingend, es gibt genau fuer solche Zwecke dedizierte 
Stack-Maschinen, die sind auch klein genug, dass man einige davon 
parallel auf einem FPGA roedeln lassen kann. Geht etwas in Richtung der 
auf beiden Ufern (Hardware, Software) vergessen gegangenen 
Transputer-Konzepte.
Aber da ist nichts mit HLS a la Xilinx, man muss sich den Mikrocode 
manuell entwerfen/auf das Kernproblem anpassen. In klassischer HDL ist 
das kaum noch sinnvoll machbar, insofern bliebe das fuer eine solche 
Anwendung ein teurer akademischer Spass.

Kritiker schrieb:
> Berkley bei kritischen mathematischen Problemen mitlesen zu lassen,
> damit sie gleich die Resultate haben ... hm (?)

Wenn du dein eigenes BOINC Projekt hast, musst du auch eigene Server 
betreiben um Arbeit zu verteilen/einzusammeln. Da liest Berkley nicht 
mit (ausser die Arbeitspakete die sie vielleicht für dich rechnen).

@InvalidFacts Ich werde das was Du sagst auf jeden Fall beachten. Vielen 
Dank! Denn mein erstes Ziel ist die GPU-Implementierung. Im Augenblick 
bin ich aber noch an Test-Code dran, damit ich prüfen kann, ob die 
alternativen Implementierung tatsächlich die identischen Ergebnisse 
bringen.

@strubi Stack-Maschinen sind mir kein Begriff. Hast Du irgendwas 
besonders lesenswertes bei der Hand?

Bitte bedenke, dass ich mit FPGAs noch nichts gemacht habe. Welche 
Sprache, welche Entwicklungsumgebung und welche FPGA-Familie würdest Du 
empfehlen?

Im Augenblick bin ich noch ziemlich am schwimmen. Es hat ja Beiträge 
gegeben, die sich sicher sind, dass eine FPGA-Optimierung möglich ist 
und andere, die das für unmöglich halten.

@christophz

Das Problem ist so komplex (und zu dem nach oben offen)... die Hardware 
kann garnicht speziell genug sein. Nur das Geld ist ein Limit. Denn noch 
ist es ein Hobbyprojekt.

In jedem Fall danke ich für die vielen Hinweise. Was ich definitiv 
verstehe ist, dass die Schwierigkeit des Problems nicht zu unterschätzen 
ist und, dass ich mit High-Level Sprachen nicht weit komme. Auch, dass 
ich nicht jeden X-beliebigen FPGA nehmen kann/sollte.

Unter der Annahme, dass eine effiziente Umsetzung möglich ist: Welche 
Software- und Hardware Plattform würdet ihr mir für einen Versuch 
empfehlen?

Dass mein Weg sehr weit wird, dessen werde ich mir bewusst :-) Um so 
mehr muss ich mit der erfolgversprechendsten Hardware und Software 
anfangen!

Bernhard L. schrieb:
> Welche Software- und Hardware Plattform würdet ihr mir für einen Versuch
> empfehlen?

Software von FPGA Herstellern, also Vivado und Quartus. Da ist jeweils 
ein Simulator mit dabei und auch IPs der Hersteller um die DSP-Blöcke in 
den FPGAs möglichst gut zu nutzen. Jeder DSP im FPGA hat/ist quasi eine 
kleine ALU wenn man den so nutzen möchte.
Das ist die Lektüre zu den DSP48E2 Blöcken:
https://www.xilinx.com/support/documentation/user_guides/ug579-ultrascale-dsp.pdf

Bernhard L. schrieb:
> Auch, dass ich nicht jeden X-beliebigen FPGA nehmen kann/sollte.

Da nimmst du erstmal gar keinen. Das lässt sich alles ganz ohne FPGA 
zusammenbauen. Iin der Synthese siehst du dann wie viele Ressourcen das 
so braucht. Und davon machst du dann abhängig welches FPGA du kaufen 
magst/musst oder ob du das lieber doch noch weiter optimierst damit das 
weniger Ressourcen braucht und in ein günstigeres FPGA passt.

Ich vermute die Auswahl zwischen Vivado und Quartus entspringt der 
Entscheidung ob ich Xilinx oder Intel FPGAs verwenden will. (Ich gehe 
davon aus, dass die jeweilige Software auch nur die Bausteine des 
Herstellers unterstützt)

Kannst Du mir bei dieser Entscheidung helfen? Gibt es technologisch 
entscheidende Unterschiede? Preisliche? Bezüglich Größe? Sonstige 
Unterschiede die für meine Anwendung entscheidend sein könnten? Oder 
ähneln sich die Produkte inzwischen so stark, dass ich das 
vernachlässigen kann?
Wenn die Unterschiede nicht ins Gewicht fallen, wäre die Erlernbarkeit 
der IDE ein gutes Entscheidungskriterium für mich.

Ich bin mir nicht sicher, wie nützlich die DSPs mir sein werden. 
Voraussichtlich werde ich keine Multiplikation und Addition benötigen. 
Andererseits lassen sich offenbar die ALUs zusammenschalten für 
Bitbreiten >48 und Logikfunktionen beherrschen sie auch. Ich werde wohl 
einfach ausprobieren müssen.

Bernhard L. schrieb:
> Es hat ja Beiträge
> gegeben, die sich sicher sind, dass eine FPGA-Optimierung möglich ist
> und andere, die das für unmöglich halten.

Dazu bringe ich immer mein Waldbetrachtungsbeispiel:

2 Förster berichten von ihren Erfahrungen im Wald.
Der eine sagt:   "Im Wald gibt es       Rehe".
Der andere sagt: "Im Wald gibt es keine Rehe".

Was schlussfolgern wir?

Meine Behauptung: Im angedachten FPGA-Wald ließen sich deine rechnenden 
Rehe züchten und ernähren. Die Frage ist nur:
- schafft man es, die Genetik für sie zu definieren?
- wieviel Aufwand ist es, sie zu erschaffen
- wieviele Rehe braucht man überhaupt, um die Rechnung zu schaffen?
- wie muss man sie positionieren und komunizieren lassen
- wie groß muss der Wald sein
- wieviel fressen die Rehe?

Was man sagen kann: Holz ist derzeit sehr teuer und kaum zu 
beschaffen.:-)

Gfs sind normale, durchschnittlich schlaue Rehe ohne Genmodifikation in 
einem anderen Wald einfacher zu halten.

Bernhard L. schrieb:
> Ich vermute die Auswahl zwischen Vivado und Quartus entspringt der
> Entscheidung ob ich Xilinx oder Intel FPGAs verwenden will.

Bernhard L. schrieb:
> Kannst Du mir bei dieser Entscheidung helfen?

Ja. Fälle die Entscheidung nicht sofort. Guck dir an wie du das Problem 
optimiert bekommst mit dem was die FPGAs der beiden Hersteller bieten. 
Und dann entscheide dich.

Bernhard L. schrieb:
> Wenn die Unterschiede nicht ins Gewicht fallen, wäre die Erlernbarkeit
> der IDE ein gutes Entscheidungskriterium für mich.

Ist eher nebensächlich. Du kannst deinen Code mit einem Texteditor 
schreiben und mit Gratissoftware wie Modelsim simulieren. In 
Quartus/Vivado drückst du dann nur noch auf Synthese und guckst was 
deine Beschreibung an Ressourcen im ausgewählten FPGA braucht.

Bernhard L. schrieb:
> Ich bin mir nicht sicher, wie nützlich die DSPs mir sein werden.

Ich mir auch nicht. Aber da DSPs feste Hardware sind können die sehr 
hoch getaktet werden. Wenn du einen Funktionen aus LUTs zusammenbauen 
lässt kann es sein, dass das langsamer wird. Die DSPs sind ausserdem 
sehr schön an die BlockRAMs angebunden.

Bernhard L. schrieb:
> Ich werde wohl
> einfach ausprobieren müssen.

Exakt!

Jürgen S. schrieb:
> Gfs sind normale, durchschnittlich schlaue Rehe ohne Genmodifikation in
> einem anderen Wald einfacher zu halten.

Guter Punkt! Vielleicht wäre es der einfachste Weg für eine kurze Zeit 
viele Instanzen bei Amazon rechnen zu lassen. Das könnte deutlich 
günstiger sein als jetzt >> 1 Mannjahr in Entwicklung zu verbraten.

foobar schrieb:
> Ich denke, das bezieht sich auf meine Aussage:
>> Eine FPGA-Implementierung, die schneller als eine hochgezüchte GPU ist,
>> ist sehr schwierig (wenn überhaupt machbar).
>
> Die Betonung liegt dabei auf "schneller als eine hochgezüchtete GPU".

Unklar. GPUs sind auf ganz andere Dinge optimiert. Wenn es hier um sehr 
viele parallele Logikfunktionen geht, dann könnte das schon dass eine 
FPGA Lösung am Ende deutlich schneller ist. Bei diesen Cryptominern ging 
es am Anfang auf CPUs los, dann ging es auf GPUs, dann auf FPGAs und 
dann zu ASICs. (Wobei Manches - speicherintensive Crypto - weiterhin auf 
GPUs geminet wird.)

Eine Implementierung für GPUs geht vermutlich sogar schneller. Und für 
CPUs in ordentlich parallel noch schneller. Da sollte er wirklich 
durchrechnen wie viele CPU-Kern-Sekunden er braucht und das gegen 
Entwicklungskosten + GPU-Sekunden oder so stellen.

Gustl B. schrieb:
> Gratissoftware wie Modelsim simulieren
wobei man sagen muss, dass ModelSIM nur bei Altera gratis ist. Will man 
Xilinx-Designs compilieren, muss man die LIBs erstellen und scheitert 
oft trotzdem immer schneller, weil Xilinx dazu übergeht, jeden Krümel an 
VHDL zu verschlüsseln.

Kann also sein, dass das Angebot Alteras, nämlich einen freien Simulator 
zur Verfügung zu stellen, doch wieder mehr zieht und sich mehr auf 
Altera stürzen, nachdem die Produktpalette und das CORE-Angebot in der 
letzten Dekade dafür gesorgt hatte, dass auch Bastler mehr mit Xilinx 
begonnen haben.

Gustl B. schrieb:
> bei Amazon rechnen
Bei Amazon???

Gustl B. schrieb:
> könnte das schon dass eine
> FPGA Lösung am Ende deutlich schneller ist.

Das ist in aller Regel sogar so. Und das ist so, weil ich im FPGA die 
Hardware genau so bauen kann, dass sie die Aufgabe optimal packt. 
Konkret dürfte hier beim Integer auch ein großer Vorteil der CPUs/GPUs 
wegfallen.

Bernhard L. schrieb:
> @strubi Stack-Maschinen sind mir kein Begriff. Hast Du irgendwas
> besonders lesenswertes bei der Hand?

Nicht wirklich, da solche Architekturen eher Nischendasein fuehren. Es 
gibt ein paar interessante Referenzen wie ZPU, oder die J1 (sehr 
kompakt).

Spannend sind noch die 'alten Sachen':
http://people.cs.bris.ac.uk/~dave/transputer.html

Ich denke aber, fuer deine innere Schleife brauchst du das nicht, 
hoechstens fuer das balancierte Fuettern deiner n-fach instanzierten 
Pipelines.

Da du ja eine Rekursionstiefe von max. 64 hast, kannst du die Rekursion 
relativ ueberschaubar 'entrollt' ausmodellieren. Unklar war mir beim 
Drueberlesen, was populationCount() macht. Geht's bei der Geschichte um 
die Hamming-Distanz? D.h. zaehlt populationCount die gesetzten Bits?
Da gibt es diesbezueglich in der Hash-Industrie (kleines Wortspiel..) 
schon FPGA-Implementierungen die richtig Durchsatz machen.


> Bitte bedenke, dass ich mit FPGAs noch nichts gemacht habe. Welche
> Sprache, welche Entwicklungsumgebung und welche FPGA-Familie würdest Du
> empfehlen?
>

Mein Favorit ist bereits genanntes myHDL zum Anfangen. Es gibt zwar 
eklige Limitierungen  bei der Konversion in die Transfersprachen (VHDL 
oder Verilog), und bei der Generierung von Logik im HLS-Sinne, aber fuer 
eine Machbarkeitsstudie machst du da wohl am wenigsten Baustellen auf.

Bei den FPGAs bringt die ganze Diskussion oben betr. DSP-Elementen nur 
Verwirrung, meist sind die so verteilt, so dass bei der 
Kaskadierung/Massen-Instanzierung die Performance in die Knie geht. Da 
du v.a. XOR-Gates brauchst, sind die eh nicht sonderlich dienlich. Also 
kannst du jegliche Vorauswahl mal offen lassen (Rhetorische Frage: 
Wieviel Zeit hast du, um dich mit den Tools rumzuschlagen..)

ich hatte mich mit CRC für Ethernetverbindung beschäftigt.


Hier war meine Diskussionsrunde dazu.

Beitrag "Ethernet GMII"

Das Polynom der Verschlüsselung war aber konstant.

Jordy schrieb:
> Es handelt sich um einen Algorithmus zur Bestimmung der Performance von
> CRC Polynomen. Also NICHT die Berechnung von CRCs, das ist trivial,
> sondern die Bewertung aller möglichen Polynome.

Bin ich da jetzt völlig paranoid, oder liefert dieses Forum einem 
ominösen Professor X und seinem Jordy Hinweise dazu, wie man CRCs 
reverse "bescheißen" kann? CRC Polynome sind so ungefähr der heilige 
Gral, wenn es um CRCs geht. Mit genügend schnellen Systemen kann man da 
ne Menge Unsinn anstellen.

Carsten P. schrieb:
> CRC Polynome sind so ungefähr der heilige
> Gral, wenn es um CRCs geht. Mit genügend schnellen Systemen kann man da
> ne Menge Unsinn anstellen.

Na und? Wenn man das kann, dann kann man das.
Wenn Professors X‘s Jordy das mit seinem Taschengeld-Budget hinbekommt, 
ist das woanders schon längst kein Problem mehr.

Oliver

Oliver S. schrieb:
> Na und? Wenn man das kann, dann kann man das.
> Wenn Professors X‘s Jordy das mit seinem Taschengeld-Budget hinbekommt,
> ist das woanders schon längst kein Problem mehr.

Das fürchte ich auch, und wir geben da noch Input. Wobei das auch wieder 
eine gute Seite hat, denn dann muss sich die "andere" Seite auch wieder 
bewegen und besser werden.

Carsten P. schrieb:
> CRC Polynome sind so ungefähr der heilige
> Gral, wenn es um CRCs geht. Mit genügend schnellen Systemen kann man da
> ne Menge Unsinn anstellen.

Der oben skizzierten 'Hash-Industrie' ist nichts heilig und es macht 
auch durchaus Sinn, Polynome mit Referenz-Daten brute-force durch 
FPGA-Banken zu schicken. Die obige Problemstellung duerfte 
schlussendlich dieselbe sein wie beim Hash-Mining fuer Digitalwaehrung 
unterschiedlichster Art.
Um die Guete von CRCs bezueglich typischer Datenstroeme zu bestimmen, 
muss man sich damit beschaeftigen, insbesondere dann, wenn es um den 
Nachweis von Fehlerraten geht. Die alten Hasen erinnern sich vielleicht 
noch an die argen Schwaechen des XMODEM-CRC...

Martin S. schrieb:
> Die alten Hasen erinnern sich vielleicht
> noch an die argen Schwaechen des XMODEM-CRC...

Ja, da hast du Recht. Ich muss mich dringend mal wieder mit Krypto 
befassen. Bisher habe ich noch jedes System dicht bekommen, indem ich 
unter anderem Schlüssel mit Faktor 4 benutzt habe, also wenn 
1024-Bit-Schlüssel up-to-date waren, habe ich 4096-er benutzt. Aber ich 
bin mir recht sicher, dass der erste Quantencomputer, der über sowas 
lacht und ein paar Sekunden dafür braucht, in China stehen wird. Und der 
chinesischen Regierung ist es erstens völlig wurscht, wie freundlich wir 
hier in diesem Forum zueinander sind, und zweitens wird sie ihre 
Technologie an den verkaufen, der zahlt, sei es eine Mafia, seien es die 
Geheimdienste der USA (mit Hinter(n)tür in diesem Fall natürlich).

Weltbester FPGA-Pongo schrieb im Beitrag #6934723:
> Geht es hier jetzt um die Sicherung der Daten im Sinne der
> Fehlerkorrektur (Fokus auf Effizienz) oder dem Schutz vor dem Ausspähen
> (Fokus auf Kryptosicherheit)?
>
> Wir machen das so, daß diese beiden Punkte getrennt sind und es mehrere
> Sicherheitsstufen gibt. Wir übertragen z.B. (wirklich nur ein Beispiel)
> eine 8 Bit Folge als 11 Bit Wort, die Matrix aus 10 Worten mit einem 11
> Bit FEC, der selber mit 7 Bit geschützt ist -> 128 Bit. Dann wird eine
> Anzahl von z.B. 8 solcher Pakete mit 2-4 Worten an Rauschinformationen
> und Täuschinformationen (einen scheinbaren Muster) aufgefüllt. Erst
> danach wird AES-codiert unter Verwendung eines dedizierten Schlüssels,
> der aber für die nächsten 8/6/32 wieder getauscht wird.
>
> Mit brute force kommt man da nicht weiter, weil dem Knacker nicht
> bekannt ist, wieviele Schlüssel er durch probieren muss und auch kein
> echtes Kriterium findet, ob ein Datenstrom valide ist, oder nicht.
> Selbst MIT Schlüssel findet man nach dem Decodieren nur einen
> Scheindatenstrom, der anhand der Musterworte ein Scheinmuster aufwirft,
> das zu dekodierbaren, aber nicht interpretierbaren Daten führt. An der
> Stelle sorgt das Protokoll dafür, dass durch Hacker dekodierte Daten
> verworfen werden.

Der Ansatz klingt gut. Ihr habt da bestimmt noch das eine oder andere 
Goodie, das du hier nicht ausplaudern magst.

Und eigentlich ist das ein eigenes Thema, das mit dem des OPs nix mehr 
zu tun hat, aber solange er sich nicht beklagt... ^^

Ich mag grundsätzlich 4 Punkte zur Krypto allgemein anmerken.

1. Security By Obscurity ist keine gute Idee. So obskur etwas auch 
erscheinen mag, mit genügend Hirnschmalz oder Rechenpower 
(Mustererkennung) kommt man auf den Kniff.

2. Security By Secrecy ist keine gute Idee. Wir leben in einer miesen 
Welt, es gibt miese Menschen. Entweder Geld oder Folter machen Menschen 
weich, und wenn es in Bereiche der jeweils nationalen Sicherheit oder 
militärischer Geheimnisse geht, gibt es Staaten, die die Geheimnisse 
wissen wollen, und es gibt Menschen, die Mittel und Wege finden werden, 
dir die Geheimnisse zu entlocken. Hast du Kinder? Das meine ich übrigens 
in keiner Weise zynisch oder "lustig".

3. Security By Disclosure ist eine sehr gute Idee. SHA, AES, RSA, PKCS 
usw usw sind nur deswegen weltweit so anerkannt, weil jeder den Code 
laden, lesen und analysieren kann -- und weil das auch ständig Leute 
machen. Inzwischen sind die Leitungen im Internet schnell genug, auch 
recht große Datenpakete, die mit RSA und genügend langen Schlüsseln 
verpackt sind, durch die Gegend zu schicken, und die Computer sind, wenn 
es denn wirklich wichtig ist, im Preis/Leistungs-Verhältnis weit in 
Richtung Leistung geneigt.

Hier etwas zum Lesen:
https://www.extremetech.com/extreme/316266-the-nvidia-rtx-3090-gpu-can-probably-crack-your-passwords

4. Mit Quantencomputern wird das alles noch ganz anders aussehen. Mit 
ein bisschen Nachdenken kommen wir doch alle darauf, dass etwa China 
nicht so unfassbar viel Geld in das Quantencomputing steckt (und die USA 
auch nicht), weil sie damit Messwerte vom James Webb-Teleskop besonders 
schön auswerten will oder PI auf die letzte Stelle berechnen möchte für 
einen Eintrag als Rekordhalter. Die möchten den Generalschlüssel für 
alle digitalen Schlösser dieser Welt.

Aber so schwer ist das eigentlich gar nicht. Es kommt immer darauf an, 
was du haben möchtest. Möchtest du wissen, wann ich zuhause bin? Dann 
könntest du dich natürlich bei mir auf die Lauer legen und mich 
observieren. Oder du könntest eine "WLAN-Falle" aufstellen, die alles an 
Datenpaketen an dich überträgt, was meine Bude so durch die Gegend 
sendet. Da langt dir eigentlich schon der gesunde Menschenverstand: Je 
mehr unterschiedliche Datenpakete es sind, desto wahrscheinlicher werde 
ich gerade da sein. Wenn es immer nur dieselben "NOP"-Blöcke sind, dann 
bin ich wohl außer Haus.

Du weißt sicher selbst, dass das ganze Smart-Home-Zeug in Sachen 
"Preis/Leistung" vor allem billig sein muss, damit es sich unter die 
Leute bringen lässt. Im Automotive-Bereich ist es nicht anders, und auch 
bei Railway, Aviation, Energy, Healthcare sieht das nicht viel besser 
aus.

Ich rede hier nicht von oller Kinderpornografie. So beschissen das wie 
in Bergisch-Gladbach war, und so traurig und einfach nur widerlich: Das 
waren "nur" ein paar hundert Kinder und perverse Arschlöcher. (Das wäre 
übrigens mal eine prima Anwendung für eine ganze Batterie aus 3090ern: 
deren Verschlüsselung zu knacken, die Pervs zu überführen und sie 
ruck-zuck, nicht erst nach zwei Jahren ekliger und ewiger Ermittlungen 
dingfest zu machen und zu verurteilen.)

Woran ich denke, sind Anschläge wie 9/11, einfach von einer Konsole aus 
ausgeführt. Kapere ein paar Satelliten und die Steuerungen von nicht 3, 
4, 5 Flugzeugen, sondern von 50, 100, alles, was du kriegst, löse die 
Feuerlöscher in den Cockpits aus, um die Piloten k.o. zu setzen, und 
dann lässt du die Maschinen auf besonders neuralgische Punkte abstürzen. 
Dann störst du die TK-Infrastruktur und lügst den USA mit entsprechend 
manipulierten Datenpaketen vor, dass es die Russen waren, aber so, dass 
die Geheimdienste darauf kommen, dass es eigentlich China war.

Klingt nach James Bond?

Noch helfen längere Schlüssel. Mal schauen, wie lange noch.

Carsten P. schrieb:
> Ich mag grundsätzlich 4 Punkte zur Krypto allgemein anmerken.

Es fehlt Punkt 0:
Security by selbstgebastelter „Hochsicherheitsverschlüsselung„ ist gar 
keine gute Idee, auch nicht, wenn man Pongo heißt.

Carsten P. schrieb:
> Hier etwas zum Lesen:
> 
https://www.extremetech.com/extreme/316266-the-nvidia-rtx-3090-gpu-can-probably-crack-your-passwords

Aber nicht irgend einen ernsthaften Schlüssel. Ein symmetrischer 
256-Bit-Schlüssel hat über 1e77 mögliche Werte. Ende der Diskussion über 
brute force.

Und ob die Quantencomputer vor einer quantencomputersicheren 
Verschlüsselung einsatzbereit sein werden, ist immer noch mehr als 
fraglich.

Den heute abgegriffenen und vorratsgespeicherten Daten hilft eine solche 
neue Verschlüsselung zwar nicht, aber den Datenhaufen muß dann auch erst 
einmal jemand auswerten.

Oliver

Oliver S. schrieb:
> Es fehlt Punkt 0:
> Security by selbstgebastelter „Hochsicherheitsverschlüsselung„ ist gar
> keine gute Idee, auch nicht, wenn man Pongo heißt.
Der heißt "Pengo" ;-)

> Aber nicht irgend einen ernsthaften Schlüssel. Ein symmetrischer
> 256-Bit-Schlüssel hat über 1e77 mögliche Werte. Ende der Diskussion über
> brute force.
>
> Und ob die Quantencomputer vor einer quantencomputersicheren
> Verschlüsselung einsatzbereit sein werden, ist immer noch mehr als
> fraglich.
Ja, bisher. Dennoch sollte man sich vorsorglich mit Themen wie KINDI/PQC 
befassen.

Carsten P. schrieb:
> CRC Polynome sind so ungefähr der heilige
> Gral, wenn es um CRCs geht.

Eigentlich nur, wenn es "unheilige" Polynome sind, weil die heiligen 
(z.B. die "goldenen") allesamt bekannt sind. Die wurden schon in den 
1970ern untersucht und publiziert.

Oliver S. schrieb:
> Carsten P. schrieb:
>> Hier etwas zum Lesen:
>>
> 
https://www.extremetech.com/extreme/316266-the-nvidia-rtx-3090-gpu-can-probably-crack-your-passwords

Wenn man es einem System von aussen erlaubt, mit 1MHz Schlüssel zu 
probieren, ist das logisch. Wenn aber PWD-Sicherungssysteme nach 3 
mislungenen Versuchen einen timeout machen, kriegt man nur wenige 
samples aufs Target, bis es schließt. Auch bei einem Geldautomaten, 
kommt man ohne die echte Pin nicht weit, obwohl es nur einige Tausend 
Kombis gibt.

Jürgen S. schrieb:
> Wenn man es einem System von aussen erlaubt, mit 1MHz Schlüssel zu
> probieren, ist das logisch. Wenn aber PWD-Sicherungssysteme nach 3
> mislungenen Versuchen einen timeout machen, kriegt man nur wenige
> samples aufs Target, bis es schließt.

Und das sollte wohl Standard sein, wobei das natürlich auch als "Waffe" 
eingesetzt werden kann, und sei es nur, um den Nachbarn zu nerven, weil 
man das Piep-Piep-Funkschloss von seiner Karre damit blockieren kann. Es 
lebe der handgefeilte Nachschlüssel! ^^