Marco Moock wrote:
> Am 01.05.2024 schrieb Helmut Schellong <var@schellong.biz>:
>
>> Ja, es können beispielsweise 10000 Kerne parallel rechnen, jeder
>> seinen Schlüsselbereich. Das reduziert den Zeitaufwand von 2^254 auf
>> etwa 2^240 - nicht sonderlich beeindruckend.
>
> Das kann noch viel, viel mehr sein und die können in den nächsten
> Jahren auch viel schneller werden.
>
> Überlege mal, was eine CPU vor 20 Jahren für ne Rechenleistung hatte
> und was heute.

Das kenne ich bestens.
Und ich kann Zahlen wie 2^234 einschätzen.

3# echo $((log2(10000.0)))
13.2877123795494494
4# echo $((log2(1000000.0)))
19.9315685693241741
5# echo $((log2(10000000.0)))
23.2534966642115364
6# echo $((log2(1000000000.0)))
29.8973528539862611
7#

Bei 10 Mio Kernen reduziert es sich von 2^254 auf 2^231 - nicht sonderlich beeindruckend.
Bei 1 Mrd Kernen reduziert es sich von 2^254 auf 2^224 - nicht sonderlich beeindruckend.
Es geht hier um Potenzen!

Ich habe eine Workstation hier stehen, mit Sapphire-Rapids-Prozessor, 16 Kerne.
Der Prozessor mit 56 Kernen kostet über 5000 EUR!
Ich bin hier bei 89,3 Mrd EUR angekommen - nur für die nackten etwa 18 Mio Prozessoren!

Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
Man benötigt auch keine neuen Algorithmen, extra gegen Quanten-Computer.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong <var@schellong.biz> wrote:
>Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.

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
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>
> 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.

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.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong <var@schellong.biz> wrote:
>Marc Haber wrote:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>>
>> 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.
>
>Es ist lesbar, daß in heutiger Zeit und in Zukunft 256-bit sicher ist.
>Tabellen dazu postete ich bereits.

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.

>Ich verwende nur moderne NIST-geprüfte Chiffre.

Und Du traust dem NIST?

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

Was Du nicht verstanden hast ist dass das nicht hilft.

--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Marc Haber wrote:
>>> Helmut Schellong <var@schellong.biz> wrote:
>>>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>>>
>>> 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.
>>
>> Es ist lesbar, daß in heutiger Zeit und in Zukunft 256-bit sicher ist.
>> Tabellen dazu postete ich bereits.
>
> 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.

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

>> Ich verwende nur moderne NIST-geprüfte Chiffre.
>
> Und Du traust dem NIST?

Ich meine die 15-stufige NIST-Testsuite.

>> 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.
>
> Was Du nicht verstanden hast ist dass das nicht hilft.

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

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong <var@schellong.biz> wrote:
>Da wurde sogar 'future use long term' notiert.
>Symmetrische Schlüssel 256 habe ich mehrfach als sicher bezeichnet gesehen.
>Mir reicht das.

Dennoch maßt Du Dir an, die Software, die "dir reicht" und
bekanntermaßen schwere Schwachpunkte in ihrer Kryptografie enthält, zu
veröffentlichen und anderen Menschen zur Benutzung anzudienen.

Wer Dich hat, braucht keinen Jia Tan mehr.

--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

[...]
> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.

Ja - derzeit.

> Man benötigt auch keine neuen Algorithmen, extra gegen Quanten-Computer.

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

--
Arno Welzel
https://arnowelzel.de

Arno Welzel wrote:
> Helmut Schellong, 2024-05-02 12:22:
>
> [...]
>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>
> Ja - derzeit.

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

>> Man benötigt auch keine neuen Algorithmen, extra gegen Quanten-Computer.
>
> Bei AES vermutlich nicht, nein. Aber es gibt ja nicht nur AES.

Siehe oben.

--
Mit freundlichen Grüßen
Helmut Schellong

On 5/4/24 13:50, Arno Welzel wrote:
> Helmut Schellong, 2024-05-02 12:22:
>
> [...]
>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>
> Ja - derzeit.

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

Gerrit

