Am Dienstag 10 August 2010 schrieb Martin Steigerwald: > Am Montag 09 August 2010 schrieb Peter Funk: > > Hallo Liste, > > > > Martin Steigerwald schrieb am Freitag, den 06.08.2010 um 16:23: > > > Auch an Liste, da für denke ich für alle interessant: > > > > > > Am Freitag 06 August 2010 schrieben Sie: > > > > Hallo, > > > > … > > > > > > > Bitte kein DSA: Siehe DSA-1571-1 ;-). > > > > > > > > 1571 spricht doch nicht grundsätzlich gegen das DSA-Verfahren, > > > > oder? DSA-Schlüssel die mit Software von vor dem Einbau des > > > > Fehlers im September 2006 oder von nach der Korrektur dieses > > > > Fehlers im Mai 2008 erzeugt wurden, sollten doch weiterhin > > > > genauso sicher sein wie bisher auch. Außerdem hat dieser Fehler > > > > doch alle Schlüsselarten (also auch RSA ?) betroffen. > > > > > > Lies genauer. > > > > > > Da steht auch drin, dass wenn man mit einem DSA-Schlüssel via SSH > > > auf eine Debian-Box mit dieser Sicherheitslücke verbindet, der > > > DSA-Schlüssel kompromittiert ist. Wie genau das kommt, hab ich > > > ganz ehrlich gesagt damals auch schon nicht verstanden. ;) > > > > Ich bin leider auch kein richtiger Experte in Kryptografie. Aber als > > "interessierter Laie" habe ich das anders verstanden: Der Satz aus > > dem Debian Security Annoucement, auf den sich diese Befürchtung > > vermutlich > > > > bezieht, ist folgender: > > "Furthermore, all DSA keys ever used on affected Debian systems for > > > > signing or authentication purposes should be considered compromised; > > the Digital Signature Algorithm relies on a secret random value used > > during signature generation." > > > > Quelle: http://www.debian.org/security/2008/dsa-1571 > > > > Ich besitze u.a. einen SSH "private Key" aus dem Jahr 2002. Das ist > > ein mit dem DSA (Digital Signature Algorithm) hergestellter > > Schlüssel. Weil der Zufallswert, der bei der Erzeugung dieses > > Schlüssels verwendet wurde, nicht nur aus den besagten 32768 Werten > > stammt, wird > > > > dieser Schlüssel von ssh-vulnkey nicht beanstandet: > > ... Not blacklisted: DSA 2048 c1:... > > > > Deshalb gehe ich nach wie vor davon aus, dass mein SSH-Schlüssel > > auch weiterhin einigermaßen sicher ist. > > Ich beziehe mich wirklich nur auf das, wie ich und andere Mitarbeiter > damals den oben genannten Passus verstanden: > > 1) "Furthermore": Also mit den DSA-Schlüsseln ist noch etwas > Zusätzliches, was auf die RSA-Schlüssel *nicht* zutrifft. > > 2) "all DSA keys ever used on affected Debian systems for signing or > authentication purposes should be considered compromised": Ich finde > *eindeutiger* gehts nicht. Übersetzung: Alle DSA-Schlüssel, die > *jemals* auf den betroffenen System für Signier- *und* > Authentifizierungs-Zwecke zum Einsatz kamen, sollten als > kompromittiert angesehen werden. Ich verstehe nicht, wie man das vom > reinen Satzsinn her anders verstehen kann, als ich es beschrieben > habe. ssh root@kompromittierte-kiste.de => DSA-Schlüssel > kompromittiert. Ha, wofür so ein Waldspaziergang doch alles gut sein kann. Ich hab tatsächlich einen Weg gefunden, diesen Satz an einer entscheidenden Stelle ziemlich anders zu verstehen. In die Richtung, wie ich verstehe, dass Du es verstanden hast, Peter. "all DSA keys ever used *on* affected Debian systems *for* signing or authentication purposes" Meine Übersetzung gab das wieder. Aber demnach stimmt mein Beispiel "ssh root@kompromittierte-kiste.de => DSA-Schlüssel kompromittiert" nicht. *Auf* dem System. Das hieße also, ob die entfernte Box kompromittiert ist oder nicht, wäre unerheblich. Demnach würden folgende Regeln gelten. Allgemein: 1) Alle auf einem kompromittierten System erstellten RSA *und* DSA- Schlüssel sind kompromittiert. *Zusätzllich* *nur* für DSA-Schlüssel: 2) Ein DSA-Schlüssel ist auch dann kompromittiert, wenn ich mich auf einer kompromittierten Kiste damit woanders authentifiziere oder etwas signiere. Vermutung: Und zwar weil dann wie von mir geschrieben weniger Möglichkeiten zum Einsatz kommen und die entfernte Box oder derjenige der die Signatur zu Gesicht bekommt, aufgrund des DSA-Verfahrens Rückschlüsse auf den privaten Schlüssel-Teil ziehen kann - und zwar egal, ob die Box des Angreifers kompromittiert ist oder nicht. Demnach müsste ein nie auf einem kompromittierten System verwendeter DSA- Schlüssel sicher sein, solange ich dessen privaten Teil niemals via Agent Forwarding auf eine kompromittierte Kiste weitergeleitet hab *und* mich von dort woanders authentifiziert hab oder was signiert hab. Es gäbe also immer noch ein gewisses Risiko, was aber leichter zu kontrollieren würde. Mein Mißverständnis wäre demnach, dass ich dachte, es hänge *vom entfernten* System ab, ob mein DSA-Schlüssel kompromittiert ist. Nach diesem Verständnis täte es dies nicht. Damit ich mir darüber nicht den Kopf zerbrechen brauche, bleibe ich jedoch bei RSA-Schlüsseln. Obs jetzt genau so ist, weiß ich nicht. Und jetzt esse ich erstmal zu Abend ;). -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.