Dokumentation UKSwitch-SmServer

GPIO-Ausgänge nutzen

Ursprünglich wurde SmServer zum Schalten von GPIOs auf einem Raspberry Pi erschaffen. WLan-Module und ExternSm-Objekte kamen später.

Um GPIOs nutzen zu können, braucht man standardmäßig Root-Rechte. SmServer soll aber nicht als root laufen. Deshalb sind einmalig folgende Schritte notwendig:

1. sudo addgroup gpio

2. sudo adduser ukswitch gpio

3. Man erstellt mit Root-Rechten die Datei /etc/systemd/system/gpiochip.service mit folgendem Inhalt:

   
   [Unit]
   Description=GPIO-Chips für Gruppe gpio freigeben
   
   [Service]
   Type=oneshot
   RemainAfterExit=yes
   Nice=0
   User=root
   ExecStartPre=/usr/bin/chown root:gpio /dev/gpiochip0
   ExecStart=/usr/bin/chmod 0660 /dev/gpiochip0
   
   [Install]
   WantedBy=multi-user.target
                

4. sudo systemctl enable gpiochip.service

5. sudo systemctl start gpiochip.service

Wenn sich nun der Benutzer ukswitch neu anmeldet, darf er GPIOs nutzen. Da der Dienst (service) aktiviert ist, gilt das auch nach einem neuen Starten des Systems.

Was noch zu sagen wäre: Bis Debian 12 (bookworm) benötigt SmServer das Packet libgpiod2 , um auf GPIOs zugreifen zu können. In Debian 13 (trixie) wurde libgpiod2 durch libgpiod3 ersetzt. Das bedeutete für mich, dass ich die Konfiguration eines GPIO-Ausganges komplett umschreiben und aufwendige Tests (Stabilität, Geschwindigkeit, Langlebigkeit) durchführen musste. Deshalb gibt es nun SmServer Version 2 und SmServer Version 3.

Was ist synchrone Verschlüsselung?

Synchron bedeutet, das Sender und Empfänger den gleichen Schlüssel zum Kodieren und Dekodieren benutzen.

Bei einer "asynchron" Verschlüsselung gibt es 2 Schlüssel: privat und öffentlich. Was mit dem privaten Schlüssel kodiert wurde, kann nur mit dem öffentlichen Schlüssel dekodiert werden. Was mit dem öffentlichen Schlüssel kodiert wurde, kann nur mit dem privaten Schlüssel dekodiert werden.

Asynchrone Verschlüsselungen brauchen CPU-Leistung Faktor 10 und mehr gegenüber synchrone Verschlüsselungen. Deshalb nutzt man sie nur bei wenig Datenmengen.

Dehalb werden heute bisynchrone Verschlüsselungen genutzt. Beispiel: Du gibtst in deinem Browser https://www.ukswitch.de ein, dann passiert folgendes:

1. Dein Browser verbindet sich mit der Zertifizierungstelle und erhält den öffentlichen Schlüssel von www.ukswitch.de.
2. Dein Browser erstellt eine Verbindung zu www.ukswitch.de und prüft Gültigkeit und ob der Schlüssel zur Adresse passt.
3. Dein Browser sagt zu meinem Webserver asynchron verschlüsselt "Hallo ich will was."
4. Darauf hin wird per Zufall ein Schlüssel für eine synchrone Verschlüsselung ausgetauscht.
5. Dein Browser sendet nun synchron verschlüsselt zu meinem Server "GET index.html HTTP/1.1".
6. Mein Webserver antwortet synchron verschlüsselt "Status: 200 ok" und schickt die Datei index.html synchron verschlüsselt hinterher.

Im Endeffekt wird doch die Datenmenge synchron verschlüsselt übertragen. Und brauchen wir diese Prozedur für "Stehlampe on"?

Problem Schlüsselaustausch

Die Stärke der Verschlüsselung liegt nicht im Verfahren des Kodierens und Dekodirends sondern im Schlüssel selbst.

