Schlüssel: Brute force

Helmut Schellong, 2024-05-01 17:40:

Die Website nutzt WordPress. Da ist es absolut kein Problem "3 * 10^18" einzugeben oder per Copy & Paste zu übernehmen. Man gibt im Eeditor von WordPress auch kein HTML von Hand ein.

Dort gibt es aber noch andere Merkwürdigkeiten, die darauf schließen lassen, dass das alles nur hingeschludert wurde, weil es nicht viel kosten sollte:

Zitat:

"Impressum

Von Louisa N. Letzte Aktualisierung am: 27. Februar 2024 Geschätzte Lesedauer: < 1 Minute

Angaben gemäß § 5 TMG: ..."

Offenbar wissen die Betreiber nicht, dass man in WordPress auch statische Seiten ohne Autorenangabe anlegen kann. Ebenso kann man verschiedene Vorlagen für Seiten erstellen, je nach dem, ob eine Autorenangabe vorhanden sein soll oder nicht.

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

Das ist einfach nur Stümperei um mit einem weiteren Lockangebot Geschäfte zu machen. Mit "Fachwissen" hat das nichts zu tun. Sich darüber aufzuregen ist vergeutete Lebenszeit.

Laut

Hier sind die genaueren Details aufgeführt:

Ziemlich umtriebig der Mann als Geschäftsführer von nicht weniger als sechs(!) Firmen:

- VFR Verlag für Rechtsjournalismus GmbH

- DGP Deutsche Gesellschaft für Prozessfinanzierung mbH

- Legal One GmbH

- Legal One Software GmbH

- Green Offices Schwerin GmbH

- Fox Internet Beteiligungsgesellschaft mbH

Und wenn man bei North Data noch etwas weiter schaut, findet man noch mehr. Das ist halt das typische Geflecht von "Unternehmern", die ihr Geld über diverse Firmen verteilen, damit der Weg des Geldes nicht so leicht nachvollziehbar ist.

Helmut Schellong, 2024-05-02 12:22:

Ja - derzeit.

Bei AES vermutlich nicht, nein. Aber es gibt ja nicht nur AES.

Mit AES meinte und meine ich den _Algorithmus_, der ja gleich mit Rijndael ist. Ich habe es absichtlich vermieden, Rijndael stattdessen zu erwähnen.

|This standard specifies the Rijndael algorithm ([3] and [4]), a symmetric block cipher |that can process data blocks of 128 bits, using cipher keys with lengths of 128, 192, and 256 bits. |Rijndael was designed to handle additional block sizes and key lengths, however |they are not adopted in this standard.

Ich schrieb 02.05.2024, 16:00 : |AES hat jedoch keine Schlüssellänge von 56!, sondern 128, (160,) 192, (224,) 256.

Es werden halt keine standardisierten key sizes verwendet, wenn 160 oder 224 gegeben werden. Es muß deshalb nicht streng betont werden, das sei dann nicht mehr AES. Die vorstehende Definition des Standards gilt.

Die Entwickler der Algorithmen äußern, daß eine Übereinstimmung mit den Test-Vektoren die Korrektheit der Implementation beweist. Das ist ja bei deterministischen Algorithmen gar nicht anders möglich!

| 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].

Es muß nicht die gesamte Ausgabe von jeweils 2^68 Byte für jeden der 2^192 keys auf Gleichheit geprüft werden! Darauf willst Du offenbar hinaus. Das ist aber Wahnsinn und völlig unnötig zugleich.

Nein. Was muß denn zwingend sonst noch getestet werden, was die Entwickler nicht bereits taten?

Nein, ist es nicht.

Es reicht vollkommen aus.

Irgendwie spinnst Du Dir hier etwas gehörig zusammen! Die Entwickler und weitere Kryptographen haben die Algorithmen innerhalb von Jahren vielleicht 1000-fach stärker getestet, als wir oder fast der Rest der Welt das könnte. DESHALB muß _ich_ keine weiteren Tests durchführen. Du wischst die Erkenntnisse der Welt einfach hinweg.

Du bist zum Thema ein inkompetenter Spinner.

Nein, es nützt einfach nichts. Ich war schon bei einer Milliarde von Kernen, die vollkommen ohne Chance sind.

Steht im Artikel unten - unübersehbar.

. Future System Use Parameter Legacy Near Term Long Term Symmetric Key Size k 80 128 256

Die 'enisa' nennt 256 Bit sicher, auch langzeitig in der Zukunft. Unabhängig vom Algorithmus.

Siehe oben.

Wenn kein Fehler in AES-256 ist und das Landauer Limit existiert, dann bis in alle Ewigkeit.

Gerrit

Also muss man nur SSH in http oder https verstecken und hat gewonnen. Soll heissen, für die Box muss es wie http aussehen, für die Gegenseite hingegen nicht.

Gerrit

Marco Moock schrieb:

Marc hat die Antwort gegeben. Es ging hier um Verschlüsselung und nicht um das Knacken von Passwörtern. Letzteres ist immer möglich, ersteres nicht. Sobald der Schlüssel gleich lang oder länger als der Text ist, kann man die Verschlüsselung beweisbar nicht mehr knacken. Etwa beim expliziten oder impliziten one-time-pad.

...

Hab ich ja. Von Pentium nach Core2 gab es einen Sprung von einem Faktor 2. Vormals von 386 nach 486 um einen Faktor 4. Später von Core2 nach core i einen Sprung von etwa Wurzel zwei. Merkse was?

