<div dir="ltr">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...):<div><br></div><div>Als erstes, rein aus Interesse: warum kein (EC)DSA? Warum nur RSA? Wegen der möglicherweise problematischen Kurven?</div>
<div><br></div><div>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)). </div>
<div><br></div><div>Vorteil bei letzterem: man spart zu übertragene Daten.</div><div>Nachteil: ist patentiert. Von Certicom. Tja.</div><div><br></div><div>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)</div>
<div><br></div><div>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:</div>
<div><br></div><div>*) NIST, nunja</div><div>*) ANSI X9.62, wenn die NSA ein Standardisierungsinstitut kompromittiert kann sie das auch mit einem anderen</div><div>*) SECG, Konsortium aus <span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:19.1875px"> </span>Certicom<span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:19.1875px">, </span>Entrust<span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:19.1875px">, </span>Fujitsu<span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:19.1875px">, </span>NIST<span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:19.1875px">, </span>Pitney Bowes<span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:19.1875px">, </span>Unisys<span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:19.1875px">, </span>Visa<span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:19.1875px">. Auch nicht besser.</span></div>
<div><span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:19.1875px"><br></span></div><div><span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:19.1875px">Am ehesten vertraue ich da noch Herrn Bernstein [2], die Kurve ist aber meines Wissens weder in OpenSSL noch in NSS unterstützt...</span></div>
<div><br></div><div>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</div><div><br></div><div>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).</div>
<div><br></div><div><br></div><div>lg</div><div>Manuel</div><div><br></div><div><br></div><div>[1] <a href="http://eprint.iacr.org/2009/354.pdf">http://eprint.iacr.org/2009/354.pdf</a></div><div>[2] <a href="http://cr.yp.to/ecdh.html">http://cr.yp.to/ecdh.html</a></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/21 Adi Kriegisch <span dir="ltr"><<a href="mailto:adi@kriegisch.at" target="_blank">adi@kriegisch.at</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hallo!<br>
<br>
Ich bin in der letzten Zeit der Frage nach den "perfekten" SSL-Settings<br>
nachgegangen und dabei über ein paar Fragen gestolpert, die ich nicht<br>
beantworten kann -- aber hoffentlich irgendwer in dieser Runde.<br>
<br>
Zuerst kurz was ich gemacht habe (zerlegter und kommentierter OpenSSL<br>
Cipher String):<br>
# Alle ephemeral elliptic curve key exchanges; geordnet nach<br>
# GCM -> SHA384 -> SHA256 (=> Frage 1 & Frage 2)<br>
  >  EECDH+aRSA+AESGCM EECDH+aRSA+SHA384 EECDH+aRSA+SHA256<br>
# DHE mit Camellia256 (=> Frage 3)<br>
  >  EDH+CAMELLIA256<br>
# alles andere mit ECDH (das nicht weiter unten deaktiviert wurde); also<br>
# auch SSLv3/TLSv1.<br>
  >  EECDH<br>
# DHE/EDH mit RSA (auch wieder incl. SSLv3/TLSv1)<br>
  >  EDH+aRSA<br>
# alles mit SSLv3/TLSv1 nach hinten sortiert<br>
  >  +SSLv3<br>
# dann die üblichen deaktivieren (incl. RC4)<br>
  >  !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4 !SEED<br>
# dann alles mit 128bit deaktivieren<br>
  >  !AES128 !CAMELLIA128<br>
# überflüssig, aber der Lesbarkeit wegen alles mit DSA deaktivieren:<br>
  >  !ECDSA<br>
# und als "last chance" eine nicht PFS-fähige Ciphersuite, damit Windows ><br>
# XP auch noch mitspielen kann (Vista/Win7/Win8).<br>
  >  AES256-SHA<br>