Deshalb sollte ein Schlüssel folgende Eigenschaften haben:

1. mindestens 12 Zeichen lang
2. Großbuchstaben und Kleinbuchstaben
3. Zahlen und Sonderzeichen
4. Er sollte allerdings nicht mit # beginnen, da sonst Clients den Schlüssel als Kommentar werten.

Der Schlüssel wird in der Datei /home/ukswitch/.smserver/key.txt hinterlegt. Auf diese Datei sollte auch nur der Benutzer ukswitch zugreifen können.

sudo chown ukswitch /home/ukswitch/.smserver/key.txt && sudo chmod 0600 /home/ukswitch/.smserver/key.txt

Beispiel für einen guten Schlüssel: s5H76MZopuwg06f6wy/';cMnZ5C:g-zN#;,eZGi

Clients benötigen diesen Schlüssel, um mit SmServer kommunizieren zu können. Doch diesen Salat kann sich doch keiner merken. Das ist ja Sinn und Zweck der Sache.

Und hier liegt die Schwäche einer synchronen Verschlüsselung. Deshalb benötigt man gesunden Menschenverstand und Vertrauen.

Wie ihr den Schlüssel nicht übertragen dürft, ansonsten könnt ihr auch den Autoschlüssel auf dem Dach des Autos ablegen:

• Mittels WhatsApp, Telegram, Facebook, etc. Oder wisst ihr genau, was die ganzen Server machen?
• Mittels SMS.
• Mittels nicht von dir verschlüsselter Mail. Auch wenn deine Mails angeblich verschlüsselt sind, kann der Provider sie lesen.

Und wie kann man den Schlüssel weiter geben? Ganz einfach: persönlich.

• Zettel und Stift
• USB-Stick, wenn man bei der Übergabe dabei ist
• Asynchron verschlüsselte Mails, dazu benötigtst du den öffentlichen Schlüssel des Empfängers.

Der Key ist einfach gesagt der Haustürschlüssel. Und so muss man damit umgehen.

Grundkonfiguration des SmServers

Der grundlegende Syntax der Datei config.txt sieht wie folgt aus:

# config.txt - Konfiguration für smserver

# Kommentare können mit # angelegt werden. smserver ignoriert dann alle Zeichen bis zum Zeilenende.
# Leerzeichen in Namen und Beschreibungen müssen als " " (HTML-Leerzeichen) notiert werden, sonst entstehen Fehler beim Parsen der Datei.

<server>
  # --------- Attribute des Servers ----------

  # Name des Servers, hat derzeit keinen Einfluss auf den Betrieb  
  ServerName smserver1

  # Kurze Beschreibung zum SmServer, hat derzeit auch keinen Einfluss
  ServerDescription SmServer&nbsp;zu&nbsp;Hause

  # Port für unverschlüsselte TCP- und UDP-Verbindungen aus dem Heimnetz
  ListenPort 6961

  # Port für verschlüsselte TCP-Verbindungen
  EListenPort 6963

  # Breiten- und Längengrade sind für die Berechnung der Sonnenzeiten notwendig,
  # werden aber niemals übermittelt.
  Lat 50.84326
  Lon 11.01972

  # --- Hier folgen die angelegten Objekte. ---

</server>

Die gesamte Konfiguration befindet sich im Bereich von <server> bis </server>.

Die Attribute ServerName (Name des Servers) und ServerDescription (Beschreibung des Servers) werden zwar gelesen und gesetzt, haben aber auf den weiteren Betrieb keinen Einfluss. Der Server wird mittels IP-Adresse bzw. DNS-Name angesprochen.

Geografische Koordinaten werden als Dezimalgrad angegeben. Hier ist nicht die Position des Servers gemeint sondern die mitllere Position der zu schaltenden Objekte. Der Server kann sich z.Bsp. in München befinden, die zu schaltenden Objekte im Ferienhaus an der Nordsee. Also sollte die Position des Ferienhauses angegeben werden.

