Asymetrisch Verschlüsseln

Übersicht

Sonstiges

Smalltalk

	ozzi789 Betreff: Asymetrisch Verschlüsseln	Di, Mai 06, 2008 21:04 Antworten mit Zitat
Hi Ich hab heut n Pc magazin gelsen, da stand eine kleine Info über verschlüsselungs Technicken und wie man sicher Dateien usw versendet. Das ganze geht so (beispiel anhanden einer Kiste) Ich nehme die Kiste und verschliesse sie mit einer Kette und einem Schloss , den Schlüssel habe abr nur ich. So sende ich sie zu dem Empfänger, welcher auch eine Kette und ein Schloss draufhaut, jedoch nur er hat den Schlüssel daraufhin sendet er sie mir wieder zurück. Ich öffne meine Kette und sende sie wieder zurück. Er kann sie nun öffnen, ohne das irgendwann jemand den Schlüssel in die Hände bekommen hätte. Nun ist meine Frage kann man so einen Chat relaisieren, der eigentlich nicht " abhörbar " ist ausser wen man Brute benutzt ? Thx oz
0x2B \|\| ! 0x2B C# \| C++13 \| Java 7 \| PHP 5

ozzi789

Betreff: Asymetrisch Verschlüsseln

Di, Mai 06, 2008 21:04
Antworten mit Zitat

Hi

Ich hab heut n Pc magazin gelsen, da stand eine kleine Info über verschlüsselungs Technicken und wie man sicher Dateien usw versendet.

Das ganze geht so (beispiel anhanden einer Kiste)

Ich nehme die Kiste und verschliesse sie mit einer Kette und einem Schloss , den Schlüssel habe abr nur ich.
So sende ich sie zu dem Empfänger, welcher auch eine Kette und ein Schloss draufhaut, jedoch nur er hat den Schlüssel daraufhin sendet er sie mir wieder zurück.
Ich öffne meine Kette und sende sie wieder zurück.
Er kann sie nun öffnen, ohne das irgendwann jemand den Schlüssel in die Hände bekommen hätte.

Nun ist meine Frage kann man so einen Chat relaisieren, der eigentlich nicht " abhörbar " ist ausser wen man Brute benutzt ?

Thx oz

0x2B || ! 0x2B
C# | C++13 | Java 7 | PHP 5

	nils2771989	Di, Mai 06, 2008 21:18 Antworten mit Zitat
Also theoretisch müsste das gehen, man sollte glaub ich bei dem Ver-, und Entschlüsselungsverfahren darauf achten, dass sich der Key nicht mit hilfe des Inhaltes verändert wird(also z.b. der Wert des vorhergegangenden Byte zu dem Schlüssel addiert oder so), dann könnte das Ergebnis falsch sein... Ansonsten müsste das gehen, ist aber dann doch recht aufwändig, da man für das senden einer einzigen Nachricht ja 2 mal Schicken, 1 mal Empfangen und dann noch Ver-, und Entschlüsseln muss... Mfg Nils
Schummle nicht, aber spiele nach eigenen Regeln. Sei nicht verrückt, sondern einfach nur wahnsinnig. Sei nicht böse, führ nur nichts Gutes im Schilde. Verändere dich nicht, bleib immer anders.

nils2771989

Di, Mai 06, 2008 21:18
Antworten mit Zitat

Also theoretisch müsste das gehen, man sollte glaub ich bei dem Ver-, und Entschlüsselungsverfahren darauf achten, dass sich der Key nicht mit hilfe des Inhaltes verändert wird(also z.b. der Wert des vorhergegangenden Byte zu dem Schlüssel addiert oder so), dann könnte das Ergebnis falsch sein...

Ansonsten müsste das gehen, ist aber dann doch recht aufwändig, da man für das senden einer einzigen Nachricht ja 2 mal Schicken, 1 mal Empfangen und dann noch Ver-, und Entschlüsseln muss...

