On Thu, Nov 23, 2000 at 02:24:09PM +0100, Torsten Werner wrote:
Hmm, es gibt aber ein paar Unterschiede. Gnupg ist eher so angelegt, dass es auch in vielen Jahren noch als sicher gilt. Die anderen Sachen dienen eher dazu, heute einigermassen verlaesslich zu verschluesseln.
Das betrifft aber nur die symmetrischen session keys. Die geheimen asymmetrischen Schlüsel sind bei ssh und SSL genauso auf Dauerhaftigkeit angelegt wie bei gnupg. Bei allen drei Dingen werden deshalb auch die gleichen Algorithmen (RSA oder DSA) mit aehnlichen Schlüssellängen verwandt.
Ssh hat gegenueber ssl den Vorteil, dass man seine Schluessel mit anderen Hosts austauschen kann, ohne auf eine CA angewiesen zu sein, waehrend ssl mehr die PNP-Variante ist - fuer die DAUs eben ;-).
Falsch. Wie kommt wohl bei ssh der public-host-key des Zielrechners bei der ersten Verbindung zu diesem Host zu dir? Holst du dir diesen Key vom Admin des jeweiligen Rechners auf Diskette ab? Sicher nicht. Die ssh holt ihn netterweise für dich übers Netz und fragt dich: --- Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes --- Wenn du jetzt 'yes' tippst vertraust du blind(!!!) das dies der key des gewünschen Hosts ist. SSH macht sich einfach keine Birne darüber, wie der initiale Austausch der public keys passiert und geht dieser schief, ist der ganze Rest sinnlos. Der *Nutzer* muss sich darum kümmern, dass dieser Schlüsselaustausch authentisch passiert. In der Praxis klappt das natürlich nicht, das Nutzer potentiell faul sind und einfach möglichst scjnell den Prompt den Zielrechners in ihrem xterm sehen wollen stat sich mit den blöden Schlüsseln rumzuschlagen.
In der Praxis werden wohl in 99% der Fälle die Keys blind durch das "yes"-tippen bei der 1. Verbindung akzeptiert. Dieser Schlüsselautasch ist also reines Glück - im Gegensatz zur PKI bei SSL. Das kann man nicht als Vorteil bezeichnen, oder? (Der einzige Vorteil ist, dass der Nutzer weniger Stress hat und es trotzdem meistens gut geht. Also ein pragmatischer Kompromiß.)
Vergleich: Der 1. Austausch der Schlüssel bei der ssh ist anlog zu einem Schlüsseltausch bei SSL (also in einer PKI) mit einer CA, die einfach blind alles unterschreibt. Klar? --> Wenn nun aber die CA alles unterschreibt, kann man das Unterschreiben gleich ganz weglassen - das macht die ssh)
Solche "Spasszertifikate" werden übrigens von vielen auch auch für SSL benutzt. Die CA des CCC unterschreibt dir beispielsweise beliebige Certs. Das macht auch Sinn - man muß nur wissen wozu! (Verschlüsselung auf der Leitung ohne Authentisierung) Du kannst auch gleich alles selbst von deiner eigenen CA unterschreiben lassen und hast damit bei SSL keinen größeren Aufwand beim Schlüsseltausch mehr als bei der ssh.
Also alles kann man sicher nicht vereinheitlichen und auf einen einzigen Algorithmus bringen, wobei deine Motivation schon zu verstehen ist.
Ich will nicht nur einen Algorithmus. Ich will von jedem Algorithmus nur eine Implementierung auf meinem Rechner, die von allen Programmen genutzt wird. Das war der Punkt. Mich stört der Wildwuchs durch die vielen Programme, die alle ihren eigenen Bibliotheken mitbringen.
Reinhard