"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"<br>
<br>
Das ergibt dann folgenden Cipher String:<br>
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2<br>
0xC0,0x28 - ECDHE-RSA-AES256-SHA384      TLSv1.2<br>
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384    TLSv1.2<br>
0x00,0x6B - DHE-RSA-AES256-SHA256        TLSv1.2<br>
0x00,0x88 - DHE-RSA-CAMELLIA256-SHA      SSLv3<br>
0xC0,0x14 - ECDHE-RSA-AES256-SHA         SSLv3<br>
0x00,0x39 - DHE-RSA-AES256-SHA           SSLv3<br>
0x00,0x35 - AES256-SHA                   SSLv3<br>
<br>
1. Sind die NIST-Kurven jetzt als sicher anzusehen? Welche der Kurven sind<br>
   nach momentanem Wissenstand OK, welche eher nicht?<br>
   Outlook 2007 (mit TLSv1.2 aktiviert) schickt mit, daß es genau<br>
   'secp256r1' und 'secp384r1' kennt. Weiters meint es, daß es das "EC<br>
   Point Format: uncompressed" unterstützt -- bedeutet das, daß es mit<br>
   beliebigen Kurven kann? Wenn ja, kann ich mir mal ansehen, wie man<br>
   serverseitig auf die Wahl der Kurven Einfluß nehmen kann.<br>
2. "GCM -> SHA384 -> SHA256" ist das eine sinnvolle Sortierung?<br>
3. Ist Camellia256 gegenüber AES256 zu bevorzugen? Oder eher im Gegenteil?<br>
   Ivan Ristić ignoriert Camellia in seinem Beispiel ab Seite 29 im "OpenSSL<br>
   Cookbook" und ich versteh das nicht ganz.<br>
   Soweit ich bisher gesehen habe gibt es Side-Channel Attacken auf AES<br>
   durch Lookup Tables sofern man nicht die AES-NI Extension in der CPU<br>
   nutzt. Wie steht es da mit Camellia?<br>
<br>
Glg Adi<br>
<br>
PS: Auf einem Debian Wheezy kann der Apache nur DHE und nichts mit<br>
elliptischen Kurven; das kann nur der nginx. Der Grund dafür ist, daß auf<br>
Debian immer noch Apache 2.2 verwendet wird und Apache (mit mod_ssl) erst<br>
ab Version 2.4 elliptische Kurven auch zu können scheint.<br>
<br>
PPS: Das ist auf einem Standard Debian die Liste der elliptischen Kurven,<br>
die OpenSSL kennt:<br>
openssl ecparam -list_curves<br>
  secp112r1 : SECG/WTLS curve over a 112 bit prime field<br>
  secp112r2 : SECG curve over a 112 bit prime field<br>
  secp128r1 : SECG curve over a 128 bit prime field<br>
  secp128r2 : SECG curve over a 128 bit prime field<br>
  secp160k1 : SECG curve over a 160 bit prime field<br>
  secp160r1 : SECG curve over a 160 bit prime field<br>
  secp160r2 : SECG/WTLS curve over a 160 bit prime field<br>
  secp192k1 : SECG curve over a 192 bit prime field<br>
  secp224k1 : SECG curve over a 224 bit prime field<br>
  secp224r1 : NIST/SECG curve over a 224 bit prime field<br>
  secp256k1 : SECG curve over a 256 bit prime field<br>
  secp384r1 : NIST/SECG curve over a 384 bit prime field<br>
  secp521r1 : NIST/SECG curve over a 521 bit prime field<br>
  prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field<br>
  prime192v2: X9.62 curve over a 192 bit prime field<br>
  prime192v3: X9.62 curve over a 192 bit prime field<br>
  prime239v1: X9.62 curve over a 239 bit prime field<br>
  prime239v2: X9.62 curve over a 239 bit prime field<br>
  prime239v3: X9.62 curve over a 239 bit prime field<br>
  prime256v1: X9.62/SECG curve over a 256 bit prime field<br>
  sect113r1 : SECG curve over a 113 bit binary field<br>
  sect113r2 : SECG curve over a 113 bit binary field<br>
  sect131r1 : SECG/WTLS curve over a 131 bit binary field<br>
  sect131r2 : SECG curve over a 131 bit binary field<br>
  sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field<br>
  sect163r1 : SECG curve over a 163 bit binary field<br>
  sect163r2 : NIST/SECG curve over a 163 bit binary field<br>
  sect193r1 : SECG curve over a 193 bit binary field<br>
  sect193r2 : SECG curve over a 193 bit binary field<br>
  sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field<br>
  sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field<br>
  sect239k1 : SECG curve over a 239 bit binary field<br>
  sect283k1 : NIST/SECG curve over a 283 bit binary field<br>
  sect283r1 : NIST/SECG curve over a 283 bit binary field<br>
  sect409k1 : NIST/SECG curve over a 409 bit binary field<br>
  sect409r1 : NIST/SECG curve over a 409 bit binary field<br>
  sect571k1 : NIST/SECG curve over a 571 bit binary field<br>
  sect571r1 : NIST/SECG curve over a 571 bit binary field<br>
  c2pnb163v1: X9.62 curve over a 163 bit binary field<br>
  c2pnb163v2: X9.62 curve over a 163 bit binary field<br>
  c2pnb163v3: X9.62 curve over a 163 bit binary field<br>
  c2pnb176v1: X9.62 curve over a 176 bit binary field<br>
  c2tnb191v1: X9.62 curve over a 191 bit binary field<br>
  c2tnb191v2: X9.62 curve over a 191 bit binary field<br>
  c2tnb191v3: X9.62 curve over a 191 bit binary field<br>
  c2pnb208w1: X9.62 curve over a 208 bit binary field<br>
  c2tnb239v1: X9.62 curve over a 239 bit binary field<br>
  c2tnb239v2: X9.62 curve over a 239 bit binary field<br>
  c2tnb239v3: X9.62 curve over a 239 bit binary field<br>
  c2pnb272w1: X9.62 curve over a 272 bit binary field<br>
  c2pnb304w1: X9.62 curve over a 304 bit binary field<br>
  c2tnb359v1: X9.62 curve over a 359 bit binary field<br>
  c2pnb368w1: X9.62 curve over a 368 bit binary field<br>
  c2tnb431r1: X9.62 curve over a 431 bit binary field<br>
  wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field<br>
  wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field<br>
  wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field<br>
  wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field<br>
  wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field<br>
  wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field<br>
  wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field<br>
  wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field<br>
  wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field<br>
  wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field<br>
  wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field<br>
  Oakley-EC2N-3:<br>
        IPSec/IKE/Oakley curve #3 over a 155 bit binary field.<br>
        Not suitable for ECDSA.<br>
        Questionable extension field!<br>
  Oakley-EC2N-4:<br>
        IPSec/IKE/Oakley curve #4 over a 185 bit binary field.<br>
        Not suitable for ECDSA.<br>
        Questionable extension field!<br>