Mfg

Nils

Schummle nicht, aber spiele nach eigenen Regeln.
Sei nicht verrückt, sondern einfach nur wahnsinnig.
Sei nicht böse, führ nur nichts Gutes im Schilde.
Verändere dich nicht, bleib immer anders.

	StepTiger	Di, Mai 06, 2008 22:09 Antworten mit Zitat
Insgesamt 3 mal schicken und 3 mal empfangen Und das ist ein recht hoher Rechenaufwand, besonders bei größeren Dateien (1MB wird dann schon zu 3 MB reinster Datenstrom) Als Server 2 mal 1MB schicken, 1 mal 1MB empfangen, als Empfänger 1 mal 1 MB schicken, 2 mal 1MB empfangen. Also als Chat wäre das noch gut möglich. Aber durch bestimmte Muster (Vergleich von Datei 1, Datei 2 und Datei 3) könnte man die Schlüssel herausfinden. Ist also wahrscheinlich gar nicht so sicher, wie es scheint. Außerdem ist ein Algorithmus ja nur dann wirklich sicher, wenn er allen bekannt und trotzdem unknackbar ist. Bei diesem Prinzip wäre das nicht der Fall.
Noch gestern standen wir am Abgrund, doch heute sind wir schon einen Schritt weiter. Computer: AMD Sempron 3000+; ATI Radeon 9800 Pro; 512 MB DDR RAM 400Mhz; Asus E7N8X-E Deluxe; Samsung 200GB HD 5.4ns acces t Gewinner: BP Code Compo #2 Π=3.141592653589793238...<--- und das aus dem kopf Seit der Earthlings-Diskussion überzeugter Fleisch(fr)esser.

StepTiger

Di, Mai 06, 2008 22:09
Antworten mit Zitat

Insgesamt 3 mal schicken und 3 mal empfangen Wink

Und das ist ein recht hoher Rechenaufwand, besonders bei größeren Dateien (1MB wird dann schon zu 3 MB reinster Datenstrom)

Als Server 2 mal 1MB schicken, 1 mal 1MB empfangen, als Empfänger 1 mal 1 MB schicken, 2 mal 1MB empfangen.

Also als Chat wäre das noch gut möglich. Aber durch bestimmte Muster (Vergleich von Datei 1, Datei 2 und Datei 3) könnte man die Schlüssel herausfinden. Ist also wahrscheinlich gar nicht so sicher, wie es scheint.

Außerdem ist ein Algorithmus ja nur dann wirklich sicher, wenn er allen bekannt und trotzdem unknackbar ist. Bei diesem Prinzip wäre das nicht der Fall.

Noch gestern standen wir am Abgrund, doch heute sind wir schon einen Schritt weiter.
Computer:
AMD Sempron 3000+; ATI Radeon 9800 Pro; 512 MB DDR RAM 400Mhz; Asus E7N8X-E Deluxe; Samsung 200GB HD 5.4ns acces t
Gewinner: BP Code Compo #2
Π=3.141592653589793238...<--- und das aus dem kopf Laughing

Seit der Earthlings-Diskussion überzeugter Fleisch(fr)esser.

	Eingeproggt	Di, Mai 06, 2008 22:29 Antworten mit Zitat
Klugscheiß So wie ich das verstanden habe, ist das was du beschrieben hast, ozzi, keine asymmetrische Verschlüsselung sondern ein sogenanntes "Kryptographisches Protokoll" Und der von StepTiger angesprochene Punkt mit der Sicherheit nennt sich Kerckhoff-Prinzip. mfG, Christoph.

Eingeproggt

Di, Mai 06, 2008 22:29
Antworten mit Zitat

*Klugscheiß*

So wie ich das verstanden habe, ist das was du beschrieben hast, ozzi, keine asymmetrische Verschlüsselung sondern ein sogenanntes "Kryptographisches Protokoll"

