Gast
#4560983
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
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.
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.
Gast
#4561030
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.
Willst du das Rad neu erfinden? https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy
Gast
#4561063
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.
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...
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)
Gast
#4561631
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?
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.
Gast
#4561639
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 ;-)
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
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.