Verschlüsseln synchron

[hotti]

Moin,

beim Stöbern auf meiner Festplatte hab ich ein Verfahren zur Verschlüsselung wiedergefunden, was mir ein Perl-Kollege vor vielen Jahren mal schickte.

Hier ist ein Beispiel

Wie sicher ist denn das, sind hier Experten, die mir den originalen Text da rausbekommen?

Hotte

[suit]

Wie sicher ist denn das, sind hier Experten, die mir den originalen Text da rausbekommen?

wenn der algorithmus bekannt ist und es ohne den schlüssel möglich ist, den text zu entschlüsseln: wechsle das teil

wenn der algorithmus sicher ist und die sicherheit auf geheimhaltung des schlüssels basiert, kannst du das ding tendentiell behalten

[hotti]

hi danke,

wenn der algorithmus sicher ist und die sicherheit auf geheimhaltung des schlüssels basiert, kannst du das ding tendentiell behalten

ne Frage noch, was meinst Du mit "algorithmus sicher"? Im Sinne von "Geheimhaltung"?

Der Schlüssel, ja freilich, der ist geheimzuhalten. Ein interessantes Verfahren zum Schlüsseltausch haben Diffie und Hellmann vor ein paar Jahren entwickelt, das schau ich mir demnächst mal an und versuche das in Perl umzusetzen.

Hotte

[suit]

ne Frage noch, was meinst Du mit "algorithmus sicher"? Im Sinne von "Geheimhaltung"?

nein, mit sicherem algorithmus meine ich, dass es ohne den schlüssel zu kennen (aber den algorithmus), schwierig ist, das schloss zu knacken

vorhängeschlösser sehen von außen meistens relativ gleich aus (messing-korpus und ein stahlbügel) - es gibt einige schlösser die lassen sich mit einer boroklammer im schließzylinder öffnen, andere die sich mit einem dünnen metallplättchen direkt am bügel öffen lassen

wenn dieses wissen die sicherheit des schlosses kompromitiert ist der mechanismus unsicher - wenn auch ein bekanntsein dieses die sicherheit nicht maßgeblich beeinflusst, ist das schloss sicher

[Beat]

ne Frage noch, was meinst Du mit "algorithmus sicher"? Im Sinne von "Geheimhaltung"?

Ein Algorithmus kann spätestens dann nicht mehr geheim gehalten werden, wenn die eine Clientseitige Verschlüsselung / Entschlüsselung via Javascript als Gegenpartner zum Serverseitigen Perl Programm brauchst.

mfg Beat

[hotti]

ne Frage noch, was meinst Du mit "algorithmus sicher"? Im Sinne von "Geheimhaltung"?

Ein Algorithmus kann spätestens dann nicht mehr geheim gehalten werden, wenn die eine Clientseitige Verschlüsselung / Entschlüsselung via Javascript als Gegenpartner zum Serverseitigen Perl Programm brauchst.

aber lieber Beat, Du unterstellst mir doch nicht etwa, dass ICH für eine sauwichtige Verbindung, deren Inhalte vor dem Gesetz geschützt werden müssen, einen gewöhnlichen Browser verwende :-)

Hotte

[suit]

aber lieber Beat, Du unterstellst mir doch nicht etwa, dass ICH für eine sauwichtige Verbindung, deren Inhalte vor dem Gesetz geschützt werden müssen, einen gewöhnlichen Browser verwende :-)

wieso - das bundesministerium für finanzen verlangt von mir auch, dass ich einen gewöhnlichen browser verwende: "Um die Online BKU verwenden zu können verwenden Sie bitte Internet Explorer, Firefox oder Safari in der aktuellsten Version." - mit opera "funzt" die sache dank einer javascriptweiche übrigens nicht wirklich

[hotti]

aber lieber Beat, Du unterstellst mir doch nicht etwa, dass ICH für eine sauwichtige Verbindung, deren Inhalte vor dem Gesetz geschützt werden müssen, einen gewöhnlichen Browser verwende :-)

wieso - das bundesministerium für finanzen verlangt von mir auch, dass ich einen gewöhnlichen browser verwende: "Um die Online BKU verwenden zu können verwenden Sie bitte Internet Explorer, Firefox oder Safari in der aktuellsten Version." - mit opera "funzt" die sache dank einer javascriptweiche übrigens nicht wirklich

Danke. Und ich dachte schon, die Politniks sind nur hier in DE so bekloppt.

Hotte

[Der Martin]

Hallo,

wieso - das bundesministerium für finanzen verlangt von mir auch, dass ich einen gewöhnlichen browser verwende: "Um die Online BKU verwenden zu können verwenden Sie bitte Internet Explorer, Firefox oder Safari in der aktuellsten Version."