Und der von StepTiger angesprochene Punkt mit der Sicherheit nennt sich Kerckhoff-Prinzip.

mfG, Christoph.

	ChaosCoder	Di, Mai 06, 2008 22:52 Antworten mit Zitat
Ja da muss ich Eingeproggt zustimmen, das ist ja keine Verschlüsselung und somit weiß man noch überhaupt nichts über mögliche Wege der Verschlüsselung. Dein angesprochenes System ist in Bezug mit einem sehr langen Schlüssel und einer dementsprechen guten Verschlüsselung recht gut, was die Geheimhaltung der Schlüssel angeht (auch wenn sich durch das Kerckhoff-Prinzip Möglichkeiten herausbilden, diese Schlüssel herauszufinden, was aber wiederum bei geeigneten Verschlüsselungsalgorithmen sehr schwer sein wird, denn der, der die Daten mitliest, muss wohl oder übel durch Bruteforce rangehen und das ohne den originalen Text zu kennen: sehr schwer). Allerdings verdreifachen sich die übertragenen Daten und dadurch echt nur für Dinge zu benutzen die unlesbar für dritte über das internet geschickt werden oder für einen einfachen Chat. Allerdings fragt sich, wer das bei nem Chat braucht oder wer streng geheime Informationen über das Internet schickt.
Projekte: Geolaria \| aNemy Webseite: chaosspace.de

ChaosCoder

Di, Mai 06, 2008 22:52
Antworten mit Zitat

Ja da muss ich Eingeproggt zustimmen, das ist ja keine Verschlüsselung und somit weiß man noch überhaupt nichts über mögliche Wege der Verschlüsselung. Dein angesprochenes System ist in Bezug mit einem sehr langen Schlüssel und einer dementsprechen guten Verschlüsselung recht gut, was die Geheimhaltung der Schlüssel angeht (auch wenn sich durch das Kerckhoff-Prinzip Möglichkeiten herausbilden, diese Schlüssel herauszufinden, was aber wiederum bei geeigneten Verschlüsselungsalgorithmen sehr schwer sein wird, denn der, der die Daten mitliest, muss wohl oder übel durch Bruteforce rangehen und das ohne den originalen Text zu kennen: sehr schwer). Allerdings verdreifachen sich die übertragenen Daten und dadurch echt nur für Dinge zu benutzen die unlesbar für dritte über das internet geschickt werden oder für einen einfachen Chat. Allerdings fragt sich, wer das bei nem Chat braucht oder wer streng geheime Informationen über das Internet schickt.

Projekte: Geolaria | aNemy
Webseite: chaosspace.de

	StepTiger	Di, Mai 06, 2008 23:08 Antworten mit Zitat
Naja, würde sich zum Beispiel bei einem E-Mail Programm lohnen. Oder für einen firmeninternen Nachrichtendienst oder sowas. Aber realisierbar ist es recht einfach.
Noch gestern standen wir am Abgrund, doch heute sind wir schon einen Schritt weiter. Computer: AMD Sempron 3000+; ATI Radeon 9800 Pro; 512 MB DDR RAM 400Mhz; Asus E7N8X-E Deluxe; Samsung 200GB HD 5.4ns acces t Gewinner: BP Code Compo #2 Π=3.141592653589793238...<--- und das aus dem kopf Seit der Earthlings-Diskussion überzeugter Fleisch(fr)esser.

StepTiger

Di, Mai 06, 2008 23:08
Antworten mit Zitat

Naja, würde sich zum Beispiel bei einem E-Mail Programm lohnen. Oder für einen firmeninternen Nachrichtendienst oder sowas.

Aber realisierbar ist es recht einfach.

Seit der Earthlings-Diskussion überzeugter Fleisch(fr)esser.

	Smily	Mi, Mai 07, 2008 10:02 Antworten mit Zitat