<br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.6 (GNU/Linux)<br>
<br>
iQIVAwUBUmVNW3REfA6phVy/AQKUVg//bm/99MwgYKoU4NmjIagOeWzvYGyfvM4S<br>
6YCJBb9LONMxn5Eyz9Dz3HnncR7GKh3R/R1IUlvk16qEnZIbIEEQbU/CfJ35ViLa<br>
kCVuanfDNpHhKvyt/RnXICF/4THH56Ce7g0olpmBFw8EmJxvn0qNunoWQkIAwWmI<br>
RnGkn8pGCROXl9rUsiY51Cbe9p5OFTGMQwcBvCEjAycmHnIlxUdYlF+cDzdWD3FV<br>
84JkkohhJARkkEWK/xqmbDMr5YihvdsS4+TLiVmiIykXcl5r7eQblTgYnBTTc7FQ<br>
fzaKH/vsYtnTbTTq/xD1K28PAB8Arz0CN2m35CD64Pevm/E/oWrLRG41/ILBNYp+<br>
13IdRfXlh91z/LHVqrZk/m6wtgQBlvFmYzcmyNKdmNcjlubfSLLEdNVUB/hChMgm<br>
zoTRrBdOElwdNHCorJSAcXo6/hK9XN07xQEQC+Ewmv/8KvufCYTYVgRnNhJlKCN1<br>
YoQGNMVlfFMUoxu4A25nxHyhrH/mzkSGMp1h9Qz7pFyA9EW61Ab3/vTcmoA+7ur1<br>
nFTIWkVn2buMfwnAcwxrgVlpe++sLKQBYBw/HygHCXlhh9SYs+3jc50IhXEyeE+c<br>
fTVmdhoESx5p+IyAZbHlY8ZPrbYlTl9XzTtoDBVKt1IEzx8mg+6h14QklPMVbE1Y<br>
nt8LaS0BkMM=<br>
=nx0P<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
Ach mailing list<br>
<a href="mailto:Ach@lists.cert.at">Ach@lists.cert.at</a><br>
<a href="http://lists.cert.at/cgi-bin/mailman/listinfo/ach" target="_blank">http://lists.cert.at/cgi-bin/mailman/listinfo/ach</a><br>
<br></blockquote></div><br></div>