Schlüssel: Brute force

May 01, 2024 Last reply: 2 years ago 367 Replies

On Fri, 2024-05-03 at 10:25 +0200, Marc Haber wrote:

Ohne "h".

Zumal solche Softwarehäuser notorische Geheimniskrämer sind, nicht öffentlich gewordene oder ihrer Ansicht nach "harmlose" Bugs oft monate- bis jahrelang nicht fixen oder sowieso unter der Fuchtel von "Diensten" stehen.

Ja, die Linux xz/liblzma Utility Backdoor [1][2] war auch nicht gerade ein Ruhmesblatt, aber solche Dinge passieren eben, wenn es keine Peer/Code Reviews gibt und für ein eher undankbares Projekt nur ein einziger (freiwilliger) Entwickler zuständig ist, auf dem die Community auch noch rumtrampelt.

Auf der anderen Seite:

formatting link
... Na also, ich weiß nicht so recht.

Volker

[1]
formatting link
formatting link

Jetzt weiß ich, was mich an dem Wort irritiert hat ;)

Ja, und bei kommerziellen dürfte es oft vorkommen, dass solche Vorfälle einfach vertuscht werden. Dass Solarwinds nach dem Vorfall noch genausoviele Kunden gehabt hat wir vorher, das ist nicht zu vermuten, die Motivation ist hoch, sowas nicht publik zu machen, selbst wenn man draufkommt. Und solche Backdoors in diversen Fernwartungs/Softwareausroll-Tools hat es einige gebeben.

/ralph

formatting link
Kann im ersten Absatz nachgelesen werden.

Das ist eine falsche Behauptung.

Ich habe die Testsuite wochenlang praktisch betrieben. Folglich weiß ich genau, was die untersucht. Und zwar wird _nur_ die Ausgabe des Algorithmus untersucht. Es wird _nur_ der Grad von deren Zufälligkeit festgestellt. Das ist die grundlegende Eigenschaft eines jeden kryptographischen Algorithmus.

Wenn eine Ausgabe zufällig ist, können z.B. Teile des Schlüssels nicht in der Ausgabe enthalten sein, denn in diesem Fall wäre die Ausgabe nicht zufällig.

Ah ja, daß die Testsuite mittels 15 Tests ihre Eingabe testet, ist ein Trugschluß?

Ich habe nie behauptet, daß die Testsuite die Gesamtqualität eines Algorithmus unter Einschluß aller Aspekte testet. Du jedenfalls willst offenbar hartnäckig den Eindruck erwecken, ich hätte dies behauptet.

Helmut Schellong schrieb:

Nein, das sollen sie natürlich nicht! Sie sollen den Eingabedatenstrom in einen Datenstrom verwandeln, der zwar zufällig aussieht, der Zeichen gleichverteilt enthält, der aber natürlich auch noch immer den Inhalt des Eingabedatenstroms enthält

Du kapierst wirklich nicht, was das Problem ist?!

Das wäre allein bei einem Zufallszahlengenerator ein Ziel

Das ist natürlich auch falsch. Allzuoft entstehen Schwächen und Fehler nicht durch eine Schwäche der jeweiligen Algorithmen sondern durch eine fehlerhafte Umsetzung dieses Algorithmus in konkrete Software. Und es nützt leider nicht das Geringste, wenn ein einfältiger Programmierer sich über sein Werk freut, welches zwar durchaus mal dem naturgemäß allzu begrenzten Prüfungsumfang einer Testsuite standzuhalten vermag, aber daneben dann eben den ein oder anderen Schwachpunkt, das ein oder andere offene Scheunentor aufweist, weil der Kasper von Programmierer in all seiner Hybris nicht fähig ist, durch professionelle Gestaltung des Entwicklungsprozesses Fehler zu vermeiden und weil er, anders als fähige Programmierer, nicht einmal auf die naheliegende Idee kommt, sein Produkt, jede einzelne Zeile seines Produkts einem Code-Review durch ein paar unabhängige Dritte zu unterwerfen.

MfG Rupert

Leider hast Du nicht weitergelesen oder es wie üblich nicht verstanden.

Das Durchlaufen einer Testsuite sagt Dir, dass es sich lohnt, mit dem ernsthaften Test der Software anzufangen.

Bricht sie ab, brauchst du keine weitere Energie in richtige Tests zu investieren.

Die Testsuite ist Schritt 1 von X eines Softwaretests.

