Re: [Poll] https nur mit AES?

[Christian Weisgerber <naddy@xxxxxxxxxxxx>]

Raphael Eiselstein <rabe@xxxxxxxxx> wrote:

> Zu den "EC*"-Ciphern wurde mir gefluestert, dass diese tendenziell
> problemtisch seien. Ich habe mich hier nicht mit Details aufgehalten und
> sie kurzerhand aus meiner Liste verbannt ;-)

Wenn du den Kopf zur anderen Seite neigst, hoert du es von dort
fluestern, dass die klassischen DH/DSA/RSA-Verfahren tendenziell
problematisch seien.

> Wer mag mir das genaue Problem von EC*-Ciphern nochmal erklaeren?
> Patente? NIST und NSA? Irgendwas war.

Verfolgungswahn?

Vorab: Es wird gerne vergessen, dass die NSA zwei Aufgaben hat:
Erstens das Abhoeren auslaendischer Kommunikation und zweitens das
Sichern amerikanischer Kommunikation gegen auslaendisches Abhoeren.
Der Zweck der NIST-Kryptonormen ist die Sicherung amerikanischer
Daten(uebertragung) - von Wirtschaft und Behoerden, einschliesslich
Militaer und Geheimdiensten - gegen die boesen Auslaender.

Was die Kryptographie mit elliptischen Kurven angeht, sind mindestens
drei Verfahren bei der aktuellen Diskussion zu unterscheiden:
* Elliptic Curve Diffie-Hellman (ECDH)
  zur Schluesselaushandlung
* Elliptic Curve Digital Signature Algorithm (ECDSA)
  zum Signieren, also fuer Host- und Benutzerschluessel
* Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG)
  Zufallszahlengenerator #4 aus NIST SP 800-90A

Der Zufallszahlengenerator hat, seit 2007 bekannt, aller Wahrschein-
lichkeit nach eine Hintertuer fuer die NSA. Im Open-Source-Bereich findet
er aber praktisch keine Anwendung.
http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html

Es gibt derzeit keinen gut untermauerten Grund, ECDH/ECDSA mit den
NIST-Kurven nicht zu vertrauen. Man kann das natuerlich aus dem Bauch
heraus tun wie Bruce Schneier.
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929

Umgekehrt gibt es auch Leute, denen klassisches DH/DSA/RSA
Bauchschmerzen bereitet und die eine Umstellung auf elliptische
Kurven predigen.
http://blog.cryptographyengineering.com/2013/08/is-cryptopocalypse-nigh.html

Oder RSA-Schluessel von erheblicher bis unpraktischer Laenge empfehlen.
http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report

Wie dem auch sei, wenn du ECDH/ECDSA mit NIST-Kurven nicht vertraust,
dann hast du hoffentlich auch daran gedacht, sie bei SSH nicht zu
verwenden. Man kann bei OpenSSH an vier wesentlichen Stellen die
Kryptoalgorithmen einstellen:
* Ciphers
  Wie beim Fussball ist da jeder ein Fachmann.
* MACs
  Beim Schrauben an Ciphers wird oft uebersehen, dass der MAC gerne
  genauso viel oder mehr Rechenleistung schluckt.
* HostKeyAlgorithms und Wahl des Benutzerschluessels
  RSA, DSA, ECDSA, LMAA?
* KexAlgorithms
  Hae? Nie gehoert?
OpenSSH verwendet in der Standardeinstellung seit einiger Zeit
ecdh-sha2-nistp256 als KEX und ecdsa-sha2-nistp256 fuer Hostkeys.

Aber frohe Kunde dem, der keine NIST-Kurven mag. Seit einem Monat
unterstuetzt OpenSSH Curve25519 als KEX (Standardeinstellung) und
seit heu^H^H^Hges^H^H^HFreitag Nachmittag nun auch Ed25519 fuer
Schluessel (optional). Ich habe vorhin noch die ganzen Manpages
ergaenzt, die Markus vergessen hat. *Aechz* Es kann sich nur noch um
Jahre handeln, bis das von OpenBSD-current zum Rest der Welt
hinausgesickert ist.

OpenSSH_6.4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/naddy/.ssh/config
debug1: /home/naddy/.ssh/config line 34: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to partoc [2001:6f8:124a::4] port 22.
debug1: Connection established.
debug1: identity file /home/naddy/.ssh/id_rsa type -1
debug1: identity file /home/naddy/.ssh/id_rsa-cert type -1
debug1: identity file /home/naddy/.ssh/id_dsa type -1
debug1: identity file /home/naddy/.ssh/id_dsa-cert type -1
debug1: identity file /home/naddy/.ssh/id_ecdsa type -1
debug1: identity file /home/naddy/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/naddy/.ssh/id_ed25519 type -1
debug1: identity file /home/naddy/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.4
debug1: match: OpenSSH_6.4 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1305@xxxxxxxxxxx <implicit> none
debug1: kex: client->server chacha20-poly1305@xxxxxxxxxxx <implicit> none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ED25519 ff:74:35:03:fa:f6:4f:f7:7f:89:1b:93:f9:d9:22:f4
debug1: Host 'partoc' is known and matches the ED25519 host key.
debug1: Found key in /home/naddy/.ssh/known_hosts:39
debug1: ssh_ed25519_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering ED25519 public key: .ssh/id_ed25519
debug1: Server accepts key: pkalg ssh-ed25519 blen 51
debug1: Authentication succeeded (publickey).
Authenticated to partoc ([2001:6f8:124a::4]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@xxxxxxxxxxx
debug1: Entering interactive session.

PS:
Ich bin der Erste, der eingesteht, dass ich von diesem ganzen
Kryptokram keine Ahnung habe. Ich bemuehe mich nur, mit maessigem
Erfolg, soviel davon zu verstehen, dass ich Verschluesselung sinnvoll
anwenden kann.

-- 
Christian "naddy" Weisgerber                          naddy@xxxxxxxxxxxx
-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/