OTT - verschlüsselte zuschaltbare iTELEX Übertragung

Vorschläge und Wünsche für zukünftige Features des i-Telex-Systems sowie Fachforum für Entwickler.
Benutzeravatar

FredSonnenrein
Developer
Developer
Beiträge: 724
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: OTT - verschlüsselte zuschaltbare iTELEX Übertragung

#41

Beitrag von FredSonnenrein » Do 14. Sep 2017, 10:38

So wie einst die "Haus-Konferenzschaltung" mit Telefonen. Einfach ILLEGAL parallel geschaltet. Bei TW39 ist Reihenschaltung natürlich korrekt. Schön dass es einfach so funktioniert. Zwei Fernschaltgeräte?
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 8579924 (T100s) oder 781272 (T100) oder 792911 (T68d)


Helge

Re: OTT - verschlüsselte zuschaltbare iTELEX Übertragung

#42

Beitrag von Helge » Do 14. Sep 2017, 10:58

Nur ein FSG. Der T100 hat ja keins, im Wesentlichen den T100 innen im T68d an den Brücken eingeschaltet. Mit nem Kurzschluß-Schalter, wenn
man keinen Doppeldruck wünscht oder der T100 nicht da ist. Der T100 hat einen mech. Abschalter (Standleitungsmaschine). War gar nicht schlecht. Nachteil war nur, dass man im Schreiben den T100 nicht abschalten kann, weil der nach Einlegen des Kurzschliessers rattert bis der Ausschalter kommt.

Das hat gut geklappt, auch der Empfang war problemlos, wenn man den Schalter dringelassen hat. Es kommt ja immer das Datum und das reicht
locker, dass es nicht zu falschen Zeichen kommt bis der T100 hochgelaufen ist.

Benutzeravatar

Topic author
ulbrichf
Rank 12
Rank 12
Beiträge: 570
Registriert: Sa 4. Jun 2016, 20:54
Wohnort: Grefrath
Hauptanschluß: 92158 ulbrichf d

Re: OTT - verschlüsselte zuschaltbare iTELEX Übertragung

#43

Beitrag von ulbrichf » Mo 8. Jan 2018, 20:58

Ein Versuche Buchstabenkolonnen zufällig zu erzeugen, um daraus einen Schlüsselstreifen zu bauen.
#!/usr/bin/python
# -*- coding: utf-8 -*-
#***********************************************************
# Programm : ott_keys.py   (BETA)
# Autor    : Frank Ulbrich
# Datum    : 04.01.2018
#***********************************************************
version = "0.2"
# Python 2.7.12
#
# CREATING RANDOM OTT TAPE

# import some libraries
import random
import sys
import time
import datetime
import logging
from platform import python_version

# Logfile schreiben ###################################
# create a file handler
logger = logging.getLogger("socks_client")
logger.setLevel(logging.DEBUG)
#create file handler
handler = logging.FileHandler("ott_keys.log")
handler.setLevel(logging.INFO)
#create file handler
handler = logging.FileHandler("ott_keys.log")
handler.setLevel(logging.DEBUG)
# create a logging format
formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
handler.setFormatter(formatter)
# add the handlers to the logger
logger.addHandler(handler)
logger.info("# Starting Logfile ######################")
logger.info("info")
logger.debug("debug info")
######################################################

#*************************************************************************
# Check systemtime
#*************************************************************************
def timecheck():
    now = datetime.datetime.now()
    nowtime = (now.strftime("%Y-%m-%d %H:%M") + '\r\n')
    #print(nowtime)
    #print("Current year: %d" % now.year)
    #print("Current month: %d" % now.month)
    #print("Current day: %d" % now.day)
    return(nowtime)
#*************************************************************************

        
#*************************************************************************
# Hauptprogramm
#*************************************************************************
def main():
    logger.info("Starting main()")
    print("Python " + python_version())
    print("Softwareversion: "+ version)
    print(timecheck())                            # print systemtime
    
    random.seed()
    zeichenvorrat = [ 'a', 'b', 'c', 'd', 'e', 'f', 'g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z']
    m = 512
    print("Lochstreifen muss mit Transportlochung und 2 BU anfangen.")
    print"Erzeugung von : ",m,"Zeichen."
    for k in range(0,m):
        zeichen = random.choice(zeichenvorrat)
        print(zeichen)
        
    
    print("# Hauptprogramm fertig ##############")
    raw_input("Zum Beenden ENTER Taste druecken")# python 2 needs raw_input
    logger.info("Hauptprogramm fertig ##############")
    sys.exit(1)
    #END  def main()

