Schlüssel: Brute force

Am 02.05.2024 um 10:05 schrieb Marco Moock:

Weil Du als Ergebnis der BF-Analyse *alle möglichen* Texte bis zur Schlüssellänge erhältst. Damit kannst Du Dir den Angriff sparen und einfach alle Permutationen von Zeichen bis zur Schlüssellänge ansehen.

Es geht um Zahlenschlösser für Türen. Da kann der Angreifer nur die Tasten erreichen, die Schließvorrichtung nicht.

TLDR: Deine Idee ist einfach, offensichtlich ... und falsch ;-)

LOL *kicher* *gacker* *auf-dem-Boden-roll* ...

NAT wird selbst bei IPv6 noch praktiziert, gerne aus ... eher fragwürdigen Gründen, aber es ist im Einsatz. Und speziell CGNAT kann man auch prima bei IPv6 einsetzen zu Zwecken der Umsatzsteigerung: wer eine aus dem Internet erreichbare IP will, darf halt extra zahlen.

Und gerade bei grösseren Netzen die intern bewusst nicht routebaren IP-Bereich einsetzen hat man halt immer mehrere/viele Nutzer hinter einer/einer Handvoll von egress IP(s).

Besonders lustig wird das, wenn Spielkinder und eigene Mitarbeiter im selben Netz sind (Hotel, Event, ...) und man die entsprechende Egress-Adresse der Spielkinder wegen sperrt.

Man liest sich, Alex.

Ja.

Kommt drauf an. ;-)

Welcher Algorithmus, wieviele Versuche/Zeiteinheit und wie weiss ich, dass ich dass Passwort korrekt erraten habe?

Je nach Parametern ist die Antwort irgendwas zwischen quasi Echtzeit und "irgendwann nachdem die Sonne zum roten Riesen wird".

Massiv unterspezifierte Problemstellungen sind lustig.

Man liest sich, Alex.

Mit etwas Sachkenntnis weiß man auch, dass es vor etwa 25 Jahren weit verbreitete Kryptografie gab, die wirklich 56-bit-Schlüssel benutzt hat und biegt direkt in die "hoffnugslos veraltet" Schiene ab bevor einem dämmert dass da eine 2 fehlen könnte.

Grüße Marc

Dann nehmen wir halt Sagittarius A* dazu, das gibt bisserl mehr Saft.

SCNR, Alex.

Solltest Du das irgendwann mal tun (was heute zu nicht fahrlässigem Rechnerbetrieb einfach dazugehört), nimm bitte die mit Deinem Betriebssystem mitgelieferte Lösung.

Der Wechsel von Argon 2 zu Argon 2id erfolgte unter anderem um die Dauer der Schlüsselableitung den leistungsfähiger gewordenen CPUs anzupassen. Selbst auf meinen stärksten Maschinen dauert das Aufschließen der LUKS-Devices seitdem spürbar länger, und das ist gut so.

Wobei bei solchen hybriden Verfahren das asymmetrische Verfahren durch Quantencomputer und Shor's Algorithmus fallen dürfte, womit das symmetrische Verfahren mit fällt.

Grüße Marc

Seriöse Menschen formulieren das freilich anders und etwas spezifischer. Natürlich gibt es hinreichend schlechte Verfahren, die trotz eines 256 Bit breiten Keys in kurzer Zeit knackbar sind.

Grüße Marc

Ich las über AES, daß eine Implementation 500 Zeilen in C braucht. Ob der inverse Teil darin enthalten ist, weiß ich nicht. RABBIT hat jedenfalls nur 80 Zeilen, in meiner Implementation.

Ich habe RABBIT und DRAGON mit der 15-stufigen NIST-Testsuite getestet. Keine Mängel wurden gefunden.

Um wieviel die Instruktionen beschleunigen, ist mir unbekannt - 1,5 ?. Ich müßte die in Assembler per Hand einbinden.

| 56-Bit AES-Verschlüsse­lung 399 Sekunden |128-Bit AES-Verschlüsse­lung 1,02 * 1018 Jahre |192-Bit AES-Verschlüsse­lung 1,872 * 1037 Jahre |256-Bit AES-Verschlüsse­lung 3,31 * 1056 Jahre

Wirklich? Logisch ist das insgesamt nicht, denn 256-Bit ist bereits da. Mit viel längerer Zeit als 399 Sekunden.

/ralph

Ich weiß, daß man mit einer Live-DVD des richtigen BS Zugriff hat. Ich arbeite hauptsächlich mit FreeBSD.

Ist mir aber bisher egal, da ich allein in meiner Dach-Wohnung lebe.

Es ist lesbar, daß in heutiger Zeit und in Zukunft 256-bit sicher ist. Tabellen dazu postete ich bereits.

Ich verwende nur moderne NIST-geprüfte Chiffre. Was ich nicht so oft postete ist, daß ich mit mindestens 2 Algorithmen hintereinander verschlüssele. Beim Knackversuch stößt man dadurch auf einen verschlüsselten Inhalt.

Lies mal oben: "bevor einem dämmert dass da eine 2 fehlen könnte."

In welcher Zeile fehlt deiner Meinung nach eine 2 und warum? Die Zeile mit 56 Bit/399 Sekunden braucht doch wohl nicht? Bzw. wenn deiner Meinung nach schon, warum?

Versteh mich nicht falsch, das Ding scheint irgendwie schlecht gescannt zu sein, mit den irrlichternden Leerzeichen und den "verlorenen" 10ern bei der Exponentialschreibweise. Aber vor "56 Bit" geht zumindest mir, solange mir keiner das Gegenteil schlüssig darlegt, kein 2er ab.

Am 02.05.2024 schrieb Alexander Schreiber snipped-for-privacy@usenet.thangorodrim.de>:

Manche Leute wollen das so, dann müssen die mit den Nachteilen halt leben.

Hast du denn dafür auch Beispiele aus der Praxis, bitte von Leute, die IPv6 verstehen und nicht von Leuten, die ihre IPv4-Infrastruktur nachbilden wollen? Bitte ohne dummes Gegacker oder Gelache.

Sollen die dann bitte machen, wenn Kunden das so wollen. Ich schließe mit solchen Unternehmen keine Verträge ab.

Wenn man den Bockmist machen will, bitte. Dann muss man halt damit leben, dass man a) von außen nicht mehr ohne Logs zuordnen kann, welches System das Paket geschickt hat und b) sind dann alle Teilnehmer von Rate-Limits und IP-Sperren betroffen. Wer das will, bitte.

Genau deswegen macht man so einen Bockmist auch nicht bei IPv6. Dann treten die genannten Probleme nicht auf.

Ich habe sowas bisher auch nicht in freier Wildbahn gesehen. Wenn es da IPv6 gibt, dann per GUA und SPI-Firewall.

Am 02.05.2024 schrieb Helmut Schellong snipped-for-privacy@schellong.biz:

Ist aber ohne das zugehörige Passwort schwer, wenn man die Verschlüsslung eingerichtet hat.

Beachte, dass es auch Einbrecher gibt.

Oben steht: "56-Bit AES-Verschlüsse­lung 399 Sekunden"

AES hat jedoch keine Schlüssellänge von 56!, sondern 128, (160,) 192, (224,) 256. Mit und ohne 2 davor ist es FALSCH!