Gerrit Heitsch wrote:
> On 5/4/24 13:50, Arno Welzel wrote:
>> Helmut Schellong, 2024-05-02 12:22:
>>
>> [...]
>>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>>
>> Ja - derzeit.
>
> Wenn kein Fehler in AES-256 ist und das Landauer Limit existiert, dann bis in alle Ewigkeit.

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.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong <var@schellong.biz> wrote:
> Arno Welzel wrote:
>> Helmut Schellong, 2024-05-02 12:22:
>>
>> [...]
>>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>>
>> Ja - derzeit.
>
> . 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.

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.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

Alexander Schreiber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Arno Welzel wrote:
>>> Helmut Schellong, 2024-05-02 12:22:
>>>
>>> [...]
>>>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>>>
>>> Ja - derzeit.
>>
>> . 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.
>
> Angabe der Schlüssellänge ohne Angabe des Algorithmus (und der Betriebs-
> art, z.B. CBC statt ECB) ist relativ aussagefrei.

Das sprichst Du anderen nach.
Die Information kommt von der enisa, eine EU-Agentur, die auch Kryptologen beschäftigt.
Die enisa ist etwa das, was in den USA das NIST ist.
Du weißt es also besser als die Kryptologen der enisa?!

Die enisa sagt aus, daß symmetrische keys mit 256 Bit sicher sind, auch in der Zukunft.
Unabhängig vom Algorithmus und dessen Modus.
Das gilt.
Ich kann das nicht widerlegen - aber Du?

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong schrieb:
> Die enisa sagt aus, daß symmetrische keys mit 256 Bit sicher sind, auch
> in der Zukunft.
> Unabhängig vom Algorithmus und dessen Modus.
> Das gilt.
> Ich kann das nicht widerlegen - aber Du?

Natürlich kannst du das nicht. Dazu müsstest du ja erstmal verstehen, um
was es denn überhaupt geht. Keys stehen nicht für sich im luftleeren
Raum. Entscheidend ist die Sicht auf den verwendeten Algorithmus _und_
den Key
Und beides ist völlig irrelevant, wenn bereits die konkrete
Implementierung des Algorithmus fehlerhaft ist

MfG
Rupert

Helmut Schellong, 2024-05-04 17:53:

> Arno Welzel wrote:
>> Helmut Schellong, 2024-05-02 12:22:
>>
>> [...]
>>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>>
>> Ja - derzeit.
>
> . 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.

So pauschal - nein. ENISA hat das deutlich diffenzierter betrachtet:

<https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report>

>>> Man benötigt auch keine neuen Algorithmen, extra gegen Quanten-Computer.
>>
>> Bei AES vermutlich nicht, nein. Aber es gibt ja nicht nur AES.
>
> Siehe oben.

Lies einfach das Dokument selber.

--
Arno Welzel
https://arnowelzel.de

Helmut Schellong, 2024-05-04 22:03:

> Alexander Schreiber wrote:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Arno Welzel wrote:
>>>> Helmut Schellong, 2024-05-02 12:22:
>>>>
>>>> [...]
>>>>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>>>>
>>>> Ja - derzeit.
>>>
>>> . 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.
>>
>> Angabe der Schlüssellänge ohne Angabe des Algorithmus (und der Betriebs-
>> art, z.B. CBC statt ECB) ist relativ aussagefrei.
>
> Das sprichst Du anderen nach.
> Die Information kommt von der enisa, eine EU-Agentur, die auch Kryptologen beschäftigt.
> Die enisa ist etwa das, was in den USA das NIST ist.
> Du weißt es also besser als die Kryptologen der enisa?!
>
> Die enisa sagt aus, daß symmetrische keys mit 256 Bit sicher sind, auch in der Zukunft.
> Unabhängig vom Algorithmus und dessen Modus.
> Das gilt.
> Ich kann das nicht widerlegen - aber Du?

Es wäre hilfreich, wenn Du diese Aussage mit einer Quelle belegen
würdest, statt sie einfach nur hinzuschreiben und davon auszugehen, dass
das schon niemand anzweifeln wird.

--
Arno Welzel
https://arnowelzel.de