#*************************************************************************
# Aufruf des Hauptprogramms
#*************************************************************************
if (__name__ == "__main__"):
    main()
NNNN

Gruß
Frank Ulbrich / DO2FU / 92158 ulbrichf d / TeKaDe FS220z (online) / T68D (online) / T1000S (online) / iTELEX FW 781 / TW39PLUS FW 330 / seriell speicher version FW 334 / ED1000 FW 330

Benutzeravatar

Topic author
ulbrichf
Rank 12
Rank 12
Beiträge: 570
Registriert: Sa 4. Jun 2016, 20:54
Wohnort: Grefrath
Hauptanschluß: 92158 ulbrichf d

Re: OTT - verschlüsselte zuschaltbare iTELEX Übertragung

#44

Beitrag von ulbrichf » Mi 10. Jan 2018, 18:17

Ein Schlüsselstreifen, welcher die lesbare Bezeichnung „schl-1“ am Anfang enthält.
Nach BU folgen 512 Zeichen ohne CR,LF.
Der Lochstreifen wurde am T68 mittels einer modifizierten JTERM Fassung gestanzt.
Am Anfand der Dateiübertragung fügt das Terminalprogramm noch ein CRLF vorneweg ein,
was auf dem Lochstreifen noch korrigiert werden muss. Das Verhalten war mir nicht klar
und kann im Screenshot am kurzen Beispiel nachvollzogen werden.
FDF76D56-46E9-4885-8042-6BF28494A2B0.jpeg
6408621F-C30C-4D2C-991B-F139A2D6859F.jpeg
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
NNNN

Gruß
Frank Ulbrich / DO2FU / 92158 ulbrichf d / TeKaDe FS220z (online) / T68D (online) / T1000S (online) / iTELEX FW 781 / TW39PLUS FW 330 / seriell speicher version FW 334 / ED1000 FW 330

Benutzeravatar

380170JFK
Rank 9
Rank 9
Beiträge: 222
Registriert: Do 2. Jun 2016, 16:06
Wohnort: 38017 Mezzolombardo IT
Hauptanschluß: 380170 johannes it
Kontaktdaten:

Re: OTT - verschlüsselte zuschaltbare iTELEX Übertragung

#45

Beitrag von 380170JFK » Mi 10. Jan 2018, 19:27

Hallo Frank

Die geänderte Version bezieht sich wegen die fehlenden CR und LF NUR auf das Senden mit die Option "SendFile" da wurden alle CR-LF entfernt. ^^
Ich bin davon ausgegangen das Du eine CR-LF Lose Datei senden möchtest. :o

Wenn Du aber die "Human Readables" verwendest dann sind doch immer noch CR-LF vorhanden um die "Lesbare" Zeichen herzustellen, sowie der CR-LF am Anfang damit es beim FS keinen paper overshoot gibt. Das könnte vielleicht das komische Ergebnis erklären? :/
Johannes i-telex :coffee:
380170 johannes it 24/7 RFT F2000
Daytime:
331343 wefa d RFT F2000
371665 ekovk d RFT F2000
529671 heiss d Siemens T1000
633501 hoesa a Siemens T100s
970012 varint i Olivetti TE550e

Benutzeravatar

Topic author
ulbrichf
Rank 12
Rank 12
Beiträge: 570
Registriert: Sa 4. Jun 2016, 20:54
Wohnort: Grefrath
Hauptanschluß: 92158 ulbrichf d

Re: OTT - verschlüsselte zuschaltbare iTELEX Übertragung

#46

Beitrag von ulbrichf » Mi 10. Jan 2018, 20:36

Hallo Johannes, das modifizierte JTERM funktioniert recht gut für meine Zwecke.
Beim Sender der Datei werden keine CR LF eingebaut, genau richtig.
Scheinbar wird aber vor dem Senden der Textdatei ein CRLF automatisch vorher gesendet, bevor das erste Zeichen aus der Datei übertragen wird.
Wenn ich die kurze Datei mit den 4 Zeichen qeyy beispielsweise mehrfach sende, wird vorher jedesmal ein CRLF gemacht,
daran zu erkennen, daß die Buchstaben nicht hintereinander, sondern in einer neuen Zeile stehen.
Ansonsten danke ich Dir für die Spezialversion, damit kann ich gut testen.

