Re: Neue ssh-Konfiugration auf shell

Marc Haber:

> Ich schrieb oben von abgeschalteten ecdsa-sha-* Verfahren, weil Du Dich in
> dem von Dir selbst nicht mitizitierten und von mir wieder ergänzten
> Abschnitt darüber beklagt hattest, dass ich ecdsa-sha-* abgeschaltet hätte.
> 
> Ich antwortete Dir fälschlicherweise, ohne vorher geprüft zu haben, ob (a)
> Deine Behauptung überhaupt stimmt und ob es (b) die Verfahren, die ich
> angeblich abgeschaltet habe, überhaupt gibt.

Ich weiß nicht, ob "ecdsa-sha-*" ein Tippfehler von mir war oder
ein Copy&Paste aus 00_zgserver.conf und ich schlicht übersehen habe,
dass das keine gültige Namen bezeichnet. Als ich nachschauen wollte,
war die Konfiguration schon geändert. Egal, der Sachverhalt ist ja
geklärt.

> Gibt es an der aktuellen Konfiguration bis auf die Compression noch etwas
> auszusetzen?

Also bei jeder Abweichung vom Default wäre natürlich die Begründung
interessant, aber mir sticht jetzt nichts besonders ins Auge.

> > > Im Gegensatz zu dem Stand von gestern ist inziwschen ecdsa-nistp-256 wieder
> > > erlaubt; das wird in der Nutzerbasis tatsächlich benutzt.  IMO sollte man
> > > das genauso wie RSA2048 oder kleiner so langsam eigentlich rauswerfen.
> > 
> > Naja, die Stärke ist etwa die von Ed25519.
> 
> Warum migriert dann die ganze Welt auf Ed25519 wenn das nicht stärker ist
> als RSA2048?

Gemeint war, dass ECDSA NIST P-256 etwa die gleiche Stärke wie
Ed25519 hat.

NIST SP 800-57 Teil 1, Tabelle 2, veranschlagt als uuungefähr
äquivalente Stärken:

    AES     RSA     ECC
    128     3072    256
    192     7680    384
    256     15360   512

Die Welt ist zu ECC-Verfahren migriert, weil Schlüssel und Signaturen
schneller erzeugt und kleiner sind.

-- 
Christian "naddy" Weisgerber                          naddy@...

-- 
Unix User Group Rhein-Neckar e.V.: https://www.uugrn.org
Archiv und An-/Abmeldung:          https://mail2.uugrn.org
Social Media:                      https://social.uugrn.org