Das genannte verfahren ist auf dem Ersten blick zwar ganz gut, allerdings unbrauchbar. Jemand der Mithört, würde die Gesendete Nachricht insgesammt in 3 verschiedenen Ausgaben erhalten: 1: Verschlüsselt mit Key1 2: Verschlüsselt mit Key1 + 2 3: Verschlüsselt mit Key2 Die Informieren reichen bei den meisten (oder allen, kA) chifriermethoden locker aus, um darraus beide keys zu ermitteln, womit ohne weiteres die Nachricht von einem 3. Wiederhergestellt werden kann cu, Smily0412
Lesestoff: gegen Softwarepatente \| Netzzensur \| brain.exe \| Unabhängigkeitserklärung des Internets "Wir müssen die Rechte der Andersdenkenden selbst dann beachten, wenn sie Idioten oder schädlich sind. Wir müssen aufpassen. Wachsamkeit ist der Preis der Freiheit --- Keine Zensur!" stummi.org

Smily

Mi, Mai 07, 2008 10:02
Antworten mit Zitat

Das genannte verfahren ist auf dem Ersten blick zwar ganz gut, allerdings unbrauchbar.

Jemand der Mithört, würde die Gesendete Nachricht insgesammt in 3 verschiedenen Ausgaben erhalten:

1: Verschlüsselt mit Key1
2: Verschlüsselt mit Key1 + 2
3: Verschlüsselt mit Key2

Die Informieren reichen bei den meisten (oder allen, kA) chifriermethoden locker aus, um darraus beide keys zu ermitteln, womit ohne weiteres die Nachricht von einem 3. Wiederhergestellt werden kann

cu,
Smily0412

Lesestoff:
gegen Softwarepatente | Netzzensur | brain.exe | Unabhängigkeitserklärung des Internets

"Wir müssen die Rechte der Andersdenkenden selbst dann beachten, wenn sie Idioten oder schädlich sind. Wir müssen aufpassen. Wachsamkeit ist der Preis der Freiheit --- Keine Zensur!"
stummi.org

	Cardonic	Mi, Mai 07, 2008 14:44 Antworten mit Zitat
Smily hat absolut recht. Ein solches Verfahren würde nur mit einer symmetrischen Verschlüsselung Sinn ergeben. Durch dreimaliges Abfangen der Nachricht ist es dann relativ einfach die beiden Schlüssel herauszufinden. (einer würde ja auch schon genügen.) Ein asymmetrisches* Verfahren ist immer ein sog. Public-Key-Verfahren (RSA wäre ein bekanntes Beispiel). Die Nachricht wird mit einem Schlüssel verschlüsselt und mit einem anderen Schlüssel entschlüsselt. Der Absender Verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers. So kann nur der empfänger die Nachricht entschlüsseln, da er seinen öffentlichen Schlüsselgeneriert hat. Jedem anderen ist es unmöglich oder nur mit sehr viel Aufwand möglich den Schlüssel zu berechnen. Da asymmetrische Verfahren meistens sehr viel rechenintensiver sind werden oft werden sog. Hybride verfahren verwendet. (symmetrische und asymmetrische in Kombination). Der Schlüssel wird mit einem asymmetrischen Verfaheren übermittelt und die Nachricht wird dann mit einem symmetrischen Verfahren verschlüsselt. (z.b. DES oder AES). *Danke für die Korrektur Smily
If you should go skating on the thin ice of modern life, dragging behind you the silent reproach of a million tear-stained eyes, don't be surprised when a crack in the ice appears under your feet.

Cardonic

Mi, Mai 07, 2008 14:44
Antworten mit Zitat

Smily hat absolut recht.
Ein solches Verfahren würde nur mit einer symmetrischen Verschlüsselung Sinn ergeben.
Durch dreimaliges Abfangen der Nachricht ist es dann relativ einfach die beiden Schlüssel herauszufinden. (einer würde ja auch schon genügen.)