Lat steht für Latitude (Breitengrad). Breitengrade nördlich des Äquators werden positiv angegeben, südliche negativ. Lon steht für Longitude (Längengrad). Längengrade östlich vom Greenwich-Null-Meridian werden positiv angegeben, westliche negativ.

WLan-Module anlegen

# config.txt - Konfiguration für smserver
<server>
  ServerName smserver1
  ServerDescription SmServer&nbsp;zu&nbsp;Hause
  ListenPort 6961
  EListenPort 6963
  Lat 50.84326 Lon 11.01972

  # --- WLan-Module ---
  <wlanmodule>
    WmName Stehlampe
    WmDescription Stehlampe&nbsp;im&nbsp;Wohnzimmer
    WmAddress fd00::cf8:e0fa:fe43:6236
    WmPort 49112
    Device 0
    pictureFileOn /bilder/smarthome/lichtAn.png
    pictureFileOff /bilder/smarthome/lichtAus.png
    smooth
    attacksafe
    nowontime 7200
    pumpperformance 0
    pumpflowrate 0
    power 6.4
  </wlanmodule>

</server>

Für jedes WLan-Modul wird ein Bereich von <wlanmodule> bis </wlanmodule> angelegt. Die Attribute im Einzelnen:

Hinweise zu WLan-Module

WLan-Module sollten nur in vertrauenswürdigen Heimnetzten eingesetzt werden. Die Kommunikation mit ihnen erfolgt unverschlüsselt.

Ich empfehle sogar, in den Router-Einstellungen WLan-Module den Zugang zum Internet zu verbieten (Kindersicherung).

Hat man ein WLan-Modul in Betrieb genommen, erstellt es eine Heimnetz-Webseite, wo ihr IP-Adressen, Port und Hostname erfahren könnt. Es erstellt sogar ein Textfeld mit einer Beispielkonfiguration, was man mit Kopieren und Einfügen in die Datei config.txt einfügen und anpassen kann.

Als WmAddress empfehle ich, die moderne IPV6-Heimnetzadresse zu nutzen. Damit wären theoretisch 2 hoch 64 (das sind mehr als 18.446.744.073.700.000.000 Stück, also über 18 Trillionen) WLan-Module minus ein paar Heimnetzgeräte möglich. Das schafft SmServer natürlich nicht und der Router wahrscheinlich auch nicht. Benutzt man IPV4-Adressen oder Hostnames, so stehen nur etwa 240 Möglichkeiten gegenüber. Das Ansprechen eines WLan-Modules mittels IP-Adresse ist immer schneller als das Ansprechen mittels Hostname, da der Router den Hostname nicht in eine IP-Adresse umgewandeln muss.

Wie wird eine Schaltung an einem WLan-Modul durchgefürt?

Auf dem WLan-Modul befindet sich ein Server, der bis zu 8 TCP-Verbindungen annehmen kann, deren Anweisungen aber nacheinander abgearbeitet werden. Schließlich gibt es nur eine CPU, die maximal 160 MHz Betriebsfrequenz hat.

Wenn SmServer auf ein WLan-Modul zugreft, agiert er selber als Client. Er erstellt eine Verbindung zum Server des WLan-Moduls, sendet die Anfrage und empfängt die Antwort. SmServer hält die Verbindung zum WLan-Modul, falls noch weitere Anweisungen folgen.

Im SmServer läuft ein Thread, der, wenn 8 Minuten kein Datenverkehr mehr war, die Verbindung zum WLan-Modul schließt.

Einen GPIO-Ausgang anlegen

Wie schon gesagt wurde dieser Server ursprünglich für die Nutzung von GPIOs an einem Raspberry Pi erschaffen.

