Raphael Becker schrieb: > Ist nicht einzig entscheidend, mit welcher Version der Key generiert > wurde ("ssh-kegen -t dsa")? Welches OS der Client hat, dürfte ziemlich > egal sein, auch ob es ungepatchtes Debian ist oder gepatchtes. Nein. Soweit ich gelesen habe - ich kann das mangels Kenntnis nicht verifizieren, aber diejenigen, die davon sprechen, wissen in der Regel, was sie erzählen - genügt es aufgrund der Eigenheiten von DSA-Schlüsseln, diese auch nur einmal von einem "schwachen" System aus verwendet (!) zu haben, weil derselbe Fehler - schwache Zufallszahlen - dann auch beim Verbindungsaufbau den DSA-private-key enthüllt. > Entscheidend ist, aus welchem Material der Key besteht, denn dieser ist > vorhersagbar bzw. auf sehr wenige verschiedene Keys reduzierbar. Das ist nur ein Teil des Problems. > Dieses > sehe ich als eine konkrete Gefahr an und ich glaube (hoffe), dass ich mit > dowkd.pl erkennen kann, wenn ein Schlüssel dieser sehr geringen Menge von > vorhersagbaren Schlüsseln entspricht. Jein. Die Listen sind m.W. nicht vollständig, sondern sind nur für bestimmte Schlüssellängen, bestimmte Systeme und bestimmte Endianness erzeugt. > Ich gehe also mal davon aus, dass ich mittels dowkd.pl "weak keys" > anhand der public-keys erkennen kann. Das habe ich bisher getan. Begrenzt, ja. Das von Marc geschilderte Problem kannst Du aber mit diesem Tool nicht erkennen. > Wie wahrscheinlich siehst Du es an, dass ein Debian-DSA-Key von dowkd.pl > als "unbedenklich" eingestuft wird und dieser dennoch der vorhersagbaren > Schlüsselmenge entspricht (sprich: dass das tool falsch liegt)? Die Erzeugung vorhersagbarer Schlüssel ist nur *eines* der (potentiellen) Probleme an dem unbrauchbaren Zufallszahlengenerator der betreffenden Debian-OpenSSL-Versionen. Ein weiteres, wohl nicht nur potentielles, Problem ist die Kompromittierung von "starken" DSA-Schlüsseln durch die bloße Verwendung auf "schwachen" Systemen. Ein anderes potentielles System liegt m.E. in der Frage - auf die ich bisher keine Antwort kenne -, was denn mit mitgeschnittenen SSH-/SSL-/TLS-Verbindungen ist, die auf "schwachen" Schlüsseln basieren. Auf diese Weise könnten auch Paßworte, Rootpaßworte, vertrauliche Daten etc. pp. kompromittiert worden sein, wenn die Aufzeichnungen rückblickend untersucht werden. > Ich halte es für übertrieben, DSA grundsätzlich zu verbieten, denn ich > gehe zu mindest weiterhin davon aus, dass DSA-Keys, die von einem >! debian erstellt wurden, gewohnt sicher sind. Das gilt wohl theoretisch nicht mehr, wenn sie von einem solchen Debian aus verwendet wurden (und dieser Datenverkehr mitgeschnitten wurde). -thh -- http://mailman.uugrn.org/mailman/listinfo/uugrn Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste Archiv: http://lists.uugrn.org/Empfangen am 17.05.2008
Dieses Archiv wurde generiert von hypermail 2.2.0 : 17.05.2008 CEST