aber doch nur, um deine Steuerangelegenheiten dem Finanzamt zu melden - und da ist ja wohl nichts Geheimhaltungswürdiges dran. Da machen die hier in DE auch eine Mordsparanoia, irgendwas mit Java und werweißwas-verschlüsselt! Hallo, ich soll doch nur meine Einnahmen und die daraus resultierenden Steuern anmelden, das ist doch kein Staatsgeheimnis.

mit opera "funzt" die sache dank einer javascriptweiche übrigens nicht wirklich

Da sind sie hier zum Glück etwas vernünftiger: Bei der Anmeldung und der Prüfung der Systemvoraussetzung heißt es dann nur: Sie verwenden einen Browser, der nicht direkt unterstützt wird. Wir können die einwandfreie Funktion aller Komponenten nicht garantieren.

So long,
 Martin

[at]

Hallo.

Hallo, ich soll doch nur meine Einnahmen und die daraus resultierenden Steuern anmelden, das ist doch kein Staatsgeheimnis.

Gewissermaßen doch. Das Steuergeheimnis ist durch den Staat zu gewährleisten. Dass es hier ein solches gibt, ist allerdings schade, zumal es systematisch nur inkonsequent eingehalten wird.
MfG, at

[Jens Holzkämper]

Tach,

Wie sicher ist denn das, sind hier Experten, die mir den originalen Text da rausbekommen?

zeig den Algorithmus her und man kann darüber Aussagen treffen.

mfg
Woodfighter

[hotti]

Tach,

Wie sicher ist denn das, sind hier Experten, die mir den originalen Text da rausbekommen?

zeig den Algorithmus her und man kann darüber Aussagen treffen.

Freilich doch. Im Arschief steht der auch schon seit mind. 2 Jahren, SuFu, benutzen ;-)

Viel Spass damit, Hotte

  
###########################################################################  
# Text synchron verschlüsseln  
sub kryptn{  
 my ($txt, $key) = @_; # $key ist eine Referenz auf @key  
 my $len = scalar @$key;  
 my $i = 0;  
 my $crypt = join "",  
  map { $i = ($i + 1) % $len;  
   chr((ord($_) + $$key[$i]) % 256) } split //, $txt;  
 return(encode_base64($crypt));  
}  
###########################################################################  
# Verschlüsselung aufheben  
sub entkryptn{  
 my ($crypt, $key) = @_; # $key ist eine Referenz auf @key  
 my $len = scalar @$key;  
 my $i = 0;  
 $crypt = decode_base64($crypt);  
 my $orig = join "",  
 map { $i = ($i + 1) % $len;  
  chr((ord($_) - $$key[$i] + 256) % 256) }  
   split //, $crypt;  
  return($orig);  
}  
###########################################################################  

[Jens Holzkämper]

Tach,

chr((ord($_) + $$key[$i]) % 256) } split //, $txt;

wenn ich mich nicht irre, sorgst du hier dafür dass nur das letze Schlüsselbyte genutzt wird, dann gäbe es nur 256 verschiedene mögliche Urtexte und das sollte recht einfach per Brute-Force knackbar sein.

mfg
Woodfighter

[Christian Kruse]

你好 Jens,

chr((ord($_) + $$key[$i]) % 256) } split //, $txt;

wenn ich mich nicht irre, sorgst du hier dafür dass nur das letze Schlüsselbyte genutzt wird, [...]

Du irrst.

$i = ($i + 1) % $len;  
   chr((ord($_) + $$key[$i]) % 256)

$i wird mit 0 initialisiert (weiter oben). Damit wird nur dafür gesorgt, dass $i zwischen 0 und $len iteriert.

Trotzdem ist der Algorithmus nur ein besseres rot13 und alles andere als sicher.

再见,
 克里斯蒂安

[Vinzenz Mai]

Hallo Hotti,

zeig den Algorithmus her und man kann darüber Aussagen treffen.
Freilich doch. Im Arschief steht der auch schon seit mind. 2 Jahren, SuFu, benutzen ;-)

und warum hast Du diese nicht benutzt?

[code lang=perl]
###########################################################################

Text synchron verschlüsseln

sub kryptn{
my ($txt, $key) = @_; # $key ist eine Referenz auf @key
my $len = scalar @$key;
my $i = 0;
my $crypt = join "",
  map { $i = ($i + 1) % $len;
   chr((ord($_) + $$key[$i]) % 256) } split //, $txt;
return(encode_base64($crypt));
}