Die Nutzung von GPIO-Ausgängen hat aber ein Nachteil. GPIOs geben ein Signal mit 3,3V und max. 10mA aus, das entspricht etwa 0,03W. Deshalb ist es notwendig, dieses Signal mittels Solid-State-Relay oder Optokoppler auf die gewünscht Schaltleistung zu verstärken. An Entwicklung entsprechender vorgertigten Modulen dafür arbeiten wir derzeit. Aber eine Elektroinstallation lässt sich nicht umgehen.

Der Vorteil von GPIO-Ausgängen liegt in der sehr schnellen Zugreifbarkeit bei wenig CPU-Last, so sind mehrere tausend Schaltungen pro Sekunde möglich.

Folgende 14 GPIOs können vom SmServer an einem Raspberry Pi genutzt werden:

• GPIO 5, Anschluss 29
• GPIO 6, Anschluss 31
• GPIO 12, Anschluss 32
• GPIO 13, Anschluss 33
• GPIO 16, Anschluss 36
• GPIO 17, Anschluss 11
• GPIO 18, Anschluss 12
• GPIO 20, Anschluss 38
• GPIO 21, Anschluss 40
• GPIO 22, Anschluss 15
• GPIO 24, Anschluss 18
• GPIO 25, Anschluss 22
• GPIO 26, Anschluss 37
• GPIO 27, Anschluss 13

Wichtig: GPIO-Ausgänge dürfen in der config.txt erst nach den WLan-Modulen und ExternSm-Objekten angelegt werden. Irgendwie scheint libgpiod bei der Initialisierung ein Problem mit anderen Objekten zu haben, die eine Netzwerkverbindung benutzen.

Um einen GPIO-Ausgang in der config.txt anzulegen, notiert man folgendes:

# config.txt - Konfiguration für smserver
<server>
  ServerName smserver1
  ServerDescription SmServer&nbsp;zu&nbsp;Hause
  ListenPort 6961
  EListenPort 6963
  Lat 50.84326 Lon 11.01972

  # --- GPIO-Ausgänge ---
  <output>
    OutputName Fernseher
    OutputDescription Fernseher&nbsp;GPIO&nbsp;17
    OutputGpioNumber 17
    pictureFileOn /bilder/smarthome/green_on.png
    pictureFileOff /bilder/smarthome/green_off.png
    smooth
    attacksafe
    nowontime 0
    pumpperformance 0
    pumpflowrate 0
    power 110
  </output>

</server>

Die Attribute eines GPIO-Ausganges werdem im Bereich von <output> bis </output> notiert.

Soll ich alle Attribute nochmal erklären? OK ich mache es, ist ja nur Text:

ExternSm-Objekt anlegen

ExternSm-Objekte, sind Objekte, die auf anderen SmServern angelegt wurden. Daei spielt es keine Rolle, ob sie dort als WLan-Modul, GPIO-Output oder gar auch als ExternSm-Objekt angelegt wurden.

Das ist alles nicht ganz ohne, deshalb spreche ich jetzt "dieser SmServer" und "andere SmServer".

Gedacht ist die ganze Sache für Zugreifbarkeit auf ein Ferienhaus oder einer entfernten Werkstatt.

Die Datenübertragung erfolgt immer synchron verschlüsselt mittels Schlüssel des anderen SmServers. Dieser SmServer agiert dabei als Client.

Anlegen eines ExternSm-Ojektes:

# config.txt - Konfiguration für smserver
<server>
  ServerName smserver1
  ServerDescription SmServer&nbsp;zu&nbsp;Hause
  ListenPort 6961
  EListenPort 6963
  Lat 50.84326 Lon 11.01972

# ----- ExternSmObkekte -----
 <externsm>
    SmName Heizung&nbsp;Ferienhaus
    EsmName Heizung
    SmDescription Heizung&nbsp;im&nbsp;Ferienhaus
    SmAddress ferienhaus.ukswitch.de
    SmPort 6963
    SmKey n*v*sDICb:1?Z*120QmiaZ<w$ksDLnaKK6d*
    pictureFileOn /bilder/smarthome/lichtAn.png
    pictureFileOff /bilder/smarthome/lichtAus.png
    attacksafe
    nowontime 0
  </externsm>