Ein asymmetrisches* Verfahren ist immer ein sog. Public-Key-Verfahren (RSA wäre ein bekanntes Beispiel).
Die Nachricht wird mit einem Schlüssel verschlüsselt und mit einem anderen Schlüssel entschlüsselt.
Der Absender Verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers. So kann nur der empfänger die Nachricht entschlüsseln, da er seinen öffentlichen Schlüsselgeneriert hat. Jedem anderen ist es unmöglich oder nur mit sehr viel Aufwand möglich den Schlüssel zu berechnen.

Da asymmetrische Verfahren meistens sehr viel rechenintensiver sind werden oft werden sog. Hybride verfahren verwendet. (symmetrische und asymmetrische in Kombination).
Der Schlüssel wird mit einem asymmetrischen Verfaheren übermittelt und die Nachricht wird dann mit einem symmetrischen Verfahren verschlüsselt. (z.b. DES oder AES).

*Danke für die Korrektur Smily

If you should go skating on the thin ice of modern life, dragging behind you the silent reproach of a million tear-stained eyes, don't be surprised when a crack in the ice appears under your feet.

Zuletzt bearbeitet von Cardonic am Mi, Mai 07, 2008 16:09, insgesamt einmal bearbeitet

	Smily	Mi, Mai 07, 2008 14:58 Antworten mit Zitat
Zitat: Ein symmetrisches Verfahren ist immer ein sog. Public-Key-Verfahren (RSA wäre ein bekanntes Beispiel). Die Nachricht wird mit einem Schlüssel verschlüsselt und mit einem anderen Schlüssel entschlüsselt. Der Absender Verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers. So kann nur der empfänger die Nachricht entschlüsseln, da er seinen öffentlichen Schlüsselgeneriert hat. Jedem anderen ist es unmöglich oder nur mit sehr viel Aufwand möglich den Schlüssel zu berechnen. Vermutlich nur ein Vertipper, aber was du beschreibst ist nicht das symmetrische, sondern das asymetrische verfahren
Lesestoff: gegen Softwarepatente \| Netzzensur \| brain.exe \| Unabhängigkeitserklärung des Internets "Wir müssen die Rechte der Andersdenkenden selbst dann beachten, wenn sie Idioten oder schädlich sind. Wir müssen aufpassen. Wachsamkeit ist der Preis der Freiheit --- Keine Zensur!" stummi.org

Smily

Mi, Mai 07, 2008 14:58
Antworten mit Zitat

Zitat:

Ein symmetrisches Verfahren ist immer ein sog. Public-Key-Verfahren (RSA wäre ein bekanntes Beispiel).
Die Nachricht wird mit einem Schlüssel verschlüsselt und mit einem anderen Schlüssel entschlüsselt.
Der Absender Verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers. So kann nur der empfänger die Nachricht entschlüsseln, da er seinen öffentlichen Schlüsselgeneriert hat. Jedem anderen ist es unmöglich oder nur mit sehr viel Aufwand möglich den Schlüssel zu berechnen.

Vermutlich nur ein Vertipper, aber was du beschreibst ist nicht das symmetrische, sondern das asymetrische verfahren Wink

	D2006 Administrator	Mi, Mai 07, 2008 15:08 Antworten mit Zitat
Kennt mich nur ein wenig mit Verschlüsselung aus, aber gibt es denn ein Verfahren, dass das oben beschriebene Verhalten zulässt? Angenommen wir haben Text X, Schlüssel A und Schlüssel B. X mit A veschlüsselt sei X(A). X(A) mit B verschlüsselt, sei X(A,B). Normalerweise müsste man nun, um wieder an X zu gelangen, X(A,B) erst mit B entschlüsseln und dann mit A entschlüsseln. Gibt's denn Verfahren, die es zulassen, erst mit A und dann mit B zu entschlüsseln? Jetzt mal sicher Verfahren, dass "Modolu" funktioniert weiß ich.
Intel Core i5 2500 \| 16 GB DDR3 RAM dualchannel \| ATI Radeon HD6870 (1024 MB RAM) \| Windows 7 Home Premium Intel Core 2 Duo 2.4 GHz \| 2 GB DDR3 RAM dualchannel \| Nvidia GeForce 9400M (256 MB shared RAM) \| Mac OS X Snow Leopard Intel Pentium Dual-Core 2.4 GHz \| 3 GB DDR2 RAM dualchannel \| ATI Radeon HD3850 (1024 MB RAM) \| Windows 7 Home Premium Chaos Interactive :: GoBang :: BB-Poker :: ChaosBreaker :: Hexagon :: ChaosRacer 2