http://aktuell.de.selfhtml.org/weblog/php-verschluesselung-100-euro-wette: lies insbesondere das Fazit!

Freundliche Grüße

Vinzenz

[Jens Holzkämper]

Tach,

Viel Spass damit, Hotte

Vigenère-Verschlüsselung, im englischen Artikel ist die Kryptoanalyse recht ausfürlich beschrieben.

mfg
Woodfighter

[Jens Holzkämper]

Tach,

Vigenère-Verschlüsselung, im englischen Artikel ist die Kryptoanalyse recht ausfürlich beschrieben.

noch was schönes zum selben Thema: http://blog.didierstevens.com/2009/01/18/quickpost-windows-7-beta-rot13-replaced-with-vigenere-great-joke/.

mfg
Woodfighter

[hotti]

Moin,

beim Stöbern auf meiner Festplatte hab ich ein Verfahren zur Verschlüsselung wiedergefunden, was mir ein Perl-Kollege vor vielen Jahren mal schickte.

Hier ist ein Beispiel

Wie sicher ist denn das, sind hier Experten, die mir den originalen Text da rausbekommen?

Sieht bisher nicht so aus. Schade. Da habt Ihr schon den Code, redet über Brut Force und rot13, aber so richtig überzeugend wirkt das nicht hehe :)

=> Her mit dem Origialtext, ich hab den Schlüssel vergessen.

Hotti

[Vinzenz Mai]

Hallo,

Hier ist ein Beispiel

Wie sicher ist denn das, sind hier Experten, die mir den originalen Text da rausbekommen?

ich bin keiner ...

Sieht bisher nicht so aus. Schade. Da habt Ihr schon den Code, redet über Brut Force und rot13, aber so richtig überzeugend wirkt das nicht hehe :)

... aber Du hast offensichtlich meinen Beitrag und die dort verlinkte Ressource und den dazugehörigen Forumsthread nicht gelesen.

=> Her mit dem Origialtext, ich hab den Schlüssel vergessen.

Das ist halt Pech für die Kuh Elsa.

Freundliche Grüße

Vinzenz

[hotti]

Hallo,

Hier ist ein Beispiel

Wie sicher ist denn das, sind hier Experten, die mir den originalen Text da rausbekommen?

ich bin keiner ...

Sieht bisher nicht so aus. Schade. Da habt Ihr schon den Code, redet über Brut Force und rot13, aber so richtig überzeugend wirkt das nicht hehe :)

... aber Du hast offensichtlich meinen Beitrag und die dort verlinkte

Ressource und den dazugehörigen Forumsthread nicht gelesen.

Doch, hab ich, das war ja für mich der Anlass, das Verfahren meines Perl-Kollegen mal wieder vorzustellen.

Leider kann ich als Anreiz für die Lösung keine 100 € bieten ;)

Auf jeden Fall dürfte es langwierig werden, mögliche Schlüssel durchzugehen, weil nicht bekannt ist, was dabei rauskommen soll.

Passwortknacker haben es ungemein leichter: Entweder sie kommen rein oder nicht. Ein Entschlüsseler hingegen muss das Ergebnis jedesmal, nachdem ein Schlüssel probiert wurde, manuell prüfen ob es sinnfällig ist, eine Automatisierung ist hier nicht möglich.

Viele Grüße,
Hotte

[Vinzenz Mai]

Hallo,

Sieht bisher nicht so aus. Schade. Da habt Ihr schon den Code, redet über Brut Force und rot13, aber so richtig überzeugend wirkt das nicht hehe :)

Du stellst Dich in diesem Thread etwas trollig an :-)

... aber Du hast offensichtlich meinen Beitrag und die dort verlinkte
Ressource und den dazugehörigen Forumsthread nicht gelesen.

Doch, hab ich, das war ja für mich der Anlass, das Verfahren meines Perl-Kollegen mal wieder vorzustellen.

wie bitte? Mir ist völlig schleierhaft, weswegen Du eine erhöhte Sicherheit gegenüber den dort vorgestellten Verfahren vermutest.

Und nein, es ist völlig überflüssig, eine Dechiffrierung vorzunehmen genauso wie es überflüssig ist, ein altmodisches Kastenschloss mit einem Dietrich zu öffnen, um dessen Unsicherheit zu erkennen.

Freundliche Grüße

Vinzenz

[hotti]

Hallo,

Doch, hab ich, das war ja für mich der Anlass, das Verfahren meines Perl-Kollegen mal wieder vorzustellen.

wie bitte? Mir ist völlig schleierhaft, weswegen Du eine erhöhte Sicherheit gegenüber den dort vorgestellten Verfahren vermutest.