MfG
Frank
NNNN

Gruß
Frank Ulbrich / DO2FU / 92158 ulbrichf d / TeKaDe FS220z (online) / T68D (online) / T1000S (online) / iTELEX FW 781 / TW39PLUS FW 330 / seriell speicher version FW 334 / ED1000 FW 330


SAS
Rank 1
Rank 1
Beiträge: 8
Registriert: Mi 13. Jun 2018, 16:12
Wohnort: Berlin
Hauptanschluß:
Kontaktdaten:

Re: OTT - verschlüsselte zuschaltbare iTELEX Übertragung

#47

Beitrag von SAS » Di 26. Jun 2018, 12:54

Chiffrierung mittels Mischer, (Siemens M-190, Lorenz Mi-544, RFT T-307 DUDEK, Polnisch TGS-1 "DUDEK")

Das Grundprinzip ist sehr einfach, man verküpft die Informationsschritte
des ersten Kanals (z. B. Lochstreifenleser) mit denen des zweiten Kanals
(Fernschreibmaschine, Lochstreifenleser, oder direkt von der Fernschreib-
linie) XOR bitweise und gibt sie auf einen dritten Kanal (Fernschreibma-
schine, Lochstreifenstanzer, Fernschreibkanal) aus.
______________
K1 ->| XOR bzw. |
| Add MOD(2) |--> K3 Chiffrieren - Senden
K2 ->|_____________|
______________
K1 ->| XOR bzw. |
| Add MOD(2) |--> K2 Dechiffrieren - Empfangen
K3 ->|_____________|

Beginnen mit dem ersten Informationsschritt des ersten Kanals
mit dem des zweiten Kanals. Und endet mit dem 5 (6,7,8)
Informationsschritt.

Hier wird nur auf 5 bit Chiffrierung eingegangen.

1 2 3
Standardgemäß ist dann K XOR K = K
n n n

1 3 2
Die Umkehrung ist dann K XOR K = K
n n n

Wie immer keine Regel ohne Ausnahme: Der Mischer der Fa. Siemens M-190
invertiert den Kanal-2. Das bedeutet das die anderen Mischer nicht mit
dem Siemens-Mischer zusammenarbeiten können. Kleiner Trick am Rande
man muß das Ergebnis nur mit 1-1-1-1-1 XOR Verknüpfen, dann erhält man
wieder den Klartext zurück.

Die Chiffrierung der Start-Stopp Schritte ist kontraproduktiv.
Auch hier wieder die Ausnahme: Synchronbetrieb, bei der zwar der
Startschritt chiffriert wird aber der Stopp-Schritt nicht gesendet.
Das erhöht die Übertragungsgeschwindigkeit um 1 1/2 Schritt.

Der erste Kanal, meine Festlegung für die Beschreibung, ist der Zufalls-
schlüssel, der zweite Kanal immer die Klar- bzw. Geheimtexteingabe und
der dritte Kanal der Übertragungskanal - alternativ auch Stanzer oder
als Ausdruck. Der Ausdruck macht aber nur Sinn wenn man eine Code-
wandlung vornimmt. TGS-1 DUDEK als Beispiel.

