[Ach] SSL Parameter und Elliptische Kurven...

Tue Oct 22 09:54:02 CEST 2013

Da kann ich kurz was beitragen, wenn ich schon sonst nix leiste (hab eh ein
unglaublich schlechtes Gewissen, aber aktuell geht's in der Arbeit dermaßen
zu...):

Als erstes, rein aus Interesse: warum kein (EC)DSA? Warum nur RSA? Wegen
der möglicherweise problematischen Kurven?

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)

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:

*) NIST, nunja
*) ANSI X9.62, wenn die NSA ein Standardisierungsinstitut kompromittiert
kann sie das auch mit einem anderen
*) SECG, Konsortium aus  Certicom, Entrust, Fujitsu, NIST, Pitney Bowes,
Unisys, Visa. Auch nicht besser.

Am ehesten vertraue ich da noch Herrn Bernstein [2], die Kurve ist aber
meines Wissens weder in OpenSSL noch in NSS unterstützt...

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

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).

lg
Manuel

[1] http://eprint.iacr.org/2009/354.pdf
[2] http://cr.yp.to/ecdh.html

2013/10/21 Adi Kriegisch <adi at kriegisch.at>

> Hallo!
>
> Ich bin in der letzten Zeit der Frage nach den "perfekten" SSL-Settings
> nachgegangen und dabei über ein paar Fragen gestolpert, die ich nicht
> beantworten kann -- aber hoffentlich irgendwer in dieser Runde.
>
> Zuerst kurz was ich gemacht habe (zerlegter und kommentierter OpenSSL
> Cipher String):
> # Alle ephemeral elliptic curve key exchanges; geordnet nach
> # GCM -> SHA384 -> SHA256 (=> Frage 1 & Frage 2)
>   >  EECDH+aRSA+AESGCM EECDH+aRSA+SHA384 EECDH+aRSA+SHA256
> # DHE mit Camellia256 (=> Frage 3)
>   >  EDH+CAMELLIA256
> # alles andere mit ECDH (das nicht weiter unten deaktiviert wurde); also
> # auch SSLv3/TLSv1.
>   >  EECDH
> # DHE/EDH mit RSA (auch wieder incl. SSLv3/TLSv1)
>   >  EDH+aRSA
> # alles mit SSLv3/TLSv1 nach hinten sortiert
>   >  +SSLv3
> # dann die üblichen deaktivieren (incl. RC4)
>   >  !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4 !SEED
> # dann alles mit 128bit deaktivieren
>   >  !AES128 !CAMELLIA128
> # überflüssig, aber der Lesbarkeit wegen alles mit DSA deaktivieren:
>   >  !ECDSA
> # und als "last chance" eine nicht PFS-fähige Ciphersuite, damit Windows >
> # XP auch noch mitspielen kann (Vista/Win7/Win8).
>   >  AES256-SHA
>
> "EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA"
>
> Das ergibt dann folgenden Cipher String:
> 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2
> 0xC0,0x28 - ECDHE-RSA-AES256-SHA384      TLSv1.2
> 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384    TLSv1.2
> 0x00,0x6B - DHE-RSA-AES256-SHA256        TLSv1.2
> 0x00,0x88 - DHE-RSA-CAMELLIA256-SHA      SSLv3
> 0xC0,0x14 - ECDHE-RSA-AES256-SHA         SSLv3
> 0x00,0x39 - DHE-RSA-AES256-SHA           SSLv3
> 0x00,0x35 - AES256-SHA                   SSLv3
>
> 1. Sind die NIST-Kurven jetzt als sicher anzusehen? Welche der Kurven sind
>    nach momentanem Wissenstand OK, welche eher nicht?
>    Outlook 2007 (mit TLSv1.2 aktiviert) schickt mit, daß es genau
>    'secp256r1' und 'secp384r1' kennt. Weiters meint es, daß es das "EC
>    Point Format: uncompressed" unterstützt -- bedeutet das, daß es mit
>    beliebigen Kurven kann? Wenn ja, kann ich mir mal ansehen, wie man
>    serverseitig auf die Wahl der Kurven Einfluß nehmen kann.
> 2. "GCM -> SHA384 -> SHA256" ist das eine sinnvolle Sortierung?
> 3. Ist Camellia256 gegenüber AES256 zu bevorzugen? Oder eher im Gegenteil?
>    Ivan Ristić ignoriert Camellia in seinem Beispiel ab Seite 29 im
> "OpenSSL
>    Cookbook" und ich versteh das nicht ganz.
>    Soweit ich bisher gesehen habe gibt es Side-Channel Attacken auf AES
>    durch Lookup Tables sofern man nicht die AES-NI Extension in der CPU
>    nutzt. Wie steht es da mit Camellia?
>
> Glg Adi
>
> PS: Auf einem Debian Wheezy kann der Apache nur DHE und nichts mit
> elliptischen Kurven; das kann nur der nginx. Der Grund dafür ist, daß auf
> Debian immer noch Apache 2.2 verwendet wird und Apache (mit mod_ssl) erst
> ab Version 2.4 elliptische Kurven auch zu können scheint.
>
> PPS: Das ist auf einem Standard Debian die Liste der elliptischen Kurven,
> die OpenSSL kennt:
> openssl ecparam -list_curves
>   secp112r1 : SECG/WTLS curve over a 112 bit prime field
>   secp112r2 : SECG curve over a 112 bit prime field
>   secp128r1 : SECG curve over a 128 bit prime field
>   secp128r2 : SECG curve over a 128 bit prime field
>   secp160k1 : SECG curve over a 160 bit prime field
>   secp160r1 : SECG curve over a 160 bit prime field
>   secp160r2 : SECG/WTLS curve over a 160 bit prime field
>   secp192k1 : SECG curve over a 192 bit prime field
>   secp224k1 : SECG curve over a 224 bit prime field
>   secp224r1 : NIST/SECG curve over a 224 bit prime field
>   secp256k1 : SECG curve over a 256 bit prime field
>   secp384r1 : NIST/SECG curve over a 384 bit prime field
>   secp521r1 : NIST/SECG curve over a 521 bit prime field
>   prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
>   prime192v2: X9.62 curve over a 192 bit prime field
>   prime192v3: X9.62 curve over a 192 bit prime field
>   prime239v1: X9.62 curve over a 239 bit prime field
>   prime239v2: X9.62 curve over a 239 bit prime field
>   prime239v3: X9.62 curve over a 239 bit prime field
>   prime256v1: X9.62/SECG curve over a 256 bit prime field
>   sect113r1 : SECG curve over a 113 bit binary field
>   sect113r2 : SECG curve over a 113 bit binary field
>   sect131r1 : SECG/WTLS curve over a 131 bit binary field
>   sect131r2 : SECG curve over a 131 bit binary field
>   sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
>   sect163r1 : SECG curve over a 163 bit binary field
>   sect163r2 : NIST/SECG curve over a 163 bit binary field
>   sect193r1 : SECG curve over a 193 bit binary field
>   sect193r2 : SECG curve over a 193 bit binary field
>   sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
>   sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
>   sect239k1 : SECG curve over a 239 bit binary field
>   sect283k1 : NIST/SECG curve over a 283 bit binary field
>   sect283r1 : NIST/SECG curve over a 283 bit binary field
>   sect409k1 : NIST/SECG curve over a 409 bit binary field
>   sect409r1 : NIST/SECG curve over a 409 bit binary field
>   sect571k1 : NIST/SECG curve over a 571 bit binary field
>   sect571r1 : NIST/SECG curve over a 571 bit binary field
>   c2pnb163v1: X9.62 curve over a 163 bit binary field
>   c2pnb163v2: X9.62 curve over a 163 bit binary field
>   c2pnb163v3: X9.62 curve over a 163 bit binary field
>   c2pnb176v1: X9.62 curve over a 176 bit binary field
>   c2tnb191v1: X9.62 curve over a 191 bit binary field
>   c2tnb191v2: X9.62 curve over a 191 bit binary field
>   c2tnb191v3: X9.62 curve over a 191 bit binary field
>   c2pnb208w1: X9.62 curve over a 208 bit binary field
>   c2tnb239v1: X9.62 curve over a 239 bit binary field
>   c2tnb239v2: X9.62 curve over a 239 bit binary field
>   c2tnb239v3: X9.62 curve over a 239 bit binary field
>   c2pnb272w1: X9.62 curve over a 272 bit binary field
>   c2pnb304w1: X9.62 curve over a 304 bit binary field
>   c2tnb359v1: X9.62 curve over a 359 bit binary field
>   c2pnb368w1: X9.62 curve over a 368 bit binary field
>   c2tnb431r1: X9.62 curve over a 431 bit binary field
>   wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
>   wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
>   wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
>   wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
>   wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
>   wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
>   wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
>   wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
>   wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
>   wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
>   wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field
>   Oakley-EC2N-3:
>         IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
>         Not suitable for ECDSA.
>         Questionable extension field!
>   Oakley-EC2N-4:
>         IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
>         Not suitable for ECDSA.
>         Questionable extension field!
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iQIVAwUBUmVNW3REfA6phVy/AQKUVg//bm/99MwgYKoU4NmjIagOeWzvYGyfvM4S
> 6YCJBb9LONMxn5Eyz9Dz3HnncR7GKh3R/R1IUlvk16qEnZIbIEEQbU/CfJ35ViLa
> kCVuanfDNpHhKvyt/RnXICF/4THH56Ce7g0olpmBFw8EmJxvn0qNunoWQkIAwWmI
> RnGkn8pGCROXl9rUsiY51Cbe9p5OFTGMQwcBvCEjAycmHnIlxUdYlF+cDzdWD3FV
> 84JkkohhJARkkEWK/xqmbDMr5YihvdsS4+TLiVmiIykXcl5r7eQblTgYnBTTc7FQ
> fzaKH/vsYtnTbTTq/xD1K28PAB8Arz0CN2m35CD64Pevm/E/oWrLRG41/ILBNYp+
> 13IdRfXlh91z/LHVqrZk/m6wtgQBlvFmYzcmyNKdmNcjlubfSLLEdNVUB/hChMgm
> zoTRrBdOElwdNHCorJSAcXo6/hK9XN07xQEQC+Ewmv/8KvufCYTYVgRnNhJlKCN1
> YoQGNMVlfFMUoxu4A25nxHyhrH/mzkSGMp1h9Qz7pFyA9EW61Ab3/vTcmoA+7ur1
> nFTIWkVn2buMfwnAcwxrgVlpe++sLKQBYBw/HygHCXlhh9SYs+3jc50IhXEyeE+c
> fTVmdhoESx5p+IyAZbHlY8ZPrbYlTl9XzTtoDBVKt1IEzx8mg+6h14QklPMVbE1Y
> nt8LaS0BkMM=
> =nx0P
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20131022/667ab671/attachment.html>