Wir hatten das bereits, wird wohl ein-zwei Jahre her sein: Unit Tests wurden bestanden -> Software ist fehlerfrei. Vergessen, ignoriert, nicht nachvollzogen.   Idiotie manifestiert sich in vielerlei Hinsicht: Groteske Selbstüberschätzung, mangelnde Introspektion, Unfähigkeit zur logischen Schlußfolgerung, Schwächen bei Transfer, Genereralisierung und Abstraktion. Naive Gutgläubigkeit, fehlende Kritikfähigkeit, mangelnde Sorgfalt, Unfähigkeit zum methodischen bzw. wissenschaftlichen Vorgehen, NIHS/kategorische Ablehnung etablierter Standards, unsaubere, schlampige Ausdrucksweise und vieles mehr.

Sollen wir für Chuck Schellong eine Liste anlegen?

Volker

Diese Antwort ist einfach Unfug und zeugt von hochgradiger Inkompetenz zum Thema.

Du bist es, der nur Behauptungen von sich gibt - wegen Inkompetenz und Hilflosigkeit.

Nein, das ist eigentlich bei allen kryptographischen Algorithmen der Fall. Also bei Verschlüsselungen, Zufallszahlen-Generatoren, Hash-Generatoren, ...

Das ist einfach pauschales, dummes Geschwalle, mangels echter Argumente, die hier mangels Kompetenz ausbleiben.

Wie bei Dir üblich - komplett unbegründete Behauptungen. Ich habe den Artikel schon vor Jahren wiederholt gelesen und verstanden.

Meine Antwort oben bezieht sich ausdrücklich auf den ersten Absatz (s.u.). Hast Du Probleme mit Deutsch?

Gegenüberstellung:

|Der Advanced Encryption Standard (AES) ist eine Blockchiffre, die als Nachfolger des DES |im Oktober 2000 vom National Institute of Standards and Technology (NIST) |als US-amerikanischer Standard bekanntgegeben wurde. |Der Algorithmus wurde von Joan Daemen und Vincent Rijmen unter der Bezeichnung Rijndael entwickelt.

"Der ursprüngliche Name, bevor es vom NIST als Adanced Encryption Standard normiert wurde."

Normalerweise teste ich nur, ob die Referenz-Ausgabe übereinstimmt. Und keinerlei weitere Tests - weil die unnötiger Ballast wären.

Das reichte völlig zur Implementierung von RABBIT, DRAGON, SHA2-xxx, SHA3-xxx, SPRITZ, ... Du tust seit Tagen so, als ob ich selbst kryptographische Algorithmen entwickelte. Das wirkt mittlerweile albern, und läßt über Deinen Geisteszustand nachdenken.

Das stimmt so nicht. Auch damals schon waren die Referenz-Ausgaben übereinstimmend. Unmittelbar nach der Implementation, vor der Testsuite. Das ist der absolute Beweis der Korrektheit der Implementation.

| This is a set of test vectors for conformance testing, given in octet | form. For use with Rabbit, they have to be transformed into integers | by the conversion primitives OS2IP and I2OSP, as described in [5].

Solche Auslassungen deuten auf Irrsinn Deinerseits hin.

Den Witz kapier ich jetzt nicht. Bitlocker statt Truecrypt? Weia.

Warum behauptest Du dann man könnte AES mit anderen Blockgrößen als

128 haben?

Nein. Es ist der Beweis dass die Tests bestanden wurden. Tests sind aber niemals vollständig.

Das ist fehlerhaftres Vorgehen.

Das ist ein Trugschlus.

Nein.

Ich habe ein effizientes Programm zur Errechnung von Primzahlen erfunden. Ohne Durchprobieren!

int Prim(int i) { static const int v[10] = { 2, 3, 5, 7, 11, 13, 17, 19, 23, 29 }; return v[i%10]; }

Mein Unit-Test für i∈[0;9] war erfolgreich.

Volker

Helmut Schellong, 2024-05-01 12:15:

Ja. Denn "3,31 * 1056 Jahre" sind halt nicht "mehrere Erdenzeitalter" sondern 3495,36 Jahre. Wieso diese seltsame Schreibweise gewählt wurde, statt einfach die Zahl der Jahre zu nennen, ist auch unklar.

Und statt mehr Zeit kann man auch einfach mehr Hardware investieren.

Welche "studierten Fachleute"?

Laut

formatting link
ist der Betreiber der Website der "VFR Verlag für Rechtsjournalismus GmbH". Welche "Fachleute" für das Thema Verschlüsselung sollen da sein?

Es handelt sich, wie irgendwo anders in diesem Thread diskutiert, vermutlich um einen OCR-Fehler bei der Exponentialschreibweise. Gemeint ist 3,31 * 10^56 Jahre.

Ich würde auch andere Fehler in diesem Dokument (AES statt DES etc.) potentiell als durch schlampiges Konvertieren/Scannen entstanden vermuten.

/ralph

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required