Arno Welzel wrote:
> Helmut Schellong, 2024-05-04 17:53:
>
>> Arno Welzel wrote:
>>> Helmut Schellong, 2024-05-02 12:22:
>>>
>>> [...]
>>>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>>>
>>> Ja - derzeit.
>>
>> . 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.
>
> So pauschal - nein. ENISA hat das deutlich diffenzierter betrachtet:
>
> <https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report>

Aus dieser pdf-2013 habe ich die Tabelle, die ich oben zeige.

Lade Dir die aktuelle pdf-2014, rechts vom Download der pdf-2013.

Wenn man dort nach Publikationen sucht, per Suchfunktion, wird man stets
zur alten Datei geleitet.

>>>> Man benötigt auch keine neuen Algorithmen, extra gegen Quanten-Computer.
>>>
>>> Bei AES vermutlich nicht, nein. Aber es gibt ja nicht nur AES.
>>
>> Siehe oben.
>
> Lies einfach das Dokument selber.

enisa und deren Webseite ist mir seit 2022 ein Begriff.

--
Mit freundlichen Grüßen
Helmut Schellong

Arno Welzel wrote:
> Helmut Schellong, 2024-05-04 22:03:
>
>> Alexander Schreiber wrote:
>>> Helmut Schellong <var@schellong.biz> wrote:
>>>> Arno Welzel wrote:
>>>>> Helmut Schellong, 2024-05-02 12:22:
>>>>>
>>>>> [...]
>>>>>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>>>>>
>>>>> Ja - derzeit.
>>>>
>>>> . 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.
>>>
>>> Angabe der Schlüssellänge ohne Angabe des Algorithmus (und der Betriebs-
>>> art, z.B. CBC statt ECB) ist relativ aussagefrei.
>>
>> Das sprichst Du anderen nach.
>> Die Information kommt von der enisa, eine EU-Agentur, die auch Kryptologen beschäftigt.
>> Die enisa ist etwa das, was in den USA das NIST ist.
>> Du weißt es also besser als die Kryptologen der enisa?!
>>
>> Die enisa sagt aus, daß symmetrische keys mit 256 Bit sicher sind, auch in der Zukunft.
>> Unabhängig vom Algorithmus und dessen Modus.
>> Das gilt.
>> Ich kann das nicht widerlegen - aber Du?
>
> Es wäre hilfreich, wenn Du diese Aussage mit einer Quelle belegen
> würdest, statt sie einfach nur hinzuschreiben und davon auszugehen, dass
> das schon niemand anzweifeln wird.

Die von mir gezeigte Tabelle aus dem enisa-Dokument ist der Beleg.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong, 2024-05-05 12:48:

> Arno Welzel wrote:
>> Helmut Schellong, 2024-05-04 22:03:
>>
>>> Alexander Schreiber wrote:
>>>> Helmut Schellong <var@schellong.biz> wrote:
>>>>> Arno Welzel wrote:
>>>>>> Helmut Schellong, 2024-05-02 12:22:
>>>>>>
>>>>>> [...]
>>>>>>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>>>>>>
>>>>>> Ja - derzeit.
>>>>>
>>>>> . 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.
>>>>
>>>> Angabe der Schlüssellänge ohne Angabe des Algorithmus (und der Betriebs-
>>>> art, z.B. CBC statt ECB) ist relativ aussagefrei.
>>>
>>> Das sprichst Du anderen nach.
>>> Die Information kommt von der enisa, eine EU-Agentur, die auch Kryptologen beschäftigt.
>>> Die enisa ist etwa das, was in den USA das NIST ist.
>>> Du weißt es also besser als die Kryptologen der enisa?!
>>>
>>> Die enisa sagt aus, daß symmetrische keys mit 256 Bit sicher sind, auch in der Zukunft.
>>> Unabhängig vom Algorithmus und dessen Modus.
>>> Das gilt.
>>> Ich kann das nicht widerlegen - aber Du?
>>
>> Es wäre hilfreich, wenn Du diese Aussage mit einer Quelle belegen
>> würdest, statt sie einfach nur hinzuschreiben und davon auszugehen, dass
>> das schon niemand anzweifeln wird.
>
> Die von mir gezeigte Tabelle aus dem enisa-Dokument ist der Beleg.

Und wo liegt dieses Dokument? URL?

--
Arno Welzel
https://arnowelzel.de