Die "dort" vorgestellte Glyphe UND das Verfahren wurde ratz fatz geknackt. In meinem Fall wurde nicht einmal mit bekanntem Verfahren die Glyphe geknackt. Das sind die Fakten.

Und nein, es ist völlig überflüssig, eine Dechiffrierung vorzunehmen genauso wie es überflüssig ist, ein altmodisches Kastenschloss mit einem Dietrich zu öffnen, um dessen Unsicherheit zu erkennen.

Das klingt sehr überheblich, wenn nicht sogar arrogant.

Hotte

[flowh]

Hallo Rolf.

In meinem Fall wurde nicht einmal mit bekanntem Verfahren die Glyphe geknackt.

Liegt höchstwahrscheinlich daran, dass es niemand gemacht hat.

Und nein, es ist völlig überflüssig, eine Dechiffrierung vorzunehmen genauso wie es überflüssig ist, ein altmodisches Kastenschloss mit einem Dietrich zu öffnen, um dessen Unsicherheit zu erkennen.

Das klingt sehr überheblich, wenn nicht sogar arrogant.

"Nur Verschlüsselungsalgorithmen die öffentlich bekannt sind und wenigstens ein paar Jahre lang von Kryptologen ergebnislos untersucht wurden sind vertrauenswürdig." (Henryk)

Aus welchem Grund stimmst du dieser Aussage augenscheinlich nicht zu?

Servus,
Flo

[Henryk Plötz]

Moin,

Wie sicher ist denn das, sind hier Experten, die mir den originalen Text da rausbekommen?

Schlüssel: #%')(&$"!
Anfang des Textes: ~~~

echo                7/tcp
 echo                7/udp
 discard             9/tcp    sink null
 discard             9/udp    sink null

Ende des Textes: ~~~
  
 sapsp95   3495/tcp  
 sapsp96   3496/tcp  
 sapsp97   3497/tcp  
 sapsp98   3498/tcp  
 sapsp99   3499/tcp  
 sappcd    3500/tcp  
  

[Jens Holzkämper]

Tach,

Schlüssel: #%')(&$"!

YMMD

mfg
Woodfighter

[Vinzenz Mai]

Hallo Henryk,

Wie sicher ist denn das, sind hier Experten, die mir den originalen Text da rausbekommen?

Schlüssel: #%')(&$"!

danke fürs Dietrich rumdrehen :-)

Freundliche Grüße

Vinzenz

[Henryk Plötz]

Moin,

Und weil bunte Bilder allgemein beliebt sind hier noch ein Nachtrag. Zuerst aber noch eine Anmerkung:

Schlüssel: #%')(&$"!

hab ich etwas vorschnell aus meinem Tool kopiert. Das ist der Schlüssel wie er intern in meinem Tool vorlag. Die Version die hotte benutzt hat dürfte wohl eher [3, 5, 7, 9, 8, 6, 4, 2, 1] sein, also Zahlen zwischen 1 und 9 (mein Tool hat ASCII-Zeichen benutzt, und 32 draufaddiert).

Die anfängliche Vorgehensweise ist wie damals:
Zuerst der übliche Blick auf den ciphertext als Hexdump nach BASE64-Dekodierung:

zeigt wieder viel und sich wiederholendes ASCII -> schwache Verschlüsselung. Autokorrelation um die Schlüssellänge zu gewinnen deutet eine Schlüssellänge von 20 an:

Da damit aber die Entschlüsselung nicht auf Anhieb klappt ist wohl doch ein genauerer Blick vonnöten. Also mein Lieblingstool anwerfen, den Dotplot (hier für 10gramme):

Das verrät schon mal viel über die Struktur der Originaldatei: Sie besteht aus zwei deutlich voneinander verschiedenen Teilen, die Grenze liegt ungefähr bei Offset 7400. Der erste Teil ist recht wild, aber der zweite Teil besteht selbst wieder aus drei leicht unterschiedlichen Teilen. Die nah beieinanderliegenden Streifen im Dotplot des zweiten Teils haben übrigens einen Abstand von 80, die weit entfernten Streifen einen Abstand von 1800. Sollte die die Schlüssellänge etwa 180 sein? Das trau' ich hotte ehrlich gesagt nicht zu.

Noch eine Nebenbemerkung zur Struktur: hier mal die ASCII-Werte der einzelnen Zeichen im Ciphertext über ihrem Offset aufgetragen:

Man erkennt in den drei Unterteilungen des zweiten Teils der Datei eine wiederkehrende aufsteigende Sequenz (sieht man noch besser wenn man reinzoomt, aber ich will das Posting nicht mit unnötig vielen Bildern verpesten).

