Telexforum.de

Ohne Bedienungsanleitung kannst du die Kiste nicht bedienen. Ausprobieren hilft da nicht...

Ich sagte ja schon, das ist nicht einfach den "Verschlüsselungsbutton" bei einer eMail anzuklicken...

DF3OE hat geschrieben: ↑Mo 25. Apr 2022, 16:45 Die Farbsteuerung bei dieser "Spezialmaschine" ist sehr besonders und hat nichts mit der Senderichtung zu tun.

Ein manueller Schalter für die rot/schwarz-Umschaltung?

Hallo Martin,

um wieder auf den Eingangspost zurückzukommen und das Interesse noch nicht verloren gegangen ist:

Earl0fPudding hat geschrieben: ↑So 17. Apr 2022, 23:22 An alle aus Österreich: falls ihr einen Fernschreiber loszuwerden ​habt, meldet euch gerne bei mir. Ich würde mich freuen schon bald ein solches Gerät mein Eigen nennen zu dürfen.

Im Moment bietet wieder jemand aus Niederösterreich das Gerät an. (Die Reservierung muß ein Irrtum sein.)
https://www.willhaben.at/iad/kaufen-und ... -572014847

DF3OE hat geschrieben: ↑Mo 25. Apr 2022, 10:32 Ich möchte nochmal wiederholen: Das alles hier ist Spielerei, auch mit solchen antiken Maschinen, und mir geht es am A***** vorbei,
ob mein "Dummsülz", den ich über i-Telex sende, von jemandem mitgehört wird oder nicht.

Ja das und ist I-Telex nicht sowieso (für heute) verschlüsselt, weil ja kein ASCII, sondern 5-Bit- CCITT-Telegraphenalphabeth Nr. 2 -Code gesendet wird?
Da müßte der jeweilige Hacker auch erstmal drauf kommen

Hallo Finn,
Du hast schon aus Deiner Sicht und Alter mit der Bezeichnung "(für heute) verschlüsselt" oberflächlich recht. Es ist zwar keine Verschlüsselung, maximal eine Verschleierung wegen der verdreht gesendeten Baudotzeichen. Dazu kommt der Effekt, das es aus der heute benutzten ASCII-Welt alles nicht druckbare Zeichen sind . Kein Text/Hex-Editor zeigt dir da was an. Dazu kommt noch die Verpackung in das i-telex binär Protokoll. Für Laien ist es ein undurchsichtiges Zeichenwirrwarr das aussieht wie ein normaler IP-Datenstrom oder Webseiten mit den ganzen Sonderzeichen im HTML-Format.
Aber für Insider, die wissen wie Netzwerktrace zu filtern sind um schnell die Nutzdaten zu isolieren ist das überhaupt kein Thema. Das machen Fred, Detlef, Björn , Andere und auch ich im Fehlerfall auch. Natürlich wissen wir wonach wir suchen müssen, aber der reine Protokoll-Datenstrom nach der Spec von Fred weist schon ein gewisses Muster auf (ähnlich dem TCProtokoll). Das zu analysieren fällt Fachleuten nicht schwer. Wenn man dann beobachtet wo längere Sequenzen auftauchen, ist man schon mal bei den Baudotdaten mit dem Header 02. Da ich grundsätzlich jedes Baudotzeichen einzeln verschicke, fällt es zwischen den Acks und Heartbeats ,Dw und Ende etwas weniger auf. Aber auch auf dieser Ebene bleibt der visuelle Schutz als nicht druckbar eine kleine Hürde, denn da rechnet keiner sofort mit. Da es aber Nutzdaten zu sein scheinen, lohnt eine weitere Betrachtung hinsichtlich des "decodierens". Ein Hacker macht vor nichts halt und wird sehen, das dort mitunter Pakete mit 10 oder 13 auftauchen, zwei der wenigen Befehle die ASCII darstellen kann. Hat zwar nichts sinnvolles an diesem Punkt, ein CR oder LF reizt da aber schon. Wenn nun die Verpackungsstrategie dazugenommen wird (Typ,Länge, Daten) steht der Isolierung der vermeintlichen Nutzdaten nichts im weg. Wer dann den Wertebereich betrachtet sieht das nur die unteren 5 bit benutzt werden, wird im Netz schnell fündig, selbst wenn er nicht weiß was das ist. Es nützt auch nichts das ganze um ein bis 3 Bit zu verschieben, es bleibt auffällig. Lediglich das Auffüllen der oberen 3 Bit mit einem Zufallsmuster, sodaß die wildesten ASCII-Zeichen entstehen, könnte zu einer etwaigen Verzögerung führen.
Wer dann die unteren 5bit-Worte nach Baudot umwandelt, wird einen nichtssagendenText zu sehen bekommen, so als würde man den Lochstreifen seitenverkehrt einlegen. Das ist dann aber nur noch eine kleine Hürde die mit etwas probieren oder Mathematik zu lösen ist.
Auf IP-Ebene ist mit Schlüsseln jeder Schutz möglich, die Geschwidigkeit gibt es speziell bei telex her. Aber ich halte es wie Henning, schreibe aber hoffentlich keinen "Dummsülz" und bleibe da gelassen.
Wenn Du auf unterster Ebene etwas unverständlich übertragen willst, stanz es auf einen ls und sende es rückwärts. Schreibe aber dem Partner vorher, das er mitstanzen soll um es dann nochmal rückwärts (also wieder richtig) auszudrucken. Der Effekt das BU/ZI und WR/ZL in anderer Reihenfolge kommen hat verblüffende Wirkung.
Noch einen schönen Feiertag.
Gruß
Willi

