Abo
  1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Schlüsselaustausch: Eine…

Der Test kann einige Zehntelsekunden dauern...

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Der Test kann einige Zehntelsekunden dauern...

    Autor: Captain 08.08.16 - 09:11

    Wenn es um Sicherheit geht, werden die Zehntelsekunden beim Schlüsseltausch einen nicht umbringen...

  2. Re: Der Test kann einige Zehntelsekunden dauern...

    Autor: robinx999 08.08.16 - 09:27

    Captain schrieb:
    --------------------------------------------------------------------------------
    > Wenn es um Sicherheit geht, werden die Zehntelsekunden beim Schlüsseltausch
    > einen nicht umbringen...
    evtl. bringt es aber den Server um bzw. dieser hängt dann permanent bei 100% CPU Last da bei jeder neu aufgebauten SSL Verbindung der Server diese Zehntel Sekunden aufbringen muss, was bei hohem Nutzer aufkommen evtl. dafür sorgen könnte das nichts mehr klappt

  3. Re: Der Test kann einige Zehntelsekunden dauern...

    Autor: Xiut 08.08.16 - 09:34

    robinx999 schrieb:
    --------------------------------------------------------------------------------
    > Captain schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wenn es um Sicherheit geht, werden die Zehntelsekunden beim
    > Schlüsseltausch
    > > einen nicht umbringen...
    > evtl. bringt es aber den Server um bzw. dieser hängt dann permanent bei
    > 100% CPU Last da bei jeder neu aufgebauten SSL Verbindung der Server diese
    > Zehntel Sekunden aufbringen muss, was bei hohem Nutzer aufkommen evtl.
    > dafür sorgen könnte das nichts mehr klappt

    Könnte man die dann nicht einfach Stichprobenartig testen und die Quote für diese Stichproben bei weniger Last steigen und bei mehr Last senken?

    Würde dann die Sicherheit erhöhen ohne, dass der Server dauerhaft mehr belastet wird. Aber vielleicht übersehe ich auch etwas, was dagegen spricht. Wäre nur mein erster Gedanke bei soetwas.

  4. Re: Der Test kann einige Zehntelsekunden dauern...

    Autor: zampata 08.08.16 - 09:38

    Xiut schrieb:
    --------------------------------------------------------------------------------
    > Könnte man die dann nicht einfach Stichprobenartig testen und die Quote für
    > diese Stichproben bei weniger Last steigen und bei mehr Last senken?

    Wenn 0.01% aller Verbindungen auf diese Weise geprüft werden würde dann bringt diese "Sicherheitsverbesserung" auch keine Sicherheitsverbesserung. Streiten können wir uns gerne ob es nun 0.01, 0.1 oder 1% sind; am Gesamtwerk ändert es aber nichts -> Die Chance mit einem derartigen Angriff erwischt zu werden ist zu gering.

  5. Re: Der Test kann einige Zehntelsekunden dauern...

    Autor: Sharra 08.08.16 - 09:45

    Wozu denn jedes mal, immer und immer wieder die selben Zahlen nachrechnen? Es reicht doch einmal. Wenn das System für sich selbst befunden hat, die Zahl ist eine Primzahl, landet diese in einer Liste. Danach muss nur noch bei Zahlen nachgerechnet werden, die nicht in der Liste stehen. Zeitaufwand bei einem Listencheck = Nanosekunden. CPU-Last kaum messbar.

    Natürlich muss die Liste abgeschottet werden, damit keiner von aussen eine x-beliebige Zahl einschleusen kann. Und wenn mans ganz lustig haben möchte, werden die Listeneinträge, in Zeiten geringer Last, pro Forma nochmal überprüft.

  6. Re: Der Test kann einige Zehntelsekunden dauern...

    Autor: Wallbreaker 08.08.16 - 09:48

    Captain schrieb:
    --------------------------------------------------------------------------------
    > Wenn es um Sicherheit geht, werden die Zehntelsekunden beim Schlüsseltausch
    > einen nicht umbringen...

    In dieser Hinsicht gibt es immer wieder ganz besondere Spezialisten bei Unternehmen. Da werden nur um mehr Geschwindigkeit herauszuholen, mal eben kryptografische Werte genullt, die Algorithmen selbst angepasst, z.B. Runden entfernt und all solche Spielchen. Und genau solche Dinge führen die Sicherheit ad absurdum. Oftmals steht Sicherheit nicht an erster Stelle, auch wenn das so sein sollte.

    Nur die Sache mit der Geschwindigkeit ist ein generelles Problem asymmetrischer Verschlüsselung. Allein wenn man die Schlüssellänge von 2048-Bit nimmt, die noch sicher ist, aber zugleich auch nur noch eine annehmbare Geschwindigkeit ermöglicht. Müsste man diese nun auf 3072/4096-Bit anheben, dann wird es immer kritischer. Daher unter Anderem auch die Entwicklungen mittels elliptischer Kurven.

  7. Re: Der Test kann einige Zehntelsekunden dauern...

    Autor: robinx999 08.08.16 - 10:18

    Diese Idee kann man schnell vergessen die Länge der Primzahlen ist zu groß. Und somit würde man zu viele Einträge in einer Derartigen Liste benötigen, so dass diese Liste sowohl zu viel Festplatten speicher bräuchte und es schlicht und einfach nicht praktikabel ist.
    http://crypto.stackexchange.com/questions/1963/how-large-should-a-diffie-hellman-p-be

  8. Re: Der Test kann einige Zehntelsekunden dauern...

    Autor: Tragen 08.08.16 - 11:26

    Man könnte ja auch eine Liste mit Primzahlhashes nehmen. Die wäre erheblich kleiner.

  9. Re: Der Test kann einige Zehntelsekunden dauern...

    Autor: robinx999 08.08.16 - 11:49

    Wenn ich dann z.B.: versuche darin alle Primzahlen abzuspeichern die sich sagen wir zwischen 2^277 und 2^278 befinden wird das aber auch eine verdammt lange Liste.

  10. Re: Die Lösung steht sogar im Artikel...

    Autor: crypt0 08.08.16 - 12:13

    Für einen voreingestellten DH Modulus werden NUR starke/sichere Primzahlen verwendet (für diese PZ gilt: q sei prim - dann muss gelten: (q-1) / 2 ist ebefalls prim => Das Decisional-Diffie-Hellman-Problem (DDH) ist 'schwer')

    Solche Primzahlen existieren (bsp. RFC3526 https://www.ietf.org/rfc/rfc3526.txt)
    Alle "on-the-fly" generierten Moduli werden NIEMALS wiederverwendet!

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. EWE AG, Oldenburg
  2. SEW-EURODRIVE GmbH & Co KG, Bruchsal
  3. Ludwig-Maximilians-Universität München (LMU), München
  4. Bosch Service Solutions Leipzig GmbH, Leipzig

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


China: Die AAA-Bürger
China
Die AAA-Bürger
  1. Microsoft Supreme Court entscheidet über die Zukunft der Cloud

Berlin: Verfassungsschutz hat Lizenz zur Gesichtserkennung
Berlin
Verfassungsschutz hat Lizenz zur Gesichtserkennung
  1. Finnairs Gesichtsscanner ausprobiert Boarden mit einem Blick in die Kamera

Watch Series 3 im Praxistest: So hätte Apples erste Smartwatch sein müssen
Watch Series 3 im Praxistest
So hätte Apples erste Smartwatch sein müssen
  1. Apple Watch Apple veröffentlicht WatchOS 4.2
  2. Alivecor Kardiaband Uhrenarmband für Apple Watch zeichnet EKG auf
  3. Smartwatch Die Apple Watch lieber nicht nach dem Wetter fragen

  1. Zeitpunkt verschoben: Musk reduziert Erwartungen an autonomes Fahren
    Zeitpunkt verschoben
    Musk reduziert Erwartungen an autonomes Fahren

    Vor zwei Jahren hat Elon Musk autonom fahrende Autos für 2018 angekündigt. Nun verschiebt der Tesla-Chef diese Erwartung zwei Jahre nach hinten. In drei Jahren sollen autonome Autos aber sogar besser fahren als der Mensch.

  2. MacOS High Sierra: Grafikleistung beim Macbook Pro bricht durch Bug ein
    MacOS High Sierra
    Grafikleistung beim Macbook Pro bricht durch Bug ein

    In MacOS High Sierra steckt ein Fehler, durch den die Grafikleistung des Macbook Pro 15 Zoll mit dedizierter Grafik erheblich gemindert wird, wenn das Gerät aus dem Ruhezustand geweckt wird. Abhilfe von Apple gibt es noch nicht, Selbsthilfe ist aber möglich.

  3. Elektromobilität: VW-Chef will Diesel-Steuervorteile für E-Autos streichen
    Elektromobilität
    VW-Chef will Diesel-Steuervorteile für E-Autos streichen

    Auf Diesel ist die Mineralölsteuer 18,4 Cent niedriger als auf Benzin. Volkswagen-Chef Matthias Müller plädiert dafür, diesen Steuervorteil abzuschaffen und das Geld in den Aufbau der Elektromobilität zu stecken.


  1. 07:58

  2. 07:33

  3. 07:21

  4. 10:59

  5. 09:41

  6. 08:00

  7. 15:44

  8. 14:05