Hallo,

Die Fragen kann man auf zwei Arten beantworten. Die Art der Verschlüsselung geht ja aus der Fragestellung nicht hervor.

1) Nutzung Symmetrischer Verschlüsselung

Zunächst gehe ich von symmetrischer Verschlüsselung aus (Sender und Empfänger benutzen den selben Schlüssel)

a) Zwei Leute wollen miteinander kommunizieren (Alice mit Bob), dann brauchen Sie einen gemeinsamen Schlüssel.

b) Drei Leute wollen miteinander kommunizieren (Alice, Bob und Charlie). Dann brauchen Alice und Bob einen Key, Alice und Charlie, und Bob und Charlie. Also brauchen wir 3 Schlüssel.

c) Nun haben wir vier Leute die kommunizieren wollen. Der Einfachheit halber A,B,C und D

Wir haben folgende Kommumikationswege die jeweils einen Schlüssel brauchen

A-B

A-C

A-D

B-C

B-D

C-D

also ingesamt 6 Schlüssel.

d) Nun haben wir n Leute die miteinander kommunizieren wollen. Also haben wir folgende Kommunkationsteilnehmer A,B,C,D,...,N

Für A brauchen wir n-1 Schlüssel, da A mit n-1 anderen Leuten kommuniziert.

Für B brauchen wir nun n-2 zusätzliche Schlüssel, da wir zwischen A-B bereits einen Schlüssel gezählt haben, aber für alle anderen mit B noch einen Schlüssel brauchen.

Für C brauchen wir nun n-3 zusätzliche Schlüssel, da wir zwischen A-C und B-C bereits jeweils einen Schlüssel gezählt haben und für alle anderen mit C noch einen Schlüssel brauchen.

...

Für N brauchen wir keinen zusätzlichen Schlüssel mehr, da wir mit allen vorherigen und N bereits einen Schlüssel gezählt haben.

Wir brauchen für jeden Teilnehmer mit jedem anderen Teilnehmer einen Schlüssel. Das entspricht bei n Teilnehmern (n * (n-1)) / 2. Wir teilen das durch 2, da ja z.B. A-B und B-A den selben Schlüssel benutzen.

Es gibt auch einen Beweis um von (n-1) + (n-2) + (n-3) + ... + (n-n) auf diese Formel zu kommen. Das spare ich mir hier jetzt aber :-)

2) Nutzung Asymmetrischer Verschlüsselung:

Bei asymmetrischer Verschlüsselung hat jeder der n-Teilnehmer einen öffentlichen und einen privaten Schlüssel. Je nachdem ob man die zusammen als einen oder zwei zählt, sind es entweder n Schlüssel oder n*2 Schlüssel. Es sind deutlich weniger, weil ja jeder den öffentlichen Schlüssel des Kommunikationspartners verwenden kann. Also z.b. sowohl A an C mit dessen öffentlichen Schlüssel was verschlüsseln kann, aber auch B and C mit dessen öffentlichen Schlüssel verschlüsseln kann.

Die Problematik bei der symmetrischen Verschlüsselung und großen Gruppen ist natürlich das Verwalten und Verteilen der ganzen Schlüssel. Bei vielen Teilnehmern braucht man sehr viele Schlüssel. Die Anzahl der benötigten Schlüssel wächst hier quadratisch. Bei asymmetrischer Verschlüsselung wächst die Anzahl der Schlüssel linear. Je Teilnehmer braucht man hier nur ein neues Schlüsselpaar.

Viele Grüße,

Nils

Hallo,

Als Idee würde ich hier wie folgt vorgehen:

1) Kriterien für kryptographisch sichere Hashfunktionen einmal auflisten (preimage resistance, 2nd preimage resistance und collision resistance)

2) Schauen, ob diese Kriterien erfüllt sind oder ob ich eine von denen "wiederlegen" kann...

Als Tipp: Berechne mal den Hashwert für einen wert X und den Hashwert für ein X + n * p also das selbe X auf das wir ein beliebiges Vielfaches unser Primzahl addieren :-)

Falls Dir unklar ist, welche kriterien kryptographisch sichere Hashfunktionen erfüllen müssen, schau Dir einfach mal mein (Englisches) Video über kryptographische Hashfunktionen hier an: https://www.youtube.com/watch?v=Rwvpngxp438

Viele Grüße,

Nils

Hallo,
Ich bin der Projektleiter des CrypTool 2-Projekts.
CrypTool 2 nutzt und verarbeitet verschiedene Datentypen. Im Fall vom AES werden CrypToolStreams (binäre Datenströme) für die Daten (Geheimtext, Klartext) als Eingaben benötigt und als Ausgaben ausgegeben. Der Schlüssel vom AES kann 128 bit, 192 bit oder 256 bit breit sein (je nach Einstellung der Komponente). Auch er wird er als binäres Datum (Byte-Array) dem AES gegeben.

Im oben aufgeführten Beispiel werden ein Klartext als Text (String) eingegeben. Die Textinput-Komponente ist direkt mit dem oberen AES verbunden. Das geht, führt aber zu einer impliziten Konvertierung von String nach CrypToolStream. CT2 nutzt dafür automatisch UTF-8 als Codierung. Der AES wiederrum liefert im AusgabeStream binäre Daten. Diese werden auch automatisch vom TextOutput als solche erkannt und dann in hexadezimaler Codierung ausgegeben.

Der untere AES erhält nun wiederrum einen String welcher in einen binären Datenstrom implizit umgewandelt wird. So werden die Hex-Werte nicht in einen binären Stream umgewandelt sondern der String an sich. Um allerdings den Inhalt des Strings als binäre Daten zu interpretieren muss dieser bzw sein Inhalt (die Hex-Werte) in binäre Daten umgewandelt werden. Dafür kann man da eine String-Decodierer-Komponente zwischenschalten. Diese wandelt dann die Hexwerte (z.B. A0 1B AF CC... ) in einen Strom binärer Daten um.

Ebenso müssen bei der finalen Ausgabe (unterer AES) die Ausgabedaten von einem binären Strom wieder in Text (String) umgewandelt werden. Dafür brauchen wir eine String-Codierer-Komponente, die dann von ByteArray (der Ausgabe des unteren AES) in einen UTF-8 String umwandelt.

Ebenso gibt man den Key nicht als String bzw Passwort an, sondern man gibt den Key ebenfalls als Hex-String ein, welcher dann in ein Byte-Array umgewandelt wird. Beispiel: "FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF" (16 bytes = 128bit; alle bits auf 1 gesetzt). Dies gibt man in die TextEingabe-Komponente des Keys eing und wandelt das dann ebenfalls mit einer String-Decodierer-Komponente in ein ByteArray um.

Falls das alles zu theorisch ist, habe ich übrigens ein YouTube-Video (Englisch) auf meinem Kryptographie-Kanal, welches genau solche Dinge (Datentypen und Konvertierung) ausführlich erklärt: https://www.youtube.com/watch?v=1P00GGmx7o8

Viele Grüße,
Nils