nicht angemeldet
MudGuard
Felix Riesterer
Henryk Plötz
Henryk Plötz
Henryk Plötz
Henryk Plötz
Hallo,
ich soll per PHP einen String ver- und dann wieder entschlüsseln.
MD5 ist für diesen Zweck nicht geeignet, ich brauche tatsächlich den entschlüsselten String im Klartext.
Hat jemand eine Idee?
Dank und Gruss
Klaus
Hi,
ich soll per PHP einen String ver- und dann wieder entschlüsseln.
PHP bietet z.B. einige mcrypt_ Funktionen (hab ich aber noch nie benutzt und auch nicht genauer studiert). Vielleicht ist da ja was für Dich dabei.
MD5 ist für diesen Zweck nicht geeignet,
md5 ist ja auch keine Verschlüsselung.
cu,
Andreas
Hi,
PHP bietet z.B. einige mcrypt_ Funktionen (hab ich aber noch nie benutzt und auch nicht genauer studiert). Vielleicht ist da ja was für Dich dabei.
Hättest ihm ja wenigstend den Link geben können.
Faule Socke! ;-)
so short
Crhistoph Zurnieden
Hi,
Hättest ihm ja wenigstend den Link geben können.
Wenn er PHP programmiert, dann hat er das Manual doch wohl sicher bei sich lokal installiert - da wollte ich ja auch hinverlinken, aber er hat mir ja nicht gesagt, wo er es installiert hat ;-)
Und wenn er es tatsächlich nicht lokal haben sollte, wird er doch wohl wenigstens wissen, wo die Doku in der von ihm gewünschten Sprache zu finden ist.
Außerdem bin ich nicht unbedingt ein Fan von derartigem Sprachmischmasch:
Zitat aus der von Dir verlinkten Seite:
LXVII. Mcrypt Encryption Functions
Einführung
This is an interface to the mcrypt library,
Allein in den ersten 3 Zeilen finden 2 Sprachwechsel statt.
Eine Doku in diesem Zustand halte ich für unbrauchbar.
Da setz ich doch keinen Link drauf.
cu,
Andreas
Hi,
[...]
Da setz ich doch keinen Link drauf.
Aber ich. Und zwar mit voller Absicht genau da drauf. Der Smiley bezog sich nicht nur auf die "Faule Socke". Genauso, wie eben jene Titulierung als allzu bequemer Fußlappen sich nicht unbedingt auf Dich bezog.
so short
Christoph Zurnieden
PS: ich würde die PHP-Doku alleine schon wegen der Kommentare nicht lokal halten wollen, wenn's keine anderen Gründe dafür gibt.
CZ
Hi,
PS: ich würde die PHP-Doku alleine schon wegen der Kommentare nicht lokal halten wollen, wenn's keine anderen Gründe dafür gibt.
Ich schon - um kurz die Reihenfolge der Parameter nachzugucken oder ähnliches möcht ich mich nicht von der Verbindung ins Internet abhängig machen.
cu,
Andreas
Hallo zusammen,
vielen Dank für Eure Hilfe. Ich denke ich versuche es mal mit Mcrypt.
Grüsse
Klaus
Lieber Klaus,
wenn es um Sicherheits-Sachen geht, dann möchtest Du den String vielleicht lieber über eine SSL- oder https-Verbindung übertragen.
Wenn es nur um eine Art der "Maskierung" geht, damit sich Skripte nicht an bestimmten Zeichen Stören bzw. bestimmte Zeichenkodierungen nicht abartig um- und/oder abgewandelt werden, dann könnte Dich vielleicht die base64-Codierung interessieren.
Liebe Grüße aus Ellwangen,
Felix Riesterer.
Hello,
bau Dir doch eine "Domino-Verschlüsselung".
Da wird auf einen String ein anderer (Schlüssel) aufaddiert und dann jedem Nachfolger der Wert des Vorgängers hinzuaddiert. Man arbeitet mit Überschlag. Am Ende wird dann wieder der Schlüssel hinzuaddiert.
Ist eine gute Übung für diverse Fuktionen...
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo Klaus,
falls die bisherigen Posts nicht helfen solltest Du vielleicht etwas genauer beschreiben was Du vor hast.
Je nach Verwendung kann eine einfache Verschlüsselung (Tom Domino genannte), eine simple Umkodierung (base64 von Felix genannt) oder eben eine Verschlüsselung mit z.B. mcrypt oder einem von vielen, vielen anderen Algos sein.
Wenns etwas sicherer sein soll findest du zu den gängigen Algos auch Implementierungen für die häufigsten Programmiersprachen.
Ciao
Thommy
Hi,
ich war jetzt etwas faul mir die antwort hier genau durchzulesen, aber
ich hatte schonmal ähnliches "problem". So hab ich es gelöst.
$Text = $_POST['text'];
$lang = strlen($Text);
$TextteilCode = false;
echo "Text: $Text<br>";
for ($z=0; $z<$lang; $z++)
{
$Textteil = substr($Text, $z);
$Textteil = ord($Textteil);
$Code = "~";
$Code = ord($Code);
$TextteilCode[$z] = $Textteil+$Code;
}
if ($TextteilCode <> false)
{
$anzahl = count($TextteilCode);
$TextCodiert ="";
for ($z=0; $z<$anzahl; $z++)
{
$TextCodiert .= $TextteilCode[$z];
}
echo "Textgewandelt: $TextCodiert<br>";
$TextDecode = "";
for ($z=0; $z<$anzahl; $z++)
{
$Textteil = $TextteilCode[$z];
$Code = "~";
$Code = ord($Code);
$Decoded = $Textteil - $Code;
$Decoded = chr($Decoded);
$TextDecode .= $Decoded;
}// for ($z=0; $z<$anzahl; $z++)
echo "Decodiert: $TextDecode";
}// if ($TextteilCode <> false)
hoffe du verstehst den Code, wenn nicht beantworte ich dir gerne rückfragen.
MfG
HI,
du kannst natürlich gleich den Code als ordnungszahl angeben. beachten
solltest du das der wert >= 100 ist und nicht 256. bei 256 sieht der
Codierte text genauso aus wie normal.
MfG
Hi,
nichts gegen Daniel persönlich aber die Lösung finde ich nicht gut.
Ich würde Dir raten wenn Du schon wirklich verschlüsseln und entschlüsseln willst einen richtigen Verschlüsselungsalgorithmus zu nehmen. Der ist dann schwerer zu knacken und auch ggf. in anderen Sprachen (C, Java, perl,...) verfügbar falls eine verschlüsselte Zeichenkette irgendwann mal dort weiterverarbeitet werden soll oder das Programm portiert werden müsste.
Ciao
Thomas
Hello,
Ich würde Dir raten wenn Du schon wirklich verschlüsseln und entschlüsseln willst einen richtigen Verschlüsselungsalgorithmus zu nehmen.
Was ist denn ein richtiger[tm] Verschlüsselungsalgorithmus?
Es gibt ja im Prinzip nur zwei große Gruppen:
1.) Ein Schlüssel, zwei Methoden
2.) Eine Methode, zwei Schlüssel (Private + Public)
Und der Algorithmus sollte dann berücksichtigen
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Was ist denn ein richtiger[tm] Verschlüsselungsalgorithmus?
Vielleicht hätte ich mich präzisier ausdrücken sollen.
Mit "richtiger[tm]" meine ist einen standardisierten. Also z.B.:
-Blowfish
-Twofish
-CAST5
-Serpent
-AES
-Triple DES
-...
Damit hast Du halt den Vorteil dass Du nichts selbst programmieren (testen,...), dass der Algo schätzungsweise durchdachter / sicherer als der eigene ist und dass (wie schon erwähnt) der Algo idR. auch in verschiedenen Sprachen bereits vorliegt.
Ciao
Thommy
Hello,
das hatte ich schon so verstanden, doch die Frage, was diese Algorithmen auszeichnet, bleibt trotzdem. Das würde mich _grundsätzlich_ mal interessieren. Allerdings ist Cryptographie wohl sowieso eine eigene Wissenschaft und meistens äußerst mathematisch.
Damit hast Du halt den Vorteil dass Du nichts selbst programmieren (testen,...), dass der Algo schätzungsweise durchdachter / sicherer als der eigene ist und dass (wie schon erwähnt) der Algo idR. auch in verschiedenen Sprachen bereits vorliegt.
Wenn ish ihn dan auch im Quellcode habe, also noch nicht compiliert, dann mnag ich dem auch vertrauen.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Moin,
Es gibt ja im Prinzip nur zwei große Gruppen:
1.) Ein Schlüssel, zwei Methoden
2.) Eine Methode, zwei Schlüssel (Private + Public)
Ein Schlüssel, eine Methode (XOR mit One-Time-Pad) und zwei Methoden, zwei Schlüssel (etwa ElGamal) sind dir wohl zu uncool?
Und der Algorithmus sollte dann berücksichtigen
- Vollen Wertevorrat
Das ergibt sich ja automatisch da man üblicherweise Verschlüsselungsverfahren haben will bei denen der Geheimtext nicht länger ist als der Klartext (von Ephemeralschlüsseln mal abgesehen).
- Veränderung der Sequenzlängen (mal 2, mal 7, mal 1 Schlüsselzeichen für dasselbe Original)
Security by Obscurity funktioniert nicht, abgesehen davon dass das eine Verländerung des Textes bewirken würde und damit in die Tonne gehört.
- Aufbruch von Grenzen (Wortlängen variabel, keine Strukturfestschreibung)
Hmm? Falsche Ebene, bzw. in
- Streuung / Verwürfelung der Häufigkeiten von der Normalverteilung einer Sprache
(also z.B. durch zweistufiges Schlüsselverfahren oder eben Domino)
enthalten.
Hello,
- Veränderung der Sequenzlängen (mal 2, mal 7, mal 1 Schlüsselzeichen für dasselbe Original)
Security by Obscurity funktioniert nicht, abgesehen davon dass das eine Verländerung des Textes bewirken würde und damit in die Tonne gehört.
Ich vermute mal, dass du hiermit Deine möglich Karriere als Kryptologe vorzeitig beendet hast.
Es geth doch bei der Verschlüsselung gerade nicht nur um die Übertragung mathematischer Verfahren, sondern um die Unterbindung der Entschlüsselungm und dies mit allen denkbaren Mitteln.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo Tom
Security by Obscurity funktioniert nicht, abgesehen davon dass das eine Verländerung des Textes bewirken würde und damit in die Tonne gehört.
Ich vermute mal, dass du hiermit Deine möglich Karriere als Kryptologe vorzeitig beendet hast.
Soweit mir bekannt ist, geht man bei der Kryptologie durchaus davon aus, dass der Verschlüsselungsalgorithmus bekannt ist. Deswegen gilt schon: "Security by Obscurity funktioniert nicht, ..."
Weiterhin ist es ein völlig normales Ziel, dass das Chiffrat (die verschlüsselte Nachricht) nicht oder nur unwesentlich umfangreicher ist, als der Klartext.
Bitte begründe Deine Vermutung, so dass ich es auch verstehe.
Es geth doch bei der Verschlüsselung gerade nicht nur um die Übertragung mathematischer Verfahren, sondern um die Unterbindung der Entschlüsselungm und dies mit allen denkbaren Mitteln.
Die Unbekanntheit des Verschlüsselungsverfahrens gehört nicht dazu :-)
Ganz gutes und meiner Meinung nach gut verständliches Material findet man bei CrypTool.
Freundliche Grüße
Vinzenz
Hello,
Soweit mir bekannt ist, geht man bei der Kryptologie durchaus davon aus, dass der Verschlüsselungsalgorithmus bekannt ist. Deswegen gilt schon: "Security by Obscurity funktioniert nicht, ..."
Ich habe auch nicht davon gesprochen, den Algorithmus nicht offenzulegen, sondern die Sequenzlängen zu ändern. Und man hat mir deshalb Obscurity unterstellt. Das hat mich dann dazu veranlasst, über die Erfolgsaussichten des Posters als Kryptologe nachzudenken.
Weiterhin ist es ein völlig normales Ziel, dass das Chiffrat (die verschlüsselte Nachricht) nicht oder nur unwesentlich umfangreicher ist, als der Klartext.
Hier sehe ich überhaupt keinen Zusammenhang. Das Ergebnis der Verschlüsselung kann sowohl kürzer, als auch länger ausfallen. Es gibt kein zwingendes Verbot, dass bei der Verschlüsselung nicht auch gepackt werden dürfte.
Die Unbekanntheit des Verschlüsselungsverfahrens gehört nicht dazu :-)
Davon habe ich auch nicht gesprochen, sondern nur von der Unbekanntheit der Länge einer Sequenz. Schließlich werden Zeichen nicht nur verschleirt (also eines durch ein anderes ersetzt), sondern verschlüsselt. Das einfachste effektive Prinzip hierfür ist das von mir benannte Domino-Prinzip. Andere Prinzipien verändern zusätzlich zu den internen Relationen zwischen den Zeichen einer Zeichenkette auch die Länge der Ersetzungssequenzen oder die Lage der Zeichen im ersetzten String.
Wenn Du Dich schon jemals selber damit auseinandergesetzt hast, wie man Verschlüsseln könnte und wie man das wieder "knacken" könnte kommst Du vielleicth auch mal auf neue Ideen. ;-))
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Moin,
Ich vermute mal, dass du hiermit Deine möglich Karriere als Kryptologe vorzeitig beendet hast.
Schätzchen, du solltest einem Gärtner nichts über's Bäumepflanzen erzählen. Einfach nur die Länge der Ausgabezeichen zu vergrößern bewirkt im besten Falle nichts, macht den Algorithmus aber im schlechtesten Fall unsicherer. Im klassischen Fall wo du für jedes Eingabezeichen ein Ausgabezeichen der gleichen Länge generierst muss die Abbildung notgedrungenermaßen so aussehen dass jedes mögliche Ausgabezeichen entstehen kann, und wenn der Algorithmus nicht vollkommen bekloppt ist sind die auch ordentlich gleichverteilt, d.h. für jedes mögliche Ausgabezeichen gibt es ein Eingabezeichen welches (einen passenden Schlüssel vorausgesetzt) dieses erzeugt.
Wenn du nun die Länge der Ausgabezeichen erhöhst gibt es zwei mögliche Fälle: a) Es sind jeweils nicht alle Ausgabezeichenkombinationen möglich, sondern nur soviele wie man vorher auch mit einem Zeichen hätte darstellen können. Dann sieht das zwar komplizierter aus, ist aber letztlich genauso kompliziert wie der normale Fall indem man sich einfach ein neues Alphabet definiert und deine merkwürdigen längereren Zeichen darauf abbildet. Das ist Security by Obscurity: es sieht irre kompliziert aus, wenn man den Algorithmus aber nicht geheimhält fällt es ganz schnell auf den normalen Fall zusammen.
b) Es gibt mehr Ausgabezeichenkombinationen als Eingabezeichen. Dann gibt es offensichtlich Ausgabezeichenkombinationen die nur von einer oder wenigen Eingabezeichen/Schlüsselkombination erzeugt werden können -> diese sind besonders schwach und können leichter zurückgerechnet werden.
Es gibt zwar Möglichkeiten wie man durch Verlängerung der Ausgabe die Sicherheit erhöhen kannst, aber das geht nicht durch plumpes Aufblasen der Zeichenlänge. Denkbar wäre etwa jedes Eingabezeichen [latex]x[/latex] auf [latex]X_1 || X_2[/latex] mit [latex]X_1 = r \wedge K_1, X_2 = r \wedge K_2 \wedge x[/latex], [latex]r[/latex] zufällig abzubilden ([latex]K_1[/latex] und [latex]K_2[/latex] sind jeweils Schlüsselzeichen, die zum Beispiel zu einer Stromchiffre gehören). Das kann unter Umständen schwieriger zu brechen sein als einfaches [latex]x \wedge K_2[/latex] (bin mir noch nicht ganz sicher) aber wenn dem so ist, dann sollte man offensichtlich bei jedem Eingabezeichen die längere Form nehmen, weil man sonst bei allen Zeichen wo man das nicht tut etwas Sicherheit 'verschenkt'.
Es geth doch bei der Verschlüsselung gerade nicht nur um die Übertragung mathematischer Verfahren, sondern um die Unterbindung der Entschlüsselungm und dies mit allen denkbaren Mitteln.
Ja, und die Chiffre versehentlich schwächer zu machen mag zwar ein denkbares Mittel sein, sicher aber kein geeignetes.
Moin,
ich war jetzt etwas faul mir die antwort hier genau durchzulesen, aber
ich hatte schonmal ähnliches "problem". So hab ich es gelöst.
Danke für deine Mühe, aber solchen Code kann ich hier nicht unkommentiert stehen lassen. Das Fragment ist etwas merkwürdig, riecht aber nach einer Caesar-Chiffre, eine Sonderform einer monoalphabetischen Substitution. Davon sollte man vor allem eines halten: Abstand. Dabei bleibt die Struktur der Eingabe erhalten, so dass man selbst im allgemeinen Fall sehr leicht über die Zeichenhäufigkeiten den Schlüssel erraten kann (sowas findet man auch manchmal als Rätsel in der Zeitung, neben dem "Farbe mit 3 Buchstaben"-Kreuzworträtsel).
Speziell bei der Caesar-Chiffre fängt man sich noch zusätzlich das Problem, dass man selbst ohne Computer und per Hand alle möglichen Schlüssel in kurzer Zeit durchprobiert hat.
Zum Code:
$Text = $_POST['text'];
$lang = strlen($Text);
$TextteilCode = false;
echo "Text: $Text<br>";
for ($z=0; $z<$lang; $z++)
{
$Textteil = substr($Text, $z);
$Textteil = ord($Textteil);
$Code = "~";
$Code = ord($Code);
$TextteilCode[$z] = $Textteil+$Code;
}
Diese Schleife soll offenbar einen Schlüssel auf den Zeichenwert aller Buchstaben im Text aufaddieren. Das müsste aber so in moderneren PHP-Versionen mindestens eine Warnung produzieren, weil $TextteilCode als Boolean initialisiert aber später als Array angesprochen wird. Auf jeden Fall ist es äusserst schlechter Stil. Auch ist es unnötig langsam, wenn man substr() benutzt, um einzelne Zeichen rauszupicken. Die »$Code = "~"; $Code = ord($Code);«-Zeilen sind weitgehend überflüssig, zumal sie nicht dem Verständnis dienen.
Die gesamte Schleife oben lässt sich eindampfen zu
~~~php
$TextteilCode = Array();
for($=0; $z<$lang; $z++) {
$TextteilCode[$z] = $Text{$z} + 126;
}
if ($TextteilCode <> false)
{
$anzahl = count($TextteilCode);
$TextCodiert ="";
Beim if sollte man jetzt besser auf »count($TextteilCode) > 0« prüfen.
> ~~~php
> for ($z=0; $z<$anzahl; $z++)
> {
> $TextCodiert .= $TextteilCode[$z];
> }
> echo "Textgewandelt: $TextCodiert<br>";
>
Das gibt zwar eine schöne Ausgabe, bringt aber nicht so viel da der ausgegebene Text nicht weiter verarbeitet wird. Sinnvoll im Rahmen des verbreiteten Algorithmus wäre zum Beispiel sowas wie
for($z=0; $z<$anzahl; $z++) {
$TextCodiert .= chr($TextteilCode[$z] % 256);
}
(was man natürlich gleich mit der obigen Schleife zusammenzieht)
$TextDecode = "";
for ($z=0; $z<$anzahl; $z++)
{
$Textteil = $TextteilCode[$z];
$Code = "~";
$Code = ord($Code);
$Decoded = $Textteil - $Code;
$Decoded = chr($Decoded);
$TextDecode .= $Decoded;
}// for ($z=0; $z<$anzahl; $z++)
Hier gilt das gleiche wie oben (in der Form unnötig komplex, »$TextDecode .= chr($TextteilCode[$z] - 126);« würde reichen), bzw. mit der veränderten Form:
~~~php
$TextDecode = "";
for($z=0; $<$anzahl; $z++) {
$TextDecode .= chr( (ord($TextCodiert{$z}) + 256 - 126) % 256 );
}
Die %256 sorgt in den beiden Fällen übrigens dafür dass die entstehenden Zeichencodes innerhalb des gültigen 8-Bit-Bereichs bleiben.
echo "Decodiert: $TextDecode";
}// if ($TextteilCode <> false)
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! <http://www.heise.de/ct/cd-register/> ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
Hi,
Ich weis das der code nicht perfekt ist, war auch die alte
version. In der schon lngst existierenden version hab ich vieles
der vorschläge die du gebracht hast schon drin. wenn du im
Archiv etwas suchst (meine März/April) dann findest du den
thread sicher und weist wie in etwa der neue Code aussieht. Jo
das ist Caesar-Chiffre die wohl einfachste Codier-Methode die
auch am einfachsten decodiert werden kann.
Wenn man sich aber noch etwas geschickter anstellt dann kann man
den Code auch mit dieser methode schwerer knackbar machen indem
man $Code z.B. =168 setzt und dann beim 2ten durchlauf auf 170
dann im dritten auf 173 im vierten 177 etc. etc.
Ich weis das es nicht perfekt ist, aber es funktioniert und läßt
sich wieder eindeutig decodieren im gegensatz zu md5().
MfG
Moin,
Wenn man sich aber noch etwas geschickter anstellt dann kann man
den Code auch mit dieser methode schwerer knackbar machen indem
man $Code z.B. =168 setzt und dann beim 2ten durchlauf auf 170
dann im dritten auf 173 im vierten 177 etc. etc.
Nope, das ist _nicht_ sicherer. Der Schlüssel ist weiterhin nur eine einzige Zahl (168). Der Angreifer zieht einfach von der zweiten Zahl 2 ab, von der dritten 3 usw. und erhält dann den gleichen Geheimtext wie in der einfachen Variante mit den selben Angriffsmöglichkeiten.
Was einen Gewinn an Sicherheit ausmachen würde wäre eine ordentliche de-Vigenere-Verschlüsselung wo man ein ganzes Schlüsselwort benutzt (etwa "hallo" , entsprechend 104, 97, 108, 108 und 111) und dann auf das erste Zeichen der Eingabe die erste Zahl addiert, auf das zweite Zeichen die zweite Zahl usw. Der Schlüssel ist dadurch länger was eine Brute-Force-Attacke schwieriger macht, und zumindest die offensichtliche Struktur des Geheimtextes wird zerstört. Sehr viel sicherer ist das aber auch nicht, da der Schlüssel wiederholt werden muss: Der Angreifer nimmt sich einfach Zeichen die mit der ersten Zahl verschlüsselt wurde, alle mit der zweiten Zahl etc. und macht dann den gleichen statistischen Angriff wie vorher bei Caesar.
Hallo Henryk
Was einen Gewinn an Sicherheit ausmachen würde wäre eine ordentliche de-Vigenere-Verschlüsselung wo man ein ganzes Schlüsselwort benutzt [...]. Sehr viel sicherer ist das aber auch nicht, da der Schlüssel wiederholt werden muss:
Es sei denn, der Schlüssel ist so lang wie der Klartext. Dann nicht.
Ist natürlich nicht sonderlich praktikabel, aber durchaus denkbar. Buchkapitel bieten sich an. Man muss nur - wie in ähnlich gelagerten Fällen - dafür sorgen, dass die Auswahl des Schlüssels sicher übermittelt werden kann.
Freundliche Grüße
Vinzenz
Moin,
Es sei denn, der Schlüssel ist so lang wie der Klartext. Dann nicht.
Ja, klar.
Ist natürlich nicht sonderlich praktikabel, aber durchaus denkbar. Buchkapitel bieten sich an. Man muss nur - wie in ähnlich gelagerten Fällen - dafür sorgen, dass die Auswahl des Schlüssels sicher übermittelt werden kann.
Nicht wirklich, Ausschnitte eines veröffentlichten Buches sind wieder sehr schlechte Beispiele. Wenn dann sollte der Schlüssel zufällig (kryptographisch starker Zufall) sein. Ansonsten hat der Schlüssel wieder nette statistische Eigenschaften die einen Angriff erleichtern, bzw. im schlimmsten Fall known-plaintext-Attacken sehr erfolgversprechend machen. (Wenn man den Geheimtext hat und einen Teil des Klartextes kann man einen Teil des Schlüssels rekonstruieren. Damit geht man dann in die Bibliothek/zu Google und findet den Rest des Buches.)
Hallo Henryk
Nicht wirklich, Ausschnitte eines veröffentlichten Buches sind wieder sehr schlechte Beispiele.
War in alter Zeit durchaus praktikabel ;-)
im schlimmsten Fall known-plaintext-Attacken sehr erfolgversprechend machen. (Wenn man den Geheimtext hat und einen Teil des Klartextes kann man einen Teil des Schlüssels rekonstruieren. Damit geht man dann in die Bibliothek/zu Google und findet den Rest des Buches.)
Klar, was ich vergessen hatte zu erwähnen: Jeder Schlüssel wird nur einmal verwendet (One-time-pad). Somit sind known-plaintext-Attacken zum Scheitern verurteilt.
Buchkapitel fallen selbstverständlich unter Katalogangriffe und sind deswegen als unsicher zu betrachten.
Freundliche Grüße
Vinzenz
Hi,
Was bei dieser verschlüsselung rauskommt ist ja eine endlos lange zahl,
145789654412357415675135795462113253576632154478925213
zum beispiel. diese könnte man dann in eine hex-Zahl umwandeln das wäre:
F1AFAC93DF4CE663
dann holt man sich den aktuellen timestamp im pronzip auch eine lange
zahl. wandelt diese in eine hexzahl, dreht sie z.b. noch um (spiegeln)
und setzt sie vorne oder hintendrann. dann muss man nurnoch den timstamp
seperat irgendwie speichern damit man den text korrekt entschlüsseln
kann.
MfG