Arno Welzel wrote:
> Helmut Schellong, 2024-05-05 12:48:
>
>> Arno Welzel wrote:
>>> Helmut Schellong, 2024-05-04 22:03:
>>>
>>>> Alexander Schreiber wrote:
>>>>> Helmut Schellong <var@schellong.biz> wrote:
>>>>>> Arno Welzel wrote:
>>>>>>> Helmut Schellong, 2024-05-02 12:22:
>>>>>>>
>>>>>>> [...]
>>>>>>>> Irgendwann sollte man konstatieren, daß Keys mit 256 Bit Breite unknackbar sind.
>>>>>>>
>>>>>>> Ja - derzeit.
>>>>>>
>>>>>> . 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.
>>>>>
>>>>> Angabe der Schlüssellänge ohne Angabe des Algorithmus (und der Betriebs-
>>>>> art, z.B. CBC statt ECB) ist relativ aussagefrei.
>>>>
>>>> Das sprichst Du anderen nach.
>>>> Die Information kommt von der enisa, eine EU-Agentur, die auch Kryptologen beschäftigt.
>>>> Die enisa ist etwa das, was in den USA das NIST ist.
>>>> Du weißt es also besser als die Kryptologen der enisa?!
>>>>
>>>> Die enisa sagt aus, daß symmetrische keys mit 256 Bit sicher sind, auch in der Zukunft.
>>>> Unabhängig vom Algorithmus und dessen Modus.
>>>> Das gilt.
>>>> Ich kann das nicht widerlegen - aber Du?
>>>
>>> Es wäre hilfreich, wenn Du diese Aussage mit einer Quelle belegen
>>> würdest, statt sie einfach nur hinzuschreiben und davon auszugehen, dass
>>> das schon niemand anzweifeln wird.
>>
>> Die von mir gezeigte Tabelle aus dem enisa-Dokument ist der Beleg.
>
> Und wo liegt dieses Dokument? URL?

https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report

Rechts auf der Seite ist der neuere Report 2014.
Tabelle auf Seite 41.

|In Table 3.6 we present our explicit key size guidelines.

--
Mit freundlichen Grüßen
Helmut Schellong

On Sat, 4 May 2024 13:50:03 +0200
Arno Welzel <usenet@arnowelzel.de> wrote:

> > Man benötigt auch keine neuen Algorithmen, extra gegen
> > Quanten-Computer.
>
> Bei AES vermutlich nicht, nein. Aber es gibt ja nicht nur AES.

Derzeit sind die Quantenrechner weit unter 4k Qubits (2000+irgendwas).
Allein um eine AES-Operation auf einem 128k Block vorzunehmen braucht
der Quantenrechner also 6.3443466e+88 Durchläufe.

Die bessere Takteffizienz hilft dem Quantenrechner nicht, wenn es ein
Shift&Shuffle Algorithmus ist.

Falk D.

--
Falk Dµebbert <falk@duebbert.com>

Falk Dµebbert wrote:
> On Sat, 4 May 2024 13:50:03 +0200
> Arno Welzel <usenet@arnowelzel.de> wrote:
>
>>> Man benötigt auch keine neuen Algorithmen, extra gegen
>>> Quanten-Computer.
>>
>> Bei AES vermutlich nicht, nein. Aber es gibt ja nicht nur AES.
>
> Derzeit sind die Quantenrechner weit unter 4k Qubits (2000+irgendwas).
> Allein um eine AES-Operation auf einem 128k Block vorzunehmen braucht
> der Quantenrechner also 6.3443466e+88 Durchläufe.
>
> Die bessere Takteffizienz hilft dem Quantenrechner nicht, wenn es ein
> Shift&Shuffle Algorithmus ist.

Krypto-Algorithmen zur Verschlüsselung, Random und Hash haben zumeist massiv
Operationen wie Shift, Rotate, Or, Xor, sowie Add, Mul mit weggeworfenem Überlauf
in Verwendung.
Das dürfte maximal unbequem für Quanten-Computer sein.
Insbesondere, weil das derartig intensiv angewandt wird, daß eine hohe /Verstärkung/ resultiert.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong, 2024-05-05 20:34:

> Arno Welzel wrote:
>> Helmut Schellong, 2024-05-05 12:48:
>>
>>> Arno Welzel wrote:
>>>> Helmut Schellong, 2024-05-04 22:03:
[...]
>>>>> Die enisa sagt aus, daß symmetrische keys mit 256 Bit sicher sind, auch in der Zukunft.
>>>>> Unabhängig vom Algorithmus und dessen Modus.
>>>>> Das gilt.
>>>>> Ich kann das nicht widerlegen - aber Du?
>>>>
>>>> Es wäre hilfreich, wenn Du diese Aussage mit einer Quelle belegen
>>>> würdest, statt sie einfach nur hinzuschreiben und davon auszugehen, dass
>>>> das schon niemand anzweifeln wird.
>>>
>>> Die von mir gezeigte Tabelle aus dem enisa-Dokument ist der Beleg.
>>
>> Und wo liegt dieses Dokument? URL?
>
> https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report
>
> Rechts auf der Seite ist der neuere Report 2014.
> Tabelle auf Seite 41.
>
> |In Table 3.6 we present our explicit key size guidelines.

Das ist Seite 35, nicht 41. Weiterhin ist diese Tabelle nicht komplett
ohne Kontext, sondern bezieht sich ganz konkret auf AES.

--
Arno Welzel
https://arnowelzel.de

Arno Welzel wrote:
> Helmut Schellong, 2024-05-05 20:34:
>
>> Arno Welzel wrote:
>>> Helmut Schellong, 2024-05-05 12:48:
>>>
>>>> Arno Welzel wrote:
>>>>> Helmut Schellong, 2024-05-04 22:03:
> [...]
>>>>>> Die enisa sagt aus, daß symmetrische keys mit 256 Bit sicher sind, auch in der Zukunft.
>>>>>> Unabhängig vom Algorithmus und dessen Modus.
>>>>>> Das gilt.
>>>>>> Ich kann das nicht widerlegen - aber Du?
>>>>>
>>>>> Es wäre hilfreich, wenn Du diese Aussage mit einer Quelle belegen
>>>>> würdest, statt sie einfach nur hinzuschreiben und davon auszugehen, dass
>>>>> das schon niemand anzweifeln wird.
>>>>
>>>> Die von mir gezeigte Tabelle aus dem enisa-Dokument ist der Beleg.
>>>
>>> Und wo liegt dieses Dokument? URL?
>>
>> https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report
>>
>> Rechts auf der Seite ist der neuere Report 2014.
>> Tabelle auf Seite 41.
>>
>> |In Table 3.6 we present our explicit key size guidelines.
>
> Das ist Seite 35, nicht 41. Weiterhin ist diese Tabelle nicht komplett
> ohne Kontext, sondern bezieht sich ganz konkret auf AES.

Die pdf-Präsentierer stellen doch die Seitenzahlen oft falsch dar.
Andere Seiten-Kategorien (ii,iii,iv) werden ignoriert und in die Hauptkategorie übertragen.
Mir wurde halt '41 von 113' angezeigt.

Auf jeden Fall werden wesentlich längere Keys und Hashes als sicherer dargestellt, als kürzere.
Auch in allen anderen Dokumenten.
Dabei weiß ich natürlich, daß es eine Bit-Sicherheit im _Unterschied_ zur bloßen Key-size gibt.
Es gibt eben auch eine _effektive_ Key-size.

Ich mache mir auch grundsätzlich keinen /Wolf/, weil RABBIT herabgestuft wurde.
Mehrere Jahre lang steht da, daß man die Wirkung des Angriffs in der Praxis feststellen muß;
nichtsdestotrotz bleibe die Herabstufung bestehen.

Die jeweilige Popularität der Algorithmen entscheidet darüber, welcher Algorithmus
besonders stark angegriffen und untersucht wird.
Die Unterschiede dort halte für 50..1000-fach unterschiedlich.
Das bedeutet, daß ein unpopulärer Algorithmus, der aktuell maximal empfohlen wird,
plötzlich erfolgreich angegriffen werden kann - und daher heftig herabgestuft wird.
AES hat den Vorteil, daß er wohl der Populärste ist, und bisher dennoch nicht
mit erkannter Praxisrelevanz angegriffen werden konnte.

