Sportliches Ziel!

Ich halte das Unterfangen ohne fundiertes Wissen für unmöglich. Selbst wenn du dein Protokoll richtig wählst kann die Implementierung fehler bzw. Schwachstellen beinhalten.
Wenn du dich damit trotzdem richtig auseinandersetzen willst fürht um soetwas wie eine Vorlesung "Systemsicherheit" kein Weg dran vorbei.

Das vermittelt dir einen Eindruck wo schwachstellen lauern und einen blick dafür ob die Ideen aus dem Netz eher Hobby sind oder ernstgemeiente Lösungen.

Ich denke an Unterlagen zu Vorlesungen kommt an im Netz

Viel Erfolg

@EaranMaleasi
Schicke einen Master- oder wie auch immer Schlüssel auf einem völlig anderen Weg, EMail, SMS, Ansichtskarte.

ähm...wie soll das gehen, ich nutze bei dem SMD Small Data Server ein ähnliches verfahren

1. Server sendet Client einen public Key zum verschlüsseln des Kennwortes
   
2. Client verschlüsselt das Kennwort und sendet es
   
3. Server Entschlüsselt mit dem Private Key (nur mit dem kann Entschlüßelt werden)
   

sollte eigentlich ja ausreichen, wer mag mit dem Public Key das Kennwort Entschlüsseln ?

Habe auch gestern mal mich mit AES und DES beschäftigt. Aber ich denke RSA ist für Server Client Kommunikation das Beste

------
@EaranMaleasi Die NSA bekommt eh deine Daten wenn die es wollen

EaranMaleasi schrieb:

die sind von Natur aus Abhörsicher

Die kleinen grünen Quantenbeißer schaffen selbst das.
Mach mit dem Kollegen einen gemeinsamen Urlaub oder Kneipenbesuch und feddich.

Das mein lieber @EaranMaleasi ist das größte Problem bei dem ganzen Cryptozeug. Und bisher gibt es keine Möglichkeit die 100%ig Sicherheit bietet.
Eine Möglichkeit wäre mittels PSK, den du deinem Client User auf einem alternativen Kommunikationsweg zukommen lässt (wie @RodFromGermany schon sagte) und symmetrischer Verschlüsselung. ABER auch das bietet keine 100%ig Sicherheit.

@Andy16823 nope, nicht wenn man Krypto richtig nutzt - in deinem Beispiel könnte man sich zwischen die Verbindung hängen und den pub. Key gegen seinen eigenen tauschen.

Naja du könntest das auch alles ein paar mal verschateln

1. Klartext mit RSA
   
2. RSA mit AES
   
3. AES mit DES
   
4. DES mit RSA
   
5. RSA mit AES
   
6. AES mit DES
   
7. DES mit RSA
   
8. usw.....
   

Irgendwann sollte es dann dem Hacker zu Dumm werden

----------
@slice wie soll das gehen, wenn du dan entschlüßelen magst bekommst du einen fehler weil die Keys nicht zusammen passen.

Auch das hilft nichts, die Clients müssen entsprechende Infos haben damit sie das entschlüsseln können, also kann es auch ein Angreifer.

Nein wie denn wen einer den Public Key austauscht dann wird doch beim Entschlüsseln ein Fehler auftreten weil die Schlüssel nicht Kompatibel zueinander sind. Das ist wie wenn du einen Ersatz Auto Schlüssel austauschen würdest, dieser würde ja auch nicht gehen weil es nicht zum Schloss passt.

-----------

Edit: achso ihr meint das das kennwort entschlüßelt wird naja dann hast du recht wie wäre es noch mit SSL zusätzlich

Mehr krypto hilft nicht, es gibt einfach keinen Weg für den Austausch von Keys der absolut sicher ist (selbst ein treffen im RL ist nicht 100%ig sicher).

Nein, der Angreifer hängt sich zwischen Client und Server, wärend der Server seinen pub. Key sendet tauscht der Angreifer diesen gegen seinen aus und der Client schickt ihm das Kennwort verschlüsselt mit dem pub. Key des Angreifers zurück. Der nimmt das und verschlüsselt es mit dem des Servers und leitet es weiter. Tada der Angreifer hat das Kennwort abgegriffen und der User hat nichts davon mitbekommen.

