[Ach] Review

Fri Nov 15 04:01:19 CET 2013

Wow. A lot of useful stuff in here! Thank you very much! BTW: this list is in english (since there are a lot of non-german speaking people on it)

On 14 Nov 2013, at 23:48, Philipp Gühring <pg at futureware.at> wrote:

> 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

ACK.

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

not sure about SRP and NTRU (can anyone supply proper information and practical knowledge on those?) - looks fine to me besides that.

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

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

Could you go into detail about that assumption? I’d be very much interested in that.

> 
> 
> 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?
GCM basically removes the need for an additional hash function to do message authentication. 

BTW: there is also GMAC - which basically just does authentication for symmetric block ciphers (http://tools.ietf.org/html/rfc4543)

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

That needs to be evaluated - IMHO the attack on RC4 is more general and problematic than BEAST which can be resolved if users update their browers (for example).

> 
> 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
> 
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131115/c4e89e8a/attachment.sig>