================================================================================================
3.6 Key Size Analysis
Providing key sizes for long term use is somewhat of a hit-and-miss affair, for a start it assumes that
the algorithm you are selecting a key size for is not broken in the mean time.
So in providing key sizes for specific application domains we make an implicit assumption
that the primitive, scheme or protocol which utilises this key size is not broken in the near future.
All primitives and schemes marked as suitable for future use in this document we have confidence
will remain secure for a significant period of time.
Making this assumption still implies a degree of choice as to key size however.

The AES block cipher may remain secure for the next fifty years, but one is likely to want to use
a larger key size for data which one wishes to secure for fifty years as opposed to, say, five years.
Thus in providing key size guidelines we make two distinct cases for schemes relevant for future use.
The first cases is for security which you want to ensure for at least ten years (which we call near term),
and secondly for security for thirty to fifty years (which we call long term).
Again we reiterate these are purely key size guidelines and they do not guarantee security,
nor do they guarantee against attacks on the underlying mathematical primitives.

In Table 3.6 we present our explicit key size guidelines.
The reader will see that we have essentially followed the NIST equivalence [262] between the different key sizes.
However, these key sizes equivalences need to be understood to apply only to the “best in class” algorithm
for block ciphers, hash function, RSA parameters, etc etc.

It is clearly possible for a block cipher of 128-bits security to not offer 128-bit security due to cryptanalytic attacks.
We have focused on 128 bit security in this document for future use guidelines;
clearly this offers a good long term security guarantee.
It is plausible that similar advise could be made at (say) the 112 bit security level
(which would correspond to roughly 2048 bit RSA keys).
The line has to be drawn somewhere and there is general agreement this should be above the 100-bit level;
whether one selects 112 bits or 128 bits as the correct level is a matter of taste.
Due to the need to protect long term data we have taken the conservative choice and settled on 128 bits;
with a higher level for very long term use.

Due to the problem of key sizes not being a good measure of security on their own, and also due
to considerations of underlying performance costs, at the time of writing the guidelines for future
use can be summarised in the following simple choices:
1. Block Ciphers: For near term use we advise AES-128 and for long term use AES-256.
2. Hash Functions: For near term use we advise SHA-256 and for long term use SHA-512.
3. Public Key Primitive: For near term use we advise 256 bit elliptic curves, and for long term
.. use 512 bit elliptic curves.

TABLE
Table 3.6: Key Size Analysis.
A * notes the value could be smaller due to specific protocol or system reasons, the value given
is for general purposes.

Note, that all of our guidelines need to be read given the aspects described in Section 2.4 which
we do not cover in this report. Finally, we note that the guidelines above, and indeed all analysis
in this document, is on the basis that there is no breakthrough in the construction of quantum
computers. If the development of quantum computers became imminent, then all this documents
guidelines would need to be seriously reassessed. In particular all of the public key based primitives
in this document should be considered to be insecure.
================================================================================================

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong <var@schellong.biz> wrote:
>AES hat den Vorteil, daß er wohl der Populärste ist, und bisher dennoch nicht
>mit erkannter Praxisrelevanz angegriffen werden konnte.

.... und außerdem auf breiter Basis in weit verbreiteter Hardware
implementiert ist.

(>50 Zeilen unwichtiges Zitat gelöscht)

--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> AES hat den Vorteil, daß er wohl der Populärste ist, und bisher dennoch nicht
>> mit erkannter Praxisrelevanz angegriffen werden konnte.
>
> ... und außerdem auf breiter Basis in weit verbreiteter Hardware
> implementiert ist.

Ich muß mal testen, was das wirklich bringt.

Am Rande:

|Rabbit 2.80
|Salsa20 2.80
|Sosemanuk 1.20
|HC-128 0.60
|NLS v2 -0.60
|LEX v2 -1.20
|CryptMT v3 -1.40
|Dragon -1.60
| |For each algorithm attendees were asked to tick one of the following three
|choices regarding its suitability for the final portfolio:
| very suitable, neutral, not very suitable.
|The first and third votes counted for +5 and -5 points each, with
|the final score being averaged over the number of votes cast for a given algorithm.

Es gibt bei weitem nicht nur AES.
(Man könnte den Eindruck gewinnen.)

--
Mit freundlichen Grüßen
Helmut Schellong