[Ach] Review

[Philipp Gühring]

Hallo,

Hier mein Review vom gestern verteilten Papier:

Ich bin jetzt mal alle Ciphersuites durchgegangen, und habe folgende Liste
an Regeln aufgestellt, die ich für "Konfiguration A" für sinnvoll halte:

Cipher die bekanntermaßen unsicher sind:
-NULL
-MD5
-SHA
-EXPORT
-RC4
-DES
-DES40
-CBC
-DSS
-DSA
-FORTEZZA
-EXPORT1024
-GOST
-GOSTR341044
-GOSTR3411
-GOSTR341001
-FIPS
-IDEA
-DH
-DH_ANON
-3DES_EDE
-ECDH

Cipher, die ich für sicher halte:
+SHA256
+SHA384
+SHA512
+SHA3
+PSK
+CAMELLIA 
+AES_256
+SEED
+ARIA
+GCM
+SRP
+NTRU
+KRB5
+DHE

Cipher, die wahrscheinlich vorläufig noch sicher sind:
~AES_128
~RSA
~ECDSA
~ECDHE
~DHE


Zum Kapitel 4:
Ich bin zwar kein Spezialist für elliptische Kurven, aber ich glaube schon
seit längerer Zeit, 
dass sie nicht so wesentlich kürzere Bitlängen brauchen als RSA wie das
allgemein angenommen wird. 
Ich habe vor kurzem auch erste Hinweise darauf gefunden, die ich aber noch
verifizieren muß.
Ich würde daher empfehlen, Elliptische Kurven mit so langen Schlüsseln wie
irgendwie möglich einzusetzen (Soweit ich gesehen habe gibt es 512 Bits,
wenn dem so ist, würde ich >=512 Bit empfehlen.)


Zum Kapitel 6: Random Number Generators
Soweit ich das in Erinnerung habe kann man bei den meisten Plattformen als
Sysadmin nicht viel zum Random Number Generator konfigurieren.
Was man machen kann ist den Random Number Generator testen, ich biete
hierzu einen kostenlosen Service an:
http://www.cacert.at/random/


Zum Kapitel 7.1.1:
Mich wundert dass bei ECDHE-RSA-AES256-GCM-SHA384 als Hash dann AEAD steht. 
Nachdem SHA384 im Ciphersuite-Namen steht hätte ich mir erwartet, dass
SHA384 auch als Hash verwendet wird.
Die Message-Authentication hingegen wird durch GCM mit AEAD anstatt SHA384
gemacht, daher wäre als Überschrift vielleicht MAC anstelle von Hash
besser geeignet?

Ich würde (aufgrund meiner Befürchtungen zu den elliptischen Kurven)
folgende Reihenfolge vorschlagen:
0x009F
0x006B
0xC030 
0xC028
Ich bin mir aber nicht sicher, ob die elliptischen Kurven nicht vielleicht
sogar besser sind als ein 1024 Bit DHE...


7.1.2:
!PSK: Ok, das macht bei den meisten Servern keinen Sinn, ja.
!SRP: Da bin ich anderer Meinung, ich denke, dass SRP sehr wohl Sinn
machen müßte bei z.B. Webservern, und mir ist nicht bekannt, dass SRP
gefährdende Sicherheitslücken hätte.
!SEED: Was habt ihr gegen SEED? Mir sind keine praxisrelevanten
Schwachstellen bekannt.
!(AES|CAMELLIA)128: Soweit ich das verstanden habe hängt es vom Space-Time
Tradeoff ab, ob AES 128 sicherer oder unsicherer als AES256 ist. (also ob
der Angreifer mehr CPUs oder mehr Storage hat). Ich sehe daher keinen Sinn
darin, AES-128 zu deaktivieren.
Details gibt es hier:
https://financialcryptography.com/mt/archives/001180.html
Wie die Situation bei CAMELLIA ist, bin ich mir nicht ganz sicher, aber
ich habe auch da nichts davon gehört, dass CAMELLIA-128 als unsicher
anzusehen ist.



7.2.1:
Unter Prefer finde ich AES_256_CBC: War da nicht die BEAST Attacke,
wodurch wir CBC nicht mehr präferieren sollten?
Was spricht eigentlich gegen ARIA? (Ok, den hat wahrscheinlich noch
niemand implementiert ...)

8.1.1-3: Ich würde !SRP und !SEED zulassen

8.1.4:
Ich würde darauf tippen, dass viele Clients(vielleicht die Browser noch am
ehesten, aber viele andere eher nicht) nichts mit Elliptischen Kurven in
Serverzertifikaten anfangen können.

8.2.4:
Ich dachte, dass DH mit 1024 Bit schon fast zuwenig ist, warum generieren
wir hier 512 Bit DH Keys? Braucht der Postfix das unbedingt?

9.3:
CAcert provides a service to test the entropy of your random number
generator: http://www.cacert.at/random/

Bezüglich HaveGE: Ja, ich finde Havege auch eine sehr gute Idee.
Ich habe vor kurzem gehört, dass HAVEGE eine neue URL hat:
http://www.issihosts.com/haveged/


Eine ganze Menge an Rechtschreibfehlern kann ich noch anbieten:

4: descrete -> discrete (kommt mehrmals vor)
4: infeaseble -> infeasible
4: Descrete -> Discrete
4: computonally -> computationally
4: keylenghts -> keylengths (kommt auch mehrmals vor)
5: In general, for asymmetric cryptography,  -> In general, for RSA
cryptography, (Es gibt auch andere asymmetrische Algorithmen, hier ist
aber nur RSA gemeint.)
5: deprectated -> deprecated
7.1: throught -> throughout
7.2: Chosing -> Choosing
8.1.4: TLS 2.0 -> TLS 1.2
9.2: Keylenght -> Keylength

Schöne Grüße,
Philipp