hmm aber da würde doch ssl Abhilfe Schafen oder nicht ? das ist doch extra dafür da

-----------

warum überhautp verschlüßeln und keinen Hash senden der dann vom Server geprüft wird. Wird doch auch so bei logins in php seiten gemacht. Den Hash kann man ja noch zusätzlich bverschlüsseln

Du hast schon mitbekommen was in 2012/2013 alles passiert ist? Da hatten einige CAs diverse Probleme (zb. DigiNotar), also darauf würde ich mich auch nicht verlassen. Den Hash kannst du nachbilden wenn bekannt ist wie er gebaut wird.

Aber im Endeffekt muss man dazu sagen: Bei der Software hier würde es sich nicht lohnen so paranoid zu sein

Ich glaube man kann hier noch lange diskutieren wie man sicher verschlüsseln könnte. Im Endeffekt gibt es keine 100% Sicherheit. Ich würd sogar meinen wenn man gut ist kommt man auf 90 - 95 prozentige Sicherheit. Ansonsten würden Ja Adobes Softwares und andere Programme nicht gecrackt werden.

gar nicht wahr.
Nach heutigem Stand der Technik gilt richtig gemachtes TLS als sicher.
Es kommt v.a. drauf an, sich nix selbst neues auszudenken, sondern die bekannten Konzepte zu schnackeln und so anzuwenden, wie sie im Framework eiglich schon fixnfertig bereitstehen.

(Das hab ich jetzt schön geredet, aber ich selbst scheitere auch immer noch an dem Zertifikats-Brimborium, was da zu treiben ist )

Oder soll ich lieber gleich auf verschränkte Quanten umsteigen? die sind von Natur aus Abhörsicher

Gewöhnliche Materie hat eine definierte Phase von Null, daher wären leicht in der Phase verschobene Brieftauben auch zu 100% abhörsicher!

@Andy16823

Wikipedia schrieb:

​Heute wird DES aufgrund der verwendeten Schlüssellänge von nur 56 Bits für viele Anwendungen als nicht ausreichend sicher erachtet.

Vielleicht dazu noch interessant.

​ Seine Entstehungsgeschichte hat wegen der Beteiligung der NSA am Design des Algorithmus immer wieder Anlass zu Spekulationen über seine Sicherheit gegeben

ErfinderDesRades schrieb:

Nach heutigem Stand der Technik gilt richtig gemachtes TLS als sicher.

Der Knackpunkt liegt hier in "richtig gemacht". Wenn ein CA gehackt wird kann derjenige beliebig Zertifikate für beliebige Domains generieren und das ist es was @slice meinte (ganz frisch dazu: Ein Drittel aller Zertifikats-Herausgeber nur Security-Ballast). Man kann es nur immer weiter erschweren, aber 100% Sicherheit gibt es nie, der Aufwand wird für den Angreifer nur irgendwann unverhältnismäßig. In diesem spezifischen Fall könnte er sich dagegen schützen indem er den Fingerprint des Serverzertifikates bzw. eines eigenen CAs (was sich dann nicht mehr ändern darf) im Client direkt überprüft (hardcoded), das macht MITM dann unmöglich bis die Verschlüsslung geknackt wird. Absolute Sicherheit für Client und Server vorrausgesetzt und das ist unmöglich (abgesehen davon muss der Client auch erstmal an den richtigen Fingerprint kommen). Und selbst wenn man den perfekten Schlüsselaustausch hinbekommen könnte, besteht immernoch das Problem das es warscheinlich irgendwelche Lücken in der Software und der Verschlüsslung gibt (vom benötigten Zufall will ich jetzt nicht auch noch anfangen^^).
tl;dr: Irgendwie muss immer etwas über einen potentiell unsicheren Kanal ausgetauscht werden, seien es nun jedes Mal direkt die Schlüssel oder eben ein einziges Mal das Clientprogramm mit dem Fingerprint.