Schlüssel: Brute force

Am 01.05.24 um 16:06 schrieb Thorsten Böttcher:

Vermutlich nicht. Aber der Schlaufuchs, der es kopiert hat, hat das Superscript-Attribut ignoriert.

Marcel

Der Schlaufuchs war eventuell ein mäßig gutes OCR-Programm.

/ralph

Am 01.05.2024 um 19:53 schrieb Marco Moock:

Wenn Schlüssel.length >= Text.length ist dann nicht (Siehe OTP).

Am 01.05.24 um 17:42 schrieb Wolfgang Schmidt:

Das ist technisch je nach Anwendungsfall unmöglich.

Wenn man bereits im Besitz verschlüsselter Daten ohne Schüssel ist, führt der Aufdruck "Sie dürfen nur einen Schlüssel pro Sekunde probieren" eher zu einem Lachkrampf als zu einer Verlangsamung der Attacke. ;-)

Und wenn es um die Sicherung öffentlich erreichbarer Accounts geht, dann wären in 5 Minuten alle existierenden Accounts gesperrt, weil irgendein Depp versucht es immer mal. Das wäre quasi ein sehr einfacher Angriffsverktor für eine DOS-Attacke.

Umgekehrt gilt: wenn man nur eine Hand voll versuche hat, ist auch eine

Der Trick ist ja, dass man über solch eine Zugangskennung nur eine Authentifizierung vornimmt, während der eigentliche Datenverkehr über einen ausgewürfelten Schlüssel erfolgt, der über ein asymmetrisches Verfahren mit ebenfalls ausgewürfelten, hinterlegten Schlüssel vereinbart wird. Damit muss die Verschlüsselung für den Datenverkehr Brute Force stand halten, Aber den Schlüssel müssen sich nur die beteiligten Rechner merken, und das auch nur vorübergehend, dann gibt es einen neuen. Man muss sich also mit dem Knacken beeilen.

Marcel

Egal! Es wundert mich aber, dass derlei offensichtliche Dinge in einer "sci"-Gruppe tatsächlich thematisiert werden müssen, auch wenn der Poster das "Problem" in seinem Zitat natürlich nicht zu erkennen vermochte. Jeder mit auch nur rudimentärer mathematisch-naturwissenschaftlicher (Aus)Bildung sollte doch unschwer erkennen, was mit Angaben wie "1,02 *

MfG Rupert

Ja klar, zumindest wenn man es nicht nur überfliegt, sondern mal genauer hinsieht, dann sollte was klingeln.

/ralph

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

Das kann noch viel, viel mehr sein und die können in den nächsten Jahren auch viel schneller werden.

Am 01.05.2024 schrieb Rolf Bombach snipped-for-privacy@invalid.invalid:

Ja, es ist nur eine Frage der Zeit. Das Konzept von Verschlüsselung ist, diese zeit so groß werden zu lassen, dass es sich nicht rentiert.

Kommt auf die Rechenleistung an, kann ich dir nicht genau sagen.

In den letzten Jahren mag das nicht mehr so steil gewesen sein, gefühlt ist es aber noch so. Vergleiche mal einen Pentium 4 670 (früher ein Monster) gegen einen Celeron J4125 (billige low-end-low-power CPU).

Am 02.05.2024 schrieb Eric Bruecklmeier snipped-for-privacy@5i7.de:

Erkläre das bitte genauer. Warum soll ein Knacken dann nicht mehr möglich sein?

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

Das funktioniert aber halt nur dann, wenn der Angreifer auf diesen Mechanismus keinen Einfluss hat. Bei verschlüsselten Daten, die der Angreifer aber hat (mitgeschnittene Kommunikation, Mails etc.) kannst du sowas prinzipbedingt nicht umsetzen, denn der hat die Daten und kann damit machen, was der will.

Am 02.05.2024 schrieb Marcel Mueller snipped-for-privacy@spamgourmet.org:

Daher macht man das auch nicht pro Account sondern pro IP-Adresse/Netz. Dann ist der Kollateralschaden sehr begrenzt und wer meint, sich mit so Leuten ein Netz teilen zu müssen, hat halt ein Problem. Mit IPv6 gibt es kein CGNAT & anderen Mist mehr und man kann sehr genau den Verursacher abstrafen.

Wiki:

"Das One-Time-Pad (Abkürzung: OTP, deutsch: Einmalverschlüsselung oder Einmalschlüssel-Verfahren, wörtlich Einmal-Block, nicht zu verwechseln mit dem Einmalkennwort) ist ein symmetrisches Verschlüsselungsverfahren zur geheimen Kommunikation. Kennzeichnend ist, dass ein Schlüssel verwendet wird, der mindestens so lang wie die Nachricht ist. Das OTP ist informationstheoretisch sicher und kann nachweislich nicht gebrochen werden, wenn es bestimmungsgemäß genutzt wird."

Es ist äquivalent zu eine Code-Buch: Ein Liste möglicher Nachrichten, und es wird nur der Index in diese Liste übertragen. Ohne Kenntnis der Liste ist der Index wertlos und nicht knackbar.

(NB: "bestimmunggemäß genutzt"...)

Thomas Prufer

Kann nicht ein Text, der kürzer ist als der Schlüssel, prinzipiell nicht geknackt werden? Du kommst nach einer endlichen Zahl von Versuchen vielleicht auf das richtige Ergebnis, aber Du mußt dann auch noch erkennen, daß es richtig ist.

Es ging doch um ein Zahlenschloß (an einer Tür).

Festplattenverschlüsselung habe ich noch nie erwogen, weshalb ich dazu Details betreffend nichts sagen kann.

Landauer's principle könnte hier, wenn es stimmt, eine harte Grenze setzen. Soll heissen, die Sonne kann nicht genug Energie liefern um

Gerrit

|<td class="column-2">1,872 * 1037 Jahre</td></tr>

Vorstehend der Quelltext der Webseite. Der falsche Text steht jedenfalls als Konstante in der Quelle.

Durchaus - wenn Zeit zum ungestörten Rekapitulieren vorhanden ist.

Das Problem ist, dass Rabbit sowohl mit TMD- als auch Frequenzraum- Angriffen Schwächen zeigt, da man mit Teilprodukten große Schlüsselmengen angreifen und mit Cos^2-Transformationen auf halber Strecke die Entropieabnahme beobachten kann.

In der BSI TR-02102-1 (Europa) oder der NIST SP 800-131A (US von A) kann ich keine Empfehlung entdecken. Kannst Du die empfehlende Körperschaft benennen?

Bislang kenne ich Rabbit nur als AES alternative um mit kleineren CPUs oder Mikrocontrollern ohne AES-Hardware effizient Data-at-Rest verschlüsseln zu können.

Da aber alle aktuellen CPUs von Intel, ARM, Mediatek, VIA Qualcomm und AMD mit AES Hardware kommen, macht es keinen Sinn davon abzuweichen, solange das Betriebssystem und der Compiler die AES-NI-Schnittstellen auf dem Schirm haben.

Falk D.

Richtig, man muß ungestört rekapitulieren können. Hier war es noch so, daß eine kraß falsche Angabe '56-Bit' vorhanden ist. Dadurch hatte ich zunächst eine vorgefaßte stark negative Meinung.