Security des tages

Der „GNU privacy guard“, besser bekannt als GPG und das programm, mit dem beinahe jeder seine mäjhl verschlüsselt, hatte ein sicherheitsloch, durch das eventuell doch ein paar bit privater schlüssel ermittelbar wurden. Ob die auswirkungen so groß sind, dass wir jetzt besser alle unsere schlüssel zurückziehen sollten, kann im moment noch keiner sagen — wer ganz sicher gehen will oder muss, sollte es tun…

(Ich weiß, das klingt im artikel anders. Aber es gibt auch hin und wieder einmal menschen, die sich darauf verlassen müssen, dass eine digitale signatur echt ist und/oder dass eine nachricht von niemanden anders mitgelesen werden kann. Es kann sogar jeder in die situazjon kommen, darauf angewiesen zu sein. Deshalb ist neurotische übervorsicht bei fehlern im kryptokram die einzig angemessene haltung. Die beschwichtigenden worte zu einem zeitpunkt, an dem die auswirkungen des fehlers noch nicht vollständig analyisiert sind, wecken meinen hang zur skepsis.)

Aber die neue GPG-versjon ziehen, das sollten wir alle! Denn nur ein beseitigter fehler ist ein guter fehler.

2 Antworten zu “Security des tages

  1. Sieht auch aus meiner Sicht übel aus. Die Einstufung als critical security problem ist sicherlich richtig.
    Wobei ich ja argwöhne, dass die Vorhersagbarkeit des nächsten 20-Byte-Blocks aus den 29 vorangegangenen Blöcken die Verhersagbarkeit aller nachfolgenden Blöcke impliziert. Das ist so nicht angegeben worden, und vielleicht stimmt das so nicht, aber so stelle ich mir das erst einmal vor.
    In dem Fall bräuchte es für einen Exploit lediglich genügend viele aufeinanderfolgende Daten aus dem Zufallsgenerator, um das, was danach kommt, vorhersagen zu können. Ich gehe davon aus, dass RSA-Signaturen mit vielen Zufallsbits aufgefüllt werden. Dann ginge ein Explot etwa so: Der Angreifer bringt das Opfer dazu, drei 2048-Bit-Signaturen zu leisten und direkt danach einen neuen privaten Schlüssel zu generieren. Zur Sicherheit, denn da war ja diese Lücke…! Nur kann der Angreifer dann den generierten privaten Schlüssel vorhersagen.
    Wird nicht ganz so einfach sein, aber beunruhigend ist diese Lücke allemal.

  2. Beim Code-Auditing sollte man folglich mal darauf achten, ob beim Erzeugen eines Schlüsselpaares die Pseudo-Zufalls-Bits zum Füllen der eigenen Signatur des öffentlichen Schlüssels „vorsorglich“ vor den Zufallsbits des privaten Schlüssels generiert werden. Das könnte so eine U-Boot-Aktion sein, um möglichst viele Hinweise auf die geheimen Bits durchsickern zu lassen.
    Geheime Pseudo-Zufalls-Bits sollten demnach vor den öffentlichen Bits erzeugt werden, und besser noch mit separaten Generatoren (separate Zustandsspeicher).

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s