Die single-thread-Rechenleistung hat vom E8500(2008) zu was heutigem i7-12nnn oder so um etwa einen Faktor 3 zugenommen. In mehr als einem Jahrzehnt. Das geht schon länger in Sättigung.

Oder innerhalb der Familie: Vom i7-2600K (Ende 2010) bis zum i7-10700K (Mitte 2020) ein Faktor von 1.6. Das ist unterhalb 5% pro Jahr.

In dieser Zeit hat AMD kräftig aufgeholt, eher mit 10%-15% pro Jahr. Mittlerweile hingegen findet man AMD nicht mehr unter den Top 20 Desktopprozessoren bezüglich single thread Leistung.

Da wurden zwei Stufen Architektur genommen, hatte ich erwähnt.

Die Leistungssteigerung seit '486 kommt primär und direkt von der Erhöhung der Taktfrequenz, hier etwa von 33 MHz auf 3.3 GHz, damit wir runde Zahlen haben. Bei etwa 6 GHz hört die Vernunft bei Silizium auf. Klar, mit LN2 oder total dekadent mit flüssigem Helium gekühlt geht auch 8-9 GHz. Dass in den nächsten Jahren 100 GHz InP für den Hausgebrauch kommt, halte ich für wenig wahrscheinlich.

Des weiteren hilf Materialschlacht; die Anzahl Transistoren pro Kern stieg von ca. 1 Mio auf 1 Mia. Brachte aber nur etwa einen Faktor 10. Das geht auch in Sättigung.

Was in den letzten Jahren zugenommen hat, ist die Anzahl Kerne. Klar, da hat der grösste Threadripper 96 Stück (x2 Threads). Allerdings ist die Single thread Leistung knapp 4Gops/s und damit im Bereich normaler Büro-PCs.

Es hängt also davon ab, inwieweit man das a) Verschlüsselungsknacken und b) das Passwortknacken parallelisieren kann.

Und wieweit man diese Monster-CPUs wirklich mit vielen Kernen gleichzeitig laufen lassen kann. Die rennen erstaunlich schnell ins thermische Limit. So eine OC-ausgereizte i9-14900KS zieht bei Vollauslastung 400 W und rennt da blitzartig ins thermische Limit. Klar, man kann natürlich die CPU köpfen und mit Flüssigmetall direkt auf die Wasserkühlung kontakten...

Dann doch eher auf GPU auslagern. Und irgendwann merkt man vielleicht, dass spezielle Aufgaben besser mit spezieller Hardware durchgeführt werden sollten.

Genau darauf wollte ich mit meiner rhetorischen Frage hinaus...

Arno Welzel schrieb:

Was genau gefällt dir daran nicht? Und warum? Warum eigentlich sollte bei einem Impressum denn nicht auf den Autor desselben hingewiesen werden (dürfen)? Was genau lässt dich überdies annehmen, dass das aus Kostengründen so geschehen sein soll wie es geschah? Hast du etwa irgendwelche anderweitigen Probleme mit den Betreibern dieser Site?

MfG Rupert

Da ist halt falsch.

Das würde ich in Deiner Situation auch sagen.

Du sprachst weiter vorne von anderen Blockgrößen. Dein Rückzugsgefecht ist sehr durchschaubar.

Arno Welzel schrieb:

Richtig. Und wohl jeder auch nur halbwegs kundige Leser wird binnen einer halben Sekunde oder so erkennen, wie das gemeint ist und kein Wort darüber verlieren... Sich allein über sowas zu mokieren, ist ja schon fast auf Niveau Schellong :->

MfG Rupert

Du hast den Algorithmus implementiert. Deine Implementierung kann fehlerhaft sein. Und dabei bin ich noch nett zu Dir, sonst würde ich sagen sie IST fehlerhaft.

Grüße Marc

Angabe der Schlüssellänge ohne Angabe des Algorithmus (und der Betriebs- art, z.B. CBC statt ECB) ist relativ aussagefrei.

Man liest sich, Alex.

DRAGON hat auch 256 Bit. Ich glaube nicht, daß AES-256 praktisch signifikante Fehler enthält. Sobald ein Algorithmus auftaucht, versuchen die Kryptologen der Welt, Schwächen zu finden. AES wurde 2001 vom NIST als Sieger standardisiert und wurde während des Wettbewerbs getestet. Bisher wurden keine praxisrelevanten Schwächen gefunden, wie berichtet wird.

RABBIT wurde 2003 veröffentlicht. Bis heute wird geschrieben, daß bisher keine Schwächen gefunden wurden. Deshalb wurde RABBIT von der enisa 2013 empfohlen für future use long term. In der neuesten pdf 2014 wird RABBIT abgewertet, wegen eines Angriffs 2013. RABBIT wird von enisa seitdem nur für legacy use empfohlen.

Ich bin deshalb nicht nervös, weil ich stets 128+64 = 192 Bit key verwende. Allerdings hatte ich wegen 128 den Algorithmus DRAGON mit 256 Bit ebenfalls implementiert. Außerdem verwende ich mehrere verschiedene Verschlüsselungen hintereinander.

Es muß folglich auch lange Zeit nach Erscheinen mit einem erfolgreichen Angriff gerechnet werden. Andererseits sind die Institute (enisa, NIST) auch unterschiedlicher Meinung. Enisa empfiehlt beispielsweise etwa 15000 Bit bei asymmetrischer Verschlüsselung, während das NIST hier 2048 Bit für ausreichend hält. Kann sein, daß enisa wesentlich strenger ist als NIST, und NIST entdeckte Schwächen für nur theoretisch hält, während enisa diese auch praktisch für signifikant hält.