Vielen Dank für die detaillierten Erläuterungen!
Das ist mir schon verschlüsselt genug. Das ist sogar mehr erforderlicher Entschlüsselungs-Aufwand, als ich erwartet hatte.

Fernschreiber hat geschrieben: ↑Do 26. Mai 2022, 13:32 Es nützt auch nichts das ganze um ein bis 3 Bit zu verschieben, es bleibt auffällig. Lediglich das Auffüllen der oberen 3 Bit mit einem Zufallsmuster, sodaß die wildesten ASCII-Zeichen entstehen, könnte zu einer etwaigen Verzögerung führen.
Wer dann die unteren 5bit-Worte nach Baudot umwandelt,

Ich bin auch schon mal erfreut, dass es nicht plaintext (ASCII etc.) ist, was übertragen wird.
Der Aufwand ist tatsächlich höher als ich erwartet hätte.

Zum Thema bitshift... Man könnte es mit dem Auffüllen koppeln und davon abhängig machen:
Je nach den ersten bits wird der BaudotCode an anderer Stelle gesendet.
mit 3 führenden 0 bleibt er da wo er ist (letzten 5 bit).
Damit ist abwärtskompatibilität beim Empfang gewährleistet. Beim Senden muss der Sender die Version der Gegenstelle prüfen, wenn die zu alt ist, wird mit 000 gesendet.
Sollten die ersten Bits anders sein, hat das dann Auswirkungen auf die Position im Code.
01 bedeutet Baudot begint ab 3. Stelle
1 bedeutet Baudot beginnt an 2. Stelle
001 ist wie 000
Schematisch dann so: Welche der drei Übertragungen für ein Zeichen gewählt wird bestimmt entweder der Zufall oder das zuletzt gesendete Zeichen.

So könnte man mit wenig Aufwand mehr Varianz hinein bringen.

Das ist natürlich weiterhin keine Verschlüsselung. Aber als Obfuscation kann man das schon bezeichnen.

Hallo Raphael,
na ja, das i-telex kann auch ASCII, je nachdem was die Gegenstelle so macht. So ist z.B. der Wetterdienst 727272 von Frank und ich meine auch der Abo-Service wie auch der Minitelex-Übergang ASCII-basiert. Dann ist es im Netzwerktrace natürlich ein leichtes, im Klartext mitzulesen.
Das mit der Bitverschiebung habe ich nur erwähnt, weil es sich förmlich aufdrängt. Ein solches Muster, wo die oberen 3 Bit immer auf "0" stehen fällt jedem, der Netzwerktraces auf Ebene der Payload macht ,irgendwann auf. Deine Idee ist völlig logisch, würde aber eine neue Generation von abwärtekompatiblen "Ethernet-Karten" erfordern. Da das Thema Verschlüsseln und Kryptologie ist ein spezielles und hier schon oft angesprochen und schnell wieder ad acta gelegt, würde das nicht weiter vertiefen. Ist wie ich immer wieder höre ja ein Hobbynetz. Wer aber individuell Ende zu Ende verschlüsseln will kann das ja tun (Lochstreifen) ändert aber nichts auf der Netzwerkebene. Ich arbeite in dieser Hinsicht an keinem Projekt. Da ich mit Kryptologie im Mobilfunksektor zwecks Authentifizierung zu tun hatte, reizt es mich natürlich ab und zu in die alten Unterlagen zu schauen. Was mich in Zukunft aber beschäftigen wird ist eine geschützte Übertragung auf Technik/ Bedienerseite zwecks Telemetrie via auch Fernschreiber.

Gruß
Willi