Es werden alle 2^5 bit, 32 Elemente genutzt. Ergo 0x00 bis 0x1f.
(Bei den elektronischen Fernschreibmaschinen wurden die Stopp-Schritte
etwas Länger da man nicht 1 1/2 sondern schlichtweg 2 Schritte
als Stoppschritt nutzte. Hintergrund ist das man ein 5bit Zeichen
dann so gut in ein Byte packen kann:
Bit 0, 1, 2, 3, 4, 5, 6, 7
Start, 1, 2, 3, 4, 5, Stopp, Stopp.
Bit 7, 6, 5, 4, 3, 2, 1, 0 -> je nach System".

Wie wird jetzt der Zufall erzeugt und wie erhält der Empfänger,
der chiffrierten Fernschreibverbindung, den Schlüssel zur de-
chiffrierung?

Geschichtlich wurde zuerst ein relativ kurzer Schlüssellochstreifen
erzeugt und als Schleife zusammengeklebt.
Vernam propagiertes als erster, laut Literatur.
Nachteil: Bereits nach der zweiten Runde ist es einem Angreifer möglich
den Text zu dechiffrieren. Siehe Literatur Bauer.

Nach dem man erkannt hatte, daß der Mangel ein kurzer Schlüssel ist,
und die Regeln von Kerckhoffs Maxime nicht eingehalten wurde, ist man
dazu übergegangen industriell Zufallsfolgen als Lochstreifen, Lochkarte
und als Zahlen- Buchstaben oder Mischfolgen auf Papier herzustellen.

Die Erzeugung von Zufallsfolgen wurde realisiert mittels Rauschgene-
ratoren oder von radioaktivem Zerfall.
Die einfachste Art der Erzeugung von Zufallsfolgen ist das Schrot-
rauschen von pn-Übergängen von Transistoren auszuwerten.
Dabei ist zu beachten das nicht die laufenden Folgen genutzt werden
sondern auch immer wieder Folgen verworfen werden.
Bei einem Rauschgenerator die das ZfCh und das ZCO verwendete, bei
dem Z-Dioden verwendet wurden, stellte man fest das diese zyklisch
wiederholende Zufallsfolgen erzeugt wurden. Das ZCO verwendete da-
raufhin keine Z-Dioden.

Die Zufallsfolgen die mittels Rauschgeneratoren erzeugt wurden, wurden
z. B. auf Hollerith-Lochkarten gestanzt. Mittels Rechentechnik auf
Wiederholungen, Zyklus, geprüft und nach erfolgreicher Prüfung wurden
die Karten gemischt.
Danach erfolgte die Erzeugung auf Lochstreifen, Lochkarten oder als
Ausdruck auf Papier.

Ausgehen von einer individuellen Verkehrsbeziehung, also Teilnehmer 1
mit Teilnehmer 2, gibt es nur zwei "endlos" lange Lochstreifen.
Die Lochstreifen wurden markiert, bedruckt, so das beide Teilnehmer immer
mit der gleichen "ersten" Folge chiffrieren.

Die Erzeugung mittels "pseudozufälligen Folgen", auch PRG genannt,
sind bereits seite dem zweiten Weltkrieg bekannt: T52 d und weitere.

Moderne Erzeugung des Schlüssels basieren auf mathematische Verfahren.
Der Beweis der Sicherheit ist sehr schwierig, aber wie die Vergangenheit
gezeigt hat, sind auch diese Verfahren nicht unfehlbar - brechbar.

Wie würde eine Realisierung auf dem i-Telex oder TXP aussehen?

Die erste Variante ist eine hardwarebasierende, und nicht ganz preiswerte!

- Man schaltet zwischen Fernschreibmaschine und dem TXP einen Mischer der
o. g. Firmen.
Schwierigkeit: Schlüsselaustausch, Kosten eines originalen Mischer - ab 3kEuro,
der Platzbedarf ist auch nicht ohne, Siehe Lorenz-Mischer.
Und ein nicht unerheblicher zusätzlicher Geräusch-Pegel. Siehe Video DUDEK.

FSM -> DUDEK -> Kanal ..... Kanal -> DUDEK -> FSM

- Man baut sich, bassierend auf Microcontroller, einen Mischer selber. Wieder ein
Zusatzgerät.

Die zweite Variante ist am effektivsten und entspricht auch dem gegenwärtigen
Stand der Technik. Die Erzeugung mittels PRG bei denen vorher ein Schlüssel
vereinbart wurde:

- Es wird eine Zusatzplatine im TXP eingebaut die die Erzeugung der Zufalls-
folgen mittels, derzeit, noch sicheren Verfahren.
Diese Zusatzkarte muß auch die Chiffrierung und Ausgaben realisieren.
- Verwendung von Algorithmen wie DES/AES ( wirklich ?), T-310/50, T-325 oder
auch PGP.
- Wichtig ist die Festlegung welche Arbeitsart der Verbindung man nutzen möchte:
Start-Stopp-Betrieb, Synchronbetrieb und ob man zusätzlich Prüfsummen
mit Übertragen will als Verbindungscheck.

Die einfachste Methode ist die Nutzung eines mathematischen Verfahrens,
bei der vorher über einen "sicheren" Kanal der Verbindungsschlüssel übertragen wird.

Wurde der aktuelle Schlüssel eingestellt ist es erforderlich zu vereinbaren wie
die Chiffrierung gestartet wird. Das kann über Kommandofolgen praktiziert werden.
Z. B. die T-310/50 realisiert das wie folgt:
BBBB -> starte Synchronisationsschlüssel
xyxyxyxyx Folge von Fs-Zeichen.
KKKK -> Ende der Synchronisation und wenn die Folge korrekt ist automatische
Umschaltung in den Chiffrierbetrieb.

Man kann die Chiffrierung aber auch händisch starten in dem der Teilnehmer 1
das Kommando CCCC schickt und wartet das der Teilnemer 2 das bestätigt
z. B. mit KKKK danach drücken beide einen Knopf am Chiffratoreinschub
und danach Schreibt der Teilnehmer 1 den ersten Text.

Allen Prinzipien muß eine Funktion der Erkennung des Gegenschreibens aktiv sein.
Dieser muß alle Chiffriervorgänge beenden.

Benutzeravatar

Topic author
ulbrichf
Rank 12
Rank 12
Beiträge: 570
Registriert: Sa 4. Jun 2016, 20:54
Wohnort: Grefrath
Hauptanschluß: 92158 ulbrichf d

Re: OTT - verschlüsselte zuschaltbare iTELEX Übertragung

#48

Beitrag von ulbrichf » Di 26. Jun 2018, 21:33

Hallo SAS,
Ich glaube Du hast eine engere Beziehung zu der unten genannten Webseite :D kann das sein ? http://scz.bplaced.net/t353.html
Falls Du Jörg bist, vielen Dank für die Seite. Ein Schatz an Wissen.
Ich bin dort sehr häufig am Lesen. Hoffentlich bleibt uns der Schatz lange erhalten.
Ich hatte mir vorgestellt, beim Projekt „einfaches Interface“ hier im Forum , einen Softwaremixer als Funktionsmodell dazu zu programmiere, um die Sache einfach mal ausprobieren zu können. Die Bauteile liegen schon ewig hier in meiner Bastelkiste und setzen Staub an.
Gruß Frank
NNNN

Gruß
Frank Ulbrich / DO2FU / 92158 ulbrichf d / TeKaDe FS220z (online) / T68D (online) / T1000S (online) / iTELEX FW 781 / TW39PLUS FW 330 / seriell speicher version FW 334 / ED1000 FW 330


SAS
Rank 1
Rank 1
Beiträge: 8
Registriert: Mi 13. Jun 2018, 16:12
Wohnort: Berlin
Hauptanschluß:
Kontaktdaten:

Re: OTT - verschlüsselte zuschaltbare iTELEX Übertragung

#49

Beitrag von SAS » Do 12. Jul 2018, 20:19

Hallo Frank,

zu 1. Ja
zu 2. ich hatte mir bei den ersten Versuchen mit TXP1 und 2 schon immer eine Schnittstelle gewünscht in der der Fs-Strom über eine "Mischer-Funktion" eingreift bzw. chiffriert. .......... .. . .... . . .... .

Benutzeravatar

Klaus
Rank 7
Rank 7
Beiträge: 98
Registriert: Mi 10. Mai 2017, 23:49
Hauptanschluß: 8869114 mpir d

Re: OTT - verschlüsselte zuschaltbare iTELEX Übertragung

#50

Beitrag von Klaus » Fr 13. Jul 2018, 22:51

ulbrichf hat geschrieben:
Di 26. Jun 2018, 21:33
Ich hatte mir vorgestellt, beim Projekt „einfaches Interface“ hier im Forum , einen Softwaremixer als Funktionsmodell dazu zu programmiere, um die Sache einfach mal ausprobieren zu können. Die Bauteile liegen schon ewig hier in meiner Bastelkiste und setzen Staub an.
Na dann mal ran ans Löteisen!
XOR geht beim Arduino mit ^
Den Schlüssel kannst Du einfach auf der SD-Karte speichern (als Datei) und beim Start in einen String lesen.
Ich würde empfehlen nicht nur die Start und Stop Bits unverschlüsselt zu lassen, sondern sogar die BU und ZI Zeichen.
Die werden nämlich ggf. bei der Wandlung baudot<->ascii<->baudot entfernt wenn doppelt bzw. hinzugefügt wenn fehlend.

Grüße,
Klaus
Grüße,
Klaus

8869114 mpir d -> LO133 -> online
36323 ife dr dd -> T-51 -> kein Anschaltgerät -> Offline
71614 feo d -> T68d -> Testgerät -> Offline
8510881D bay d -> T68d -> Vorschub defekt -> Offline

Antworten