Eigene Kodiertabelle für base64 zur RS232-Verschlüsselung

[Frank (Gast)]

Hi,

ich möchte ein serielles Protokoll verschlüsseln und dachte dabei an 
eine base64-Kodierung, bei der ich eine eigene Kodiertabelle verwende.

base64 wird ja so kodiert:

static const std::string base64_chars =
             "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
             "abcdefghijklmnopqrstuvwxyz"
             "0123456789+/";

Wenn ich den Inhalt der Tabelle jetzt scramble, "A" wird 1, "B" z.B. "Q" 
usw. und ich die Tabelle natürlich jeweils im Sender und im Empfänger 
hinterlege, wie einfach ist die Kodierung zu knacken, wenn jemand das 
serielle Protokoll mitschreibt.

Was meint ihr?

Bitte kein Themenwechsel in Richtung AES usw.
Mich interessiert einfach Eure Meinung, wie schnell oder einfach man das 
Ursprungstelegramm herausfinden könnte.
Sehe ich das richtig, dass man 2hoch64 Möglichkeiten ausprobieren 
müsste? Und auch dann wüßte man ja immer noch nicht, welches der 
Telegramme nun gültig ist, da das Protokoll ja ebenfalls kodiert ist. 
Natürlich darf ich dann keine "auffälligen" Bytes senden, wie STX, DLE, 
ETX usw.
Falls ich ein Byte im Telegramm unkodiert lasse, könnte ich darüber ja 
auch weitere Kodiertabellen anspringen, um den Hacker zusätzlich zu 
verwirren...

Danke.

[zwieblum (Gast)]

ist ein kinderspiel.

[Peter (Gast)]

gab es schon vor ein paar 100Jahren und da konnte man es auch schon 
knacken.

http://de.wikipedia.org/wiki/Monoalphabetische_Substitution

[Frank (Gast)]

@Peter
Danke für den Link, sehr interessant. Das Knacken geht aber von einem 
Klartext aus, Häufigkeitsverteilungen der Buchstaben und 
Schlüsselwörtern.

Wenn mein unverschlüsseltes Telegramm z.B. in Hex so streamt:

fa 35 29 4b 22 9f bb d1 04 c1 5a usw.

wer will dann einen Angriff per Muster machen können? Keiner weiß, dass 
sich z.B. im 5. Byte die Adresse des Slaves befindet. Und wonach soll 
gesucht werden? Das Telegramm ist ja selber "verschlüsselt".

[Frank (Gast)]

@zwieblum

Ich habe ein Telegramm verschlüsselt mit base64 und eigener 
look-up-table:

AwCC4EwdoUi9Dc5Yl42D4GGh6H7WMngbz79DLodQ51S4t&4J3S1VgPQd35dX

Wie lautet das Ursprungstelegramm, wenn es ein "Kinderspiel" ist???

[Arc N. (arc)]

Frank schrieb:
> @Peter
> Danke für den Link, sehr interessant. Das Knacken geht aber von einem
> Klartext aus, Häufigkeitsverteilungen der Buchstaben und
> Schlüsselwörtern.
>
> Wenn mein unverschlüsseltes Telegramm z.B. in Hex so streamt:
>
> fa 35 29 4b 22 9f bb d1 04 c1 5a usw.
>
> wer will dann einen Angriff per Muster machen können? Keiner weiß, dass
> sich z.B. im 5. Byte die Adresse des Slaves befindet. Und wonach soll
> gesucht werden? Das Telegramm ist ja selber "verschlüsselt".

Ist die Slave-Adresse immer an der gleichen Position, werden die Slaves 
immer in der gleichen Reihenfolge angesprochen, dazu mit den gleichen 
(wenigen) Kommandos (nur unterschiedliche Parameter), gibt es 
unveränderliche Header, dazu noch eine CRC am Ende etc. pp. alles 
Hinweise bzw. konstante Werte (ausser man ändert den Schlüssel nach 
jeder Übertragung) die das Entschlüsseln vereinfachen.

Zum Testen wie sicher das tatsächlich ist...
http://cryptool.com/index.php/de/download-topmenu-63.html

[Peter (Gast)]

auch wenn du es im klartext überträgst muss ich erstmal rausbekommen ob 
die 5. Stelle die Slave adresse ist. Und ob nun an der 5. Stelle eine 
0x34 oder eine 0x77 steht ist mir dabei sogar egal. Ich nehm einfach an 
es ist die Slave adresse

[Roland P. (pram)]

Ich denke mal dass eine derartige Verschlüsselung schon mal 80-90% der 
Hacker/Script Kiddies abhält. Wenns einer wirklich darauf anlegt und ein 
bisschen Zeit, Glück und Know-How hat, dann hält die Verschlüsselung 
wohl einer Zeitspanne von wenigen Stunden bis ein paar Tage stand :-)

Gruß
Roland

[Frank (Gast)]

@ Arc Net
Danke für den Link. Sehr schönes Programm, und gute Überlegungen von 
Dir.

@Roland Praml
Du sagst es! So wollte ich es hören!

Meldet sich sonst noch jemand?

[Tim T. (tim_taylor)]

Sobald es einen interessiert kannst du deine "Verschlüsselung" knicken, 
bis dahin funktionierts natürlich.

Das Interesse könnte dabei durch 2 Sachen geweckt werden:

1. Jemanden interessieren die Daten aus welchen gründen auch immer.
2. Jemand will deine Unfähigkeit zur Schau stellen.

Die Scriptkiddies sind ansich schon raus wenn es kein Plaintext ist...

[Läubi .. (laeubi)]

Troz allem ist eine Kodierung keine Verschlüsselung!
Das "Problem" tritt doch erst auf wenn ich mehr als 1 Telegramm empfange 
oder schon Informationen über den Klartext habe.
Solange das Telegramm unter der Eindeutigkeitslänge liegt ist sogar eine 
simple Textersetzung sicher (liegt im Deutschen glaub ich bei etwa 3 
Zeichen oder so).
Wenn das ganze eh binär ist, würde ich mir eine Menge an zufallszahlen 
(z.B. 1 kb) anlegen und dann halt einfach XOR verschlüsseln und nach 
jedem senden halt entsprechend den lesezeiger weiterrücken.

Dein Hauptproblem ist nämlich auch wenn ich nicht weiß was :
AwCC4EwdoUi9Dc5Yl42D4GGh6H7WMngbz79DLodQ51S4t&4J3S1VgPQd35dX
bedeutet, so weiß ich doch das jedemal wenn ich diese Zeichenkette sehe 
die gleiche Aktion durchgeführt wird...

[zwieblum (Gast)]

igitt du böser hacker! weißt du denn nicht dass die applikation durch 
technische maßnamen geschützt wurde? wenn du darüber nachgrübelst was da 
wie geht bist du ein terrorist!

[Wolfgang S. (Gast)]

Hier der Link für unsere Terroristen ;)
http://www.dubistterrorist.de

[Sven P. (Gast)]

Die Frage ist viel grundlegender: Ist dein Datenstrom überhaupt 
schützenswert?

Selbst wenn man annimmt, dass irgendeine Adresse immer an Stelle #5 (wie 
auch immer geartet) steht, dann gibts nur zwei Möglichkeiten:
1. Der 'Code' ist leichter zu knacken
2. Dein Protokoll ist miserabel dokumentiert, das entspräche etwa 
'Sicherheit durch Unklarheit', also auch nur billigstes 
Pseudo-Verfahren.