sichere Verschlüsselung in .net

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 37 Antworten in diesem Thema. Der letzte Beitrag () ist von Artentus.

    sichere Verschlüsselung in .net

    hallo leute

    irgentwie habe ich anscheint ein übelstes logikproblem was verschlüsselungen in .net angeht...
    kurz zum problem

    ich habe einen kleinen Client-Server-Chat gebastelt. man muss sich allerdings zuerst auf dem Server einloggen. Das macht man indemm man dem Server über TCP die Zugangsdaten übermittelt. (der Server prüft die dann und lässt verbindung zu...)
    soweit alles gut. funktioniert auch alles perfekt... allerdings werden die Zugangsdaten im Klartext übergeben. Das würde ich gerne ändern und mir eine verschlüsselung ausdenken.

    nehmen wir mal als Beispiel sowas hier
    a=1
    b=2
    c=3
    d=4
    ...

    wenn ich mir jetzt ein Modul (oder eine .dll) schreibe welches mir mein String verschlüsselt... dann werden die Zugangsdaten schonmal verschlüsselt zwischen client und server übergeben. Genau das was ich ja will
    Mein Problem ist allerdingsdass jeder mein Quellcode auslesen kann und jeder sieht wie meine verschlüsselung funktioniert und somit ist die verschlüsselung wieder sinnlos....

    jetzt meine Frage: wie mach ich denn jetzt mit .net eine verschlüsselung die man nicht einfach im Quellcode auslesen kann? Soll ich de verschlüsselung so verwirrend in den code schreiben das selbst ich nit mehr weiss was ich da getan habe?

    Bei einer guten Verschlüsselung muss der Algo bekannt sein, alles andere ist nicht sicher. Security through Obscurity hat außerdem noch nie funktioniert...
    tldr: Nimm etwas fertiges aus dem Framework, solche Encryption ist nicht safe.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    leider führt dein link nicht zur gewünschten seite
    wusste allerdings nicht das .net schon verschlüsselungen anbietet. welche davon sind denn sicher bzw unknackbar?
    @ichduersie
    du sagtest das AES unknackbar wäre? also das hier?
    msdn.microsoft.com/de-de/libra…cs-lang=vb#code-snippet-2
    und das kann ich jetzt zum verschlüsseln einfach auf meinen client bauen und die entschlüsselung auf meinen server und alles wäre gut?
    das wäre ja zu einfach... aber wieso ist diese verschlüsselung dann sicherer als eine ausgedachte von mir?

    Das reine Verschlüsseln bringt aber noch nix, da ein Angreifer einfach den Schlüssel mitlesen kann.
    Um den Schlüssel auszutauschen fällt daher in der Regel nochmal Mehraufwand an. Du könntest einen Austausch nach Diffie-Hellman implementieren, oder du verwendest dafür ein asynchrones Verfahren wie RSA.

    Edit: eine solche Verschlüsselung kann dann, wenn korrekt implementiert, tatsächlich als quasi unknackbar angesehen werden. Selbst die NSA sollte da Schwierigkeiten haben, es sei denn natürlich MS musste Hintertüren in ihren Code einbauen. ;)

    dürfte sie aber so ziemlich sein, solange man keinen Quantencomputer hat.
    @TE: weil die Leue, die sich diese Verschlüsselungen überlegt haben etwas mehr mit Mathe auskennen als wir normal sterblichen. Eine Verschlüsselung zu verstehen ist sowieso nochmal etwas ganz anderes, als selbst auf eine gute zu kommen.
    Außerdem ist AES nur in sofern sicher, wenn das Passwort für die Verschlüsselung auf Client und Server vorliegen und niemand auf diese Zugreifen kann->Schlechter weg
    Mache erst einen SChlüsselaustausch siehe Diffie-Hellman, oder verwende RSA.
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    was genau macht denn dieses DEffie Hellmann?
    bei meinem chat muss man sich mit benutzernamen und password einloggen. der server überprüft dann diese daten und lässt dann die verbindung zu oder eben nicht...
    ich dachte es würde reichen wenn ich password und benutzernamen verschlüsselt zwischen client und server über tcp übertrage?
    was genau macht jetzt dieses deffie-hellmann anders?

    EDIT:
    es gibt noch ein weiteres password das mann auch an den server schicken muss damit überhaupt die verbindung mit dem server besteht...
    vllt kann ich damit noch was reissen?

    Ich würde sowieso eine asynchrone Verschlüsselung (RSA, DSA) verwenden, weil dann die 2 Clients einfach die Schlüssel haben und damit die Daten verschlüsselt und nur von ihnen wieder entschlüsselt werden können.
    Credentials werden normal übrigens beim Senden an den Server nicht verschlüsselt, sondern gehashed, sodass man eine Prüfsumme hat, die dann mit der bestehenden verglichen werden kann.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Diffie-Hellman ist keine Verschlüsselung, sondern ein Schlüsselaustausch, guck es dir einfach auf Wikipedia an. Ist ein sehr gutes Beispiel dabei, RSA arbeitet auf ähnliche weise für den Schlüsselaustausch(nur nicht mit den primitivwurzeln)
    de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch

    Was deine Frage wäre ist was AES z.B. anders macht. Da könnten wir anfangen mit alles.
    Das was du hast ist keine Verschlüsselung sondern ein Encoding. Rot13/Caesar wären Verschlüsselungen auf einfachstem Niveau, denn dort wird bereits ein Passwort verwendet, bei Rot13 ist das Passwort der "13". Bei Caesar gibt es wenn du es auf byte basis baust 255 verschiedene Möglichkeiten zu verschlüsseln, diese sind sehr schnell durchprobiert, für Texte braucht man außerdem im Deutschen nur auf die Häufigkeit von e prüfen und kann somit nach Wahrscheinlichkeit gucken, dass richtig entschlüsselt wurde, d.h. ein Angreifer braucht maximal 255 Möglichkeiten durchprobieren, die bei Caesar ein billig Laptop in weniger als einer sekunde schafft, mit gescheitem Algo muss der Mensch nichtmal alle 255 angucken, sondern bekommt sogar sofort das richtige Ergebnis(hat Versuchsweise bei normalen dt. Texten immer auf anhieb funktioniert)
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    @jvbsl
    versteh ich nicht...
    das versteh ich nicht wie das funktioniert und sicher sein soll... ok wie es funktioniert schon aber nicht warum es für andere abhörer sicher sein soll? upload.wikimedia.org/wikipedia…Key_Exchange_(de).svg.png
    wenn ein anderer das gesammte gespräch abhören kann... wieso kommt der dann nicht aufs selbe "geheimes ergebniss"?


    also muss ich zuerst eine tcp zum server aufbauen... dann erstmal diesen schlüsselaustausch starten und erst dann die zugangsdatem fürs chatten senden oder wie jetzt?
    wenn ich jetzt "gemeinsame Farbe" in den quellcode vom Client schreibe (beispiel "rot"(ich weiss man soll keine passwörter in den code schreiben...)) dann kann man doch die gemeinsame farbe vom client ganz einfach auslesen? und wenn man die doch weiss kann man doch einfach "geheimes ergebnis" herrausfinden....
    wieso soll es dann noch sicher sein?

    Der Austausch bleibt sicher, da beide Parteien einen geheimen Schlüssel (dieser Schlüssel kann von unterschiedlichster Art sein) generieren, der nicht preisgegeben wird. Stattdessen wird eine mathematische Operation darauf ausgeführt, die mit aktueller Computerhardware aufgrund enorm großen Rechenaufwandes nicht rückgängig gemacht werden kann (z.B. Multiplikation zweier gigantisch großer Primzahlen, der Rechenaufwand für Primfaktorzerlegung wächst mit steigender Länge exponentiell).
    Die beiden Parteien schicken sich dann das Ergebnis dieser Operation gegenseitig zu und führen eine weitere Operation auf dem Ergebnis des anderen mithilfe ihres geheimen Schlüssels durch. Dadurch gelangen beide Parteien dann schlussendlich zum gleichen Ergebnis, dem Schlüssel für die Kommunikation, ohne dass dieser oder Bausteine führ ihn auch nur einmal übertragen wurden.

    leider immernoch nicht so ganz verstanden warum es unknackbar sein sollte...

    Client
    		Server
    Gemeinsame zahl 5
    		Gemeinsame zahl 5
    Geheime Zahl 2 (5+2=7)
    		Geheime Zahl 3 (5+3=8)
    Austausch Ergebnis mit Client 8
    		Austausch Ergebnis mit Client 7
    Geheime Zahl + Ergebnis Server 8+5=10
    		Geheime Zahl + Ergebnis Client 7+5=12
    Ergebnis 13
    		Ergebnis 12

    unterschiedliche ergebnise.
    Weiss der Client das "Gemeinsame Geheimnis" vom Server also garnicht? und der Server vom Client nicht?
    Da der andere jetzt das Ergebnis vom anderen hatt kann er ja einfach rechnen und weiss was der andere für Ergebnis hätte und somit ist es ein Gemeinsames Ergebnis.
    oder war mein Beispiel nur zufall das es Funktionierte? :D

    Da liegt jetzt mein Problem... Wenn jetzt jemand auf der TCP verbindung mitgehört hat dann hatt er doch alle Ergebnise vom Client. Die Geheime Zahl wird also Generiert und nicht fest gespeichert? soweit schonmal gut. Allerdings könnte man doch den Ram auslesen und man hätte die Geheime Zahl vom Client und wüsste somit auch sein Ergebnis. 13
    Wenn ich die Geheime Zahl vom Client weiss tjah dann...
    austauschzahl vom Server -Gemeinsame Zahl = Geheime zahl vom Server = 3
    8-5 = 3 ?(
    oder geht man davon aus das die Geheime Zahl nicht ausgelesen werden kann?
    Du sagtest was mit Primzahlen... also nimmt man statt wie ich jetzt + einfach * ?
    das wäre doch auf genau die gleiche Art und weisse ausrechenbar welches ergebnis wer hätte? irgentwie ja doch nicht ... ist das die Lösung?
    brauch man dann für das Ergebnis auszurechen einfach nur einen "Guten" Rechner und man kann alle verschlüsselungen mit Diffie Hellmann entschlüsseln? Da man ja weiss Wie sie verschlüselt sind (Ergebnis)?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „MVN050“ ()

    MVN050 schrieb:

    könnte man doch den Ram auslesen und man hätte die Geheime Zahl vom Client
    Das ist richtig, aber wenn der Angreifer bereits den RAM des Clients auslesen kann sind jegliche Verschlüsselungen sowieso absolut nutzlos, ein kompromittiertes System ist wertlos.

    Dein Rechenweg ist allerdings fehlerhaft, so ist es logisch, das etwas anderes rauskomm.
    Das Problem für den Angreifer ist, dass die gemeinsam vereinbarte Zahl auf beiden Seiten jeweils mit der geheimen Zahl potenziert und dann mit einer vereinbarten Primzahl Modulo genommen wird. Dadurch entsteht auf beiden Enden der selbe Schlüssel, aber damit der Angreifer den Schlüssel berechnen kann müsste er ebenfalls in Besitzt von mindestens einer der beiden geheimen Zahlen sein. Diese können theoretisch ausgerechnet werden, und zwar mit dem diskreten Logarithmus, der Rechenaufwand dafür übersteigt bei entsprechend großen Zahlen und entsprechend großer Primzahl jedoch alles, was selbst Supercomputer in Millionen von Jahren berechnen könnten und ist damit praktisch gesehen unknackbar.

    So wie ich das verstanden habe (hab nur Bildchen geguckt) läuft das bspw. so ab:
    Alice
    		Bob
    Public Key: 9
    		Public Key: 9
    Private Key: 12
    		Private Key: 33
    = 21
    		= 42
    N. Austausch: 42
    		N. Austausch: 21
    Private Key: 12
    		Private Key: 33
    -> 54
    		-> 54
    Die Zahlen und Operationen sind natürlich nur beispielhaft. Der Sinn dahinter ist, dass der private Key geheim bleibt. Ohne diesen Key, kann auch der resultierende Key der genutzt wird auch nicht errechnet werden.

    @Gonger96
    kannst du mir Bitte auch die Rechnung zeigen? das intressiert mich viel mehr ;) das die was austauschen habe ich bis jetzt verstanden aber nicht wie die auf die selben Ergebnise kommen...

    ok nehmen wir mal an das wäre unknackbar...

    wie genau muss ich denn jetzt meine chatverbindungen aufbauen?
    Client verbindet sich also zum Server und sagt Hallo Server meine Zahl ist 384275.
    Server sagt : Hallo Client. Meine Zahl ist 23784.
    Client Schickt Server Benutzernamen+Password für die Chatanmeldung verschlüsselt.
    Server weiss nun wie verschlüsselt wurde und entschlüsselt die Nachricht (also Benutzernamen und Password) kontrolliert ob die Zugangsdaten Stimmen und gibt (in verschlüsselter Form) rückmeldung ob Login Erfolgreich oder nicht...

    Nun haben die 2 eine Verschlüsselung und können nun weiterhin mit der Geheimen Verschlüsselung Nachrichten Ausstauschen wie sie wollen?

    Ich bin jetzt auch kein Sicherheitsexperte, aber lange nicht einfache Hashes ? Username + PW im Client nach Eingabe hashen, in den Networkstream legen, und mit Hashes beim Server vergleichen. Oder gibts da iwelche Probleme ?
    »There's no need to "teach" atheism. It's the natural result of education without indoctrination.« — Ricky Gervais

    1. Client verbindet sich mit dem Server und sendet die Primzahl p, den Erzeuger g und sein errechnetes A
    2. Server antwortet mit auf seiner Seite erzeugtem B
    3. Beide errechnen den Schlüssel K, der ab sofort alle Übertragungen symmetrisch mit AES verschlüsselt
    Danach kannst du ganz normal fortfahren, z.B. mit dem Senden von Benutzername und Passwort

    Oder du verwendest gar nicht Diffie-Hellman sondern RSA, dann muss nichts errechnet werden sondern beide Parteien müssen einen öffentlichen Schlüssel senden und dann asymmetrisch verschlüsseln.


    @ThePlexian
    Wenn der Server die Hashes erwartet und der Client diese schickt sind sie genauso viel wert wie das Passwort selber, da ein Angreifer ja auch den Hash mitlesen und an den Server, der auf diesen wartet, senden kann.

    Ich hab nur addiert ;) Du wendest halt die selben Operationen auf die selben Zahlen an. Auf Wikipedia ists ganz leicht erklärt, das Beispiel ist da auch besser.

    MVN050 schrieb:

    ok nehmen wir mal an das wäre unknackbar.

    Unkackbar ist garnichts.

Facebook
Telefonspende