D2006

Administrator

Mi, Mai 07, 2008 15:08
Antworten mit Zitat

Kennt mich nur ein wenig mit Verschlüsselung aus, aber gibt es denn ein Verfahren, dass das oben beschriebene Verhalten zulässt?

Angenommen wir haben Text X, Schlüssel A und Schlüssel B.

X mit A veschlüsselt sei X(A).
X(A) mit B verschlüsselt, sei X(A,B).

Normalerweise müsste man nun, um wieder an X zu gelangen, X(A,B) erst mit B entschlüsseln und dann mit A entschlüsseln. Gibt's denn Verfahren, die es zulassen, erst mit A und dann mit B zu entschlüsseln? Jetzt mal sicher Verfahren, dass "Modolu" funktioniert weiß ich.

	ozzi789	Mi, Mai 07, 2008 15:16 Antworten mit Zitat
Hmm.. thx für die Antworten, doch ich hab keinen blassen wie ich verschlüsseln soll. ausser Cäsars system, aber das ist zuwenig sicher ... Naja ich werd mal ein bissl rumraten
0x2B \|\| ! 0x2B C# \| C++13 \| Java 7 \| PHP 5

ozzi789

Mi, Mai 07, 2008 15:16
Antworten mit Zitat

Hmm.. thx für die Antworten, doch ich hab keinen blassen wie ich verschlüsseln soll.
ausser Cäsars system, aber das ist zuwenig sicher ...

Naja ich werd mal ein bissl rumraten Smile

0x2B || ! 0x2B
C# | C++13 | Java 7 | PHP 5

	F	Mi, Mai 07, 2008 15:32 Antworten mit Zitat
Bsp1 : Du benutzt einen String um den Asciiwert der einzelnen Buchstaben zu den Bytes einer Datei zu Addieren. Natürlich im Loop. Bp2 : Du frägst den Benutzer nach einem Passwort(Integer) und benutzt diesen mit Seedrnd als Zufallswertanfang. Dann ließt du eine Bestimmte anzahl an Bytes ein und Tauscht ihre Positionen mit Rand(1-Anzahl) (Natürlich musst du verhindert das du zwei geleiche Positionen rauskrigst) und Schreibst sie dann wieder in eine Neue Datei. Natürlich auch im Loop. Halt nur Beispiele aber Kombinierbar
Signatur? Noch nie Gehört...

F

Mi, Mai 07, 2008 15:32
Antworten mit Zitat

Bsp1 : Du benutzt einen String um den Asciiwert der einzelnen Buchstaben zu den Bytes einer Datei zu Addieren. Natürlich im Loop.

Bp2 : Du frägst den Benutzer nach einem Passwort(Integer) und benutzt diesen mit Seedrnd als Zufallswertanfang. Dann ließt du eine Bestimmte anzahl an Bytes ein und Tauscht ihre Positionen mit Rand(1-Anzahl) (Natürlich musst du verhindert das du zwei geleiche Positionen rauskrigst) und Schreibst sie dann wieder in eine Neue Datei. Natürlich auch im Loop.

Halt nur Beispiele aber Kombinierbar

Signatur? Noch nie Gehört...

	Pdd	Mi, Mai 07, 2008 15:44 Antworten mit Zitat
