Erst einmal zum Passwort.
Das Passwort ist ja beiden Seiten bekannt, es muss nur sichergestellt werden, das man die Übertragung nicht nutzen kann um das Passwort wieder herzustellen. Hier eignen sich Hashingalgorithmen, um Das Passwort in eine eindeutige, aber nicht rekonstruierbare Form zu bringen. Die Gegenseite macht das selbe und vergleicht dann die erzeugten Zeichenketten miteinander. Sind sie identisch, muss aus auch das Passwort identisch gewesen sein.
Das Problem ist natürlich das ein Passwort meist aus lesbaren Zeichen besteht, recht kurz ist und häufig auch einen "Sinn" hat. Das macht das entschlüsseln einfacher. (Gerade MD5 ist da Anfällig weil man sehr effiziente Rainbowtables erstellen kann, die schon recht früh nicht darstellbare Zeichen ausschließen können und die Entschlüsselung damit sehr beschleunigen)
Hier kommt das "Salt" ins Spiel. Das ist eine zufällige Zeichenfolge, die auf das Passwort angewendet wird. Dadurch wird das Länger und komplizierter. Im Idealfall wird auch das Specktrum der verwendeten Zeichen Größer. Das Salt kann man einfach als Klartext mitschicken. Er dient nur dazu dem erzeugten Hasch eine "Rauschen" mitzugeben, was das entschlüsseln erschwert. (Bei MD5 steht die Zeit zum entschlüsseln in Fakultät zur Länge des Passworts. Wenn man Rainbowtables verwendet. Ein Zeichen mehr kann den unterschied von einem Tag zu einigen Monaten bedeuten. Wenn man das Salt nicht nur anhängt, sondern z.B. per XOR darauf anwendet wird auch die Zeichen Varianz größer und Normale Rainbowtables funktionieren nicht mehr.)

zum verschlüsselten übertragen von Daten.
Die Beste Verschlüsselung ist das XOR mit einer zufälligen Zeichenfolge, welche die selbe Länge hat wie die zu verschlüsselten Daten. Das Ergebnis ist eine Zufällig wirkende Zeichenfolge, die erst wider Sinn Ergibt wenn noch einmal Xor mit zufälligen Zeichenfolge darauf angewendet wird. Das Problem ist nun, dass man die Zufallsfolge nicht so einfach weitergeben kann. Zum einen ist das eine nicht geringe Menge an Daten, zum anderen Muss man sicherstellen das kein anderer diese Folge zu sehen bekommt.
Die Länge kann man reduzieren wenn man Pseudozufallsgeneratoren verwendet. Das sind Algorithmen, die eine Serie von Werten ausgeben, die Zufällig erscheinen. Der Nächtse Wert basiert aber immer auf dem letzten Wert der aus dem Algorithmus kam. Einerseits bedeutet es, man kann über einen Anfangswert "Seed" bestimmen welche Folge generiert wird zum anderen lässt sich aus einer genügend großen Folge der "Seed" rekonstruieren. Die Güte eines Algorithmus bestimmt sich nach welcher Anzahl von Werten er sich wiederholt, wie viele Werte man braucht um den Seed zu rekonstruieren und wie zufällig die Werte erscheinen.
Mit einem guten Pseudozufallsgenerator braucht nur noch der Seed beiden Seiten bekannt zu sein um Daten verschlüsselt übertragen zu können. Man kann natürlich das Passwort als Seed benutzen, was aber problematisch ist da ein Passwort wie schon ausgeführt nicht sehr zufällig ist. Wenn die Daten nicht extrem Brisant sind und deren Gültigkeit recht kurz ist. Kann das schon reichen.

Besser ist es aber den Seed möglichst "Echt-Zufällig" zu wählen und verschlüsselt zu übertragen. Hier kommt die Asymmetrische Verschlüsselung ins Spiel. XOR ist eine Symmetrische Verschlüsslung da ein Wert zum ver- und entschlüsseln reicht. Das wichtige an asymmetrischen Verschlüsselungen ist nun, das man ein Wert hat mit dem man nur Verschlüsseln kann, den "Public Key" und einen mit dem man nur Entschlüsseln kann, den "Private Key". Damit kann man den Public Key ohne Probleme weiter geben. Dieser wird verwendet um das Seed für den Zufallsgenerator zu übertragen, mit dem alle weiteren Daten verschlüsselt werden.
Asymetrische Verschlüsselungen Basieren darauf was die Umkehrung einer mathematischen Operation schwerer sein kann als diese selbst. Als Beispiel die Multiplikation zweier Primzahlen. Die Zerlegung des Produkts dauert um ein vielfaches länger als die Multplikation. Wählt man sehr große Primzahlen wird es noch schwerer. Die Idee ist aus dem Produkt Wertepaare zu erzeugen, die sich gegenseitig so ergänzen, dass eine Mathematische Operation vom einen nur vom anderen umgekehrt werden kann. (Siehe dazu z.b das RSA Verfahren)

Das wären die Grundzüge einer verschlüsselten Kommunikation. Nun gibt es noch andere Angriffsmöglichkeiten als direkt auf die verschlüsselten Daten. z.B. ein "Man in the middle" Angriff. Dazu gibt sich ein System als Ziel einer Kommunikation aus und stellt sich für das eigentliche Ziel als Partner dar. Es baut auf beiden Seiten eine Verbindung auf und reicht die Daten durch. Auf dem System selber liegen die Daten somit Unverschlüsselt vor. Gegen so etwas kann man sich schützen. z.B indem man vorher über eine definitiv sichere Verbindung einen Öffentlichen Schlüssel überträgt (Eingabe per "Hand"). Oder beide Seiten bauen eine Verbindung zu einem Dritten auf der beide Seiten identifizieren kann.
SSH und SSL gehen solche Wege. Wenn man das Rad nicht neu erfinden will, sollte man darauf zurück greifen.


Ein Beispiel was schlechte Verschlüsselung ist:
Die Daten wurden von einem Nutzer A verschlüsselt und an einen Nutzer B gegeben der sie an einen Server weitergab welcher die Daten entschlüsselte und einen Teil davon für den Nutzer B anzeigte. Das ist soweit zwar nicht Ideal aber einfach zu implementieren. Nun kommt der Hammer. Zum verschlüsseln der Daten wurde das Zugangspasswort des Nutzers A und XOR verwendet. Wenn das Passwort zu kurz war wurde es so lange an sich selber angehängt bist es passte. Aus den für den Nutzer B angezeigten Daten konnte genügend des verschlüsselten Strings rekonstruiert werden, um daraus das Passwort des Nutzers A zu rekonstruieren, wenn es kürzer als 10 Zeichen war!