</server>

Die Attribute:

Das Attribut smooth (sanft schalten) gibt es hier nicht, dieser kann nur an dem SmServer definiert werden, der das Engerät direkt anspricht.

Pseudo-Objekt anlegen

Ein Pseudo-Objekt ist ein Objekt, dass ein- aus- und umgeschaltet werden kann. Aber es passiert nichts. Es ist ein virtuelles Objekt.

Im folgendenden Absatz werden Links beschrieben, wie man Geräteschaltungen miteinander verknüpfen kann. Aber sind diese Verknüpfungen auch immer wirklich gewünscht?

Wenn "nein" kann man ein Pseudo-Objekt nutzen, wo diese Verknüpfung(en) anschließend angelegt werden. So bleiben Geräte einzeln schaltbar oder mittels diesem Objekt zusammen schaltbar.

Bei Pseudo-Objekten ist grundsätzlich der Attackenschutz gesetzt. Das Attribut power beträgt 0,0, da ein Pseudo-Objekt keine elektrische Leistungsaufnahme hat.

Beispiel für das Anlegen eines Pseudo-Objektes:

  # ----- Pseudo-Objekte -----
  <pseudo>
    PsName Wohnzimmer
    PsDescription schaltet&nbsp;Schreibtischlampe&nbsp;und&nbsp;Stehlampe
    pictureFileOn /bilder/smarthome/lichtAn.png
    pictureFileOff /bilder/smarthome/lichtAus.png
    nowontime 0
  </pseudo>

Die Attribute im Einzelnen:

Links, Verknüpfungen

Links bzw. Verknüpfungen sind Verkettungen von Schaltungen. Sie sollen das Leben vereinfachen und helfen, Energie zu sparen.

Allerdings sollte man vorher in Ruhe überlegen, wie man sie anlegt. Verknüpfungen werden immer beim Schalten eines Gerätes ausgeführt. Da kann es auch nerven, wenn ein zweites Gerät immer mit geschaltet wird..

Da Verknüpfungen auch so angelegt werden können, dass man z.Bsp. 12 Geräte gleichzeitig eingeschaltet werden können, erfolgt vor jeden folgenden Schaltung ein Warten von 12ms, um Stromspitzen zu vermeiden.

Bei einer Verknüpfung werden 2 Objekte angegeben, das "ausgeführte Objekt" und das "auszuführende Objekt". Beide Objekte werden mit dem Namen angesprochen, der in den vorher angelegten Objekten definiert wurde. Leerzeichen in diesen Namen müssen leider wieder als &nbsp; (HTML-Leerzeichen) notiert werden. Beispiele:

# config.txt - Konfiguration für smserver
<server>
  ServerName smserver1
  ServerDescription SmServer&nbsp;zu&nbsp;Hause
  ListenPort 6961
  EListenPort 6963
  Lat 50.84326 Lon 11.01972

# ----- Wlan-Module -----
# ----- ExternSm-Obkekte -----
# ----- GPIO-Outputs -----
# ----- Pseudo-Objekte -----

  # ------- Links, Verknüpfungen -------
  <links>
    when Stehlampe 1 Schreibtischlampe off
    when Schreibtischlampe 1 Stehlampe off
    when Fernseher 1 Audioanlage on
    when Fernseher 0 Audioanlage off
  </links>

</server>

Alle Verknüpfungen werden im Bereich von <links> bis </links> notiert. Dieser Bereich wird nur einmal angelegt.

Der Syntax ist eigentlich sehr einfach:

when "ausgeführtes Objekt" Zustand "auszuführendes Objekt" Komanndo

Dabei bedeuten:

Die ersten zwei Verknüpfungen in diesm Beispiel bedeuten, dass nur die Stehlampe oder die Schreibtischlampe eingeschaltet sein kann. Die nächsten zwei Verknüpfungen sorgen dafür, dass immer, wenn der Fernseher ein- bzw. ausgeschaltet wird, die Audioanlage mit dem tollen Sound mit ein- bzw. ausgeschaltet wird.

  when Objekt1 1 Objekt2 on
  when Objekt2 1 Objekt3 on
  when Objekt3 1 Objekt1 on

Hinweise zu einigen Attributen

Namen

Objektnamen dürfen nur einmal vergeben werden, sonst klappt das nicht mit dem Zugriff auf das gewünschte Objekt.

Besitzen z.Bsp. ein WLan-Modul, ein GPIO-Ausgang und ein ExternSm-Objekt den gleichen Namen, werden alle Objekte von den Clients auch angezeigt. Möchte man nun eins dieser Objekte einschalten, so wird immer das WLan-Modul geschaltet, da es SmServer zuerst findet.

Werden viele Objekte im SmServer angelegt, muss man etwas kreativ sein. Auf der einen Seite dürfen sich Namen nicht wiederholen, auf der anderen Seite sollten sie eindeutig zu einem Endgerät passen. Man will sich doch nicht viel merken müssen.

attacksafe

Dieses Attribut schützt ein Endgerät vor ungewolltem häufigen Schalten und kann standardmäßig immer notiert werden. Damit wartet SmServer vor dem Einschalten eine Zeit von mindestens 3s bis nach dem letzten Ausschalten des Objektes. Somit sind noch nicht mal 20 Ein- und Asschaltungen pro Minute möglich.

Soll ein Objekt von Clients sehr häufig geschaltet werden (z.Bsp. mehrmals pro Sekunde), darf dieses Attribut nicht notiert sein, oder man kommentiert es mit # aus.

smooth

Dieses Attribut schützt die Feinsicherungen in der Hardware vor ungewolltem Auslösen beim Ansteuern von Geräten mit Netzteil. Somit beträgt die Zeit für das Ein- und Ausschalten jeweils etwa 0,4s.

Für häufiges Schalten (mehrmals pro Sekunde) darf dieses Attribut nicht aktiv sein.

Beispiel: 230V-LED-Lampen besitzen ein Netzteil. Das WLan-Modul kann 460W schalten, LED-Glühlampe braucht 12W elektrische Leistung. Alles gut? Schaltet man diese LED-Glühlampe zu einem ungüstigen Zeitpunkt ein, kann sie 1200W und mehr elektrische Leistung kurzzeitig ziehen. Feinsicherung ist nun kaputt.

Deshalb eignen sich 230V-LED-Glühlampen nicht für sehr schnelle Schaltungen.

power

Mit diesem Attribut wird eine durchschnittlich elektrische Leistungsaufnahme angegeben, damit SmServer daraus einen grob geschätzen Energieverbrauch errechnen kann. Da der errechnete Energieverbrauch nur grob geschätzt ist, kann er nicht als Nachweis z.Bsp. für Klagen oder vor Gericht verwendet werden.

Mit dem errechneten Energieverbrauch soll der Anwender ein Gefühl bekommen, welches Gerät etwa wieviel an elektrischer Energie verbraucht.

Bei kurzen Einschaltzeiten entstehen hier größere Abweichungen, da sich Geräte beim Aus- und Einschalten anders verhalten, siehe eben 230V-LED-Glühlampe.

Herstellerangaben zu benötigten elektrischen Leistungen von Geräten werden meist im Labor unter idealen Bedingungen ermittelt und vielleicht abgrundet an den Kunden weitergegeben. Dabei werden die Geräte vor den Messungen schon einige Stunden laufen gelassen. Nutzt man diese Angaben für dieses Attribut, empfehle ich ca. 10% aufzuschlagen.

Wie bekommt man das relativ genau hin? Beispiel Kühlschrank im Ferienhaus