Zurück zur Schlüssellänge: Bei dem angenommenen einfachen Algorithmus müssten die Histogramme für alle Zeichen die mit dem gleichen Schlüsselbyte verschlüsselt wurden ungefähr gleich sein, aber verschoben. Gehen wir für den Augenblick erstmal von Schlüssellänge 20 aus und tragen die Histogramme für die Zeichen auf die mit dem ersten Schlüsselbyte verschlüsselt wurden:

  
c = load("ciphertext.txt");  
hold on  
for i = 1:3; hist(c(i:20:13438),1:130); endfor  

Das sieht nicht richtig aus. Während man im Bereich über 100 zwar mit etwas Phantasie noch sagen könne dass das blaue und rote Histogramm ungefähr gleich dem grünen, aber verschoben ist, sind sie in den Bereichen darunter --besonders zu sehen im Bereich von 33 bis 42-- ungefähr identisch.

Tatsächlich sieht jedes der Teilhistogramme ungefähr genauso wie das Histogramm über die gesamte Datei aus:

In erster Näherung sieht das eigentlich sogar fast wie das zu erwartende Histogramm einer unverschlüsselten Datei aus, mit leicht verbreiterten Balken. Die Häufung bei 10 aufwärts sind Zeilenumbrüche, bei 32 aufwärts Leerzeichen, dann ein Hügel für Zahlen, ein kleiner Hügel für Großbuchstaben und ein großer Hügel für Kleinbuchstaben. Die Breite des Leerzeichenspikes verrät uns den Werteumfang des Schlüssels: Es handelt sich offenbar um Verschiebungen zwischen 1 und 9 (inklusive). Das ist um eine Größenordnung weniger als bei dem 'normalen' naiven Ansatz mit einem ASCII-Text als Schlüssel. Ausserdem wurden die Verschiebungen offenbar auch nicht als ASCII-String eingegeben (sonst wäre die kleinste Verschiebung mindestens 10 (Zeilenumbruch), eher 32 (Leerzeichen)) sondern als Liste von Zahlen.

Anyway, Schlüssellänge. Durch Zufall hab ich mir den Geheimtext mal nicht als Hexdump sondern als normalen ASCII-Text angesehen:

Hier fällt das ^M^N in der ersten Zeile auf, was man vorher im Hexdump nicht so deutlich gesehen hat. Davor und dahinter steht jeweils auch ungefähr der gleiche Text. Gehen wir mal als Arbeitshypothese von einer Windows-Textdatei mit CRLF als Zeilentrenner aus, dann müssten das Zeilenumbrüche sein die mit den gleichen Schlüsselbytes verschlüsselt wurden. Ihr Abstand ist 9, also ist das jetzt unsere Schlüssellänge. Und tatsächlich, wenn man wieder die Histogramme für die einzelnen Schlüsselbytes eines 9 Byte langen Schlüssels malt, kommt was raus was richtig aussieht:

Jedes der einzelnen Histogramme einen klar definierten und 1 Zeichen Breiten Spike für das Leerzeichen, so muss das aussehen. Den Schlüssel könnte man jetzt hier an dem Histogramm ablesen, aber ich hatte dafür ein paar Zeilen Python geschrieben die das machen und dann den Klartext ausgeben. Hier also das Histogramm für den Klartext:

Man sieht den Leerzeichenspike und zwei Spikes bei 9 und 10. Stellt sich raus das das keine Windows-Datei ist, sondern die im Klartext nah beieinanderliegenden Zeichen unter 32 je ein Tab (0x9) und ein Zeilenumbruch (0xa) sind. Und zur allgemeinen Belustigung noch ein Dotplot (wieder 10gramme) für den Klartext:

Ein Blick auf den Klartext zeigt auch, warum die Autokorrelation die Schlüssellänge nicht gezeigt hat: Die Datei ist in sich so extrem stark strukturiert, und die 'Verschlüsselung' unterdrückt die Struktur so wenig (wie man an den Dotplots sieht) dass die Regularität im hinteren Teil der Datei durchgedrückt hat. Dort finden sich sehr viele, fast identische Zeilen (die sich nur in der aufsteigenden Nummer unterscheiden, daher die aufsteigende Struktur die man oben im Plot der ASCII-Werte gesehen) die jeweils 20 Bytes lang sind. Das kleinste gemeinsame Vielfache von 9 und 20 ist 180 (konnte man im Dotplot ja schön sehen), das war der andere Kandidat für die Schlüssellänge. Oh, und natürlich funktioniert mein Schlüsselfinderskript auch wenn man ihm sagt der Schlüssel wäre 180 Byte lang.