Verschlüsselung

[Ganon]

Hi,

ich hab mal ein paar Fragen zum Thema Verschlüsselung! Ich kann mir das ganze irgendwie nicht erklären und desshalb brauche ich mal eure Hilfe!

1. Wie funktioniert das ganze eigendlich und was hat "bit" damit zu tun?

2. Warum dauert es eigendlich so lange bis man sowas "illegal" entschlüsselt hat?

Im vorraus schonmal Danke!

[aths]

Du müsstest schon konkreter werden, welchen Verschlüsselungsalgorithmus du meinst.

[Ganon]

Sorry, aber ich kenne mich damit nicht aus! Es geht mir auch nur ums Prinzip!
Also wenn z.B. einer von "128bit-Verschlüsselung" spricht, würde ich gerne wissen wie das so zustande kommt (Ver-/Entschlüsselung usw.)!

Falls es dort große Unterschiede geben sollte, dann nimm einfach irgendeines!

Hauptsache ist nachher das ich mir was darunter vorstellen kann!

[aths]

Originally posted by Ganon
Sorry, aber ich kenne mich damit nicht aus! Es geht mir auch nur ums Prinzip!
Also wenn z.B. einer von "128bit-Verschlüsselung" spricht, würde ich gerne wissen wie das so zustande kommt (Ver-/Entschlüsselung usw.)!

Falls es dort große Unterschiede geben sollte, dann nimm einfach irgendeines!

Hauptsache ist nachher das ich mir was darunter vorstellen kann!Die Unterschiede sind so groß, da kann man nicht einfach "irgendeins" nehmen.

[Ganon]

Hmpf,

naja OK!

PGP?

[loewe]

Ich weiß nicht so richtig was du suchst.

Hier sind wohl eher keine absoluten Profis was dieses Gebiet anbelangt, also biete ich dir mal zwei Links:

1. mehr aus der Richtung Schule

http://www.lehrer.uni-karlsruhe.de/~za382/mag/mag959697/mag1.htm

- leicht Verständlich an Hand von Aufgaben und Beispielen eine kleine Einführung

2. schon eher gehobens Niveau

http://www.uni-mainz.de/~pommeren/Kryptologie/

- sehr umfangreich auf hohem Niveau, sollte kaum Fragen offen lassen

[Demirug]

Das Prinzip der Verschlüsselung ist es Daten zu umzukodieren das ein dritter damit nichts mehr anfangen kann. Damit aber die berechtigte Person diese wieder lesen kann benötigt man auch eine Entschlüsselung.

Alle verfahren haben gemeinsam das sowohl der Sender der Nachricht wie auch der Empfänger über einen richtigen Schlüssel verfügen müssen.

Benutzt das Verfahren auf beiden Seiten einen identischen Schlüssel spricht man von einem symetrischen Verfahren.

Haben Sender um Empfänger unterschiedliche Schlüssel handelt es sich um ein asymetrisches Verfahren und die beiden Schlüssel bilden ein Schlüsselpaar.

Die Schlüssellänge (in Bits) ist dabei ein Indiez wie aufwendig es ist diesen durch ein Bruteforce Verfahren zu finden. Die Längenangabe gibt einfach an aus wie vielen Bits Information der Schlüssel besteht. Würde man zum Beispiel einen 16 ASCII Zeichen langen Text als Schlüssel benutzten hätte man einen Schlüssel von 16*8 Bit = 128 Bit

Eines der einfachsten Verfahren ist ein Verfahren bei dem der Schlüssel einfach bestimmt ob ein Bit invertiert wird oder nicht.

Gehen wir von einem 8 Bit Schlüssel 01101100 aus un kodieren damit eine Bitsequenz nach dem Prinzip das immer wenn der Schlüssel eine 1 enthält das Bit Invertiert wird und bei 0 unverändert bleibt.


Original 10100111 01110111 01111010 10101010 10101011
Key 01101100 01101100 01101100 01101100 01101100
Kodiert 11001011 00011011 00010110 11000110 11000111


Der Empfänger macht das gleiche:


Kodiert 11001011 00011011 00010110 11000110 11000111
Key 01101100 01101100 01101100 01101100 01101100
Original 10100111 01110111 01111010 10101010 10101011

[Sunrise]

@Ganon:

Um´s ganz einfach zu machen:

Eine 128Bit-Verschlüsselung kann folgendes bedeuteten:

Du hast einen 128bittigen Schlüssel, sprich: Bits die zusammengenommen als Zeichenfolge aus Werten die z.b. in ASCII definiert sind abgebildet werden, also 256 (0-255) verschiedene Zeichen. Mit dieser Zeichenfolge wird ein Text, der vorher mit einem Schlüssel verschlüsselt wurde wieder entschlüsseln.

Genau hier gibt es aber dutzende, wenn nicht hunderte verschiedener Methoden, wie man diese/n Schlüssel erhält, es ist also schwer allgemein etwas dazu zu sagen.

Allgemein gilt, desto mehr Bit der Schlüssel hat, desto schwieriger ist er zu knacken. Dies gilt aber nur in Verbund mit dem gleichen Verschlüsselungs-Algorithmus, nicht als Vergleich untereinander !

Das ganze dauert nun deshalb solange, da Du ja nicht weißt, welchen Schlüssel du verwenden musst, damit die verschlüsselte Information wieder einen Sinn ergibt (also entschlüsselt ist).

Im Prinzip fängst du mit einem Ratespiel an, und versuchst die richtigen Kombinationen zu finden, ähnlich wie bei einem Tressor.
Das Problem ist aber, das du mit höherer Bittiefe plötzlich soviele Kombinationen hast, das man dies nur mit Computerhilfe erledigen kann.

Und selbst der Computer, dem du diese Informationen zuführst, kann nur ausprobieren, denken musst immernoch du. Es ist deshalb nicht einfach einen Schlüssel zu knacken, erst recht nicht, wenn der Algorithmus der dahinter steckt intelligent ist, und zugleich einen sehr hohen Schlüssel hat.

Ich hoffe das war ein gutes Beispiel, an dem du dir jetzt Ansatzweise etwas vorstellen kannst. Auf Richtigkeit gebe ich keine Garantie, es sollte zum Verständniss dienen, und das ist mir hoffentlich gelungen.

Grüße
Sunrise

PS: Demirug hat oben das ganze auf Bitebene abgebildet, damit solltest du 2 nachvollziehbare Beispiele haben, wie das ganze vor sich geht.

[Ganon]

@Demirug & Sunrise

Vielen Dank!
Muss jetzt noch ein bisschen grübeln, aber vom Prinzip her ist es klar!

[PhoenixFG]

DAs Bruteforce entschlüsseln dauert auch deshalb so lange, weil ja mit einem 128bit-Schlüssel theoretisch 3,4 * 10^38 Kombinationen möglich sind.
Und im schlimmsten Fall weiß man noch nicht einmal, wie eigentlich der Schlüssel auf die Nutzdaten wirkt, d.h. das Verschlüsselungsverfahren ist unbekannt.

Dieser große Aufwand wird ja auch aktiv bei TCPA genutzt, wo die Schlüssel 1024bit lang sind. Damit wird sicher gestellt, dass es auch mit zukünftiger Rechentechnik nicht möglich ist, den Schlüssel zur Laufzeit zu knacken.

MfG

[Frank]

Originally posted by PhoenixFG
DAs Bruteforce entschlüsseln dauert auch deshalb so lange, weil ja mit einem 128bit-Schlüssel theoretisch 3,4 * 10^38 Kombinationen möglich sind.
Und im schlimmsten Fall weiß man noch nicht einmal, wie eigentlich der Schlüssel auf die Nutzdaten wirkt, d.h. das Verschlüsselungsverfahren ist unbekannt.

Dieser große Aufwand wird ja auch aktiv bei TCPA genutzt, wo die Schlüssel 1024bit lang sind. Damit wird sicher gestellt, dass es auch mit zukünftiger Rechentechnik nicht möglich ist, den Schlüssel zur Laufzeit zu knacken.

MfG
teilweise falsch
1.
Ein 128bit Schlüssel ist nicht unbedingt 128bit lang. Das gibts durchaus unterschiedliche Möglichkeiten - ua. auch daraus ständig permutierte Teilschlüssel für eine Verschlüsselungsrunde zu verwenden. Der klassische Vertreter dafür ist wohl DES. Das benutzt in der 08/15 Standardversion ein 56bit Schlüssel, aus dem in 16 Runden des Chiffrieralgorithmus 16 mal ein neuer schlüssel permutiert wird. Die sind dann alle 48 bit lang.

2.
Man kann die Sicherheit eines Systems nicht auf die Unkenntnis des eigentlichen Kryptosystems aufbauen. Nur auf den Schlüssel. Das ist absoluter Usus.


