Forum: Offtopic AES Verschlüsselung


von Werner P. (Gast)


Lesenswert?

Hab mal ne Frage zu AES.

Wenn die Daten die verschlüsselt werden bekannt sind, kann dann von den 
verschlüsselten Daten der Schlüssel abgeleitet werden?

Danke

von Pandur S. (jetztnicht)


Lesenswert?

Eine Frage der Menge an bekannten Daten. Dieses Feld nennt sich 
differential Decodierung. So wurden uebrigens auch die Codes der Enigma, 
des deutschen Kryptosystems, im 2.Weltkrieg geknackt. Jede Mitteilung 
begann mit "Sehr geehrter Herr Oberst" oder aehnlich.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Werner P. schrieb:
> Wenn die Daten die verschlüsselt werden bekannt sind, kann dann von den
> verschlüsselten Daten der Schlüssel abgeleitet werden?

Der Sinn solcher Verschlüsselungsverfahren besteht darin, dass dies 
eigentlich nicht möglich sein sollte. Man kann aber AES in einer Weise 
verwenden, in der es u.U. doch möglich ist. Etwa wenn man ECB an Stelle 
des gängigeren CBC verwendet.

von Werner P. (Gast)


Lesenswert?

Danke für die Infos.

Wäre folgende Lösung ok.

A sendet an B einen generierten Schlüssel welcher mit dem 
Masterschlüssel verschlüsselt ist.

A und B kennen jetzt den gemeinsamen Schlüssel.

A sendet an B die Daten welche mit dem generierten Schlüssel 
verschlüsselt werden.

Natürlich müsste sichergestellt werden dass sich die generierten 
Schlüssel nicht wiederholen.

von (prx) A. K. (prx)


Lesenswert?


: Bearbeitet durch User
von Werner P. (Gast)


Lesenswert?

A. K. schrieb:
> Willst du das Rad neu erfinden?
> https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
> https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy

Nein, will ich nicht. Arbeite mich da grad rein und will verstehen wo 
denn die Schwachstellen sind.

Danke an alle. Hilft mir schon mal weiter.

von Uhu U. (uhu)


Lesenswert?

A. K. schrieb:
> Willst du das Rad neu erfinden?

Jeder, der eine Sache gründlich durchschauen will, muss das Rad neu 
erfinden - zumindest im Geiste und mit spicken...

von Vlad T. (vlad_tepesch)


Lesenswert?

Werner P. schrieb:
> A sendet an B einen generierten Schlüssel welcher mit dem
> Masterschlüssel verschlüsselt ist.

ganz schlecht! Das heißt es muss ein Master-Schlüssel getauscht werden.

Das Stichwort

A. K. schrieb:
> Diffie–Hellman

fiel ja schon.

Anschaulich dargestellt, schickst du deinem Gegenüber ein Schloss, zu 
dem nur du den Schlüssel hast.
Er Verpackt die Nachricht (in dem Fall den symmetrischen Session-Key) 
und packt da dein Schloss drann und schickt es dir.

Du öffnest mit deinem Schlüssel das Schloss und die eigentliche 
Datenübertragung kann mit dem symmetrischen AES erfolgen.

Eine weitere Herausforderung ist, sicherzustellen, dass kein böser 
dritter dein Schloss abfängt, seins weiterschickt, die (mit seinem 
Schloss) verschlossene Box empfängt, ausspioniert und mit deinem 
Schlüssel zu dir weiter leitet.

Die Schlüssel heißen Private Keys und die Schlösser heißen Public Keys.
Die Sicherstellung, dass ein Public Key wirklich zu dem gehört, von dem 
er vorgibt zu sein wird in der Praxis über Zertifikate, die den 
Schlüssel beglaubigen und Web-Of-Trusts geregegelt  (A traut B, B traut 
C, B hat den Schlüssel von C unterschrieben, also kann A darauf 
vertrauen, dass er wirklich zu C gehört)

: Bearbeitet durch User
von Werner P. (Gast)


Lesenswert?

Vlad T. schrieb:
> ganz schlecht! Das heißt es muss ein Master-Schlüssel getauscht werden.

Blöde Frage. Meinst Du jetzt als Master-Schlüssel den generierten 
Schlüssel?

von Vlad T. (vlad_tepesch)


Lesenswert?

Werner P. schrieb:
> Blöde Frage. Meinst Du jetzt als Master-Schlüssel den generierten
> Schlüssel?

ich bezog mich darauf:

Werner P. schrieb:
> A sendet an B einen generierten Schlüssel welcher mit dem
> Masterschlüssel verschlüsselt ist.

hier schreibst du, du willst einen Sessionkey mit einem Masterschlüssel 
verschlüsseln. Das hört sich für mich so an, als soll der anderen den 
Sessionkey mit dem selben Schlüssel entschlüsseln.

von Werner P. (Gast)


Lesenswert?

Vlad T. schrieb:
> Das hört sich für mich so an, als soll der anderen den
> Sessionkey mit dem selben Schlüssel entschlüsseln.

Wenn Du jetzt den Masterkey meinst dann ja.

A und B kennen den Masterkey.

A generiert einen Sessionkey und verschlüsselt diesen mit dem Masterkey.

B entschlüsselt den verschlüsselten SessionKey mit dem Masterkey und hat 
somit den Sessionkey.

also liegt da schon das Problem. Oder?

Wie gesagt. Ich arbeite mich da grad rein. Hatte jetzt aber noch keine 
Zeit die vorgeschlagenen Links zu studieren. Hole ich aber noch nach ;-)

von Johannes O. (jojo_2)


Lesenswert?

Du hast noch ein ganz anderes Problem: Wie verwendest du überhaupt 
deinen AES? Machst du CFB, ECB, GCM, ...?
https://de.wikipedia.org/wiki/Betriebsmodus_%28Kryptographie%29

Davon hängt nämlich auch deine Sicherheit ab. Wenn du den AES nur Block 
für Block verwendest (ECB Modus), dann könnte man beispielsweise 
Datenblöcke, die ausschließlich 0 enthalten, relativ leicht erkennen, 
weil diese in vielen Dateien am häufigsten Vorkommen.
https://de.wikipedia.org/wiki/Electronic_Code_Book_Mode


Werner P. schrieb:
> Wenn die Daten die verschlüsselt werden bekannt sind, kann dann von den
> verschlüsselten Daten der Schlüssel abgeleitet werden?

Ja, wenn du ciphertext und plaintext hast, dann könntest du den 
verwendeten Schlüssel extrahieren. Zumindest Theoretisch, wenn du die 
Rechenleistung dafür hättest um es beispielsweise per Brute-Force 
auszuprobieren.... Das ist aber aktuell bei AES keine Gefahr.
Wenn dein Angreifer aber Ciphertext und Plaintext gleichzeitig hat, dann 
kommt es auch wieder auf den verwendeten Modus und dessen 
Implementierung an, dann kanns nämlich trotzdem unangenehm werden.

Kurz gesagt: Es ist auf jeden Fall gut, wenn du die Hintergründe 
verstehen willst! Aber das Design beispielsweise eines verschlüsselten 
Übertragungsprotokolls und die eigentliche Implementierung (für eine 
kommerzielle Anwendung!) solltest du aber immer Spezialisten überlassen 
bzw. fertige Libraries verwenden. Ich habe da in den letzten Monaten 
sehr viel grauenhaftes gesehen. Nur weil du AES verwendest, bist du noch 
lange nicht auf der sicheren Seite. Da gibt es noch viel falsch zu 
machen... :-P

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.