On Thu, Nov 23, 2000 at 01:17:15PM +0100, Thomas Guettler wrote:

BTW, telnet ist absolut unsicher. Passwoerter werden im klartext uebertragen. Laesst sich leicht mit z.B. ethereal ausprobieren (Packet-sniffer). Man sollte sich das verwenden von telnet gleich ausgewoehnen und SSH verwenden.

Vielleicht macht er ja Telnet über SSL, IPSec oder ueber einen sonstigen verschlüselten Kanal. Dieses "telnet ist absolut unsicher" ist mittlerweise jedenfalls gewagt.

BTW: Ansätze, die Telnet,POP und sonstwas ... ueber SSL machen oder auf tieferen Schichten verschlüsseln, haben nebenbei den Vorteil, daß damit der sicherheitsrelavante Teil des Kodes *nur einmal* da ist und und von allen Programmen genutzt wird. Der gut zu prüfende Kode ist also deutlich kleiner als es heute der Fall ist. Auf einer im Moment übliche Linux-Box hat man wahrscheinlich eine Ylonen-ssh, Apache+openssl, gnupg und Netscape drauf, und somit fuer eine große Zahl sicherheitsrelevanter Sachen *meheere* Implementierungen der gleichen Algorithmen auf der Platte und in Nutzung. Das ist auch völlig schrottig, gilt aber als hip, da allgemein "viel Cryptokram hilft viel" angenommen wird.

Reinhard

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

BTW: Ansätze, die Telnet,POP und sonstwas ... ueber SSL machen

achtung: ssl wird im allgemeinen nicht mehr als besonders sicher eingestuft. d.h. nicht das es unsicher ist, aber root-passwörter von wichtigen servern sollte man vielleicht doch noch sicherer verschlüsseln.

cu ronny

Von wem? Begründet wodurch? Quelle?

ja, sobald ich wieder in der bibliothek bin, suche ich das buch.

Wieviel Platz ist denn noch zwischen "nicht mehr als besonders sicher eingestuft" und "unsicher" :-)

"unsicher" läßt sich schon heute relativ problemlos komprementieren. "nicht mehr als besonders sicher" meint, daß es in absehbarer zeit ein verfahren geben wird (z.b. finden von gleichen klartexten für md5). andere verfahren wie rsa mit entsprechender schlüssellänge sind zwar mathematisch nicht sicher (falls du einen faktorisierungsalgo hast, kannst du dir ja die fieldsmadal abholen ;), aber eben nach allgemeinem verständnis als sicher zu betrachten (ob der nsa das auch so sieht?).

Glaub nicht alles, ohne die Details zu erfragen.

thanx 4U flame...

cu ronny

Logo, assym. Krypt geht nicht theoretisch sicher. (Wobei ich statt stressiger Faktorisierung einfach den passenden secret key richtig raten würde)

naja, mit brute force hast du da wahrscheinlich genau so wenig erfolg wie mit faktorisierung - aber, solang keiner den beweis findet, daß die faktorisierung np-vollständig ist, könnte die faktorisierung theoretisch auch auf ein triviales problem reduziert werden.

einigen und dann kommunizieren. Wenn sich beide Seiten auf einen nach heutigem Verständnis unsicheren Lösung (z.B. DES) einigen,

rsa mit effektiv 48bit ist auch nicht viel sicherer (zumindest aus der sicht des nsa ;)

Problem, kann das aber nicht auf SSL schieben. Diese Betrachtung brachte mich zu der Antwort auf dein "unsichers SSL".

gut, dann hatte ich das mißverstanden.

cu ronny