zum Threadanfang:
Vieles wurde schon gesagt Ganon. Die Schlüssellänge ist letztendlich schon irgendwo der Knackpunkt der Sicherheit. Aber nicht der Einzigste. Oben habe ich DES erwähnt - übrigens ein symetrisches Verfahren. Das kommt mit einem 56bit Schlüssel aus. Im sogenannten TripleDES, der auch heute im Gegensatz zum veralten DES als "sicher" gilt, mit 3+56bit. AES - auch symetrisch - mit 128/192bit. Gilt auch als nicht brechbar aktuell. Diese Verfahren basieren meist auf einen PermutationSubstituionsnetzwerk - kurz SPN. Natürlich mehr oder weniger abgewandelt (gerade AES mit untypischer ByteCodierung in dem Bereich). Ich habe hier ein kleines Programm welches kurz aufzeigt wie dies funkioniert: http://rcswww.urz.tu-dresden.de/~fh468638/sub/spn.htm

Asymtrische Verfahren beruhen auf mathematisch "komplexen" Problemen: Um nicht um den heißen Brei zu reden: NP sagt den evtl ein oder anderen was: NonPolynomial. Das heißt der Aufwand ist nicht polynomial - also exponentiell. Allerdings muss man fairerweise sagen, dass zb die Primzahlzerlegung oder die Lösung des diskreten Logarithmus als solche math. Probleme (noch) nicht nachweisbar NP sind. Aber man vermutet es. Sehr bekannte Ausnutzung der Primfaktorzerlegung ist RSA. Das kennt eigentlich jeder. Ein anderes Verfahren ist Elgamal. Auch bekannt und auch weiterverwendet für Kryptsysteme auf Elliptischen Kurven - heute nonplusUltra und läuft unter ECIES oder zb auch ECM.
Erklären gibts da ziemlich viel, weswegen aths schon richtig meinte, dass deine Frage eigentlich präziser sein müsste. Jedenfalls zu den Assymetrischen kurz: Auch hier ist die bitzahl nicht unbedingt ein Indiz für Sicherheit. Auf EC brauchst du zb viel weniger bits bei gleicher Sicherheit als RSA. Verhältnis etwa 200 zu 1000bit.


Zu deiner 2. Frage: Assymetrische Verfahren beruhen halt auf netten math Problemen: siehe RSA letztendlich auf Primfaktorzerlegung (man kann aber RSA auch anders brechen). Und daran beissen sich zig Mathematiker die Zähne aus. Symetrische Verfahren haben ihre Sicherheit eher in den komplexen Substitionboxen. Die sind einfach darauf ausgelegt eine Eingabefolge in eine Ausgangsfolge zu zerstückeln, wo jedes Ausgangsbit fifty fifty 1 oder 0 ist :D . Und das zb bei DES in 16 mal hintereinander.

Falls du genaue Fragen hast - auch gern per PM. Bin da nicht ganz so unbelastet zu den Thema.

[PhoenixFG]

Hi!

Ich meinte auch nicht, dass die Sicherheit auf der Unbekanntheit des Verschlüsselungsalgorithmus aufbaut, sondern nur dass es nochmal extra schwer wird Daten zu entschlüsseln, wenn man neben dem eigentlichen Schlüssel auch den Algorithmus nicht kennt.

MfG

[Abe Ghiran]

Originally posted by Frank
NP sagt den evtl ein oder anderen was: NonPolynomial. Das heißt der Aufwand ist nicht polynomial - also exponentiell.

Nope, das ist ein sehr verbreitetes Mißverständnis. NP heißt nichdeterministisch polinomiell. D.h. man kennt für Probleme dieser Klasse momentan keine Algorithmen mit polynomialer Laufzeit.
Hat man aber eine mögliche Lösung (z.B. geraten) gibt es polynomiale Algorithmen, um zu überprüfen ob diese Lösung richtig ist.
Ob es aber für np harte Probleme nie polynomialzeit Algorithmen geben wird, ist ja noch nicht bewiesen (die berühmte Frage n=np oder n!=np).

Sorry für die Korintenkackerei aber für irgendwas muß GTI lernen ja gut sein :).

Grüße, Jan

[Frank]

nein - bestimmt keine Korintenkackerei. Ich habs einfach falsch hingeschrieben. Danke für die Veresserung. Irgendwie habsch da wohl was in der Nacht verdüdelt. (hatte das ja auch schon in "Numerische Simulationen..." *schäm* )