![[HaBo]](/styles/default/logoklein.png){kind=small}
Elderan
0
@zzador:
Ah okay, dann habe ich es nun verstanden. Dann wäre es sinnvoll dies nicht asymmetrische Verschlüsselung zu nennen, da dies nahe legt dass man das Schlüsselpaar einmalig geniert und dann fortlaufend nutzt (wie bei z.B. RSA).
Stattdessen beschreibst du ein Key-Exchange- bzw. Key-Establishment-Protokoll.
Das extreme Problem bei deinem Protokoll ist, das es meiner Meinung nach keine leichte Möglichkeit gibt, einen MITM Angriff zu verhindern bzw. die von Alice and Bob geschickten öffentlichen Schlüssel zu signieren, da sich dieser stets ändert.
Protokolle die nicht gegen MITM-Angriffe resistent sind, finden in der Praxis fast keine Anwendung. Auch das Diffie-Hellman Protkoll wird nur in einer Fassung verwendet, die es erlaubt einen MITM-Angriff auszuschließen. Und zwar indem Alice nicht jedes mal ein neues a wählt und g^a mod p rechnet, sondern einmalig g^a mod p berechnet, das Ergebnis sich von jemand fremdes signieren lässt und es dann zukünftig stets das gleiche, signierte Ergebnis an Bob sendet.
Da wie erwähnt ich nicht aktuell sehen kann wie man dein Verfahren gegen einen MITM Angriff absichern kann ohne den öffentlichen Schlüssel für Alice zu fixieren, sähe ich auch kein Einsatzgebiet für die Praxis.
Aber für jeden neu generierten Schlüssel braucht man eine neue Signatur für den Schlüssel von einer externen Partei (einer CA). Dies macht es extrem ineffizient für jede neue Sitzung einen neuen Schlüssel zu generieren.
In der sicheren Kommunikation heutzutage läuft nichts mehr ohne Zertifikate ab. Unternehmen geben dafür Unsummen aus und beschäftigen eigene Abteilungen, nur um die Zertifikatsinfrastruktur zu managen.
Der Ablauf ist wie folgt:
Der Server erzeugt ein RSA-Schlüsselpaar (oder was auch immer man nutzen möchte) und sendet den öffentlichen Schlüssel per sicheren Kanal an eine Certificate Authority (CA) wie z.B. VeriSign. Diese CA signiert dann den öffentlichen RSA-Schlüssel und bestätigt damit, dass der RSA-Schlüssel zu einem bestimmten Server gehört, z.B. von einer Bank.
Der Server sendet dann später an seine Clients das Zertifikat, bestehend aus dem eigenen öffentlichen Schlüssel, der eigenen Identität (Bank XYZ) und der Unterschrift der CA.
Der Client hat zumeist vorab die entsprechenden Zertifikate der CAs installiert (wird bei Windows, Linux, MacOS direkt bei der Installation mit ausgeliefert) und kann so überprüfen, ob die CA wirklich die Identität des Servers überprüft hat und ob der öffentliche Schlüssel zum Server gehört.
Die Schlüssel werden so selten gewechselt (für gewöhnlich alle 1 bis 2 Jahre), da die Identitätsfeststellung durch die CA recht aufwendig und auch recht teuer ist. Wie gesagt, große Unternehmen beschäftigen eigene Abteilungen die sich nur um bald auslaufende Zertifikate kümmern und dass diese rechtzeitig erneuert werden.
---------------------
Zwar ist die Grundidee sehr nett, für die Praxis aber leider nicht wirklich zu gebrauchen. Wie bereits oft erwähnt, lassen sich MITM Angriffe nicht ausschließen. Aber selbst wenn man das gar nicht fordert, ist das große Problem die großen Datenmengen.
Die beiden Matrizen (256x1024 Bits) haben eine Größe von zusammen 64KB. Da wie erwähnt die Datenübertragung der langsamste Schritt ist, hätte die CPU schon längst die Operationen für Diffie-Hellman berechnet während man bei deinem Verfahren noch bei der Übertragung der Daten ist.
Weitere Probleme wäre, dass sich die Entschlüsselung nicht effizient auf aktuellen CPUs realisieren lässt, da man nur umständlich die Parität berechnen kann. Die Erweiterungs des Instruction Sets der CPU wäre also von nöten. Bis aber CPU-Hersteller kryptographische Funktionen in ihre CPUs verdrahten, vergeht Jahre bis Jahrzehnte.
Ebenso muss man jedes mal neu mehr als 64KB an zufälligen Daten erzeugen (die Matrizen+Subsets), und zwar auf eine sichere Art und Weise. Da ist dann die Frage, ob man die Erzeugung der 64KB Zufallsdaten schneller hinbekommt als z.B. die Entschlüsselung bei RSA bzw. die Berechnungen bei Diffie-Hellman.
Nutzt man Skein-512 zur Erzeugung von kryptographisch sicheren Zufallsdaten (einer der schnellsten kryptographisch sicheren Zufallsgeneratoren), so muss man ca. 7 Cylces/Byte an Rechenzeit aufwenden. Bei 64Kb wären dies bereits ca. 470 000 CPU-Cycles, nur zur Erzeugung der beiden Martizen notwendig sind.
Ein vollständiger Key-Exchange mittels elliptischen Kurven und Diffie-Hellman braucht laut eBATs nur ca. 200 000 bis 250 000 CPU-Cycles.
Auch wenn die involvierten Operationen sehr simpel sind, braucht die zufällige Erzeugung der Matrizen unglaublich viel Zeit, was sich auch nicht wirklich reduzieren lässt.
Ah okay, dann habe ich es nun verstanden. Dann wäre es sinnvoll dies nicht asymmetrische Verschlüsselung zu nennen, da dies nahe legt dass man das Schlüsselpaar einmalig geniert und dann fortlaufend nutzt (wie bei z.B. RSA).
Stattdessen beschreibst du ein Key-Exchange- bzw. Key-Establishment-Protokoll.
Das extreme Problem bei deinem Protokoll ist, das es meiner Meinung nach keine leichte Möglichkeit gibt, einen MITM Angriff zu verhindern bzw. die von Alice and Bob geschickten öffentlichen Schlüssel zu signieren, da sich dieser stets ändert.
Protokolle die nicht gegen MITM-Angriffe resistent sind, finden in der Praxis fast keine Anwendung. Auch das Diffie-Hellman Protkoll wird nur in einer Fassung verwendet, die es erlaubt einen MITM-Angriff auszuschließen. Und zwar indem Alice nicht jedes mal ein neues a wählt und g^a mod p rechnet, sondern einmalig g^a mod p berechnet, das Ergebnis sich von jemand fremdes signieren lässt und es dann zukünftig stets das gleiche, signierte Ergebnis an Bob sendet.
Da wie erwähnt ich nicht aktuell sehen kann wie man dein Verfahren gegen einen MITM Angriff absichern kann ohne den öffentlichen Schlüssel für Alice zu fixieren, sähe ich auch kein Einsatzgebiet für die Praxis.
Das stimmt, aber das ist nicht die Begründung warum dieser so selten neu generiert wird.
Nicht wirklich. RSA & Co. sind nach dem aktuell stand weiterhin sicher, auch wenn man den selben Schlüssel über Jahre nutzt. Dies zeichnet auch ein gutes Verschlüsselungsverfahren aus, dass man den Key eben nicht ständig wechseln muss. Die große Gefahr ist, dass der private Schlüssel gestohlen wird. Deswegen sollte muss man einen Trade-Off finden wie oft man diesen wechselt im Vergleich zu den Kosten diesen neu signieren zu lassen.
Aber für jeden neu generierten Schlüssel braucht man eine neue Signatur für den Schlüssel von einer externen Partei (einer CA). Dies macht es extrem ineffizient für jede neue Sitzung einen neuen Schlüssel zu generieren.
In der sicheren Kommunikation heutzutage läuft nichts mehr ohne Zertifikate ab. Unternehmen geben dafür Unsummen aus und beschäftigen eigene Abteilungen, nur um die Zertifikatsinfrastruktur zu managen.
Der Ablauf ist wie folgt:
Der Server erzeugt ein RSA-Schlüsselpaar (oder was auch immer man nutzen möchte) und sendet den öffentlichen Schlüssel per sicheren Kanal an eine Certificate Authority (CA) wie z.B. VeriSign. Diese CA signiert dann den öffentlichen RSA-Schlüssel und bestätigt damit, dass der RSA-Schlüssel zu einem bestimmten Server gehört, z.B. von einer Bank.
Der Server sendet dann später an seine Clients das Zertifikat, bestehend aus dem eigenen öffentlichen Schlüssel, der eigenen Identität (Bank XYZ) und der Unterschrift der CA.
Der Client hat zumeist vorab die entsprechenden Zertifikate der CAs installiert (wird bei Windows, Linux, MacOS direkt bei der Installation mit ausgeliefert) und kann so überprüfen, ob die CA wirklich die Identität des Servers überprüft hat und ob der öffentliche Schlüssel zum Server gehört.
Die Schlüssel werden so selten gewechselt (für gewöhnlich alle 1 bis 2 Jahre), da die Identitätsfeststellung durch die CA recht aufwendig und auch recht teuer ist. Wie gesagt, große Unternehmen beschäftigen eigene Abteilungen die sich nur um bald auslaufende Zertifikate kümmern und dass diese rechtzeitig erneuert werden.
---------------------
Zwar ist die Grundidee sehr nett, für die Praxis aber leider nicht wirklich zu gebrauchen. Wie bereits oft erwähnt, lassen sich MITM Angriffe nicht ausschließen. Aber selbst wenn man das gar nicht fordert, ist das große Problem die großen Datenmengen.
Die beiden Matrizen (256x1024 Bits) haben eine Größe von zusammen 64KB. Da wie erwähnt die Datenübertragung der langsamste Schritt ist, hätte die CPU schon längst die Operationen für Diffie-Hellman berechnet während man bei deinem Verfahren noch bei der Übertragung der Daten ist.
Weitere Probleme wäre, dass sich die Entschlüsselung nicht effizient auf aktuellen CPUs realisieren lässt, da man nur umständlich die Parität berechnen kann. Die Erweiterungs des Instruction Sets der CPU wäre also von nöten. Bis aber CPU-Hersteller kryptographische Funktionen in ihre CPUs verdrahten, vergeht Jahre bis Jahrzehnte.
Ebenso muss man jedes mal neu mehr als 64KB an zufälligen Daten erzeugen (die Matrizen+Subsets), und zwar auf eine sichere Art und Weise. Da ist dann die Frage, ob man die Erzeugung der 64KB Zufallsdaten schneller hinbekommt als z.B. die Entschlüsselung bei RSA bzw. die Berechnungen bei Diffie-Hellman.
Nutzt man Skein-512 zur Erzeugung von kryptographisch sicheren Zufallsdaten (einer der schnellsten kryptographisch sicheren Zufallsgeneratoren), so muss man ca. 7 Cylces/Byte an Rechenzeit aufwenden. Bei 64Kb wären dies bereits ca. 470 000 CPU-Cycles, nur zur Erzeugung der beiden Martizen notwendig sind.
Ein vollständiger Key-Exchange mittels elliptischen Kurven und Diffie-Hellman braucht laut eBATs nur ca. 200 000 bis 250 000 CPU-Cycles.
Auch wenn die involvierten Operationen sehr simpel sind, braucht die zufällige Erzeugung der Matrizen unglaublich viel Zeit, was sich auch nicht wirklich reduzieren lässt.
. Die Hauptintention meines Verfahrens ist wie bereits erwähnt die realisierung direkt in Hardware um z.B. 2 Chips auf einer Platine sicher miteinander kommunizieren zu lassen. Das Beispiel mit dem Server, habe ich lediglich als Vergleich zu RSA herangezogen. Wie bereits erwähnt hat asymmetrische Verschlüsselung nur bedingt etwas mit Zertifikaten zu tun. Zertifikate gehören in die Sparte "Digitale Signatur" und das ist etwas anderes, als asymmetrische Verschlüsselung, auch wenn RSA als Paradebeispiel hierfür genutzt werden kann. Eine nackte asymmetrische Verschlüsselung muss lediglich über eine abgehörte Datenleitung sicheren Datensaustausch ermöglichen. Verfahren zum Vermeiden eines MITM wurde erst später entwickelt (Digitale Signatur) und setzten IMHO praktisch nur auf der asym. Verschlüsselung auf. Was Deinen (Elderan) Einwand der Paritätsprüfung auf heutigen CPUs angeht bzgl. der fehlenden Instruktionen...also ich teste meine Paritäten im Beispiel per XOR und XOR ist verdammt schnell auf meiner CPU. Mir ging es bei diesem Thread hauptsächlich darum mögliche Schwächen am Verfahren selbst aufzudecken und nicht, ob es dies und das nicht beherrscht. Daher möchte ich hier besonders Elderan nochmal danken, der sich die Mühe gemacht hat einen Ciphertext-Angriff zu entwickeln für den Fall, dass ein öffentlicher Schlüssel für mehrere Sitzungen verwendet wird. Auch Danke an alle die sich einfach mal so mit dem Verfahren beschäftigt haben, auch wenn sie vll. nicht die Zeit oder die Lust hatten eine echte Schwachstelle zu suchen.