Ich habe mich selbst durch Zufall seit einiger Zeit damit beschäftigt. Du solltest bei einer Verschlüsselung zwischen 2 Typen unterscheiden. Zum einen gibt es Blockchiffres (richtig geschrieben?), die immer nur eine bestimmte Menge an Daten verschlüsseln (64Bit, 128Bit, etc.). Der Nachteil ist hierbei, dass man, sofern man keine Daten in passender Blockgröße hat, den Block mit Füllzeichen auffüllen muss. Irgendwie muss also die Information mitgeliefert werden, wie lang der Originaltext war, damit später die Füllzeichen wieder entfernt werden können. Bekannte System sind hier AES, DES, Rijndael (ist AES), TripleDES, etc. Bei Interesse einfach mal in Wikipedia eingeben. Der andere Typ sind sogenannte Streamchiffres, welche _keine_ feste Blöckgröße haben, d.h. sie verschlüsseln Byte für Byte. Für mich ist dies eindeutig der einfachere Weg, weshalb ich in meinem Programm (wie erwähnt) ein solches Verfahren verwendet habe. Beispielhafte Verschlüsselungen sind RC4 oder SEAL. Zu beachten ist hier, dass RC4 nichts mit RC6 oder RC5 zu tun hat (das sind nämlich Blockchiffres. Es gilt also nicht: Je höher die Zahl, desto sicherer ). Alle diese Verfahren nutzen den vorhergegangenen Block (bzw das Byte), um das/den nächste(n) zu verschlüsseln. So ist es unmöglich, den Originalzustand der Daten wieder herzustellen, wenn der Anfang nicht mitgeschnitten wurde. Trotz alledem kann mit genügend Zeit und geballter Rechenkraft jeder dieser Mechanismen durch BruteForce geknackt werden. Hier steht allerdings die Frage nach dem Sinn ganz vorne. Übrigens: Die meisten Verfahren arbeiten nicht nur mit einem Schlüssel (Key), sondern auch noch zusätzlich mit einem Initialisierungsvektor (IV), welcher ebenfalls zur Verschlüsselung benötigt wird. So werden also gleich 2(!) Keys benötigt, um den Klartext wieder herzustellen. Der IV kann dabei öffentlich sein (im Programm fest gespeichert), oder aber irgendwie ausgetauscht werden. So erhält man praktisch die doppelte Sicherheit.
Lieber Apfel als Birne.

Pdd

Mi, Mai 07, 2008 15:44
Antworten mit Zitat

Ich habe mich selbst durch Zufall seit einiger Zeit damit beschäftigt. Du solltest bei einer Verschlüsselung zwischen 2 Typen unterscheiden.
Zum einen gibt es Blockchiffres (richtig geschrieben?), die immer nur eine bestimmte Menge an Daten verschlüsseln (64Bit, 128Bit, etc.). Der Nachteil ist hierbei, dass man, sofern man keine Daten in passender Blockgröße hat, den Block mit Füllzeichen auffüllen muss. Irgendwie muss also die Information mitgeliefert werden, wie lang der Originaltext war, damit später die Füllzeichen wieder entfernt werden können. Bekannte System sind hier AES, DES, Rijndael (ist AES), TripleDES, etc. Bei Interesse einfach mal in Wikipedia eingeben.

Der andere Typ sind sogenannte Streamchiffres, welche _keine_ feste Blöckgröße haben, d.h. sie verschlüsseln Byte für Byte. Für mich ist dies eindeutig der einfachere Weg, weshalb ich in meinem Programm (wie erwähnt) ein solches Verfahren verwendet habe. Beispielhafte Verschlüsselungen sind RC4 oder SEAL. Zu beachten ist hier, dass RC4 nichts mit RC6 oder RC5 zu tun hat (das sind nämlich Blockchiffres. Es gilt also nicht: Je höher die Zahl, desto sicherer Wink

).

