[Ach] SSL Parameter und Elliptische Kurven...

[Adi Kriegisch]

Hallo!

Vielen Dank für Deine Antwort!

> Als erstes, rein aus Interesse: warum kein (EC)DSA? Warum nur RSA? Wegen
> der möglicherweise problematischen Kurven?
Nein, ich hab im Moment keine passenden Keys und "spiele" mit dem
Livesystem auf plunge.at (https://rhodecode.plunge.at).
 
> zu 1) Nachdem elliptische Kurven symmetrisch um die x-Achse (bzw. im
> kryptographischen Fall symmetrisch um eine von der Kurve abhängige
> Mittelachse) sind, gibt es 2 Möglichkeiten, einen Punkt auf einer Kurve zu
> übertragen: als Tupel aus x und y Koordinate (P = (x,y)), oder als
> x-Koordinate und einem Bit als Information, ob der zugehörige y-Wert "über"
> oder "unter" der Symmetrieachse gemeint ist (P = (x,1|0)).
> 
> Vorteil bei letzterem: man spart zu übertragene Daten.
> Nachteil: ist patentiert. Von Certicom. Tja.
> 
> Macht aber keine Aussage über die unterstützten Kurven, wenn Outlook also
> nur die beiden Kurven anbietet kann es auch nur mit den beiden umgehen
> (obwohl mich das ein wenig überrascht)
Hmmm... ich hab mit tcpdump den TLS handshake angesehen; dort schreibt
Outlook nur etwas von den beiden Kurven. Ich dachte, daß es grundsätzlich
beliebige Kurven kann/versteht, die aber zuerst testen muß, bevor es sie
verwenden darf...
(Die beiden Kurven sind auch das Fallback und Minimum Requirement für
TLSv1.2; siehe [1])

> Zur Sicherheit: ganz ehrlich, keine Ahnung. _wenn_ die tatsächlich die
> standardisierten Kurven speziell konstruiert haben, dann werden die wohl
> alle angepasst haben. Und wenn man sich die Dokumente ansieht, die man für
> Kurven zur Auswahl hat, hat man die Wahl zwischen:
[Pest, Cholera und einer dritten, schweren, noch nicht entdeckte Krankheit]
> Am ehesten vertraue ich da noch Herrn Bernstein [2], die Kurve ist aber
> meines Wissens weder in OpenSSL noch in NSS unterstützt...
Ja. Ich glaube allerdings, daß es nicht nötig ist, alle Kurven zu
manipulieren. Der TLSv1.2 Standard[1] sieht ein Fallback auf genau
secp256r1 und secp384r1. Damit genügt es, sich darauf zu verlassen, daß es
sonst zu keiner Einigung über eine andere Kurve kommt, niemand sich die
Arbeit antut, neue Kurven hinzuzufügen, weil die 2 eh implementiert werden
müssen. So interpretiere ich auch die Outlook-Implementierung (ohne es
ausprobiert zu haben).
Auf das bin ich über die Dovecot Mailingliste[2] gestolpert, wo die
Implementierung in Dovecot diskutiert wird. Um selbst eine Kurve
auszusuchen müsste ich die meinen Key bereits mit der Kurve generieren --
und dann hängts davon ab, ob die Gegenstelle den akzeptiert; sonst wirds
eine NIST-Curve. Falls ich das so richtig verstanden habe, kann ich ECs
niemandem ernsthaft empfehlen, ehrlichgesagt.

Weiters hab ich eine interessante Aufstellung zur Sicherheit von Kurven
gefunden[3]; das sollten wir vielleicht in unser Paper aufnehmen?!

> zu 2) mir wäre jetzt kein (praktischer) Vorteil von GCM über SHA384
> bekannt, allerdings auch kein Nachteil, von daher ist das in meinen Augen
> so auch ok
Ok, perfekt! Vielen Dank!
 
> zu 3) Zu AES gibt's halt mehr Research als zu Camelia, das haben die
> Japaner gebastelt... Seitenkanalattacken gibt's dagegen genauso (z.B. [1]),
> aber aktuell werden beide für gleich sicher gehalten. Ich wüsste momentan
> keinen Grund, eins von beiden zu bevorzugen (wenn man natürlich annimmt,
> dass die NSA sich eine Backdoor in AES offengehalten haben, dann ist das in
> Camelia unwahrscheinlicher).
Hmmm... ok. Dann ist der Unterschied hauptsächlich, daß es für AES eine
Hardware-Implementierung gibt mit der man einen eindeutigen
Performance-Vorteil hat.

So wie ich das im Moment sehe, ist vom Einsatz elliptischer Kurven (wegen
Fallbacks auf die NIST-Kurven und deren unklarem Sicherheitsstand) in
Wirklichkeit abzuraten. Damit bleibt nur mehr EDH/DHE oder eben keine
Forward Secrecy.

Glg Adi

[1] https://www.rfc-editor.org/rfc/rfc6460.txt
[2] http://dovecot.org/list/dovecot/2013-July/091318.html
[3] http://safecurves.cr.yp.to/rigid.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20131022/41647fdc/attachment.sig>