4
Suche Webseite zum Cryptovergleich
Hallo erstmal,
im Zuge der weltpolitischen Entwicklung habe ich mir gedacht ich widme mich mal ein wenig der Konfiguration der von mir verwendeten Kryptografischen Systeme (OpenSSH, GnuPG, dm-crypt, HTTPS, etc.). Mein Gedanke war, bei allem die Sicherheitsstufe ein klein wenig anzuheben.
Glücklicherweise erlauben es ja fast alle Programme, dass man ihnen eine Liste an Algorithmen mitsamt Präferenz vorgibt.
Das Problem ist jedoch: Als Laie ist es ziemlich schwierig einzuschätzen, wie es mit der Sicherheit der einzelnen Algorithmen bestellt ist.
Also ich meine innerhalb eines Systems ist es ja schon so, dass längerer Schlüssel mehr Sicherheit bedeuted, aber wie stehen die Algorithmen zueinander?
Beispiel: OpenSSH bietet mir folgende Verschlüsselungsoptionen (defaulteinstellung):
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
Da stellt sich doch natürlich die Frage, wie sich zum Beispiel aes zu blowfish oder zu arcfour verhält, wenn es um die Sicherheit geht.
Lange Rede kurzer Sinn: Ich suche eine Webseite, die möglichst verständlich die verschiedenen Verfahren gegenüberstellt und vielleicht eine kleine Pro/Contra Gegenüberstellung präsentiert.
Das ganze sollte natürlich gut gepflegt, also aktuell sein, da es ja durchaus gelegentlich vorkommt, das Verfahren geknackt oder anderweitig kompromittiert werden, wie RC4 vor einer Weile.
im Zuge der weltpolitischen Entwicklung habe ich mir gedacht ich widme mich mal ein wenig der Konfiguration der von mir verwendeten Kryptografischen Systeme (OpenSSH, GnuPG, dm-crypt, HTTPS, etc.). Mein Gedanke war, bei allem die Sicherheitsstufe ein klein wenig anzuheben.
Glücklicherweise erlauben es ja fast alle Programme, dass man ihnen eine Liste an Algorithmen mitsamt Präferenz vorgibt.
Das Problem ist jedoch: Als Laie ist es ziemlich schwierig einzuschätzen, wie es mit der Sicherheit der einzelnen Algorithmen bestellt ist.
Also ich meine innerhalb eines Systems ist es ja schon so, dass längerer Schlüssel mehr Sicherheit bedeuted, aber wie stehen die Algorithmen zueinander?
Beispiel: OpenSSH bietet mir folgende Verschlüsselungsoptionen (defaulteinstellung):
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
Da stellt sich doch natürlich die Frage, wie sich zum Beispiel aes zu blowfish oder zu arcfour verhält, wenn es um die Sicherheit geht.
Lange Rede kurzer Sinn: Ich suche eine Webseite, die möglichst verständlich die verschiedenen Verfahren gegenüberstellt und vielleicht eine kleine Pro/Contra Gegenüberstellung präsentiert.
Das ganze sollte natürlich gut gepflegt, also aktuell sein, da es ja durchaus gelegentlich vorkommt, das Verfahren geknackt oder anderweitig kompromittiert werden, wie RC4 vor einer Weile.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 210588
Url: https://administrator.de/contentid/210588
Ausgedruckt am: 25.11.2024 um 13:11 Uhr
4 Kommentare
Neuester Kommentar
Hi!
nimm:
aes256-cbc
ansonsten:
kannst mal hier beginnen: http://www.truecrypt.org/docs/encryption-algorithms#Y0
blowfish at einen Nachfolger: twofish
RC4 - arcfour - frag mal Google
sonst ist Wikipedia sehr aufschlussreich.
es hängt aber nicht nur vom crypto ab, der muss auch richtig implementiert werden. Und wenn es einen Mechanismus gibt die gesamte Verschlüsslung zu umgehen ist's ganz egal (Trojaner, Backdoor ...).
aber AES ist extrem verbreitet, daher liegst du mit einem weniger verbreitetem Crypto wieder besser gegen die Staaten
außerdem, weil ein Angriff gegen ein Verfahren möglich ist, heißt das nicht, dass das Verfahren völlig unbrauchbar/unsicher ist.
nimm:
aes256-cbc
ansonsten:
kannst mal hier beginnen: http://www.truecrypt.org/docs/encryption-algorithms#Y0
blowfish at einen Nachfolger: twofish
RC4 - arcfour - frag mal Google
sonst ist Wikipedia sehr aufschlussreich.
es hängt aber nicht nur vom crypto ab, der muss auch richtig implementiert werden. Und wenn es einen Mechanismus gibt die gesamte Verschlüsslung zu umgehen ist's ganz egal (Trojaner, Backdoor ...).
aber AES ist extrem verbreitet, daher liegst du mit einem weniger verbreitetem Crypto wieder besser gegen die Staaten
außerdem, weil ein Angriff gegen ein Verfahren möglich ist, heißt das nicht, dass das Verfahren völlig unbrauchbar/unsicher ist.
Hallo,
ich bezweifle das es eine solche Seite geben kann. Die Relativitätstheorie läßt sich auch nicht in zwei Sätzen erklären. Kryptografische Systeme bestehen leider aus sehr vielen Komponenten die optimal aufeinander abgestimmt sein müssen und die ganze Kette ist nicht stärker als der schwächste Teil. Als allgemeine Hinweise folgendes:
- Nicht versuchen schlauer als der Mainstream zu sein. Je bekannter ein Verfahren desto mehr verstanden/getestet ist es in der Regel
- Als "Optimierung" alte Kompatibilitäts Verfahren (DES etc.) soweit wie möglich und nicht schon geschehen deaktivieren
- Aktuelle Software verwenden, OpenSSL liefert z.B. erst ab 1.0.1 TLS 1.2
Ansonsten solche Sachen verfolgen http://www.golem.de/news/ssl-tls-schwaechen-in-rc4-ausnutzbar-1303-9816 ... und die geeigneten Schlüsse daraus ziehen.
Gruß
Andi
ich bezweifle das es eine solche Seite geben kann. Die Relativitätstheorie läßt sich auch nicht in zwei Sätzen erklären. Kryptografische Systeme bestehen leider aus sehr vielen Komponenten die optimal aufeinander abgestimmt sein müssen und die ganze Kette ist nicht stärker als der schwächste Teil. Als allgemeine Hinweise folgendes:
- Nicht versuchen schlauer als der Mainstream zu sein. Je bekannter ein Verfahren desto mehr verstanden/getestet ist es in der Regel
- Als "Optimierung" alte Kompatibilitäts Verfahren (DES etc.) soweit wie möglich und nicht schon geschehen deaktivieren
- Aktuelle Software verwenden, OpenSSL liefert z.B. erst ab 1.0.1 TLS 1.2
Ansonsten solche Sachen verfolgen http://www.golem.de/news/ssl-tls-schwaechen-in-rc4-ausnutzbar-1303-9816 ... und die geeigneten Schlüsse daraus ziehen.
Gruß
Andi
Hi,
Ich will ja keine Seite, die die Verfahren im Detail erklärt.
Das leistet Wikipedia m. E. eigentlich schon gut genug.
Ich suche halt möglichst einfach gestaltete Vergleiche.
Also dass z.B. ein AES256 sicherer (und damit langsamer) ist, als ein AES128 ist ja noch ziemlich simpel, ebenso wie ein CAMELLIA256 sicherer und langsamer sein dürfte als ein CAMELLIA192.
Aber was mich halt interessiert ist, ob möglicherweise ein CAMELLIA128 mit nur 128 bit vielleicht in der Performanz einem AES256 ebenbürtig sein könnte oder umgekehrt.
(Diese Beispiele stammen jetzt aus GnuPG)
Aber das ist doch auch ein Zweischneidiges Schwert, oder?
Klar sind weniger populäre Verfahren von wesentlich weniger Fachpersonal auf mögliche Schwachstellen abgeklopft worden, aber gleichzeitig bedeutet dies doch auch, dass potenzielle Angreifer sich eher auf die populären Verfahren stürzen.
Das ist auch so ein Punkt. So wurde bei OpenSSH ja vor einer Weile defaultmäßig auf ECDSA für die Schlüssel umgestellt. Woher weiß man, ob das „die richtige“ Entscheidung war?
Das war ja der Grund, warum ich gesagt habe eine entsprechende Seite müsse zwingend aktuell sein. Ein kompromitiertes Verfahren nützt ja nicht mehr wirklich.
Zitat von @AndiEoh:
ich bezweifle das es eine solche Seite geben kann. Die Relativitätstheorie läßt sich auch nicht in zwei
Sätzen erklären.
ich bezweifle das es eine solche Seite geben kann. Die Relativitätstheorie läßt sich auch nicht in zwei
Sätzen erklären.
Ich will ja keine Seite, die die Verfahren im Detail erklärt.
Das leistet Wikipedia m. E. eigentlich schon gut genug.
Ich suche halt möglichst einfach gestaltete Vergleiche.
Also dass z.B. ein AES256 sicherer (und damit langsamer) ist, als ein AES128 ist ja noch ziemlich simpel, ebenso wie ein CAMELLIA256 sicherer und langsamer sein dürfte als ein CAMELLIA192.
Aber was mich halt interessiert ist, ob möglicherweise ein CAMELLIA128 mit nur 128 bit vielleicht in der Performanz einem AES256 ebenbürtig sein könnte oder umgekehrt.
(Diese Beispiele stammen jetzt aus GnuPG)
- Nicht versuchen schlauer als der Mainstream zu sein. Je bekannter ein Verfahren desto mehr verstanden/getestet ist es in der
Regel
Regel
Aber das ist doch auch ein Zweischneidiges Schwert, oder?
Klar sind weniger populäre Verfahren von wesentlich weniger Fachpersonal auf mögliche Schwachstellen abgeklopft worden, aber gleichzeitig bedeutet dies doch auch, dass potenzielle Angreifer sich eher auf die populären Verfahren stürzen.
- Aktuelle Software verwenden, OpenSSL liefert z.B. erst ab 1.0.1 TLS 1.2
Das ist auch so ein Punkt. So wurde bei OpenSSH ja vor einer Weile defaultmäßig auf ECDSA für die Schlüssel umgestellt. Woher weiß man, ob das „die richtige“ Entscheidung war?
Ansonsten solche Sachen verfolgen http://www.golem.de/news/ssl-tls-schwaechen-in-rc4-ausnutzbar-1303-9816 ... und die geeigneten
Schlüsse daraus ziehen.
Schlüsse daraus ziehen.
Das war ja der Grund, warum ich gesagt habe eine entsprechende Seite müsse zwingend aktuell sein. Ein kompromitiertes Verfahren nützt ja nicht mehr wirklich.
Hallo,
zu 1.) Das Problem beginnt damit das sich die Sicherheit eines Verfahrens eigentlich nicht beweisen läßt sondern nur das Gegenteil. Deshalb macht es kaum Sinn die Verfahren nach Sicherheit zu sortieren. Die Geschwindigkeit hingegen ist sehr stark von der verwendeten Software und Hardware abhängig d.h. ein echter Vergleich ist auch nicht wirklich möglich.
zu 2.) Ja, ist zweischneidig. Wenn eine Lücke im Mainstream gefunden wird freuen sich die ScriptKiddies, wenn kein Mainstream verwendet wird freuen sich die Angreifer mit Kapital/Fachwissen und Zeit weil die Wahrscheinlichkeit höher ist, das eine bisher unendeckte Lücke existiert.
zu 3.) Weiß man erstmal nicht, siehe 1. Allerdings werden in neueren Verfahren Sachen geändert die sich als problematisch herausgestellt haben. Z.B. gibt es TLS 1.2 neuen Verfahren zur Blockanordnung (GCM statt CBC) bei blockbasierten Verfahren welche einige Attacken wie BEAST verhindert.
http://www.isg.rhul.ac.uk/tls/
Lange Rede kurzer Sinn: Nach einiger Zeit weiß man welche Verfahren unsicher sind, aber nicht welche Sicher sein werden. Deshalb wird es schwierig sein eine aktuelle Zusammenfassung mit auch nur begrenzter Gültigkeit für die Zukunft zusammen zu tragen
zu 1.) Das Problem beginnt damit das sich die Sicherheit eines Verfahrens eigentlich nicht beweisen läßt sondern nur das Gegenteil. Deshalb macht es kaum Sinn die Verfahren nach Sicherheit zu sortieren. Die Geschwindigkeit hingegen ist sehr stark von der verwendeten Software und Hardware abhängig d.h. ein echter Vergleich ist auch nicht wirklich möglich.
zu 2.) Ja, ist zweischneidig. Wenn eine Lücke im Mainstream gefunden wird freuen sich die ScriptKiddies, wenn kein Mainstream verwendet wird freuen sich die Angreifer mit Kapital/Fachwissen und Zeit weil die Wahrscheinlichkeit höher ist, das eine bisher unendeckte Lücke existiert.
zu 3.) Weiß man erstmal nicht, siehe 1. Allerdings werden in neueren Verfahren Sachen geändert die sich als problematisch herausgestellt haben. Z.B. gibt es TLS 1.2 neuen Verfahren zur Blockanordnung (GCM statt CBC) bei blockbasierten Verfahren welche einige Attacken wie BEAST verhindert.
http://www.isg.rhul.ac.uk/tls/
Lange Rede kurzer Sinn: Nach einiger Zeit weiß man welche Verfahren unsicher sind, aber nicht welche Sicher sein werden. Deshalb wird es schwierig sein eine aktuelle Zusammenfassung mit auch nur begrenzter Gültigkeit für die Zukunft zusammen zu tragen