1. Man installiert vorher ein Enrgiemessgerät zwischen Stromversorgung und Kühlschrank im Fereinhaus, welches selbst elektrische Energie benötigt.
2. Wir wollen vom 2. Mai bis 18. Mai ins Ferienhaus. Die Frau hat schon Wurst und Gemüse eingekauft. Per SmServer schalte ich das den Kühlschrank am 1. Mai 18 Uhr ein, damit wir sofot die Lebensmittel in den Kühlschrank legen können, Energiemessung läuft.
3. Am Abreisetag, alles ist schon im Auto ordentlich verladen, schalte ich den Kühlschrank per SmServer aus.
4. Das Energiemessgerät hat eine durchschnittlich elektrische Leistungsaufnahme von 24,3276W errechnet, die ich bei power eintragen werde.

Jetzt habe ich eine zuverlässige Energieangabe, oder doch nicht? Dazu müssten im Folgejahr folgende Bedingungen vorliegen:

1. Die Frau kauft exakt auf das Gramm genau die gleichen Lebensmittel, Kühlschrank wird am 1. Mai exakt 18 Uhr eingeschaltet.
2. Ab dieser Zeit müssen Temperatur und Luftfeuchtigkeit bis zum Abreisetag exakt den Werten des Vorjahres sein, das geht nicht.
3. Alle Lebensmittel, die im Vorjahr in den Kühlschrank getan oder herausgenommen wurden, müssen dieses Jahr die gleiche Masse, den gleichen Wasseranteil, die gleiche Temperatur und zur selben Zeit hinein- bzw. herausgenommen werden. Das wird ja ein schöner Urlaub.
4. Die Anlage des Kühlschranks muss exakt dem des Vorjahres sein. Die Kühlrippen sind genauso verschmutzt, das Kältemittel besitzt noch exakt die gleichen Eigenschaften, Mechanik im Motor und Kompressor ebenso.

Ich hoffe, ihr seht, worauf ich hinaus will und warum ich dieses Attribut als grob geschätzt einstufe.

Sicherheit einer Verschlüsselung

Die Sicherheit einer Verschlüsselung liegt nicht im Verfahren, im Gegenteil, denn Sender und Empfänger müssen das Verfahren kennen.

Die Sicherheit liegt nur im Schlüssel selbst. Deshalb sollte ein Schlüssel folgende Eigenschaften haben:

• Derzeit mindestens 12 Zeichen lang, länger ist expotentiell besser.
• Großbuchstaben
• Kleinbuchstaben
• Zahlen
• Sonderzeichen
• Niemals Wortlaute aus privatem oder geschäftlichem Umfeld

Es laufen irgendwo auf der Welt laufen tausende Programme, die versuchen, Passwörter und Schlüssel zu knacken. Hierfür werden sogar GPUs (CPUs von Grafikkarten) eingesetzt, weil die das schneller können. Man probiert anfangs komplette Wörterbücher mit Zahlenkombinationen durch. Um 123456 zu knacken, brauchen die weniger als 0,1 Sekunden. Bei Nissan385 könnte es schon 2 bis 6 Sekunden dauern. Haltet ihr euch an die obrigen Angaben, dauert es etwa 100 Jahre, da jeder Punkt expotentiell mehr Möglichkeiten darstellt.

Problem Schlüsselaustausch

Bei synchronen Verschlüsselungen besteht grundsätzlich das Problem des Weitergebens des Schlüssels. Zu viele können mitleseen. Der Schlüssel darf niemals veröffentlicht werden.

Deshalb gelten folgende Regeln für die Weitergabe des Schlüssels:

• Niemals per Social-Media wie WhatsApp, Telegram, Facebook u.a.
• Niemals auf eigener Webseite ausgeben.
• Per Mail nur, wenn die Nachrichten asynchron (mittels GPG) verschlüsselt werden, machen heute leider nur sehr wenige Menschen.
• Zettel und Stift, persönliche Übergabe, ok, da darf es auch ein USB-Stick sein.