Fragen? Antworten! Siehe auch: Alternativlos
Ich persönlich halte DSA in allen Ausprägungen inzwischen für eine NSA-Hintertür und rate von der Verwendung ab. Der Grund ist, dass DSA so ausgelegt ist, dass man einen Zufallswert nimmt pro Operation mit dem geheimen Schlüssel, und wenn man zweimal den gleichen verwendet, dann fällt auf der anderen Seite der geheime Schlüssel aus einer vergleichsweise einfachen arithmetischen Umformung heraus. Das ist offensichtlich völlig unakzeptabel. Wie DSA überhaupt jemals soweit kommen konnte, dass es ein internationaler Standard wurde, erläutert djb in seinem Blog.
Kommen wir zu GCM. GCM ist der Galois Counter Mode. TLS hat einen Geburtsfehler, der seit vielen Jahren bekannt ist, und uns in letzter Zeit vermehrt auf den Fuß fällt. Nehmen wir mal an, Alice schickt Bob eine verschlüsselte Nachricht. Dann will man nicht nur, dass die Nachricht nicht von jemandem auf dem Weg gelesen werden kann, sondern auch, dass sie nicht verändert werden kann. Deshalb machen Protokolle wie TLS immer zwei Schritte: Verschlüsseln und eine Integritätssicherstellung. Dafür verwendet man sogenannte Message Authentication Codes, oder MAC. Dafür verwendet man häufig eine kryptographische Hash-Funktion mit einem beiden Seiten bekannten Geheimnis, aber man kann sowas auch anders konstruieren.
So, wenn man verschlüsseln will, verschlüsselt man dann erst und macht dann den MAC? Oder macht man erst den MAC und dann verschlüsselt man? Das war lange Jahre nicht so klar, ob das eine oder das andere besser ist. TLS macht erst MAC und verschlüsselt dann. Das hat über die Jahre zu einem Haufen an Bugs und Problemen geführt, so dass heute klar ist, dass man das besser anders herum machen sollte. Die IETF-Arbeitsgruppe zu TLS weiß das seit vielen Jahren, aber (u.a. durch Sandsack- und Betoniertätigkeiten der NSA) konnte sie sich noch nicht durchringen, da was zu tun. Das ist eine Schande für alle Beteiligten und sollte zu einem fetten Arschtritt für die NSA-Abgesandten führen — tat es aber bisher nicht.
Warum erzähle ich das alles? Weil jemand auf die Idee kam, "aus Performance-Gründen" Verschlüsselung und Authentication in einem zu machen, und zwar mit einem Verfahren namens Galois Counter Mode. Ein Mode ist eine Art, wie man einen Block Cipher wie AES aufruft. Das heißt Block Cipher, weil es nicht auf einem Bytestrom arbeitet, sondern auf Blöcken von Daten. Wenn die Daten keinen ganzen Block füllen, muss man am Ende mit sogenanntem "Padding" auffüllen. Da gab es schon Stress in TLS. Man kann jeden Block mit dem selben Schlüssel verschlüsseln ("ECB"), aber das ist eine ganz schlechte Idee. Wikipedia hat eine schöne Visualisierung anhand eines Pinguin-Bildes. Welchen Modus man benutzt ist also wichtig. ECB ist offensichtlich doof, daher haben wir halt alle immer CBC genommen. Das flog uns dann mit BEAST um die Ohren.
Übrig blieben Cipher-Suites auf Basis von RC4 (von dem wir inzwischen wissen, dass die NSA es in Echtzeit entschlüsseln kann) und GCM.
Warum ich das jetzt hier alles ausführe: GCM ist auch Scheiße. Das Paper dazu kommt von Niels Ferguson. Es sei noch angemerkt, dass man GCM in Software schon mal gleich so gut wie gar nicht ohne Timing-Probleme implementieren kann. Intel hat in ihren neueren CPUs Hardware-Support für GCM eingebaut, damit geht das dann. Aber fühlt sich damit jemand wohl?
Was können wir denn jetzt überhaupt noch tun? Wir können entweder warten, bis die TLS Working Group mal ihren Arsch hochkriegt und den offensichtlich notwendigen Schritt geht. Es gibt da Bemühungen, aber das kann sich noch um Jahre handeln. Die Situation ist gänzlich unakzeptabel.
Bleibt die Einsicht, dass uns gerade nur djb-Krypto überhaupt noch realistisch retten kann. djb hat als Konkurrenz zu ECDSA ein Verfahren namens ed25519 gemacht, das könnte den public key Teil abdecken. ed25519 wird u.a. in der neuesten Version von openssh unterstützt. Und als Ersatz für AES mit irgendwelchen grottigen Modi könnte man ChaCha20 einbauen. Das ist in Chrome schon eingebaut, aber hat es m.W. in noch keine einzige öffentlich verfügbare TLS-Library geschafft. Es ist alles zum Heulen.
Ich habe ja jahrelang nicht verstanden, wieso djb nie versucht hat, TLS zu fixen. Ich glaube, so langsam kann ich es nachvollziehen.
Update: CBC ist nicht an sich unsicher, sondern wie TLS 1.0 es angewendet hat. Ein Upgrade auf TLS 1.2 galt damals noch als unrealistisch, inzwischen ist es weitgehend vollzogen.