Alle diese Verfahren nutzen den vorhergegangenen Block (bzw das Byte), um das/den nächste(n) zu verschlüsseln. So ist es unmöglich, den Originalzustand der Daten wieder herzustellen, wenn der Anfang nicht mitgeschnitten wurde. Trotz alledem kann mit genügend Zeit und geballter Rechenkraft jeder dieser Mechanismen durch BruteForce geknackt werden. Hier steht allerdings die Frage nach dem Sinn ganz vorne.

Übrigens: Die meisten Verfahren arbeiten nicht nur mit einem Schlüssel (Key), sondern auch noch zusätzlich mit einem Initialisierungsvektor (IV), welcher ebenfalls zur Verschlüsselung benötigt wird. So werden also gleich 2(!) Keys benötigt, um den Klartext wieder herzustellen. Der IV kann dabei öffentlich sein (im Programm fest gespeichert), oder aber irgendwie ausgetauscht werden. So erhält man praktisch die doppelte Sicherheit.

Lieber Apfel als Birne.

	Marek	Do, Mai 08, 2008 16:48 Antworten mit Zitat
Was ist wenn man die Methoden des "Abhörers" gegen ihn verwendet? Also, es gibt 2 Personen A und B sowie 2 Schlussel Sa und Sb. A besitzt Sa; B besitzt Sb. A will die Datei D an B schicken und verschlusselt D mit Sa. D(Sa)->B so, jetzt verschlüsselt B die Datei mit Sb... D(Sa;Sb)->A Jetzt entfernt A den Schlüssel Sa von D und hat jetzt D(Sb) A kennt jetzt... Sa, Klartext und hat sowohl D(Sa;Sb) als auch D(Sb). Soweit hatten wir das ja schon. Jetzt kann A doch aber den Schlüssel Sb herausfinden! Mit Sb kann A jetzt "Müll" in die Datei einfügen... ergo Sb als Wert für Seedrnd benutzen und dann zu jedem Bye ein Rand addieren (natürlich modulato). D(Sb+Trash)->B B entfernt daraufhin den "Trash", da ja auch er Sb besitzt und entfernt zuletzt Sb... was herauskommt ist der Klartext von D. Ich habe keine Ahnung ob das so funktioniert... wenn wer ne Lücke sieht, bitte posten
Wer lesen kann ist klar im Vorteil...

Marek

Do, Mai 08, 2008 16:48
Antworten mit Zitat

Was ist wenn man die Methoden des "Abhörers" gegen ihn verwendet?
Also, es gibt 2 Personen A und B sowie 2 Schlussel Sa und Sb. A besitzt Sa; B besitzt Sb.
A will die Datei D an B schicken und verschlusselt D mit Sa.
D(Sa)->B
so, jetzt verschlüsselt B die Datei mit Sb...
D(Sa;Sb)->A
Jetzt entfernt A den Schlüssel Sa von D und hat jetzt D(Sb)
A kennt jetzt... Sa, Klartext und hat sowohl D(Sa;Sb) als auch D(Sb). Soweit hatten wir das ja schon. Jetzt kann A doch aber den Schlüssel Sb herausfinden!
Mit Sb kann A jetzt "Müll" in die Datei einfügen... ergo Sb als Wert für Seedrnd benutzen und dann zu jedem Bye ein Rand addieren (natürlich modulato).
D(Sb+Trash)->B
B entfernt daraufhin den "Trash", da ja auch er Sb besitzt und entfernt zuletzt Sb... was herauskommt ist der Klartext von D.

Ich habe keine Ahnung ob das so funktioniert... wenn wer ne Lücke sieht, bitte posten Very Happy

Wer lesen kann ist klar im Vorteil...

Übersicht

Sonstiges

Smalltalk

Nach Oben

BlitzBasic Portal

Asymetrisch Verschlüsseln

Betreff: Asymetrisch Verschlüsseln