Schlüssel: Brute force

Eventuell ist es ein Scanfehler DES? Eventuell hat jemand den AES-Algorithmus mit nicht-standardkonformen 56 bit (keine Ahnung ob das in der Praxis geht) ausprobiert, um zu zeigen, wie schnell die Anforderung nach oben geht?

Eventuell. Aber mir ist nicht klar, warum du dich so drüber aufregst. Das Dokument hat sichtbare schlimme Konvertierungs- oder Scan/OCR-Artefakte. Ist es wirklich so schlimm, wenn da statt DES AES steht?

/ralph

Siehe z.B. auch

Das ist eine Art von Wunschdenken. Aber es kann im Ursprung DES sein.

Ich könnte das sicherlich mit 56 implementieren. Ganz simpel ist das nicht, weil die Blockgröße von AES 128 beträgt.

Ja, es ist so schlimm. Man weiß ja nicht, was korrekt wäre. Andererseits kann die erste Zeile einfach weggeworfen werden.

... und so finde ich genau den Text, den ich finden will :-)

Thomas Prufer

Dann ist es halt kein AES mehr.

Mit der Fähigkeit, die restlichen 72 Bit mit Nullen oder Einsen oder irgend einem anderen bekannten und konstanten Wert auszufüllen und somit AES128 mit 56 Bit effektiver Schlüssellänge zu "implementieren" wirst ja selbst Du Dich ja nicht ernsthaft brüsten wollen.

Du gehst dennoch mit Kundendaten um, nehme ich an?

Das bekommt man freilich aber auch mit einfacheren Mitteln hin als mit NAT.

Aber solche Netze setzen doch üblicherweise Application Level Gateways ein. Heute heißt das dann zwar Next Generation Firewall, aber irgendwas ist ja immer.

Ich war neulich in einem vermieteten Büroraum (mit anhängender Werkstatt, da ist jede Woche ein anderer Mieter drin), aus dessen WLAN keine VPN-Verbindungen möglich waren, weil ein Bluecoat-Dings im Datenweg war.

Grüße Marc

Aus der einzigen Tabelle die Du gepostet hattest ging nichtmal klar hervor mit welchem Algorithmus getestet wurde. 256 Bit AES gilt aktuell als sicher, das kann sich morgen allerdings bereits ändern.

Und Du traust dem NIST?

Was Du nicht verstanden hast ist dass das nicht hilft.

Würde da ein SSH-Tunnel helfen?

Ansonsten... Beim OS das 'HV'-Flag im Netzwerkstack setzen. Dann werden Hochgeschwindigkeitspakete versendet die solche Firewalls einfach durchschlagen. ;)

Gerrit

Du bist im Zweifel nicht alleine auf dem Rechner und solltest keine allgemein nutzbaren Rechenwerke mit Dingen beschäftigen für die Du Spezialhardware hast.

Never roll your own crypto. Die zahlreich vorhandenen hochoptimierten Standardbibliotheken machen das für Dich automatisch.

Und das Bestehen einer Testsuite ist Basisvoraussetzung, das taugt nur zum Aussortieren einer untauglichen Implementierung. Dass die Testsuite unfallfrei durchläuft ist nicht die Garantie dass Deine Implementierung schwachstellenfrei ist.

Es geht ja um Geschwindigkeitsvorteile durch kurzen Key. Padding würde da nichts bringen. Deshalb schrieb ich, daß es nicht ganz simpel wäre.

Na ja, ich werde das natürlich nicht machen - ich könnte es halt. Falls ich AES implementiere, würde ich allerdings 5 Schlüssellängen anbieten. Die Blocksize jedoch auf 128 belassen.

Laufenden Umgang damit hatte ich vor Jahrzehnten - seit langem keinen mehr. Als Rentner hatte ich nur ein freiberufliches Projekt vor Jahren (Augsburg). Diese Daten könnte ich selektiv selbst verschlüsseln.

Bei der Sache mit xz neulich sogar eher umgekehrt ;)

/ralph

Da wurde sogar 'future use long term' notiert. Symmetrische Schlüssel 256 habe ich mehrfach als sicher bezeichnet gesehen. Mir reicht das.

Ich meine die 15-stufige NIST-Testsuite.

Ich glaube allerdings nicht, daß der Zeitbedarf dabei gleich ist.

Das ist ein Punkt, der auf mich nicht zutrifft.

Instruktionen statt Funktionen zu nutzen, hat nichts mit "Never roll your own crypto" zu tun. Ich zweifle daran, daß ich unter FreeBSD solche Unterstützung habe.

Ich habe bisher RABBIT, DRAGON und SPRITZ damit getestet - keine Eigenentwicklungen. Meine Implementationen generieren die Referenz-Ausgaben. Das ist der Beweis, daß diese korrekt sind, und zwar unerschütterlich. Das schrieb ich bereits zuvor.

Die Wahrscheinlichkeit für gute Algorithmus-Qualität ist aber sehr hoch, wenn die NIST-Testsuite makellos durchlaufen wird.

Das ist eigentlich irrelevant, weil die Qualität abhängig ist von dem komprimierten Inhalt.

$ cd /usr/src $ got log -S '[Ss]chellong' $

$ cd /usr/ports $ got log -S '[Ss]chellong' $

Puh, ich bin erleichtert.

Am 02.05.24 um 10:10 schrieb Marco Moock:

Alle, die DS-Lite nutzen müssen.

Marcel

Am 02.05.24 um 13:19 schrieb Marc Haber:

Gegen Quantencomputer hilft sowieso nur Quantenkryptografie. Die allerdings ist nicht knackbar. Da muss man dann schon andere Wege finden.

Marcel